[Fwd: Thread group disposal question]
martinrb at google.com
Fri Aug 22 19:52:51 PDT 2008
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
and the controlling thread probably needs to await termination.
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.
> 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
>> 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?
>> 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:
>>> The question is whether the hang can be caused by using these unsafe
>>> methods, and whether I can workaround it in any way.
More information about the hotspot-runtime-dev