[Fwd: Thread group disposal question]

Xiaobin Lu Xiaobin.Lu at Sun.COM
Thu Aug 21 10:53:24 PDT 2008


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
>




More information about the hotspot-runtime-dev mailing list