Thread group disposal question
David Holmes - Sun Microsystems
David.Holmes at Sun.COM
Thu Aug 21 17:29:51 PDT 2008
Just in case it was unclear what Martin was referring to, an AppContext
has a ThreadGroup associated with it and when the AppContext is disposed
it tries to terminate all the threads in its ThreadGroup by calling
first Thread.interrupt() (safe) and then Thread.stop() (perilous).
The Thread.stop() is unreliable and completely dangerous. There is no
way for an AppContext to force threads within it to terminate on demand.
That said, I don't think that is the cause of the hang. The most suspect
part of that thread dump is this:
"AWT-EventQueue-83" prio=6 tid=0x33e6e400 nid=0x1e0 in Object.wait()
[0x3b77f000..0x3b77fb94]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x038c01a8> (a java.awt.EventQueue$1AWTInvocationLock)
at java.lang.Object.wait(Object.java:485)
at java.awt.EventQueue.invokeAndWait(EventQueue.java:992)
- locked <0x038c01a8> (a java.awt.EventQueue$1AWTInvocationLock)
at java.awt.Window.doDispose(Window.java:994)
at java.awt.Window.dispose(Window.java:937)
at
javax.swing.SwingUtilities$SharedOwnerFrame.dispose(SwingUtilities.java:1789)
at
javax.swing.SwingUtilities$SharedOwnerFrame.windowClosed(SwingUtilities.java:1767)
- locked <0x04942ed0> (a java.awt.Component$AWTTreeLock)
Here we have an AWT event thread calling EventQueue.invokeAndWait()
(which would only make sense if it were calling it on a different
EventQueue - which perhaps it is) *BUT* it does it while holding the
global AWTTreeLock. Seems like a prime candidate for a deadlock to me.
And you will see that there's a following event queue thread blocked
trying to acquire that lock:
"AWT-EventQueue-81" prio=6 tid=0x349c7400 nid=0xbdc waiting for monitor
entry [0x3bf7f000..0x3bf7fd14]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.awt.Component.invalidate(Component.java:2622)
- waiting to lock <0x04942ed0> (a java.awt.Component$AWTTreeLock)
I'd redirect this to the AWT folk.
Cheers,
David Holmes
Martin Buchholz said the following on 08/22/08 08:22:
> Hi Artem,
>
> Please read
> http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html
> The deprecated Thread methods are inherently deadlock-prone.
>
> I don't know how AWT is supposed to work, but other folks
> have had the same kind of threading reliability problems.
> Perhaps someone from awt-dev would know better - I would try there.
>
> Martin
>
> On Thu, Aug 21, 2008 at 6:26 AM, Artem Ananiev <Artem.Ananiev at sun.com> wrote:
>> Hi, hotspot team,
>>
>> (I'm not sure if hotspot-runtime-dev is a right alias for the questions like
>> this, but I haven't found anything better)
>>
>> my question is about the right way to destroy a Thread or ThreadGroup. In a
>> few words, some application periodically creates and destroys instances of
>> sun.awt.AppContext (which roughly corresponds to a ThreadGroup instance).
>> After a small number of iterations application just hangs - the stack trace
>> is attached.
More information about the hotspot-runtime-dev
mailing list