RFR: 8333791: Fix memory barriers for @Stable fields

[Aleksey Shipilev]

On Thu, 11 Jul 2024 08:47:59 GMT, John R Rose <jrose at openjdk.org> wrote:

> I like this compromise. Let me see if I got it right: A stable write in a constructor is treated like a final write — it triggers a barrier at the end of the constructor. That’s a cheap move. No other barriers are added automatically, for reads or other writes, saving us from doing less cheap moves. The burden would be on users of stable vars (in fancy access patterns) to add more fences if needed, but we don’t see any important cases of that, at the moment.

Yes, pretty much.

Looking at this another way, after this patch, there is no performance or safety cost for simple changes in user code like:
 1. Changing the previously `final` field into `@Stable` field with value overwrite outside of constructor. This looks like a useful pattern in `java.lang.invoke`.
 2. Changing the previously `@Stable` field into `final` field, if the only stores are in constructor. Basically, the reversal of (1).
 3. Putting a `@Stable` over `final` field. This is where current `String` constructor gets a bad deal today.
 4. Putting a `@Stable` over any field that is written outside of constructor. This is where lazy caches like `Enum.hashCode` get a bad deal today.

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

PR Comment: https://git.openjdk.org/jdk/pull/19635#issuecomment-2222413725