RFR: 8340490: Shenandoah: Optimize ShenandoahPacer [v2]

[Xiaolong Peng]

On Fri, 20 Sep 2024 18:27:14 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> I am trying to remember why we even bothered to go into negative budget on this path, and then waited for it to recover. I think it is from here: https://mail.openjdk.org/pipermail/shenandoah-dev/2018-April/005559.html. AFAICS, the intent for that fix was to make sure that unsuccessful pacing claim the budget, which this patch also does. And given it apparently improves performance, I don't mind it going in.
> 
> Comprehension question: the actual improvement comes from waiting in 1ms slices, not from anything else? In retrospect, _it is_ silly to wait until the deadline before attempting to claim the pacing budget.

It is primarily from the  algorithm change with 1ms slices. 

The behavior has been changed in the new algorithm with 1ms slices, e.g. when 10 threads seeming insufficient budget at the same time, assuming each of them claim 100 budget, in old algorithm all of the 10 threads forcefully claim the budget and result in `-1000` budget, them it need other mutators to release at least `1000` or they have to wait for up to 10ms even they may be woken up by the ShenandoahPeriodicPacerNotifyTask. In new algorithm, each threads will try to claim 100 budget every 1ms and don't need to wait other mutators to release at least `1000`, as soon as enough budget(>100) is returned, some thread(s) will compete others and proceed.

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

PR Comment: https://git.openjdk.org/jdk/pull/21099#issuecomment-2364322181