RFR: 8342444: Shenandoah: Uncommit regions from a separate, STS aware thread
Kelvin Nilsen
kdnilsen at openjdk.org
Tue Nov 12 17:32:01 UTC 2024
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
More information about the hotspot-gc-dev
mailing list