[concurrency-interest] deadline and long overflow

Martin Buchholz martinrb at google.com
Wed Apr 20 15:35:04 EDT 2016

On Wed, Apr 20, 2016 at 12:26 PM, Justin Sampson <jsampson at guidewire.com> wrote:
> For the MAX_VALUE case, there's only an overflow bug if nanoTime()
> goes backward, causing some negative value to be subtracted from
> MAX_VALUE in the code above. That should never happen in HotSpot,
> but there have been occasional bugs and experimental "optimizations"
> in other JVMs that allow it to be seen. JDK code is NOT written to
> be robust to that possibility, which would slightly complicate the
> code everywhere that a timeout is checked.

While JDK implementations are required to provide nanoTime
monotonicity, it is an onerous requirement and so relying on it is a
kind of stress test for VM implementers.  If I was writing application
code with "forever" timeouts, I would use MAX_VALUE/2 NANOSECONDS
which is still "forever enough".  We once investigated what it would
take to make jsr166 code robust against nanoTime occasionally going
backwards (invariably with MIN_VALUE or MAX_VALUE nanos), and the
changes required were too invasive (and untestable!)

More information about the Concurrency-interest mailing list