RFR 8173309: jvmtiDeferredLocalVariableSet may update the wrong frame

[Tom Rodriguez]

I was able to modify an existing test to show the issue so I've sent out 
a separate RFR for that.

tom

Tom Rodriguez wrote:
> Nils Eliasson wrote:
>> Hi Tom,
>>
>> Could you add the test case as well?
>
> The program that showed this was part of larger complex piece of code
> using Graal. I might be able to build a jtreg test for it, but it's a
> little challenging to hand build to test out a complex deopt situation.
> Now that Graal itself is integrated into the JDK maybe a full Graal unit
> test would work? Are the Graal unit tests run as part of testing now?
>
> I thought it might be possible to build a debugger test for this but it
> doesn't look like the jtreg tests have enough harness for such a setup.
>
> tom
>
>>
>> // Nils
>>
>> On 2017-01-25 02:06, 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
>>