OOo Performance?

[Andrew Overholt]

Is this true:

 "In OpenOffice.org, for instance, Java-based features such as the basic
 document wizards open so slowly that you may conclude that the program has
 frozen before anything happens."

?

http://www.linux.com/article.pl?sid=06/03/08/2321254

Andrew

[Fernando Lozano]

Hi Andrew,

> Is this true ?
>  "In OpenOffice.org, for instance, Java-based features such as the basic
>  document wizards open so slowly that you may conclude that the program has
>  frozen before anything happens."
>
> http://www.linux.com/article.pl?sid=06/03/08/2321254
>   
>  
I found that also very strange:

>  Other new software available in FC5 includes (...) Ruby, the popular
>  programming language, which replaces FC5's GCC-based Java applications
>  if installed. 
How come can Ruby replace GCC-Based Java applications? I hever heard of
Ruby being able to run bytecodes. ;-)


[]s, Fernando Lozano

[Caolán McNamara]

On Wed, 2006-03-15 at 13:06 -0500, Andrew Overholt wrote:
>  Is this true:
>  
>   "In OpenOffice.org, for instance, Java-based features such as the basic
>   document wizards open so slowly that you may conclude that the program has
>   frozen before anything happens."
>  
>  ?
>  
>  http://www.linux.com/article.pl?sid=06/03/08/2321254
>  
>  Andrew 
To test this wizard start-up time: File->wizards->letter.

It's possible to select a different jvm to be used by OOo with
tools->options->openoffice.org->java, so if someone has gcj as well as
sun java installed, they can do a comparison of how long it takes for
the wizards to appear using the two different versions on an otherwise
equal installation.

I don't have the two here, but from memory starting the wizards under
sun java was never particularly snappy either.

C.

[Andrew Haley]

Fernando Lozano writes:
>  
>  >Is this true ?
>  > "In OpenOffice.org, for instance, Java-based features such as the basic
>  > document wizards open so slowly that you may conclude that the program has
>  > frozen before anything happens."
>  >
>  >http://www.linux.com/article.pl?sid=06/03/08/2321254
>  
>  I found that also very strange:
>  
>  > Other new software available in FC5 includes (...) Ruby, the popular
>  > programming language, which replaces FC5's GCC-based Java applications
>  > if installed.
>  
>  How come can Ruby replace GCC-Based Java applications? I hever heard of
>  Ruby being able to run bytecodes. ;-) 
Someone is confused.

Andrew.

[Mark Wielaard]

On Wed, 2006-03-15 at 20:44 +0000, Caolan McNamara wrote:
>  On Wed, 2006-03-15 at 13:06 -0500, Andrew Overholt wrote:
>  > Is this true:
>  > 
>  >  "In OpenOffice.org, for instance, Java-based features such as the basic
>  >  document wizards open so slowly that you may conclude that the program has
>  >  frozen before anything happens."
>  > 
>  > ?
>  > 
>  > http://www.linux.com/article.pl?sid=06/03/08/2321254
>  > 
>  > Andrew
>  
>  To test this wizard start-up time: File->wizards->letter. 
The first time you use an wizard is indeed pretty slow, it sits there
eating up 100% CPU for a couple of seconds (at least on my
Debian/unstable box, I cannot get ooffice from FC5/rawhide to work
unfortunately. It seems stuck in the splash screen according to gdb
somewhere in reading the font cache). But after that using the wizards
works just fine.

What was the magic oprofile incantation again to get a useful report
about what is happening on the system?

Cheers,

Mark

[Caolán McNamara]

On Thu, 2006-03-16 at 11:50 +0100, Mark Wielaard wrote:
>  On Wed, 2006-03-15 at 20:44 +0000, Caolan McNamara wrote:
>  > To test this wizard start-up time: File->wizards->letter.
>  
>  The first time you use an wizard is indeed pretty slow, it sits there
>  eating up 100% CPU for a couple of seconds (at least on my
>  Debian/unstable box,  
Yeah, there's no argument that it does that, I just think it does pretty
much the same thing with sun java that it does with gcj. On your debian
box what's the java being used by OOo ?, quite probably gcj as well.

>  I cannot get ooffice from FC5/rawhide to work
>  unfortunately. It seems stuck in the splash screen according to gdb
>  somewhere in reading the font cache). But after that using the wizards
>  works just fine. 
I'm a bit bewildered here :-), how can using the wizards of the redhat
build work just fine if you couldn't get the rh ooffice to work at all ?

C.

[Mark Wielaard]

Hi Caolan,

On Thu, 2006-03-16 at 11:03 +0000, Caolan McNamara wrote:
>  On Thu, 2006-03-16 at 11:50 +0100, Mark Wielaard wrote:
>  > The first time you use an wizard is indeed pretty slow, it sits there
>  > eating up 100% CPU for a couple of seconds (at least on my
>  > Debian/unstable box, 
>  
>  Yeah, there's no argument that it does that, I just think it does pretty
>  much the same thing with sun java that it does with gcj. On your debian
>  box what's the java being used by OOo ?, quite probably gcj as well. 
Yes it uses gcj.

>  > I cannot get ooffice from FC5/rawhide to work
>  > unfortunately. It seems stuck in the splash screen according to gdb
>  > somewhere in reading the font cache). But after that using the wizards
>  > works just fine.
>  
>  I'm a bit bewildered here :-), how can using the wizards of the redhat
>  build work just fine if you couldn't get the rh ooffice to work at all ? 
Sorry for being confusing. I meant on Debian of course. (Sorry still a
Debian junky.) On Fedora FC5/Rawhide latest yum update thing, openoffice
never fully starts up for me. On Debian after the first use of the
wizard (which takes a couple of seconds) all other uses of the wizards
seems without any noticeable delays.

Cheers,

Mark

-- 
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html

Join the community at http://planet.classpath.org/

[Caolán McNamara]

On Thu, 2006-03-16 at 12:10 +0100, Mark Wielaard wrote:
>  Sorry for being confusing. I meant on Debian of course. (Sorry still
> a
>  Debian junky.) On Fedora FC5/Rawhide latest yum update thing, openoffice
>  never fully starts up for me.  
Log a bug please, I've gotten no reports of stuff like that :-(.
Attaching your ~/.openoffice.org2.0/user/psprint/pspfontcache to your
bugreport if you have one might help me, deleting it afterwards might
help you.

C.

[Andrew Haley]

Mark Wielaard writes:
>  On Wed, 2006-03-15 at 20:44 +0000, Caolan McNamara wrote:
>  > On Wed, 2006-03-15 at 13:06 -0500, Andrew Overholt wrote:
>  > > Is this true:
>  > > 
>  > >  "In OpenOffice.org, for instance, Java-based features such as the basic
>  > >  document wizards open so slowly that you may conclude that the program has
>  > >  frozen before anything happens."
>  > > 
>  > > ?
>  > > 
>  > > http://www.linux.com/article.pl?sid=06/03/08/2321254 
I wonder what sort of machine he was using.

>  > 
>  > To test this wizard start-up time: File->wizards->letter.
>  
>  The first time you use an wizard is indeed pretty slow, it sits there
>  eating up 100% CPU for a couple of seconds (at least on my
>  Debian/unstable box, I cannot get ooffice from FC5/rawhide to work
>  unfortunately. It seems stuck in the splash screen according to gdb
>  somewhere in reading the font cache). But after that using the wizards
>  works just fine.
>  
>  What was the magic oprofile incantation again to get a useful report
>  about what is happening on the system? 
Here you are:

samples  cum. samples  %        cum. %     image name               app name              
  symbol name
26745    26745         22.6147  22.6147    ld-2.3.90.so             ld-2.3.90.so          
  do_lookup_x
19998    46743         16.9096  39.5243    no-vmlinux               no-vmlinux            
  (no symbols)
12112    58855         10.2415  49.7658    ld-2.3.90.so             ld-2.3.90.so          
  strcmp
6050     64905          5.1157  54.8815    libuno_cppuhelpergcc3.so.3
libuno_cppuhelpergcc3.so.3 (no symbols)
5395     70300          4.5618  59.4433    libgcj.so.7.0.0          libgcj.so.7.0.0       
  GC_mark_from
5232     75532          4.4240  63.8673    libuno_sal.so.3          libuno_sal.so.3       
  (no symbols)
2224     77756          1.8805  65.7478    configmgr2.uno.so        configmgr2.uno.so     
  (no symbols)
1663     79419          1.4062  67.1540    libgcj.so.7.0.0          libgcj.so.7.0.0       
  GC_add_to_black_list_normal
1567     80986          1.3250  68.4790    libuno_cppu.so.3         libuno_cppu.so.3      
  (no symbols)
1444     82430          1.2210  69.7000    libtk680li.so            libtk680li.so         
  (no symbols)
1267     83697          1.0713  70.7713    libgcj.so.7.0.0          libgcj.so.7.0.0       
  __i686.get_pc_thunk.bx
1158     84855          0.9792  71.7505    libpthread-2.3.90.so     libpthread-2.3.90.so  
  pthread_mutex_lock
1081     85936          0.9141  72.6645    libvcl680li.so           libvcl680li.so        
  (no symbols)
1066     87002          0.9014  73.5659    libcrypto.so.0.9.8a      libcrypto.so.0.9.8a   
  (no symbols)
1019     88021          0.8616  74.4276    libpthread-2.3.90.so     libpthread-2.3.90.so  
  pthread_mutex_unlock
876      88897          0.7407  75.1683    libgcj.so.7.0.0          libgcj.so.7.0.0       
  _Jv_InterpMethod::run(void*, ffi_raw*, _Jv_InterpMethod*)
849      89746          0.7179  75.8862    libgcj.so.7.0.0          libgcj.so.7.0.0       
  .plt
829      90575          0.7010  76.5871    libgcj.so.7.0.0          libgcj.so.7.0.0       
  GC_find_start
741      91316          0.6266  77.2137    libgcc_s-4.1.0-20060304.so.1
libgcc_s-4.1.0-20060304.so.1 _Unwind_IteratePhdrCallback
643      91959          0.5437  77.7574    libsw680li.so            libsw680li.so         
  (no symbols)
634      92593          0.5361  78.2935    libgcc_s-4.1.0-20060304.so.1
libgcc_s-4.1.0-20060304.so.1 execute_cfa_program

So, this is caused by the dynamic loading of the libgcj runtime
environment, which is why it takes a long time the first time you use
it.  

After that, however, it seems reasonably quick.

This speed will be much improved once we get rid of some of the relocs
in libgcj.

Andrew.

[Andrew Haley]

Here are the profile data without any symbols.  As you can see, it's
mostly the shared library loader.

Andrew.


  samples|      %|
------------------
    40035 33.8522 ld-2.3.90.so
    20462 17.3020 libgcj.so.7.0.0
    19998 16.9096 no-vmlinux
     6050  5.1157 libuno_cppuhelpergcc3.so.3
     5232  4.4240 libuno_sal.so.3
     3769  3.1869 libc-2.3.90.so
     2623  2.2179 libgcc_s-4.1.0-20060304.so.1
     2492  2.1072 libpthread-2.3.90.so
     2224  1.8805 configmgr2.uno.so
     1567  1.3250 libuno_cppu.so.3
     1444  1.2210 libtk680li.so
     1081  0.9141 libvcl680li.so
     1066  0.9014 libcrypto.so.0.9.8a
      753  0.6367 libc-2.3.90.so
      643  0.5437 libsw680li.so
      527  0.4456 libtl680li.so
      407  0.3441 libz.so.1.2.3
      381  0.3222 libstore.so.3
      368  0.3112 libcomphelp4gcc3.so
      358  0.3027 libsvl680li.so
      354  0.2993 libcairo.so.2.2.3
      337  0.2850 libxo680li.so
      335  0.2833 oprofiled
      295  0.2494 libcairo.so.2.2.3
      266  0.2249 libfilterconfig1.so
      254  0.2148 libjava_uno.so
      244  0.2063 libucpfile1.so
      232  0.1962 soffice.bin

[Andrew Haley]

Andrew Haley writes:
>  Mark Wielaard writes:
>   > On Wed, 2006-03-15 at 20:44 +0000, Caolan McNamara wrote:
>   > > On Wed, 2006-03-15 at 13:06 -0500, Andrew Overholt wrote:
>   > > > Is this true:
>   > > > 
>   > > >  "In OpenOffice.org, for instance, Java-based features such as the
> basic
>   > > >  document wizards open so slowly that you may conclude that the program
> has
>   > > >  frozen before anything happens."
>   > > > 
>   > > > ?
>   > > > 
>   > > > http://www.linux.com/article.pl?sid=06/03/08/2321254
>  
>  I wonder what sort of machine he was using.
>  
>   > > 
>   > > To test this wizard start-up time: File->wizards->letter.
>   > 
>   > The first time you use an wizard is indeed pretty slow, it sits there
>   > eating up 100% CPU for a couple of seconds (at least on my
>   > Debian/unstable box, I cannot get ooffice from FC5/rawhide to work
>   > unfortunately. It seems stuck in the splash screen according to gdb
>   > somewhere in reading the font cache). But after that using the wizards
>   > works just fine.
>   > 
>   > What was the magic oprofile incantation again to get a useful report
>   > about what is happening on the system?
>  
>  Here you are: 
Subsequent runs look like this, with libgcj only consuming 14% of CPU time:

samples  cum. samples  %        cum. %     image name               app name              
  symbol name
9119     9119          22.7582  22.7582    no-vmlinux               no-vmlinux            
  (no symbols)
5738     14857         14.3203  37.0785    libuno_cppuhelpergcc3.so.3
libuno_cppuhelpergcc3.so.3 (no symbols)
4196     19053         10.4719  47.5505    libuno_sal.so.3          libuno_sal.so.3       
  (no symbols)
1450     20503          3.6188  51.1692    libtk680li.so            libtk680li.so         
  (no symbols)
1115     21618          2.7827  53.9519    libuno_cppu.so.3         libuno_cppu.so.3      
  (no symbols)
903      22521          2.2536  56.2055    libgcj.so.7.0.0          libgcj.so.7.0.0       
  GC_mark_from
899      23420          2.2436  58.4492    libpthread-2.3.90.so     libpthread-2.3.90.so  
  pthread_mutex_lock
867      24287          2.1638  60.6129    libvcl680li.so           libvcl680li.so        
  (no symbols)
822      25109          2.0515  62.6644    libgcj.so.7.0.0          libgcj.so.7.0.0       
  _Jv_InterpMethod::run(void*, ffi_raw*, _Jv_InterpMethod*)
798      25907          1.9916  64.6560    libpthread-2.3.90.so     libpthread-2.3.90.so  
  pthread_mutex_unlock
556      26463          1.3876  66.0436    libsw680li.so            libsw680li.so         
  (no symbols)
518      26981          1.2928  67.3363    libcrypto.so.0.9.8a      libcrypto.so.0.9.8a   
  (no symbols)
381      27362          0.9509  68.2872    libgcc_s-4.1.0-20060304.so.1
libgcc_s-4.1.0-20060304.so.1 _Unwind_IteratePhdrCallback
355      27717          0.8860  69.1732    libtl680li.so            libtl680li.so         
  (no symbols)
340      28057          0.8485  70.0217    libgcc_s-4.1.0-20060304.so.1
libgcc_s-4.1.0-20060304.so.1 execute_cfa_program
330      28387          0.8236  70.8453    libc-2.3.90.so           libc-2.3.90.so        
  memcpy

  samples|      %|
------------------
     9119 22.7582 no-vmlinux
     5738 14.3203 libuno_cppuhelpergcc3.so.3
     5683 14.1830 libgcj.so.7.0.0
     4196 10.4719 libuno_sal.so.3
     1897  4.7343 libpthread-2.3.90.so
     1762  4.3974 libc-2.3.90.so
     1475  3.6812 libgcc_s-4.1.0-20060304.so.1

Andrew.

[Caolán McNamara]

On Thu, 2006-03-16 at 11:42 +0000, Andrew Haley wrote:
>  Here are the profile data without any symbols.  As you can see,
> it's
>  mostly the shared library loader. 
Nearly all of OOo's startup and timing woes boil down to shared library
relocations :-(. Hence the redhat custom swriter/scalc/sdraw
prelink-friendly launchers, and the novell -Bdirect work. Not much we
can do inside OOo to help such dlopened stuff I guess.

C.

[Mark Wielaard]

On Thu, 2006-03-16 at 11:23 +0000, Caolan McNamara wrote:
>  On Thu, 2006-03-16 at 12:10 +0100, Mark Wielaard wrote:
>  > Sorry for being confusing. I meant on Debian of course. (Sorry still a
>  > Debian junky.) On Fedora FC5/Rawhide latest yum update thing, openoffice
>  > never fully starts up for me. 
>  
>  Log a bug please, I've gotten no reports of stuff like that :-(.
>  Attaching your ~/.openoffice.org2.0/user/psprint/pspfontcache to your
>  bugreport if you have one might help me, deleting it afterwards might
>  help you. 
There you go:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185613
Without the pspfontcache file attached to that bug report ooffice starts
up fine. And it works as on my Debian box.

Thanks!

Mark

[Andrew Haley]

Caolan McNamara writes:
>  On Thu, 2006-03-16 at 11:42 +0000, Andrew Haley wrote:
>  > Here are the profile data without any symbols.  As you can see, it's
>  > mostly the shared library loader.
>  
>  Nearly all of OOo's startup and timing woes boil down to shared library
>  relocations :-(. Hence the redhat custom swriter/scalc/sdraw
>  prelink-friendly launchers, and the novell -Bdirect work. Not much we
>  can do inside OOo to help such dlopened stuff I guess. 
Does dlopened stuff not work with prelinking?

Anyway, the other interesting thing is the huge amount of _kernel_
time each time a wizard is used.  What on earth can this be?

Andrew.

[Caolán McNamara]

On Thu, 2006-03-16 at 13:36 +0000, Andrew Haley wrote:
>  Caolan McNamara writes:
>   > On Thu, 2006-03-16 at 11:42 +0000, Andrew Haley wrote:
>   > > Here are the profile data without any symbols.  As you can see, it's
>   > > mostly the shared library loader.
>   > 
>   > Nearly all of OOo's startup and timing woes boil down to shared library
>   > relocations :-(. Hence the redhat custom swriter/scalc/sdraw
>   > prelink-friendly launchers, and the novell -Bdirect work. Not much we
>   > can do inside OOo to help such dlopened stuff I guess.
>  
>  Does dlopened stuff not work with prelinking? 
No, from prelink/doc/prelink.tex

"
As has been mentioned earlier, prelink cannot speed up loading shared
libraries using dlopen, since it cannot predict in which order and what
shared libraries will be loaded (and thus cannot compute conflict
fixups).
"

>  Anyway, the other interesting thing is the huge amount of _kernel_
>  time each time a wizard is used.  What on earth can this be? 
To be honest the java stuff is really an edge-case in OOo performance,
and I don't think anyone has looked into it very seriously.

C.

[Andrew Haley]

Caolan McNamara writes:
>  On Thu, 2006-03-16 at 13:36 +0000, Andrew Haley wrote:
>  > Caolan McNamara writes:
>  >  > On Thu, 2006-03-16 at 11:42 +0000, Andrew Haley wrote:
>  >  > > Here are the profile data without any symbols.  As you can see, it's
>  >  > > mostly the shared library loader.
>  >  > 
>  >  > Nearly all of OOo's startup and timing woes boil down to shared library
>  >  > relocations :-(. Hence the redhat custom swriter/scalc/sdraw
>  >  > prelink-friendly launchers, and the novell -Bdirect work. Not much we
>  >  > can do inside OOo to help such dlopened stuff I guess.
>  > 
>  > Does dlopened stuff not work with prelinking?
>  
>  No, from prelink/doc/prelink.tex
>  
>  "
>  As has been mentioned earlier, prelink cannot speed up loading shared
>  libraries using dlopen, since it cannot predict in which order and what
>  shared libraries will be loaded (and thus cannot compute conflict
>  fixups).
>  " 
Mmm, but there's nothing to stop us building OOo with -lgcj, is there?
If we do that, dlopen() will find the prelinked library.

Andrew.

[Mark Wielaard]

On Wed, 2006-03-15 at 23:17 +0000, Andrew Haley wrote:
>   > >http://www.linux.com/article.pl?sid=06/03/08/2321254
>   > 
>   > I found that also very strange:
>   > 
>   > > Other new software available in FC5 includes (...) Ruby, the popular
>   > > programming language, which replaces FC5's GCC-based Java applications
>   > > if installed.
>   > 
>   > How come can Ruby replace GCC-Based Java applications? I hever heard of
>   > Ruby being able to run bytecodes. ;-)
>  
>  Someone is confused. 
I asked. And this was his response:

>  The point seems to have been lost in the editing.
>  
>  What I originally wrote was "which for some reason replaces FC5's
>  GCC-based Java applications." In other words, I was pointing out that,
>  if you install Ruby on FC5, yum removed the GCC stuff as if there was
>  a conflict, which seemed more than a little strange to me. 
So it was actually a bug report disguised as a news article. But he
hadn't counted on his editor making it even more obscure :)

Cheers,

Mark

[Andrew Overholt]

* Mark Wielaard <mark(a)klomp.org&gt; [2006-03-16 12:58]:
>  > What I originally wrote was "which for some reason replaces
> FC5's
>  > GCC-based Java applications." In other words, I was pointing out that,
>  > if you install Ruby on FC5, yum removed the GCC stuff as if there was
>  > a conflict, which seemed more than a little strange to me.
>  
>  So it was actually a bug report disguised as a news article. But he
>  hadn't counted on his editor making it even more obscure :) 
Weird.  I just tried yum install ruby and it didn't remove anything.

Andrew

[Caolán McNamara]

On Thu, 2006-03-16 at 14:16 +0000, Andrew Haley wrote:
>  Mmm, but there's nothing to stop us building OOo with -lgcj, is
> there?
>  If we do that, dlopen() will find the prelinked library. 
Was worth a shot, but we seem to hang if we just naively add in a
-lgcj :-)

C.

#1  0x00a19036 in __nanosleep_nocancel () from /lib/libc.so.6
#2  0x0248647b in GC_lock () from /usr/lib/libgcj.so.7
#3  0x0247d3ea in GC_malloc_atomic () from /usr/lib/libgcj.so.7
#4  0x01e50f22 in _Jv_AllocString () from /usr/lib/libgcj.so.7
#5  0x01e8e862 in _Jv_NewStringUtf8Const () from /usr/lib/libgcj.so.7
#6  0x01e61a6b in _Jv_Linker::ensure_class_linked ()
from /usr/lib/libgcj.so.7
#7  0x01e61c3e in _Jv_Linker::wait_for_state ()
from /usr/lib/libgcj.so.7
#8  0x01e88b31 in java::lang::Class::initializeClass ()
from /usr/lib/libgcj.so.7
#9  0x01e88ad3 in java::lang::Class::initializeClass ()
from /usr/lib/libgcj.so.7
#10 0x01e88ad3 in java::lang::Class::initializeClass ()
from /usr/lib/libgcj.so.7
#11 0x01e88ad3 in java::lang::Class::initializeClass ()
from /usr/lib/libgcj.so.7
#12 0x01e514e6 in _Jv_AllocObjectNoFinalizer ()
from /usr/lib/libgcj.so.7
#13 0x01e51526 in _Jv_AllocObject () from /usr/lib/libgcj.so.7
#14 0x01e516de in _Jv_ThrowBadArrayIndex () from /usr/lib/libgcj.so.7
#15 <signal handler called>
#16 0x024787d3 in GC_is_black_listed () from /usr/lib/libgcj.so.7
#17 0x0247679d in GC_allochblk_nth () from /usr/lib/libgcj.so.7
#18 0x02476b62 in GC_allochblk () from /usr/lib/libgcj.so.7
#19 0x0248209d in GC_new_hblk () from /usr/lib/libgcj.so.7
#20 0x02478381 in GC_allocobj () from /usr/lib/libgcj.so.7
#21 0x0247ce58 in GC_generic_malloc_inner () from /usr/lib/libgcj.so.7
#22 0x0247cef1 in GC_generic_malloc_inner_ignore_off_page ()
from /usr/lib/libgcj.so.7
#23 0x0247b0a7 in GC_grow_table () from /usr/lib/libgcj.so.7
#24 0x0247b8bc in GC_register_finalizer_inner ()
from /usr/lib/libgcj.so.7
#25 0x0247ba63 in GC_register_finalizer_no_order ()
from /usr/lib/libgcj.so.7
#26 0x01e9647d in _Jv_RegisterFinalizer () from /usr/lib/libgcj.so.7
#27 0x01e8e832 in _Jv_NewStringUtf8Const () from /usr/lib/libgcj.so.7
#28 0x01e61a6b in _Jv_Linker::ensure_class_linked ()
from /usr/lib/libgcj.so.7
#29 0x01e61c3e in _Jv_Linker::wait_for_state ()
from /usr/lib/libgcj.so.7
#30 0x01e88b31 in java::lang::Class::initializeClass ()
from /usr/lib/libgcj.so.7
#31 0x01e88ad3 in java::lang::Class::initializeClass ()
from /usr/lib/libgcj.so.7
#32 0x01e524a7 in _Jv_CreateJavaVM () from /usr/lib/libgcj.so.7
#33 0x01e57b2d in JNI_CreateJavaVM () from /usr/lib/libgcj.so.7
#34 0x05a6d864 in jfw_plugin_startJavaVirtualMachine ()
   from /usr/lib/openoffice.org2.0/program/sunjavaplugin.so

[Andrew Haley]

Caolan McNamara writes:
>  On Thu, 2006-03-16 at 14:16 +0000, Andrew Haley wrote:
>  > Mmm, but there's nothing to stop us building OOo with -lgcj, is there?
>  > If we do that, dlopen() will find the prelinked library.
>  
>  Was worth a shot, but we seem to hang if we just naively add in a
>  -lgcj :-) 
Ah.  Thanks for trying, anyway.

Andrew.