RFR: 8256938: Improve remembered set sampling task scheduling

[Stefan Johansson]

On Wed, 25 Nov 2020 16:13:00 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> I tried to cover the why in the comment for `should_reschedule()`:
>>   // To avoid extensive rescheduling if the task is executed a bit early. The task is
>>   // only rescheduled if the expected time is more than 1ms away.
>>   bool should_reschedule() {
>>     return reschedule_delay_ms() > 1;
>>   }
>> But maybe this comment needs to be clearer. The problem is that when calculating the `reschedule_delay_ms()` the `since_last_gc.milliseconds()` call might round down to 299ms (when the interval is 300ms), even if we are just a microsecond away. And since there are different timestamps used to decide if the task is ready to run, we can end up in this situation.
>> 
>> Having this comment is one of the reasons I used two functions even if it meant calculating the delay two times. Makes sense? Would you like more info in the comment?
>
>> might round down to 299ms (when the interval is 300ms), even if we are just a microsecond away.
> 
> In that case, using `> 0` will just delay the start of the task for ~1ms, right? Doesn't sound like a serious problem. Similarly, `> 1` could cause the task to be run ~1ms earlier than its intended 300ms interval, right? Either way is fine, but I think `>0` is less surprising.

One would think :) But the rounding comes back the other way around, if we reschedule to 1ms in the future, the service thread will look at the timestamp a bit later and then the time left will be rounded down to 0ms. So the effect will be that the task is rescheduled and run instantly over and over until the time since GC is over the interval.

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

PR: https://git.openjdk.java.net/jdk/pull/1428