[master] RFR: Implement Shenandoah support [v23]

[Roman Kennke]

On Wed, 20 Apr 2022 12:58:09 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

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

is_forwarded() will always be good: 00 means stack-locked or inflating, 01 means unlocked, 10 means monitor and 11 means forwarded.
There are places where from-space header accesses (to get object size and/or Klass*) requires extra care: all those cases have been changed to use the new ShenandoahObjectUtils functions instead of the usual stuff, and this helper takes care of dealing with concurrent evacuation (i.e. the otherwise unexpected 11 state).

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

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