[master] RFR: Implement Shenandoah support [v23]

[Zhengyu Gu]

On Wed, 20 Apr 2022 15:01:23 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> 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?
>
> At 6, worker 1 cannot win while the from-space object has INFLATING in its header. It will always try to CAS with the real original header. That is why we need the loop in the code that installs the forwarding pointer to retry when encountering INFLATING.

Line #[79](https://github.com/openjdk/lilliput/blob/master/src/hotspot/share/gc/shenandoah/shenandoahForwarding.inline.hpp#L79) is not a stable read, right? so it can see `INFLATING` markword. I don't see why CAS at Line#[85](https://github.com/openjdk/lilliput/blob/master/src/hotspot/share/gc/shenandoah/shenandoahForwarding.inline.hpp#L85) has to fail? it may return `prev_mark = INFLATING`, no?

Also, what prevents the copy [here](https://github.com/openjdk/lilliput/blob/master/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp#L333) creates a to-space object with `INFLATING` markword?

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

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