RFR 8173309: jvmtiDeferredLocalVariableSet may update the wrong frame

[Vladimir Kozlov]

Got it. I reread your evaluation and the problem was indeed the recursive inlining in compiled code so the fix make 
sense with your explanation.

Reviewed.

Thanks,
Vladimir

On 1/24/17 8:27 PM, Tom Rodriguez wrote:
>
>
> 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
>>>