RFR: 8324050: Issue store-store barrier after re-materializing objects during deoptimization

[Vladimir Kozlov]

On Fri, 19 Jan 2024 23:02:31 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Added missing store-store barrier when we re-materialize scalar replaced object during deoptimization.
>> 
>> I also removed redundant `#if COMPILER2_OR_JVMCI` guards which were leftover from [JDK-8312579](https://bugs.openjdk.org/browse/JDK-8312579) changes. It added Vector API support to Graal and changed `#ifdef COMPILER2` to these `#if`. But this code is already under these `ifs`.
>> 
>> Tested tier1-3, scope, stress.
>> 
>> No new regression test.  I think it is "almost" impossible to hit this issue because there is a lot of VM's runtime code between the code which rematerialize scalar-replaced objects during deoptimization and a code in Interpreter which is executed after deoptimization and which may execute a store instruction that makes these objects accessible by other threads.
>
> src/hotspot/share/runtime/deoptimization.cpp line 1603:
> 
>> 1601:   // We need barrier so that stores that initialize these objects can't be reordered
>> 1602:   // with subsequent stores that make these objects accessible by other threads.
>> 1603:   OrderAccess::storestore();
> 
> This seems like the right place for normal deoptimization, but I'm worried that EscapeBarrier::deoptimize_objects() makes these objects visible to JVMTI without calling reassign_fields().

I see that `EscapeBarrier::deoptimize_objects_internal()` calls `Deoptimization::deoptimize_objects_internal()` which calls `rematerialize_objects()` which does reallocation and fields reassignment. It will execute this barrier.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17503#discussion_r1460077603