Finalizer deadlock

Wed Sep 8 20:45:00 GMT 2004

> -----Original Message-----
> From: Bryce McKinlay [mailto:mckinlay@redhat.com]
> Sent: Wednesday, September 08, 2004 4:37 PM
> To: Gladish, Jacob
> Cc: java@gcc.gnu.org
> Subject: Re: Finalizer deadlock
>> 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:
>
3.3.1
> 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