(This was seen when trying to reproduce a crash with the netbeans profiler: https://bz.apache.org/netbeans/show_bug.cgi?id=240763 )
If one writes a JVMTI agent that listens for MonitorContendedEnter, and from that callback tries to take the same lock again, the JVM will assert on objectMonitor.cpp:348: assert (Self->_Stalled == 0, "invariant")
This is the same problem as described inJDK-7184993 which was closed as a dup of the no-permgen enhancement. The problem is pretty well described in that bug in this comment https://bugs.openjdk.java.net/browse/JDK-7184993?focusedCommentId=12584932&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12584932
The first question is: Is this valid code? Is it ok for a JVMTI agent to try to acquire locks in MonitorContendedEnter?
Second question: If so, how do we make it possible?
If one writes a JVMTI agent that listens for MonitorContendedEnter, and from that callback tries to take the same lock again, the JVM will assert on objectMonitor.cpp:348: assert (Self->_Stalled == 0, "invariant")
This is the same problem as described in
The first question is: Is this valid code? Is it ok for a JVMTI agent to try to acquire locks in MonitorContendedEnter?
Second question: If so, how do we make it possible?
- relates to
-
JDK-8035150 ShouldNotReachHere() in ConstantPool::copy_entry_to
-
- Closed
-
-
-
- Closed
-