RFR: 8335356: Shenandoah: Improve concurrent cleanup locking

[Aleksey Shipilev]

On Wed, 10 Jul 2024 07:34:39 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> Also, I am thinking that a straight count might perform as well and the time-based solution almost seems overengineered to me -- or at least I'd like to see evidence that that engineering effort is worth the resulting bang for a service level metric such as latency or throughput.

I suggested the time-based approach to Xiaolong to side-step the discussion about the "reasonable" batch size. The good batch size would fluctuate between the machines, heap sizes, region counts. Since we are doing this whole dance to avoid hoarding the lock for a long time to avoid tail latencies increase for allocators waiting for the same lock, it is also more reasonable to just track the time directly here.

This is not to mention that fastdebug builds would zap the unused heap, which makes cleanup orders of magnitude slower, and the large batch sizes would hoard the lock way too much, deviating from the "normal" release behavior. Time-based approach accomodates this as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/20086#issuecomment-2219822121