[9] RFR of 8069269: (spec) Defect in the System.nanoTime spec

Martin Buchholz martinrb at google.com
Sat Jan 24 17:55:23 UTC 2015


How about:

--- a/src/java.base/share/classes/java/lang/System.java
+++ b/src/java.base/share/classes/java/lang/System.java
@@ -376,19 +376,16 @@
      * the difference between two such values, obtained within the same
      * instance of a Java virtual machine, is computed.
      *
-     * <p> For example, to measure how long some code takes to execute:
+     * <p>For example, to measure how long some code takes to execute:
      *  <pre> {@code
      * long startTime = System.nanoTime();
      * // ... the code being measured ...
-     * long estimatedTime = System.nanoTime() - startTime;}</pre>
+     * long elapsedNanos = System.nanoTime() - startTime;}</pre>
      *
-     * <p>To compare two nanoTime values
-     *  <pre> {@code
-     * long t0 = System.nanoTime();
-     * ...
-     * long t1 = System.nanoTime();}</pre>
-     *
-     * one should use {@code t1 - t0 < 0}, not {@code t1 < t0},
+     * <p>To compare elapsed time against a timeout, use <pre> {@code
+     * if (System.nanoTime() - startTime >= timeoutNanos) ...}</pre>
+     * instead of <pre> {@code
+     * if (System.nanoTime() >= startTime + timeoutNanos) ...}</pre>
      * because of the possibility of numerical overflow.
      *
      * @return the current value of the running Java Virtual Machine's


On Fri, Jan 23, 2015 at 6:16 PM, Martin Buchholz <martinrb at google.com>
wrote:

> I'm agreeing with what you say here, but t0 and t1 are symmetrical, so
> still cannot understand why you want to switch them in the javadoc.
>
> On Fri, Jan 23, 2015 at 4:27 PM, Brian Burkhalter <
> brian.burkhalter at oracle.com> wrote:
>
>>
>> On Jan 23, 2015, at 2:16 PM, Martin Buchholz <martinrb at google.com> wrote:
>>
>> I don't get it.  t0 and t1 are supposed to be symmetrical (perhaps
>> obtained in different threads).
>> Switching them around doesn't change anything.  And correctness in the
>> face of two's complement numerical overflow is the whole point of the
>> example!
>>
>>
>> My take on it is, for example, given the (non-overflowing) mathematical
>> quantities
>>
>> T0 = 2^63 - 42
>> T1 = 2^63
>>
>> and the Java variables
>>
>> long t0 = Long.MAX_VALUE - 41;
>> long t1 = t0 + 42;
>>
>> then the Java logical expression (t0 - t1) < 0 is equivalent to the
>> mathematical inequality T0 < T1 which is what would want when comparing two
>> such values.
>>
>
>



More information about the core-libs-dev mailing list