Re: hash synchronization on linux

[Bryce McKinlay <mckinlay at redhat dot com>]

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