JDK-8013945 : CMS fatal error: must own lock MemberNameTable_lock
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: hs25,7u60
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-05-06
  • Updated: 2014-10-15
  • Resolved: 2013-05-25
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 7 JDK 8 Other
7u60Fixed 8Fixed hs25Fixed
Related Reports
Relates :  
JDK-8011803 - release_C_heap_structures is never called for anonymous classes.
Relates :  
JDK-8008511 - JSR 292: MemberName vmtarget refs to methods must be updated at class redefinition
Description
Failure observed during PIT of hs25-b31 for jdk8-b89
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (C:\jprt\T\P1\151437.amurillo\s\src\share\vm\runtime\mutexLocker.cpp:150), pid=4800, tid=8288
#  fatal error: must own lock MemberNameTable_lock
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b87) (build 1.8.0-ea-fastdebug-b87)
# Java VM: Java HotSpot(TM) Client VM (25.0-b31-internal-201305031514.amurillo.hs25-b31-snapshot-fastdebug compiled mode, sharing windows-x86 )
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
Comments
7u60-critical-request justification: This bug fix is better to be in the release because it is a part of the JSR-292 support in the JVMTI HotSwap API (includes RedefineClasses, RetransformClasses and PopFrame). This bug is one of 12 bug fixes that depend on each other and must be integrated in the order: https://jbs.oracle.com/bugs/browse/JDK-7194607 https://jbs.oracle.com/bugs/browse/JDK-8005128 https://jbs.oracle.com/bugs/browse/JDK-8006542 https://jbs.oracle.com/bugs/browse/JDK-8006546 https://jbs.oracle.com/bugs/browse/JDK-8006731 https://jbs.oracle.com/bugs/browse/JDK-8008511 https://jbs.oracle.com/bugs/browse/JDK-8007037 https://jbs.oracle.com/bugs/browse/JDK-8014288 https://jbs.oracle.com/bugs/browse/JDK-8013945 https://jbs.oracle.com/bugs/browse/JDK-8014052 https://jbs.oracle.com/bugs/browse/JDK-7187554 https://jbs.oracle.com/bugs/browse/JDK-8023004 All the fixes above have been already integrated into the JDK 8 and tested in the hotspot-rt nightly for several months. Risk: low The fixes touch the JVMTI HotSwap API that includes RedefineClasses, RetransformClasses and PopFrame. The risk is only to introduce regressions in this part of the JVMTI implementation. This impacts only the debugging and profiling tools that use the JVMTI HotSwap feature. There are very small chances for regressions to sneak into the class file constant pool processing and method handles implementation. Webrevs and reviewers: The 7u60 webrevs location is: http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2013/hotspot/7u_port/ The fixes above were already passed the review process before integration into JDK 8. The reviewers were: twisti, jrose, coleenp, dholmes, etc. The 7u60 edition of fixes must be reviewed at least by jrose and twisti. Level of effort: All fixes need a secondary review phase after rebase from jdk8 to 7u60 repository. Testing coverage: The folllowing test suites must be run to ensure correctness of the fixes: JTREG tests: com/sun/jdi, java/lang/instrument NSK tests: vm.mlvm.testlist, nsk.jvmti.testlist, nsk.jdi.testlist, nsk.jdwp.testlist Result of not integrating: The users will not be able to use HotSwap technology for debuging and profiling Java code that depends on the JSR-292 implementation. In that case the integration of these fixes will have to be requested/escalated in 7 updates by the tool vendors and/or customers.
10-01-2014
The "deoptimize" and "sequences" tests may fail with another fail pattern which is unrelated to this bug (8013945): [2013-05-04T20:15:34.64] # ERROR: Caught exception in Thread[Thread-8,5,main] [2013-05-04T20:15:34.64] # ERROR: java.lang.Exception: Exception in sequence MH sequence graph TF: see sequence graph-hgb8dzpg.txt [2013-05-04T20:15:34.64] # ERROR: at vm.mlvm.meth.share.MHTransformationGen.callSequence(MHTransformationGen.java:426) [2013-05-04T20:15:34.64] # ERROR: at vm.mlvm.meth.share.MHTransformationGen.createAndCallSequence(MHTransformationGen.java:433) [2013-05-04T20:15:34.64] # ERROR: at vm.mlvm.meth.stress.compiler.deoptimize.Test.runThread(Test.java:84) [2013-05-04T20:15:34.64] # ERROR: at vm.mlvm.share.MultiThreadedTest$2.run(MultiThreadedTest.java:46) [2013-05-04T20:15:34.64] # ERROR: at java.lang.Thread.run(Thread.java:724) [2013-05-04T20:15:34.64] # ERROR: Caused by: java.lang.StackOverflowError [2013-05-04T20:15:34.64] # ERROR: at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:599) [2013-05-04T20:15:34.64] # ERROR: at vm.mlvm.meth.share.transform.v2.MHCall.call(MHCall.java:112) [2013-05-04T20:15:34.64] # ERROR: at vm.mlvm.meth.share.transform.v2.MHCall.callAndCheckRetVal(MHCall.java:120) [2013-05-04T20:15:34.64] # ERROR: at vm.mlvm.meth.share.MHTransformationGen.callSequence(MHTransformationGen.java:420) [2013-05-04T20:15:34.64] # ERROR: ... 4 more [2013-05-04T20:15:34.65] # ERROR: Caught exception in Thread[Thread-5,5,main] [2013-05-04T20:15:34.65] # ERROR: java.lang.Exception: Exception in sequence MH sequence graph TF: see sequence graph-hgb8e4h4.txt [2013-05-04T20:15:34.65] # ERROR: at vm.mlvm.meth.share.MHTransformationGen.callSequence(MHTransformationGen.java:426) [2013-05-04T20:15:34.65] # ERROR: at vm.mlvm.meth.share.MHTransformationGen.createAndCallSequence(MHTransformationGen.java:433) [2013-05-04T20:15:34.65] # ERROR: at vm.mlvm.meth.stress.compiler.deoptimize.Test.runThread(Test.java:84) [2013-05-04T20:15:34.65] # ERROR: at vm.mlvm.share.MultiThreadedTest$2.run(MultiThreadedTest.java:46) [2013-05-04T20:15:34.65] # ERROR: at java.lang.Thread.run(Thread.java:724) [2013-05-04T20:15:34.65] # ERROR: Caused by: java.lang.StackOverflowError [2013-05-04T20:15:34.65] # ERROR: at java.lang.invoke.LambdaForm$NamedFunction.invoker(LambdaForm.java:1165) [2013-05-04T20:15:34.65] # ERROR: at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:599) [2013-05-04T20:15:34.65] # ERROR: at vm.mlvm.meth.share.transform.v2.MHCall.call(MHCall.java:112) [2013-05-04T20:15:34.65] # ERROR: at vm.mlvm.meth.share.transform.v2.MHCall.callAndCheckRetVal(MHCall.java:120) [2013-05-04T20:15:34.65] # ERROR: at vm.mlvm.meth.share.MHTransformationGen.callSequence(MHTransformationGen.java:420) [2013-05-04T20:15:34.65] # ERROR: ... 4 more [2013-05-04T20:15:34.65] # ERROR: Test marked failed at vm.mlvm.share.MultiThreadedTest$2.run(MultiThreadedTest.java:56): [2013-05-04T20:15:34.65] # ERROR: Thread Thread[Thread-8,5,main] failed [2013-05-04T20:15:34.65] # ERROR: Test marked failed at vm.mlvm.share.MultiThreadedTest$2.run(MultiThreadedTest.java:56): [2013-05-04T20:15:34.65] # ERROR: Thread Thread[Thread-5,5,main] failed [2013-05-04T20:15:34.67] ### TRACE 1: TEST FAILED
24-05-2013
The MemberNameTable was added not for class redefinition only. It is planned to be used by the Compiler team more widely. However, as the initial motivation was class redefinition, it is Ok to keep this bug in the Serviceability sub-category.
08-05-2013
This is a bug in code designed to support class redefinition. Just because the bug only surfaces when running CMS does not make it a bug in CMS.
08-05-2013
CMS calls InstanceKlass::release_C_heap_structures() concurrently. The "delete mnt" needs to take MemberNameTable_lock if !SafepointSynchronize::is_at_safepoint()
07-05-2013