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

[Kelvin Nilsen]

On Tue, 12 Nov 2024 19:20:09 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> So, wait a sec. This code is in `ShenandoahResetBitmapTask`, so it can run in parallel. Putting a lock here inhibits parallelism. I understand the failure mode, but I think we should really be optimizing for the case when `ShenandoahUncommit` is not enabled (e.g. `-Xmx` == `-Xms`).
>> 
>> Sounds like there is a hassle in allowing concurrent uncommit to overlap with the GC cycle. In addition to this particular problem, we might be stealing cycles from the GC threads and take additional TTSP lag to park the uncommitter for the in-cycle GC pauses. I have no clear solution for this yet, but I think we need to explore if we can suspend the uncommit before going into GC cycle...
>
> We could have the control and uncommit threads coordinate their efforts. In the worst case, it could mean delaying concurrent reset while the control thread waits for the uncommit thread to yield.
> 
> We could also try a more targeted lock only for the region's bitmap slice, but it doesn't seem right that one thread would be trying to clear a bitmap, while the other is trying to uncommit it. A lock could preserve technical correctness, but contention here would just mean that one thread would have wasted its time (either clearing a bitmap that is then uncommitted, or attempting to clear a bitmap that was first uncommitted (in this case, we would need the control thread to detect this and skip the region)).

Can we open a ticket to consider future improved concurrency by moving clear_bitmap(region) outside the global heap lock?

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

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