[Libreoffice] Trying to diagnose base running extremely slowly

[Stephan Bergmann]

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
>>>> things.
>>>
>>> Good catch ! The irony ... :-) this Java bug was kindly fixed for us
>>> indirectly via Andrew Haley to address the bad stack page left around
>>> when
>>> we had run some java. That page was causing crashes in calc formula
>>> computation
>>> 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, 
dedicated thread.

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 
<https://bugzilla.redhat.com/show_bug.cgi?id=661738#c0>.

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 
(com.sun.star.comp.sdbc.ado.ODriver).

Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: affinejdbc.patch
Type: text/x-patch
Size: 2255 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20120112/71effae2/attachment.bin>