Thread group disposal question

[Artem Ananiev]

Hi, David,

see my comments below.

David Holmes - Sun Microsystems wrote:
> 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)

Agree with you, this is definitely a problem, and I will try to resolve 
it somehow. There is another thing which looks odd to me: stack trace 
shows a number of AWT-EventQueue-XX threads alive. Several event 
dispatch threads may only appear if several AppContexts exist, so I 
assume no AppContext is correctly disposed (and no corresponding 
ThreadGroup is destroyed). I wonder if this may be caused by:

> The Thread.stop() is unreliable and completely dangerous. There is no 
> way for an AppContext to force threads within it to terminate on demand.

There is one more idea I'm going to check. It's a known fact that AWT 
recreates its event dispatch thread if the previous one was destroyed 
for some reason (for example, because of uncaught exception). Now 
consider the following situation: when AppContext and its ThreadGroup 
are being destroyed, any incoming event leads to a new dispatch thread 
created, which in turn prevents the ThreadGroup from destroying.

Thanks,

Artem

> 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.