RFR: JDK-8221766: Load-reference barriers for Shenandoah

[Roman Kennke]

>> The main difference is that instead of ensuring correct invariant when
>> we store anything into the heap (e.g. read-barrier before reads,
>> write-barrier before writes, plus a bunch of other stuff), we ensure the
>> strong invariance on objects when they get loaded, by employing what is
>> currently our write-barrier.
> 
> OK, so how does this work? Sure, the OOP load promotes an object to
> tospace, but how do you ensure that the OOP doesn't become stale when
> a later phase occurs?

The nice property of the LRB approach is that it maintains a *strong* 
invariant over the livecycle of an oop, meaning that we guarantee that 
an oop that is currently in-use (on stack or register), is in to-space.

1. Whenver we load an oop, we do the usual write-barrier protocol to 
evacuate it (if needed) or resolve the fwd ptr (otherwise).
2. Whenever anything happens that could make an oop stale, we ensure 
that the oop is updated. Specifically, in the init-evac pause, we go 
over all oops in registers, stack and code (== constants), and pre-evac 
and update the oops.

This strong invariant makes it much easier to reason about the lifecycle 
of oops in the VM. For example, there is no need to worry about 
comparing oops (cmpxchg-oop remains funny though), no need to worry 
about resolving oops properly in intrinsics, no need to ensure that oops 
stored to fields are good, etc.

Does all that answer your question? :-)

Roman