Safepoint Deadlock Diagnosis

David Holmes David.Holmes at
Tue Apr 13 15:34:55 PDT 2010

I don't see a lot to go on here. Can you do a pstack (if on Solaris) or 
at least a "jstack -m" to get full stack traces for all threads. This 
top entry:

#0  0x00007f832653eadb in SystemDictionary::find_class (index=558, 
hash=681650688, class_name=..., class_loader=...) at 

doesn't indicate that the thread has blocked so there may be some 
"livelock" here. The main thread is _thread_blocked according to the 
Java stack but this is not apparent from the backtrace. The main thread 
is not at the safepoint.

Is this your own customized VM you are running?

David Holmes

Peng Du said the following on 04/14/10 06:40:
> Hello, list
> I have been witnessing deadlocks of the HotSpot I am working on. I tried 
> everything I know
> to diagnose this. Here is what I found: the "main" JavaThread always 
> ended up somewhere
> in the stub SharedRuntime::handle_wrong_method(). HotSpot would then 
> deadlock at this point.
> In to the thread dump, I saw all threads are: _thread_blocked. The 
> method that was patched
> with this stub is "java_lang_math_log" (frame 12 @ 0x00007f832173b40e).
> I have attached the backtrace and thread dump in the email. Can someone 
> hint on what might
> be the reason for this deadlock?
> Thanks!
> -Peng

More information about the hotspot-dev mailing list