[master] RFR: Implement Shenandoah support [v23]

[Zhengyu Gu]

On Wed, 20 Apr 2022 12:41:16 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahForwarding.inline.hpp line 91:
>> 
>>> 89:     } else if (prev_mark == markWord::INFLATING()) {
>>> 90:       // This happens when we encounter a stack-locked object in from-space.
>>> 91:       // Busy-wait for completion.
>> 
>> Can you explain how this can happen? I think we can only inflate to-space object, e.g. apply LRB first.
>
> The trouble is that we need to fetch the size of an object during evacuation *before* the object is guaranteed to be in to-space. If we encounter an object that is stack-locked there, we may race with another thread which could, in the meantime, succeed to evacuate and unlock the object, in which case the stack-lock that we fetched from the from-space object would be invalid. We prevent that by CASing 0 into the header (e.g. the INFLATING marker) - this prevents both evacuation and unlocking, but it requires that our evacuation CAS is aware of it and retries when that happens.

Hmm... it hurts my head to think about if we can see this transition state in from-space object, e.g. `ShenandoahForwarding::is_forwarded()` can return bogus result? all the from-space reads have to be stable reads?

-------------

PR: https://git.openjdk.java.net/lilliput/pull/32