JDK-8134767 : [JVMCI] CompilerToVM.getNextStackFrame loses locals for compiled frames
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2015-08-31
  • Updated: 2015-09-07
  • Resolved: 2015-09-07
Related Reports
Relates :  
JDK-8062493 - JEP 243: Java-Level JVM Compiler Interface
Description
According to javadoc for InspectedFrame.getLocal(I)  HotSpotStackFrameReference.getLocal should return an object from the locals list. But it looks like it works only for interpreted frames:

The following output shows that at compilation levels 3 and 4 frames HotSpotStackFrameReference object doesn't contain locals 
HotSpotStackFrameReference [stackPointer=140707345981904, frameNumber=0, bci=14, method=HotSpotMethod<MaterializeVirtualObjectsTest.testFrame(Object, Integer, Executable)>, locals=[compiler.jvmci.MaterializeVirtualObjectsTest@78084af3, two, 1100, private void compiler.jvmci.MaterializeVirtualObjectsTest.testFrame(java.lang.Object,java.lang.Integer,java.lang.reflect.Executable), two], localIsVirtual=null]
Has virtual: false
Is compiled: false, level: 0

HotSpotStackFrameReference [stackPointer=140707345981864, frameNumber=0, bci=14, method=HotSpotMethod<MaterializeVirtualObjectsTest.testFrame(Object, Integer, Executable)>, locals=[null, null, null, null, null], localIsVirtual=null]
Has virtual: false
Is compiled: true, level: 3

HotSpotStackFrameReference [stackPointer=140707345981952, frameNumber=0, bci=14, method=HotSpotMethod<MaterializeVirtualObjectsTest.testFrame(Object, Integer, Executable)
>, locals=[null, null, null, null, null], localIsVirtual=null]
Has virtual: false
Is compiled: true, level: 4
Comments
Thanks, Lukas. This try {} block works for me. The values are all in place.
07-09-2015
this is expected (albeit undocumented...) behavior. at the point of the call to "check" in "testFrame", the local variables are not needed any more (according to bytecode analysis) - the compilers will therefore not bother recording the value in debug information. this interface will only provide what's available, and without changes to the compiled code, the values of the local variables are simply gone. this can be worked around by something like this: try { check(s, i); } finally { assert a != null && i != null && obj != null && this != null; }
02-09-2015
Douglas, could you please look at this?
31-08-2015