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

[Andrew Haley]

On 4/4/19 10:22 AM, Roman Kennke wrote:
>>>> 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.)

Got it, OK.

> 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.

Maybe you have a different word for it? An oop that points to fromspace
even though there is a new copy of the same object in tospace.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671