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?
> 
> Whenever we start an evacuation phase, we pre-evacuate everything that's 
> referenced by stack or registers, and update those stack slots and 
> registers. (We did that with the old barrier-scheme too.)

Also, outside of evacuation phase, the LRB resolves the oop by reading 
the fwd ptr.

I am not totally sure what you mean by 'stale' though.

Roman