Bug 902004 - very bad performance with E-Porto Add-In für OpenOffice Writer installed
very bad performance with E-Porto Add-In für OpenOffice Writer installed
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: java-1.7.0-openjdk (Show other bugs)
18
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Adam Domurad
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-20 07:33 EST by Frank Büttner
Modified: 2013-05-09 05:25 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-09 05:23:55 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Frank Büttner 2013-01-20 07:33:37 EST
Description of problem:
When I open an file for example an calc or an impress document,
the application will not be usable, because it will freeze for 3 second after every operation. The will happens with local files and files on an samba share.
Other application don't show this behave.

Version-Release number of selected component (if applicable):
libreoffice-impress-3.6.3.2-8.fc18.x86_64

How reproducible:


Steps to Reproduce:
1. open an document
2. click on an menu in libre office

Actual results:
After every task the application will freeze for 3 seconds.

Expected results:
Working application.

Additional info:
The system was upgraded from FC17 to FC18 via fedup.
Comment 1 Caolan McNamara 2013-01-23 11:39:46 EST
"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.
Comment 2 Frank Büttner 2013-01-24 11:31:41 EST
-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"'
Comment 3 Frank Büttner 2013-02-09 05:59:22 EST
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.
Comment 4 Caolan McNamara 2013-02-11 09:54:05 EST
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.
Comment 5 Stephan Bergmann 2013-02-21 09:22:43 EST
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?
Comment 6 Andrew Haley 2013-02-21 11:09:10 EST
(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.
Comment 7 Andrew Haley 2013-02-21 11:26:21 EST
(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.
Comment 8 Stephan Bergmann 2013-02-22 05:58:50 EST
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?
Comment 9 Andrew Haley 2013-02-22 07:12:44 EST
(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.
Comment 11 Stephan Bergmann 2013-02-25 06:06:13 EST
(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.
Comment 12 Adam Domurad 2013-03-18 10:41:32 EDT
Hi, with which Java releases/RPMs exactly is the problem experienced?
Comment 13 Frank Büttner 2013-03-18 12:51:45 EDT
It is java-1.7.0-openjdk-1.7.0.9-2.3.8.0.fc18.x86_64
Comment 14 Adam Domurad 2013-05-08 12:13:17 EDT
This will be fixed in next release.

Thanks.
Comment 15 jiri vanek 2013-05-09 05:23:55 EDT
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

Note You need to log in before you can comment on or make changes to this bug.