RFR: 8260106: Shenandoah: simplify maybe_update_with_forwarded and related code [v5]

[Roman Kennke]

On Mon, 25 Jan 2021 14:37:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have a block in `ShenandoahHeap::maybe_update_with_forwarded` that is irrelevant after JDK-8231086. Additionally, "resolve and update" paths are really only used by STW GCs, and thus do not require atomic updates. This leads to considerable simplifications in the code, and improves performance on the common paths (especially in fastdebug builds that drop many irrelevant asserts).
>> 
>> Additional testing:
>>  - [x] `hotspot_gc_shenandoah`
>>  - [x] `tier1` with Shenandoah
>>  - [x] `tier2` with Shenandoah
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Renames
>  - Eliminate UpdateRefsMode altogether
>  - Simplify update_with_forwarded
>  - Comment updates
>  - Merge branch 'master' into JDK-8260106-shenandoah-simplify-updates
>  - Simplify ShenandoahUpdateHeapRefsTask
>  - Fix up generic update references too, introduce CONC_UPDATE
>  - Simplify further after RESOLVE removal
>  - Merge branch 'master' into JDK-8260106-shenandoah-simplify-updates
>  - Rename maybe to atomic
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/ca20c63c...f2c1ecdb

This is indeed much better! I only have a very minor comment,

src/hotspot/share/gc/shenandoah/shenandoahOopClosures.hpp line 192:

> 190: class ShenandoahUpdateRefsSuperClosure : public BasicOopIterateClosure {
> 191: protected:
> 192:   ShenandoahHeap* _heap;

While moving it around, maybe make it Shenandoah* const too?

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

Marked as reviewed by rkennke (Reviewer).

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