RFR 8173309: jvmtiDeferredLocalVariableSet may update the wrong frame

[Tom Rodriguez]

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
>