Finalizer deadlock

[Bryce McKinlay]

Gladish, Jacob wrote:

>This was proposed about two months ago:
>
>  
>
>>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
>>
>>    
>>
>
>
>Is this that case? The two threads are deadlocked. The finalizer is
>waiting for a monitor on the PlainSocketImpl. The internal data
>structures indicate that the second thread holds the mutex, but I don't
>see how that could be. The second thread is stuck waiting on the
>finalizer monitor. Could the bug you described somehow manifest itself
>into this state? I'm running with hash-sync off.
>  
>
What version of GCJ is this? This bug should be fixed by this patch:

http://gcc.gnu.org/ml/java/2004-07/msg00080.html

The finalizer thread should now not be holding any locks when 
_Jv_Runfinalizers is called. The patch is also in 3.4.2.

Regards

Bryce