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

[Kelvin Nilsen]

On Mon, 11 Nov 2024 17:31:58 GMT, William Kemper <wkemper 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()?

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

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