Re: [Libreoffice] Trying to diagnose base running extremely slowly

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

diff --git a/connectivity/source/drivers/jdbc/exports.dxp 
b/connectivity/source/drivers/jdbc/exports.dxp
index 7003307..f0e1c69 100755
--- a/connectivity/source/drivers/jdbc/exports.dxp
+++ b/connectivity/source/drivers/jdbc/exports.dxp
@@ -1 +1,2 @@
+component_getImplementationEnvironment
 component_getFactory
diff --git a/connectivity/source/drivers/jdbc/jservices.cxx 
b/connectivity/source/drivers/jdbc/jservices.cxx
index 59c73ff..85df771 100644
--- a/connectivity/source/drivers/jdbc/jservices.cxx
+++ b/connectivity/source/drivers/jdbc/jservices.cxx
@@ -83,7 +83,21 @@ struct ProviderRequest
     void* getProvider() const { return xRet.get(); }
 };
 
-//---------------------------------------------------------------------------------------
+extern "C" SAL_DLLPUBLIC_EXPORT void SAL_CALL
+component_getImplementationEnvironment(
+    char const ** ppEnvTypeName, uno_Environment **)
+{
+    // Recent Java 6 VMs make calls to JNI Attach/DetachCurrentThread (which
+    // this code does extensively) very expensive.  A follow-up JVM fix reduced
+    // the overhead significantly again for all threads but the main thread.  So
+    // a quick hack to improve performance of this component again is to confine
+    // it in the affine apartment (where all code will run on a single,
+    // dedicated thread that is guaranteed no to be the main thread).  However,
+    // a better fix would still be to redesign the code so that it does not call
+    // Attach/DetachCurrentThread so frequently:
+    *ppEnvTypeName = CPPU_CURRENT_LANGUAGE_BINDING_NAME ":affine";
+}
+
 extern "C" SAL_DLLPUBLIC_EXPORT void* SAL_CALL component_getFactory(
                     const sal_Char* pImplementationName,
                     void* pServiceManager,
diff --git a/connectivity/source/drivers/jdbc/makefile.mk 
b/connectivity/source/drivers/jdbc/makefile.mk
index befdc73..4229c8f 100755
--- a/connectivity/source/drivers/jdbc/makefile.mk
+++ b/connectivity/source/drivers/jdbc/makefile.mk
@@ -78,8 +78,6 @@ SLOFILES=\
         $(SLO)$/tools.obj                           \
         $(SLO)$/ContextClassLoader.obj
 
-SHL1VERSIONMAP=$(SOLARENV)/src/component.map
-
 # --- Library -----------------------------------
 
 SHL1TARGET=    $(JDBC_TARGET)$(DLLPOSTFIX)