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

Roman Kennke rkennke at redhat.com
Thu Apr 4 09:16:34 UTC 2019


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

Roman



More information about the hotspot-gc-dev mailing list