JDK-8059128 : VM hangs because threads fail to synchronize at safepoint
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8u40
  • Priority: P2
  • Status: Closed
  • Resolution: Incomplete
  • Submitted: 2014-09-25
  • Updated: 2017-11-03
  • Resolved: 2014-12-01
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u40Resolved 9Resolved
Related Reports
Relates :  
JDK-8114823 - G1 doesn't honor request to disable class unloading
Relates :  
JDK-8085965 - VM hangs in C2Compiler
Description
M. Makundi from the hotspot-gc-use mailing list (subject "G1gc compaction algorithm") reports a VM hang with 8u40-b02 EA and 8u40-b06 EA on their application after a few hours.

The problem is that typically one thread is not able to synchronize at the safepoint.

Internally we managed to reproduce the same problem with 8u40-b02 until after the fix for JDK-8056154.

The attached stack trace (gstacks.txt) shows that thread 49 seems stuck in compiler related methods; note that in mentioned earlier reproductions this has been a single random java thread that hung.
Comments
In retrospect, could this be a duplicate of 8085965?
03-11-2017
Thank you, Thomas I looked through PageArmed==0 bugs and did not find anything similar - hang in compiler thread during Parse phase. There are/was issues with Escape Analysis execution time but it is not related to this problem because Parse phase executed before EA. I am closing this as Incomplete.
01-12-2014
[~tschatzl], did you ever get more logs? If we can't get more information then we should close it as Incomplete.
01-12-2014
What are we doing about this bug for 8u40? There is a backport open.
01-12-2014
> gcstack.txt has 2 java threads are not in safepoint: Both those threads are in native and so safepoint safe. Only the compiler thread seems to be of concern. I'm concerned about the reference to "RT Throttling" above. The VM should not be running under a real-time scheduler!
06-11-2014
Is this really an 8u40 bug? If yes, we should do something about it.
06-11-2014
Some more information from M. Makundi: On Mon, 2014-10-13 at 16:38 +0300, Martin Makundi wrote: > We increased memory xmx to 48gb and now we get linux syslog saying RT throttling activated just before system hang: > > http://humblesblog.blogspot.fi/2011/06/hang-linux-box-with-relatime-process.html > > http://forums.debian.net/viewtopic.php?f=5&t=104550 > > Unfortunately I don't have the logs from the hangs with 8ea but that's something worth looking at. (Thomas): I will add the information to the CR. What would definitely help would be a few subsequent (maybe 5?) "gstacks.txt" stack traces when it hangs if you have time/interest in following up with that. (E.g. running gdb --batch --quiet -ex "thread apply all bt full" -ex "quit" $JAVA_HOME/bin/java <pid> > gstacks.txt)
13-10-2014
ILW=VM hang, seen in one application, none=HLH=P2
01-10-2014
Can the sibling list end up containing a cycle? Otherwise it's hard to explain why we're stuck in Dependencies::find_finalizable_subclass()..
25-09-2014
[~tschatzl] it's doesn't seem to be related to JDK-8056154.
25-09-2014
And it is not compiler problem as you see.
25-09-2014
Note, compiler thread is also Java thread. And call to VM through CI will block on safepoint: bool ciInstanceKlass::has_finalizable_subclass() { if (!is_loaded()) return true; VM_ENTRY_MARK; return Dependencies::find_finalizable_subclass(get_instanceKlass()) != NULL; } #define VM_ENTRY_MARK \ CompilerThread* thread=CompilerThread::current(); \ ThreadInVMfromNative __tiv(thread); \ ... ThreadStateTransition::transition_from_native() { ... if (SafepointSynchronize::do_call_back() || thread->is_suspend_after_native()) { JavaThread::check_safepoint_and_suspend_for_native_trans(thread); So the check for safepoint happens before call Dependencies::find_finalizable_subclass(). I don't know why why it may spend a lot time in that method - it is very simple recursive method. Of cause if k is java.lang.Object class it may take time to find subclass with finalizer.
25-09-2014
gcstack.txt has 2 java threads are not in safepoint: Thread 24 (Thread 0x7fa4ae3f9700 (LWP 2752)): #0 0x00007fa5293e6223 in poll () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x00007fa4b494b393 in NET_Timeout () from /usr/share/java/jdk1.8.0_40/jre/lib/amd64/libnet.so No symbol table info available. #2 0x00007fa4b4949527 in Java_java_net_PlainSocketImpl_socketAccept () from /usr/share/java/jdk1.8.0_40/jre/lib/amd64/libnet.so No symbol table info available. #3 0x00007fa51ec813b4 in ?? () Thread 26 (Thread 0x7fa4aebfb700 (LWP 2750)): #0 0x00007fa529ac7543 in recvfrom () from /lib/x86_64-linux-gnu/libpthread.so.0 No symbol table info available. #1 0x00007fa4b494b6f9 in NET_RecvFrom () from /usr/share/java/jdk1.8.0_40/jre/lib/amd64/libnet.so No symbol table info available. #2 0x00007fa4b4947a44 in Java_java_net_PlainDatagramSocketImpl_receive0 () from /usr/share/java/jdk1.8.0_40/jre/lib/amd64/libnet.so No symbol table info available. #3 0x00007fa51ec81e73 in ?? () and 1 compiler thread: Thread 49 (Thread 0x7fa4c536a700 (LWP 2719)): #0 0x00007fa528881a89 in Dependencies::find_finalizable_subclass(Klass*) () from /usr/share/java/jdk1.8.0_40/jre/lib/amd64/server/libjvm.so No symbol table info available. #1 0x00007fa528797bbe in ciInstanceKlass::has_finalizable_subclass() () from /usr/share/java/jdk1.8.0_40/jre/lib/amd64/server/libjvm.so No symbol table info available. #2 0x00007fa528c9a1bb in Parse::call_register_finalizer() () from /usr/share/java/jdk1.8.0_40/jre/lib/amd64/server/libjvm.so No symbol table info available. #3 0x00007fa528c9a841 in Parse::return_current(Node*) () from /usr/share/java/jdk1.8.0_40/jre/lib/amd64/server/libjvm.so No symbol table info available. #4 0x00007fa528ca77ce in Parse::do_one_bytecode() () from /usr/share/java/jdk1.8.0_40/jre/lib/amd64/server/libjvm.so No symbol table info available. #5 0x00007fa528c99668 in Parse::do_one_block() () from /usr/share/java/jdk1.8.0_40/jre/lib/amd64/server/libjvm.so No symbol table info available. #6 0x00007fa528c9d1c7 in Parse::do_all_blocks() () from /usr/share/java/jdk1.8.0_40/jre/lib/amd64/server/libjvm.so No symbol table info available. #7 0x00007fa528c9de89 in Parse::Parse(JVMState*, ciMethod*, float, Parse*) () from /usr/share/java/jdk1.8.0_40/jre/lib/amd64/server/libjvm.so
25-09-2014