RFR 8173309: jvmtiDeferredLocalVariableSet may update the wrong frame

[Tom Rodriguez]

Thanks!

tom

Vladimir Kozlov wrote:
> 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
>>>>