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

[Aleksey Shipilev]

On Fri, 19 Jan 2024 22:00:15 GMT, Vladimir Kozlov <kvn 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.

It looks good, but let's not put unrelated changes together? I think the `COMPILER2_OR_JVMCI` should come in as a separate atomic change. This will, for example, allow to cleanly backport `storestore` additions without looking back whether the vector support enablement hunks make sense.

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

PR Review: https://git.openjdk.org/jdk/pull/17503#pullrequestreview-1836050278