Summary
Update the spec of StackFrame::getByteCodeIndex
to return negative value when BCI is not available.
Problem
There are odd cases in the JITs that BCI is invalid. For example,
a synchronized
method has no explicit monitorenter
bytecode.
Since the action can block, you can hit a safepoint on BCI #0
either before or after the monitor is locked.
Solution
Change the spec of StackFrame::getByteCodeIndex
to return negative
value when BCI is not available.
Specification
The spec of java.lang.StackWalker.StackFrame::getByteCodeIndex
is modified as follows:
diff --git a/src/java.base/share/classes/java/lang/StackWalker.java b/src/java.base/share/classes/java/lang/StackWalker.java
--- a/src/java.base/share/classes/java/lang/StackWalker.java
+++ b/src/java.base/share/classes/java/lang/StackWalker.java
@@ -178,7 +178,7 @@
*
* @return the index to the code array of the {@code Code} attribute
* containing the execution point represented by this stack frame,
- * or a negative number if the method is native.
+ * or a negative number if the method is native or unavailable.
*
* @jvms 4.7.3 The {@code Code} Attribute
*/
- csr of
-
JDK-8193325 StackFrameInfo::getByteCodeIndex returns wrong value if bci > 32767
- Resolved