Finalizer deadlock

Wed Sep 8 20:37:00 GMT 2004

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