RFR: 8286829: Shenandoah: fix Shenandoah Loom support

[Aleksey Shipilev]

On Fri, 27 May 2022 14:52:19 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)

src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 529:

> 527:   heap->set_concurrent_mark_in_progress(true);
> 528: 
> 529:   _mark.start_mark();

Style: call `start_mark()` here maybe? Matches the use of `end_mark()` elsewhere.

src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp line 73:

> 71:     if (obj->is_instance()) {
> 72:       // Case 1: Normal oop, process as usual.
> 73:       if (ContinuationGCSupport::relativize_stack_chunk(obj)) {

Ooof, this is very hot code path. Is there any way to do this without injecting the code here?

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

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