RFR: 8336685: Shenandoah: Remove experimental incremental update mode

[William Kemper]

On Wed, 24 Jul 2024 18:25:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We've reason to believe that this mode is very rarely used and its maintenance has become a burden for future development.
>> 
>> ## Testing
>> * hotspot_gc_shenandoah
>> * dacapo
>> * diluvian
>> * extremem
>> * hyperalloc
>> * specjbb2015
>> * specjvm2008
>
> src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp line 571:
> 
>> 569:   /* ==== Apply keep-alive barrier, if required (e.g., to inhibit weak reference resurrection) ==== */
>> 570:   if (ShenandoahBarrierSet::need_keep_alive_barrier(decorators, type)) {
>> 571:     if (ShenandoahSATBBarrier) {
> 
> A bit weird to replace IU with SATB barrier here.

@shipilev [The original code](https://github.com/openjdk/jdk/pull/20316/files#diff-cb01b36a8c7017c9e21645a0ff9075897e5bfa67ae37d4f0d69ccc582656ec31L71) used the function `iu_barrier` to emit the pre-write barrier for both SATB and IU modes. This only happened in the `ppc` port. Other platforms just invoke the function to emit the `satb_write_barrier` directly here (see [x86](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp#L580), for example).

@kdnilsen No, `need_keep_alive_barrier` may be true in SATB mode. The use of the barrier here is to make sure weak references that get loaded during mark are added to the SATB buffer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20316#discussion_r1690320078