JDK-8023461 : Thread holding lock at safepoint that vm can block on: MethodCompileQueue_lock
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25,8u20,9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-08-21
  • Updated: 2017-07-26
  • Resolved: 2014-05-14
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
8u40Fixed 9 b15Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Description
All info I could find was:

Java HotSpot(TM) 64-Bit Server VM warning: Thread holding lock at safepoint that vm can block on: MethodCompileQueue_lock
Comments
Thanks for escalating this. I wasn't aware it is so severe for you. I'll pay more attention to this bug. It is two-fold: (1) the assertion is too strong: we can't eliminate CompileQueue locking while safepointing; (2) there are some bugs lurking in this code and I haven't had time to find a right fix for them. That's why my initial fix [1] didn't work. [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-March/013685.html
24-04-2014

It has a high impact on testing resources and dev+sqe productivity, creates a lot of noise in the reporting. Even though not a product bug, it still should be at least P2, from my point of view. I am changing to P2.
24-04-2014

If you think it introduces too much noise into the testing results, P2 is the right way to signal it.
24-04-2014

Mikhailo, rare fastdebug-only failure (asssertion failure) can't be rated P1. Please, reconsider your metrics.
24-04-2014

ILW: HMH => P1 Impact: High, crash Likelyhood: M, intermitted but common, fails a great variety of tests W: High, no known workaround Given how much disruption in testing this bug causes, and the ILW results, the priority should be elevated to P2, if not P1. Compiler SQE or Dev team, please consider raising the priority.
24-04-2014

RULE ctw/jre/lib/rt_jar/sun_nio_ch_WindowsAsynchronousSocketChannelImpl Crash Internal Error ...thread.cpp...fatal error: Thread holding lock at safepoint that vm can block on: MethodCompileQueue_lock RULE ctw/jre/lib/rt_jar/sun_reflect_UnsafeQualifiedIntegerFieldAccessorImpl Crash Internal Error ...thread.cpp...fatal error: Thread holding lock at safepoint that vm can block on: MethodCompileQueue_lock RULE ctw/weblogic_jar/weblogic_html_BigElement Crash Internal Error ...thread.cpp...fatal error: Thread holding lock at safepoint that vm can block on: MethodCompileQueue_lock
11-04-2014

RULE src/jdk/nashorn/api/javaaccess/MethodAccessTest.java Crash Internal Error ...thread.cpp...fatal error: Thread holding lock at safepoint that vm can block on: MethodCompileQueue_lock RULE vm/mlvm/meth/stress/compiler/sequences Crash Internal Error ...thread.cpp...fatal error: Thread holding lock at safepoint that vm can block on: MethodCompileQueue_lock RULE ctw/jre/lib/rt_jar/com_sun_jndi_dns_NameNode Crash Internal Error ...thread.cpp...fatal error: Thread holding lock at safepoint that vm can block on: MethodCompileQueue_lock RULE vm/mlvm/meth/stress/compiler/i2c_c2i Crash Internal Error ...thread.cpp...fatal error: Thread holding lock at safepoint that vm can block on: MethodCompileQueue_lock
04-04-2014

RULE ctw/jre/lib/rt_jar/com_sun_xml_internal_org_jvnet_mimepull_MIMEParser Crash Internal Error ...thread.cpp...fatal error: Thread holding lock at safepoint that vm can block on: MethodCompileQueue_lock
01-04-2014

AdvancedThresholdPolicy::update_rate shouldn't try to allocate method counters if they are absent, since it holds VM compile queue lock.
07-03-2014

Stack trace for the owning thread at safepoint: V [libjvm.so+0xd3cf2d] Thread::check_for_valid_safepoint_state(bool)+0x12d;; Thread::check_for_valid_safepoint_state(bool)+0x12d V [libjvm.so+0xdedad2] VMThread::execute(VM_Operation*)+0x302;; VMThread::execute(VM_Operation*)+0x302 V [libjvm.so+0x52dc5a] CollectorPolicy::satisfy_failed_metadata_allocation(ClassLoaderData*, unsigned int, Metaspace::MetadataType)+0xba;; CollectorPolicy::satisfy_failed_metadata_allocation(ClassLoaderData*, unsigned int, Metaspace::MetadataType)+0xba V [libjvm.so+0xaea325] Metaspace::allocate(ClassLoaderData*, unsigned int, bool, MetaspaceObj::Type, Thread*)+0x315;; Metaspace::allocate(ClassLoaderData*, unsigned int, bool, MetaspaceObj::Type, Thread*)+0x315 V [libjvm.so+0xafe5ec] MethodCounters::allocate(ClassLoaderData*, Thread*)+0x1c;; MethodCounters::allocate(ClassLoaderData*, Thread*)+0x1c V [libjvm.so+0xaf71b6] Method::build_method_counters(Method*, Thread*)+0x36;; Method::build_method_counters(Method*, Thread*)+0x36 V [libjvm.so+0x2cff7d] AdvancedThresholdPolicy::select_task(CompileQueue*)+0xffd;; AdvancedThresholdPolicy::select_task(CompileQueue*)+0xffd V [libjvm.so+0x5621cc] CompileQueue::get()+0x10c;; CompileQueue::get()+0x10c V [libjvm.so+0x569ab0] CompileBroker::compiler_thread_loop()+0x240;; CompileBroker::compiler_thread_loop()+0x240
05-03-2014

Calvin's rule for Kithchensink is not correct, it does not match failures, there should not be a "VM warning:". the right one is: RULE bigapps/Kitchensink/nowarnings Unknown Found warnings in server log: Thread holding lock at safepoint that vm can block on: MethodCompileQueue_lock
16-12-2013

2013.10.30 RT_Baseline nightly bigapps/Kitchensink/nowarnings [glue.process.err] [stress.process.err] Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128M; support was removed in 8.0 [glue.process.err] [stress.process.err] Java HotSpot(TM) 64-Bit Server VM warning: Thread holding lock at safepoint that vm can block on: MethodCompileQueue_lock Test run URL: http://aurora.ru.oracle.com/functional/faces/RunDetails.xhtml?names=311006.JAVASE.NIGHTLY.VM.RT_Baseline.2013-10-30-164#Kitchensink%20(bigapps)_bigapps/Kitchensink/nowarnings Host: intelsdv34, Intel x86 2933 MHz, 16 cores, 12G, Solaris / Solaris 11, i86pc Options: -d64 -server -Xcomp -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:ReservedCodeCacheSize=256M RULE bigapps/Kitchensink/nowarnings Unknown Found warnings in server log: VM warning: Thread holding lock at safepoint that vm can block on: MethodCompileQueue_lock
31-10-2013

8-defer-request: This bug does not affect the run of the test or application. It's a warning that the compiler queue lock was blocked by a safepoint. Defer to JDK9
03-10-2013

Here's another bug that mentions the same message: JDK-8017093 JVM crashes in methods compiled by C1 when Metaspace is exhausted but the message is not the focus of JDK-8017093 so I'm not adding a link to it...
19-09-2013