RFR: 8370039: GenShen: array copy SATB barrier improvements

William Kemper wkemper at openjdk.org
Mon Nov 10 23:20:03 UTC 2025


On Mon, 10 Nov 2025 21:55:37 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> When an array copy happens concurrently with old and young marking, Shenandoah's generational mode walks over the array twice. This is unnecessary and increases the workload for marking threads. It also has been unconditionally enqueuing old references during a young mark. This is also unnecessary and also increases marking workload. Finally, the barrier went through a somewhat complicated decision process based on affiliation of the region where the array resides. However, the barrier must consider the affiliation of objects that are pointed at by array elements.
>
> src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 413:
> 
>> 411:         }
>> 412:         shenandoah_assert_forwarded_except(elem_ptr, obj, _heap->cancelled_gc());
>> 413:         ShenandoahHeap::atomic_update_oop(fwd, elem_ptr, o);
> 
> Is the comment at the start of arraycopy_work() still relevant?  The description of the PR suggests that we will no longer call arraycopy_work() twice, but I'm not sure I fully understand the context of that statement.

We used to call this twice (as `arraycopy_marking`  _for each object_ if young and old marking were both in progress.. The comment at the start is trying to explain how the `arraycopy_work` could be called with different template parameters depending on the `gc_state`.  It is confusingly worded, but I believe the comment is correct and the code is wrong here. The way the code is in the PR, it would effectively turn off the old SATB during young evacuation and young update-refs, which is not what we want. Good catch!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28183#discussion_r2512294938


More information about the hotspot-gc-dev mailing list