[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    [Fwd: Thread group disposal question]
From:       martinrb () google ! com (Martin Buchholz)
Date:       2008-08-23 2:52:51
Message-ID: 1ccfd1c10808221952o29acd65fj1720fef8d2af3d6a () mail ! gmail ! com
[Download RAW message or body]

Probably, a ThreadPoolExecutor has been created and never shut down,
or not properly shut down.

This is a cooperative thing. worker tasks may need to notice
termination requests,
and the controlling thread probably needs to await termination.

Martin

On Fri, Aug 22, 2008 at 5:07 AM, Artem Ananiev <Artem.Ananiev at sun.com> wrote:
> Hi, Xiaobin,
>
> thanks to David, the deadlock seems to be caused by improper AWT tree lock
> usage, so the question about Unsafe.park() calls is now: why there are so
> many pool-XX-thread-X threads are alive and parking? I'll try to check the
> swap file usage, but I doubt this can be a cause of the problem.
>
> Thanks,
>
> Artem
>
> Xiaobin Lu wrote:
>>
>> The hang isn't caused by the Unsafe calls, sun.misc.Unsafe is used
>> explicitly by the new java.util.concurrent.locks package. I assume if the
>> application is in a deadlock situation, you could detect the hang by
>> attaching the process to Jconsole which has a deadlock detection
>> functionality built in, see
>> http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html#DeadlockDetection
>> for more details on this. Another possibility of the hang is the resource
>> restraint, meaning that the application isn't getting the memory resource it
>> needs. Would you look at the prstat output (or top output) to see whether
>> the system is out of swap when the hang occurs?
>>
>> -Xiaobin
>>
>> James Melvin wrote:
>>>
>>> Can anyone help Artem?
>>>
>>> - Jim
>>>
>>>
>>> -------- Original Message --------
>>> Subject: Thread group disposal question
>>> Date: Thu, 21 Aug 2008 17:26:58 +0400
>>> From: Artem Ananiev <Artem.Ananiev at Sun.COM>
>>> To: hotspot-runtime-dev at openjdk.java.net
>>>
>>> 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.
>>>
>>> The log shows a number of threads waiting for Unsafe.park() calls. I
>>> suspect this happens because AppContext class stops all the threads in
>>> its ThreadGroup with ThreadGroup.stop() and then destroys the group
>>> itself with ThreadGroup.destroy(). If any details are required, this
>>> code can be easily found in JDK source tree:
>>>
>>> jdk/src/share/classes/sun/awt/AppContext.java
>>>
>>> The question is whether the hang can be caused by using these unsafe
>>> methods, and whether I can workaround it in any way.
>>>
>>> Thanks,
>>>
>>> Artem
>>>
>>
>


[prev in list] [next in list] [prev in thread] [next in thread]