RFR: 8305092: Improve Thread.sleep(millis, nanos) for sub-millisecond granularity [v5]

[Alan Bateman]

On Wed, 19 Apr 2023 16:02:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
>> 
>> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
>> 
>> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
>> 
>> Additional testing:
>>   - [x] New regression test
>>   - [x] New benchmark
>>   - [x] Linux x86_64 `tier1`
>>   - [x] Linux AArch64 `tier1`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Windows fixes: align(...) is only for power-of-two alignments

test/jdk/java/lang/Thread/SleepSanity.java line 48:

> 46: 
> 47:         for (final int millis : TRY_MILLIS) {
> 48:             testTimes(() -> Thread.sleep(millis), millis, 10_000);

I wonder if 10s is enough a tolerance. JDK-8303633 has some sightings of sleep(1000) taking 5.5s. We've since changed all of these to 20s. It might be that 10s is okay, it's just that we seem to run on some test systems (Windows mostly) where we need very high tolerance for tests like this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1171736726