RFR: 8333791: Fix memory barriers for @Stable fields

[Aleksey Shipilev]

Hi Hans,

On 13.07.24 02:36, Hans Boehm wrote:
> No opinion on the merits here. But IIUC, "as memory safe as finals" is a slightly squishy notion 
> here. The downside of not having the release fence is that even with safe publication, a write to 
> an @Stable field outside the constructor can be seen by a read in the constructor, before the object 
> is published. That's arguably weirder than final field behavior, and not something that can arise 
> with final fields. But it still only happens in the presence of data races, and thus probably not in 
> code you should be writing anyway.

Agreed. "Hans Boehm's argument for doing release in initializers" [1] lives in my head rent-free :)

In the presence of @Stable writes outside of constructors, users of @Stable are basically on their 
own, and are responsible for proper fencing if data races are not benign. Including putting the 
release/seqcst fences in constructors if constructors read the @Stable fields back.

I think not giving into handling these corner cases by default gives us a reasonable 
performance/safety model for @Stable: https://github.com/openjdk/jdk/pull/19635#issuecomment-2222413725

-Aleksey

[1] https://www.hboehm.info/c++mm/no_write_fences.html



Amazon Web Services Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597