RFR: 8342444: Shenandoah: Uncommit regions from a separate, STS aware thread

[Kelvin Nilsen]

On Mon, 11 Nov 2024 18:19:33 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Currently, Shenandoah uncommits regions from its control thread. The control thread is responsible for starting GC cycles in a timely fashion. Uncommitting memory from this thread may introduce unwanted delays in the control thread's response to GC pressure.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 555:
> 
>> 553:     while (region != nullptr) {
>> 554:       {
>> 555:         ShenandoahHeapLocker locker(heap->lock());
> 
> Was it a bug that previous version of this code did not acquire the heap lock?
> 
> Is the lock required for the entirety of time that we are clearing the bitmap?  Or is it just required to get a trustworthy check on is_bitmap_slice_committed()?

After reading more of this PR, I believe we need the heap lock to get a reliable signal of bitmap_slice_committed().  But I believe we do not need the heap lock for ctx->clear_bitmap(region) so would prefer to move that outside the lock, unless I am misunderstanding.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22019#discussion_r1837053704