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