[Libreoffice] Trying to diagnose base running extremely slowly
sbergman at redhat.com
Thu Jan 12 01:44:46 PST 2012
On 10/20/2011 09:08 AM, Stephan Bergmann wrote:
> On 10/19/2011 07:17 PM, Andrew Haley wrote:
>> On 10/19/2011 05:57 PM, Michael Meeks wrote:
>>> On Wed, 2011-10-19 at 17:32 +0200, Stephan Bergmann wrote:
>>>> What the LibO hsqldb code does a lot is call JNI's
>>>> Attach/DetachCurrentThread. Googling around,
>>>> <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067> "Stack
>>>> guard pages should be removed when thread is detached" suggests that
>>>> reading /proc/self/maps might have been added into
>>>> Attach/DetachCurrentThread as part of a bug fix. That would explain
>>> Good catch ! The irony ... :-) this Java bug was kindly fixed for us
>>> indirectly via Andrew Haley to address the bad stack page left around
>>> we had run some java. That page was causing crashes in calc formula
>>> in large sheets.
>>> It seems we can't win at some stage here. Andrew - I wonder are other
>>> people getting frustrated by performance here too ? it seems there is
>>> some huge /proc/self/maps thrash as we enter/exit Java now on Linux.
>> Hmmm, I thought this had been fixed.
>> See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6978641
> This might still hit us, if the LibO hsqldb code runs in the main thread
> (which I'm pretty sure it does). That code calls
> Attach/DetachCurrentThread frequently.
> I think the best solution here would be to change the LibO hsqldb code,
> to call Attach/DetachCurrentThread rarely rather than frequently, but
> according to Ocke Janssen (who used to maintain that code) that was no
> easy option.
One rather easy fix would be to confine the
com.sun.star.comp.sdbc.JDBCDriver UNO code to a thread-affine apartment,
see the attached patch. That way, all code related to this UNO service
(which is the code that calls Attach/DetachCurrentThread so frequently
and thus causes the performance degradation) is run in a single,
That thread is guaranteed not to be the main thread (as the
thread-affine apartment explicitly creates it), so JVM versions that
include the fix for
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6978641> "Fix for
6929067 introduces additional overhead in thread creation/termination
paths" (which significantly reduces the overhead of
Attach/DetachCurrentThread for all but the main thread again) should
return to an acceptable performance. Trying it out on Fedora 16, which
includes version 1.6.0_22 of OpenJDK, the patch noticeably improves
performance of the test scenario described at
One drawback of using the thread-affine apartment is that all code
related to the JDBC driver is effectively serialized, removing any
potential performance advantage from accessing the driver from multiple
treads. I do not know whether that is acceptable or not.
I did not find problems with using the thread-affine apartment, but then
again my Base skills are virtually non-existent, so this would probably
need some QA. However, there is also already another SDBC driver that
uses the thread-affine apartment, namely the Windows-specific ADO driver
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2255 bytes
Desc: not available
More information about the LibreOffice