RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v3]

[Aleksey Shipilev]

On Tue, 31 May 2022 17:45:34 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review the patch that fixes Loom support in Shenandoah GC.
>> 
>> - stackChunkOop is a special oop that contains stack metadata, we need to utilize nmethod entry barrier to mark, evacuate and update stack metadata.
>> - During evacuation and reference updating phase, we can not guarantee all metadata in stackChunkOop is deeply good, so I force it to take slow path for the correctness, will try to optimize it later in separate CR.
>> - Shenandoah uses similar way to arm and disarm nmethod as the new mechanism introduced in JDK-8284161. We may want to migrate to it in followup CR.
>> 
>> Test:  
>> - [x] tier1 with ShenandoahGC  (Linux x86_64 and Windows x64)
>> - [x] tier2 with Shenandoah GC (Linux x86_64 and Windows x64) 
>> - [x] hotspot_gc_shenandoah  on Linux x86_32
>> - [x] tier1 with ShenandoahGC + Loom (Linux x86_64 and Windows x64)
>> - [x] tier2 with ShenandoahGC + Loom (Linux x86_64 and Windows x64)
>
> Zhengyu Gu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix
>  - NMethod::heal_nmethod() does not need to handle ref-update

I still have a question: now that closures drop `do_metadata`, does that mean we always traverse metadata now? Which means we can remove half of the closures? For example, `ShenandoahMarkUpdateRefsClosure` and `ShenandoahMarkUpdateRefsMetadataClosure` are pretty much the same, right? We can leave `ShenandoahMarkUpdateRefsClosure` only then?

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

PR: https://git.openjdk.java.net/jdk/pull/8924