RFR 8173309: jvmtiDeferredLocalVariableSet may update the wrong frame

[Tom Rodriguez]

Vladimir Kozlov wrote:
> Tom,
>
> You increase compiled frame id when sender is also compiled frame. What
> if there other frames (interpreter) between compiled frames?

A single compiled frame is a represented by a sequence of 
compiledVFrames.  One constructor is used for the first frame, so it 
starts at 0, and the other constructor is used when getting the sender 
compiledVFrame.  So the sequences are all within a single compiled frame 
but there's a vframe for each inlined scope with an increasing frame id. 
  Interpreter frames would switch over to interpreterVFrames and any new 
compiled frame would start over from 0 again.

tom

>
> Thanks,
> Vladimir
>
> On 1/24/17 5:06 PM, Tom Rodriguez wrote:
>> http://cr.openjdk.java.net/~never/8173309/webrev
>> https://bugs.openjdk.java.net/browse/JDK-8173309
>>
>> When using jvmtiDeferredLocalVariableSet to update locals in a
>> compiled frame, the code matches based purely on the method/bci pair.
>> If some recursion has been inlined then it will update the first frame
>> that matches instead of the intended frame. The code should be
>> tracking the actual depth that the compilerVFrame came from instead.
>> The JVMCI operation materializeVirtualObjects uses this code when
>> forcibly materializing EA’ed objects. Normally this would only be
>> noticed by debugger clients. Tested with failing case from Graal.
>>
>> tom
>>