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

[Dean Long]

On Sat, 20 Jan 2024 00:26:17 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> 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.

Thanks, I missed that.

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

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