hash synchronization on linux

Thu Jul 8 23:24:00 GMT 2004

Boehm, Hans wrote:
>The problem is in thread 8. I doubt it has been fixed,
>but I didn't check.
>>Basically we have
>>_Jv_MonitorEnter
>	acquires lock bit on lightweight lock entry
>	notices it needs to allocate heavyweight lock
>	calls eventually alloc_heavy.
>alloc_heavy call GC_local_gcj_malloc
>GC_local_gcj_malloc is out of free list entries AND
>	is first allocation to run since GC, which
>	results in a call to
>FinalizerThread.finalizerReady, which is currently
>	unrestricted Java code. It then calls
>_Jv_MonitorEnter
>	which tries to acquire the same lock table
>	entry it already owns ==>
>>deadlock
>>Is it hard to make FinalizerThread.finalizerReady a small piece
>of C++ code, which does not
>acquire Java locks, e.g. by just doing a pthread_cond_signal
>equivalent?
>>Yes, we could rewrite it using _Jv_CondWait/_Jv_CondNotify and other 
thread primitives defined in the thread headers.
I'm also not sure this peice of code in FinalizerThread is safe:
 public static void finalizerReady ()
 {
 synchronized (lock)
 {
 if (! thread_started)
 runFinalizers ();
Isn't there a race here? Unlikely to happen, perhaps, but it seems like 
if a finalizer needs to be run before the finalizer thread has finished 
starting, we'll try to run finalizers from the inside the GC's thread.
Regards
Bryce