[concurrency-interest] deadline and long overflow

Peter Veentjer alarmnummer at gmail.com
Sat Apr 23 00:32:57 EDT 2016

I want to thank all, especially Martin, for their answers.

On Wed, Apr 20, 2016 at 10:35 PM, Martin Buchholz <martinrb at google.com>

> 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!)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20160423/2acaa60b/attachment.html>

More information about the Concurrency-interest mailing list