Safepoint Deadlock Diagnosis
David Holmes
David.Holmes at oracle.com
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
/work/openjdk/hotspot/src/share/vm/classfile/systemDictionary.cpp:1633
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