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
 
-