RFR: 8230661: ZGC: Stop reloading oops in load barriers
per.liden at oracle.com
Mon Nov 11 20:41:59 UTC 2019
Erik, Stefan and I discussed the original patch and agreed to make some
adjustments. The changes are:
1) Broke out self healing logic into ZBarrier::self_heal(), and
restructured ZBarrier::barrier() and ZBarrier::weak_barrier() to use
2) Made sure the slow path is only ever executed once, even when self
healing is re-applied.
3) In the resurrection blocked window, allow weak oop refs to be healed
to the good state, not just the remapped state.
4) Moved the handshake in ZUnload::unload() out into ZHeap, to make it
more front-and-center, since it's no longer just needed for class unloading.
Testing: Passed tier 1-7
With these adjustments this patch looks good to me!
On 10/28/19 5:44 PM, Erik Österlund wrote:
> Oops. CR link was a bug link. For anyone that couldn't figure out what
> the CR link could possibly be, here it is:
> On 2019-10-28 17:38, Erik Österlund wrote:
>> In ZGC, an oop is first loaded somewhere, by e.g. JIT compiled code.
>> Then it passes a load barrier that typically does not take a slow
>> path. But when it does take a slow path, the oop is sometimes
>> reloaded, at historically three different places, and now two places.
>> 1) We used to do that as part of the mechanism that transferred
>> execution to the slow path because it was easier to write that stub
>> code if the original oop died. Since then, the compiler slow paths
>> have been rewritten to not reload the oop.
>> 2) Once in the slow path, we sometimes reload weak oops during the
>> resurrection block window, because there used to be a race when it
>> closed. After concurrent class unloading integrated, there is a
>> thread-local handshake before closing the resurrection block window.
>> Therefore, that race no longer exists (when class unloading is used).
>> 3) Once the final oop of a slow path has been determined, self-healing
>> kicks in. The self-healing CAS may fail. When it does, the oop is
>> reloaded. But this is completely unnecessary.
>> With obstacle 1 gone, and 2 and 3 having no reason to be in the code
>> any more, I propose to get rid of all reloading of the oops in the
>> slow paths, so that it becomes easier to reason about the code. The
>> object captured by the original load, is then always the same object
>> as the object found after the load barrier completes, although
>> possibly with a new bit representation.
More information about the hotspot-gc-dev