Official precise timer in 1.5

[abies]

I have found it

In System class, according to JSR 166 (strange place for such thing…)

nanoTime

public static long nanoTime()

    Returns the current value of the system timer, in nanoseconds.

    This method can only be used to measure elapsed time and is not related to any other notion of system or wall-clock time. The value returned represents nanoseconds since some fixed but arbitrary time (perhaps in the future, so values may be negative). This method provides nanosecond precision, but not necessarily nanosecond accuracy. No guarantees are made about how frequently values change. Differences in successive calls that span greater than approximately 292 years (263 nanoseconds) will not accurately compute elapsed time due to numerical overflow.

    For example, to measure how long some code takes to execute:

   long startTime = System.nanoTime();
   // ... the code being measured ...
   long estimatedTime = System.nanoTime() - startTime;
 

    Returns:
        The current value of the system timer, in nanoseconds.
    Since:
        1.5

[blahblahblahh]

[quote]I have found it

public static long nanoTime()

 This method provides nanosecond precision, but not necessarily nanosecond accuracy. No guarantees are made about how frequently values change. Differences in successive calls that span greater than approximately 292 years (263 nanoseconds) will not accurately compute elapsed time due to numerical overflow.

[/quote]
Oh gawd, I hope that doesn’t make it in as final documentation - I didn’t think it could get any worse than it is now, but…

292 years == 263 nanoseconds is clearly a typo (I hope!), but “not necessarily nanosecond accuracy…no guarantees are made about how frequently values change”. Doesn’t that mean it’s completely useless? It may return a difference of 5 after 240 nanoseconds have elapsed (no guarantee, etc)?

[abies]

It is about same useless as currentTimeMillis() as far as specificiation is concerned. It is just system dependent. What we can hope for, is that on most systems it will be implemented using high precision timers, as there are no technical reasons to not use them. And I think that they will just use same thing which was available in java3d, so I’m not afraid about the details.

[Orangy_Tang]

Well I’d assume its just the timer from sun.misc.Perf.* renamed and made official, in which case the accuracy seems to be pretty good.

Heres hoping at any rate ;D

[rreyelts]

I have found it

Darn - you beat me to it.

I’m very happy to see the new system timer. I’m also very happy to see all of Doug Lea’s multithreading library making it into Java. I’ve been using it for years now, but it really is the kind of thing that should have been a part of the core library since the beginning.

God bless,
-Toby Reyelts

[cfmdobbie]

[quote]Differences in successive calls that span greater than approximately 292 years […] will not accurately compute elapsed time due to numerical overflow.
[/quote]
Damn! My application needs to stay up for more that 300 years at a time. Where do I submit an RFE to get this fixed?

A long time ago, someone I worked with became concerned with a particular counter’s potential to roll over and cause havoc with our system. I did a few calculations, and related the happy news that we were safe for the next 280 million years, or so…

[quote][…] but “not necessarily nanosecond accuracy…no guarantees are made about how frequently values change”. Doesn’t that mean it’s completely useless? It may return a difference of 5 after 240 nanoseconds have elapsed (no guarantee, etc)?
[/quote]
No worse than what we’ve already got. I’d still prefer a way of querying the timer’s actual accuracy, if only for use as a guideline.

[MGodehardt]

Great, this will end the high performance discussions and problems.

But ITS NOT OVER UNTIL ITS OVER.

I hope we get 1.5 in the next 2 months

[swpalmer]

[quote]I’d still prefer a way of querying the timer’s actual accuracy, if only for use as a guideline.
[/quote]
Yes… this is important. Is there such an API? or do I have to go vote on a bug ?

[rreyelts]

You can’t create a bug, because it’s just a JSR in public review. You can give your feedback on it there, although, I don’t know how receptive they will be considering the JSR is on multi-threaded programming, and not system timers.

God bless,
-Toby Reyelts

[swpalmer]

I asked the Spec lead about providing a method to query the resolution, here is his response:

We considered options along these lines, but none of them work out
very well. Among the problems are:

1. The update frequency need not be constant, including on some
   versions of Windows.

2. The returned value may be synthetic, as it is on most
   multiprocesors, that use ntp-like adjustments to keep processor clocks
   in sync, so there is no meaningful granularity to report.

3. The internal granularities governing delay/wait times (especially
   in JSR166 timeout methods) may be different than elapsed-time
   granularities.

Of course, these kinds of problems can also hit you if you use
internal loops to estimate. In either case you are left with the
best-effort intent of nanoTime: It is the most precise timer available
on the platform.

Any further ideas or suggestions would be welcome!

-Doug

[princec]

Although it’s not perfect (like our API ) it’ll do for all gaming applications so best just get on with diverting our attention to more meaningful requirements.

Cas

[Jeff]

Hmm,

I’m not sure this is really our timer.

let me ask around.

As already pointed out it suffers from the same alck of gaurantees that got us in trouble with currentTimeMillis…

JK

[cfmdobbie]

Have we now got a multitude of different timers from Sun as well? ;D

Ahh, all good entertainment…!

[Jeff]

Okay,
Well, this IS what became of our timer.

Right now I’m pushing for inlcusion in the docs of language such as:
“The VM is required to return this time to the best possible precision on the platform.”

The idea being that this way, if an implementation sucks, its an inarguable bug.

We’ll see how far I get…

JK

[Jeff]

Okay, i got this change. Thank Josh Block and Doug Lea:

"We replaced first sentence of nanoTime spec with:

 * Returns the current value of the most precise available system
 * timer, in nanoseconds.

Which ought to have the right effect."

Its now required to be the best precision possible. If its not, and you can show a way to get higher precision, you can log it as a bug against the VM (Ours or anyone elses )

JK

[divzero]

nice going! ;D

Thank you,

Will.

[oNyx]

You da man Jeff :-*

1.5! ;D

[aikarele]

Now Sun has officially closed Bug 4478186, a.k.a. “Add a high-resolution timer to the API”:

Release Fixed: tiger-beta

This RFE has been addressed in the context of JSR-166 (java.util.concurrent).

Use java.lang.System.nanoTime

xxxxx@xxxxx 2003-10-24

[Abuse]

[quote]Now Sun has officially closed Bug 4478186, a.k.a. “Add a high-resolution timer to the API”:

Release Fixed: tiger-beta

This RFE has been addressed in the context of JSR-166 (java.util.concurrent).

Use java.lang.System.nanoTime

xxxxx@xxxxx 2003-10-24
[/quote]
hehe, u got the email as well?

[MGodehardt]

When will JDK 1.5 released ?