JDK 9 RFR of 8165664: (ch) sun.nio.ch.SocketAdaptor does not respect timeout in case of system date/time change and blocks

Martin Buchholz martinrb at google.com
Tue Dec 20 21:33:59 UTC 2016

On Mon, Dec 19, 2016 at 4:03 PM, David M. Lloyd <david.lloyd at redhat.com>

> Two things - IIRC it is possible on some systems for System.nanoTime()
> appear to move backwards (right?), thus you want to change "nanoTime() -
> startTime" constructs to be "max(0, nanoTime() - startTime)" (you can use 1
> instead if you want to always make progress).

nanoTime() is supposed to be monotonic.  For j.u.concurrent we once looked
at what it might take to be resilient against non-monotonicity, and gave up.

(It's true that some folks mod their jdk to get cheaper and buggier

It's true that in practice it's safer for users to avoid timeouts near
Long.MIN_VALUE or Long.MAX_VALUE.  A 146-year timeout is long enough for

> The other thing is to Martin's point, for posterity mainly because I'm
> sure this was just an oversight: you can't use a nanoTime() value (or a
> value based on it) as a deadline because it can wrap around at an
> unspecified point in time, causing deadline comparisons to fail (once you
> wrap around, you'll be < any likely deadline probably for a very long time).

We have many "final long deadline"s in j.u.concurrent.

> What you *can* do is get a nanoTime() "snapshot" into a constant field;
> then you can get an "absolute" nanoTime anytime you want (as long as you
> don't expect your program's uptime to exceed about 584 years) by doing:
> max(0, nanoTime() - startTime).

We just assume always nanoTime() - startTime >= 0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20161220/602a723a/attachment.html>

More information about the nio-dev mailing list