RE: Kill a static constructor in boehm-gc

["Boehm, Hans" <hans_boehm at hp dot com>]

> From: Bryce McKinlay [mailto:bryce@waitaki.otago.ac.nz]
> I managed to track down the last static constructor that was causing 
> things like "LD_PRELOAD=libgcj.so.2 ls" to segfault. It was 
> GC_init_parallel in the GC's linux_threads.c. It looks like 
> it is there 
> to ensure thread safety for the initialization of thread-local 
> allocation, but it seems a bit dubious since it will be 
> called from the 
> GC's pthread_create wrapper anyway, and the first pthread_create call 
> will always be single-threaded, right?
It's really there mostly to prepare for allocation using thread-local free
lists.  This is potentially necessary since GC_local_malloc isn't
self-initializing the same way that GC_malloc is.  This code is invoked for
allocation even before you create a second thread.

I think it's unnecessary for gcj, since the collector is explicitly
initialized, and GC_init calls GC_init_parallel (as well as the other way
around).
> 
> With this patch LD_PROFILE=libgcj.so.2 finally doesn't crash! 
> This means 
> we can profile libgcj!! Well, nearly, since unfortunatly LD_PROFILE 
> doesn't understand virtual calls. I'm guessing this might be 
> easy to fix 
> however if RTH adds the generic stack unwind facility to GCC 
> that he was 
> talking about a while back?
Great!  I'd certainly love a real way to profile.
> 
> Even without virtual support the sprof output is quite interesting. 
> There seems to be a lot (5000+) of Hashtable.get calls for 
> Hello world, 
> for instance. And 1 more call to _Jv_MonitorEnter than 
> _Jv_MonitorExit? 
> hmm...
It would be nice to fix that, for several reasons.  Performance of hash
synchronization is fairly sensitive to the number of simultaneously held
locks.  Spuriously holding one all the time certainly isn't a disaster, but
...
> 
> Hans, what do you think of this patch?
I'm not sure I understand the original problem well enough.  My impression
is that it's fine for gcj, but causes a problem if you use the collector in
other contexts.

Perhaps the right thing is to go ahead and apply your patch, and to change
the documentation to suggest that GC_init should be called somehow, e.g.
from a constructor, if you use GC_local_malloc.

Hans