Bug 902004

"it will freeze for 3 second after every operation"

when you say "operation" what do you mean ?, can you give an example of something that freezes. e.g. a step-by-step guide to a sample freeze.

It appear appear fine here. So:
a) KDE or GNOME ?
b) output of gsettings get org.gnome.desktop.interface toolkit-accessibility
true
c) anything unusual about your setup, non-default theme, anything like that.

-click on an ods file to open it.
- now try to open an entry at the menue bar or click in an cell.
- you alway have an break for ca. 3 second.
What I have seen at top, is that the soffice.bin process eat 100% CPU when it is in "break" state.

Desktop: Gnome

gsettings get org.gnome.desktop.interface toolkit-accessibility will output "true"

No the only change I have made is:
/home/frank/.config/gtk-3.0/gtk.css
@binding-set KeinF10 {
        unbind "<shift>F10"
}
* {
        gtk-key-bindings: KeinF10
}

to disable F10 in the gnome terminal.
and
dconf write /org/gnome/shell/overrides/button-layout '":minimize,maximize,close"'

Some news about the problem.
After removing the "E-Porto Add-In für OpenOffice Writer" plug-in from the German post service, it runs much faster.

caolanm->sbergman: Can you check if this is a performance regression against any older version of if this is an unavoidable problem what that java extension and we can do nothing about it.

This is the result of three problems:

* For one, due to the design of the LO extension mechanisms, Java extensions may cause frequent JNI Attach/DetachCurrentThread calls, which are expensive with modern JVMs on Linux.  This is a known problem for LO (also plaguing its database access), but one for which there is unfortunately no quick and easy general fix.

* For another, having the "E-Porto Add-In für OpenOffice Writer" extension (<http://www.deutschepost.de/dpag?tab=1&skin=hi&check=yes&lang=de_DE&xmlFile=link1024674_1024525>) installed apparently causes lots of calls from LO core code to that extension's Java code, e.g., when accessing (unrelated) menus.  This is likely a deficiency of that extension, but hard to tell without access to its source code, let alone an address where to contact its developers.

* For a third, the performance of JNI Attach/DetachCurrentThread calls has degraded significantly again with recent versions of OpenJDK 1.7.0, see <http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-February/008588.html> "Re: get_stack_bounds using read(2) syscalls to read /proc/self/maps byte-by-byte."

Andrew, is there anything that can be done about that third item?

(In reply to comment #5)

> * For a third, the performance of JNI Attach/DetachCurrentThread calls has
> degraded significantly again with recent versions of OpenJDK 1.7.0, see
> <http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-February/008588.
> html> "Re: get_stack_bounds using read(2) syscalls to read /proc/self/maps
> byte-by-byte."
> 
> Andrew, is there anything that can be done about that third item?

Yes, absolutely.  The code I originally wrote used buffered input, and was efficient. Oracle rewrote it because of some utterly bogus reasoning about "not wanting one malloc/free cycle per line". This replacement code not only used unbuffered input, it also had two errors: one buffer overflow and one use of uninitialized memory.

The whole sorry saga is at
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-February/001864.html

The obvious fix is to use my original code.

(In reply to comment #6)
> (In reply to comment #5)
> 
> > * For a third, the performance of JNI Attach/DetachCurrentThread calls has
> > degraded significantly again with recent versions of OpenJDK 1.7.0, see
> > <http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-February/008588.
> > html> "Re: get_stack_bounds using read(2) syscalls to read /proc/self/maps
> > byte-by-byte."
> > 
> > Andrew, is there anything that can be done about that third item?
> 
> Yes, absolutely.  The code I originally wrote used buffered input, and was
> efficient. Oracle rewrote it because of some utterly bogus reasoning about
> "not wanting one malloc/free cycle per line". This replacement code not only
> used unbuffered input, it also had two errors: one buffer overflow and one
> use of uninitialized memory.
> 
> The whole sorry saga is at
> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-February/
> 001864.html
> 
> The obvious fix is to use my original code.

Alternatively, we could just rewrite os::get_line_chars in src/share/vm/runtime/os.cpp to do some buffering.

The whole pain OpenJDK has to go to in order to determine the main stack extents on Linux,

> // Locate initial thread stack. This special handling of initial thread stack
> // is needed because pthread_getattr_np() on most (all?) Linux distros returns
> // bogus value for initial thread.

[openjdk/hotspot/src/os/linux/vm/os_linux.cpp] makes one wonder whether glibc's pthread_getattr_np could not be fixed, so it could be called at least in known-good scenarios?  Interestingly, pthread_getattr_np itself is implemented in terms of reading /proc/self/map [nptl/pthread_getattr_np.c].


Another angle of attack that appeared to me is as follows:  Currently, when LO instantiates an in-process JVM, it calls DetachCurrentThread after a successful JNI_CreatJavaVM.  Then, whenever LO makes a JNI call from core C++ code to Java, it wraps that call in Attach/DetachCurrentThread (with recursive calls handled by calling GetEnv first and suppressing the Attach/DetachCurrentThread pair if that succeeds).  It is generally not possible to predict which thread will instantiate the JVM (and it is also not possible in general to predict larger time spans for which a thread will make JNI calls into the JVM, in order to wrap the whole time span in a single Attach/DetachCurrentThread pair).

However, in practice, it is most likely the main thread that instantiates the JVM.  Would there be any negative consequences if the instantiating thread would be kept attached to the JVM forever, by removing the call to DetachCurrentThread after a successful JNI_CreateJavaVM call?  (That way, in the common case where the main thread instantiates the JVM, we would avoid the performance problems caused by frequent Attach/DetachCurrentThread calls on the main thread.)  Would any negative consequences be different if the instantiating thread where the main thread or some other thread (that eventually terminates via pthread_exit)?  LO currently never calls DestroyJavaVM (and only ever instantiates a single JVM per process), and it currently terminates via calling exit, not by waiting until the last thread calls pthread_exit.  Would any negative consequences be different if any of that changed?

(In reply to comment #8)

> Would there be any negative consequences if the instantiating thread
> would be kept attached to the JVM forever, by removing the call to
> DetachCurrentThread after a successful JNI_CreateJavaVM call?

Yes, absolutely there would.  You'd be replicating the bug that caused
this in the first place.

Picture this scenario:

AttachCurrentThread.  Guard pages are now installed, stack size is
limited.  Do something with Java.  Leave thread attached.

Run big LibreOffice calc that requires a deep stack.  Stack hits
guard pages.  Segfault.

(In reply to comment #9)
> > Would there be any negative consequences if the instantiating thread
> > would be kept attached to the JVM forever, by removing the call to
> > DetachCurrentThread after a successful JNI_CreateJavaVM call?
> 
> Yes, absolutely there would.

...in which case, please take over to see whether performance can be improved on the JVM side.

Hi, with which Java releases/RPMs exactly is the problem experienced?

It is java-1.7.0-openjdk-1.7.0.9-2.3.8.0.fc18.x86_64

This will be fixed in next release.

Thanks.

This patch was added to rpms for f18-20 and built. However update will be proposed after all testing is done. But you can elaborate wit raw packages:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5340338
http://pkgs.fedoraproject.org/cgit/java-1.7.0-openjdk.git/commit/?h=f18&id=4b2ee957df6866ce6c919448ce9d0e19ed21d1b2