[master] RFR: Implement Shenandoah support [v23]

[Zhengyu Gu]

On Wed, 20 Apr 2022 14:22:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

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

Okay, let's consider following scenario:
1. worker 1 tries to evac obj, reads its header and it is not `marked`
2. worker 1 reads obj size and allocates to-space obj
3. worker 2 tried to evac the same obj, reads its header and it is still not `marked`
4. worker 2 tries to read obj size and temporary installs `INFLATING` mark word
5. worker 1 copies obj to to-space with `INFLATING` mark word (?)
6. worker 1 wins CAS, so to-space obj has `INFLATING' mark word?

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

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