On Wed, 29 Mar 2023 11:28:53 GMT, Aleksey Shipilev <sh...@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`
src/hotspot/share/runtime/javaThread.cpp line 1981:
> 1979: }
> 1980:
> 1981: bool JavaThread::sleep(jlong millis, jint nanos) {
You don't need the overloads at this level - the incoming call should always
have millis and nanos, even if nanos is zero.
src/hotspot/share/utilities/globalDefinitions.hpp line 351:
> 349: millis = max_secs * MILLIUNITS;
> 350: }
> 351: return millis_to_nanos(millis) + nanos;
This can now exceed the max_secs bound though.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1152639527
PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1152640056
