[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