RFR: 8255019: Shenandoah: Split STW and concurrent mark into separate classes [v14]

[Roman Kennke]

On Fri, 20 Nov 2020 17:47:17 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> This is the first part of refactoring, that aims to isolate three Shenandoah GC modes (concurrent, degenerated and full gc).
>> 
>> Shenandoah started with two GC modes, concurrent and full gc, with minimal shared code, mainly in mark phase. After introducing degenerated GC, it shared quite large portion of code with concurrent GC, with the concept that degenerated GC can simply pick up remaining work of concurrent GC in STW mode.
>> 
>> It was not a big problem at that time, since concurrent GC also processed roots STW. Since Shenandoah gradually moved root processing into concurrent phase, code started to diverge, that made code hard to reason and maintain.
>> 
>> First step, I would like to split STW and concurrent mark, so that:
>> 1) Code has to special case for STW and concurrent mark.
>> 2) STW mark does not need to rendezvous workers between root mark and the rest of mark
>> 3) STW mark does not need to activate SATB barrier and drain SATB buffers.
>> 4) STW mark does not need to remark some of roots.
>> 
>> The patch mainly just shuffles code.  Creates a base class ShenandoahMark, and moved shared code (from current shenandoahConcurrentMark) into this base class. I did 'git mv shenandoahConcurrentMark.inline.hpp  shenandoahMark.inline.hpp, but git does not seem to reflect that.
>> 
>> A few changes:
>> 1) Moved task queue set from ShenandoahConcurrentMark to ShenandoahHeap. ShenandoahMark and its subclasses are stateless. Instead, mark states are maintained in task queue, mark bitmap and SATB buffers, so that they can be created on demand.
>> 2) Split ShenandoahConcurrentRootScanner template to ShenandoahConcurrentRootScanner and ShenandoahSTWRootScanner
>> 3) Split code inside op_final_mark code into finish_mark and prepare_evacuation helper functions.
>> 4) Made ShenandoahMarkCompact stack allocated (as well as ShenandoahConcurrentGC and ShenandoahDegeneratedGC in upcoming refactoring)
>
> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge
>  - Moved task queues to marking context
>  - Merge
>  - Merge branch 'master' into JDK-8255019-sh-mark
>  - Merge branch 'master' into JDK-8255019-sh-mark
>  - Merge branch 'master' into JDK-8255019-sh-mark
>  - Removed obsoleted class
>  - Merge branch 'master' into JDK-8255019-sh-mark
>  - Merge branch 'master' into JDK-8255019-sh-mark
>  - Merge branch 'master' into JDK-8255019-sh-mark
>  - ... and 10 more: https://git.openjdk.java.net/jdk/compare/98a5d5a6...8c58f6f4

Good work! I have a few questions...

src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 373:

> 371:   // call the entry method below
> 372:   void vmop_entry_init_mark(ShenandoahConcurrentMark* mark);
> 373:   void vmop_entry_final_mark(ShenandoahConcurrentMark* mark);

I find it odd that those entries now take ShenandoahConcurrentMark instance as argument, while all others don't. In particular because it implies it is the concurrent version anyway. Why is this necessary?

src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp line 119:

> 117:     // b. Cancel concurrent mark, if in progress
> 118:     if (heap->is_concurrent_mark_in_progress()) {
> 119:       ShenandoahConcurrentMark::cancel();

While cancel() doesn't exactly need to be an instance-method, it feels strange to do a static call here...

src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp line 126:

> 124:     // c. Update roots if this full GC is due to evac-oom, which may carry from-space pointers in roots.
> 125:     if (has_forwarded_objects) {
> 126:       ShenandoahConcurrentMark::update_roots(ShenandoahPhaseTimings::full_gc_update_roots);

Same as with cancel() above.

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

Changes requested by rkennke (Reviewer).

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