CAS in load barrier self-healing

[Aleksey Shipilev]

Hi,

On 18.11.24 10:05, Florian Weimer wrote:
> How performance-sensitive is this code path? 

Self-healing CAS is likely not a performance sensitive path. IIRC, in the overwhelming majority of 
experiments we have done, we rarely entered LRB slowpath. The bulk of the work is completed by the 
GC itself.

> I wonder if this could be a regular store if the field is final, final fields are trusted, and the
> class has only constructors that write to each final field once.

Java final fields are awkward in the sense that write-once guarantee does not actually exist for 
them. There is a weak constraint that language rules would refuse up-to-spec Java code to write to 
final fields, but you can still do it with Unsafe, Reflection, etc.

We used to have the final-field optimizations back in the days when we had read barriers, but 
ultimately we backed off doing smarter things there, because real-world Java code often does awkward 
things that break the properties you would have thought are guarantees, but actually are not.


> In this case, the data race is benign, I think: Outside the barrier, the
> mutator may write a non-null pointer, but then the previous pointer must
> have been null.  Several Two mutator threads may update the same field
> in the barrier, but new object address is the same on all threads.

Speaking of data races, there are secondary considerations around memory ordering, see the commit 
from here: https://bugs.openjdk.org/browse/JDK-8261495. *That one* is a large can of worms we would 
like to eventually figure out.

-Aleksey



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