RFR 8192004: InspectedFrame.materializeVirtualObjects only updates locals with new objects
vladimir.kozlov at oracle.com
Fri Dec 22 20:14:34 UTC 2017
Posting to hotspot-dev alias since our group does not have JVMTI experts.
I looked and it seems fine but someone from serviceability should look too.
On 12/22/17 11:08 AM, Tom Rodriguez wrote:
> Could I get some reviews? This doesn't change the way the logic behaves
> for the core use of JVMTI. It just extends the encoding so that numbers
> after the locals are interpreted as expression stack and monitor values.
> I believe there are existing tests of the JVMTI set locals part and
> JVMCI is the only only consumer of the monitor and expression stack part.
> Tom Rodriguez wrote:
>> JVMCI adds the ability to introspect on deoptimized frames which
>> requires early materialization of escape analyzed objects. The
>> jvmtiDeferredLocalVariableSet machinery is reused to capture the local
>> updates required for this. The existing code only updates locals,
>> leaving the stack and monitor information with out of date values. This
>> can lead to deadlocks and incorrect execution. The fix is to slightly
>> generalize jvmtiDeferredLocalVariableSet to handle expression stack and
>> monitor slots. Tested with new graal regression test
>> and previously failing Truffle use cases. I assume the new test case
>> will come across with a normal graal update. The clean mach5 run is in
>> the bug report.
More information about the hotspot-dev