Why not "weakNanoTime" for jdk9?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Why not "weakNanoTime" for jdk9?

Martin Buchholz-3
We all know that nanoTime has problems.  Many (most?) users of nanoTime, especially for benchmarking or concurrent algorithms, don't really care about the monotonicity guarantee and just want a "best-effort" "as-efficient-as-possible" version of nanoTime.  Sure, some algorithms in java.util.concurrent might need to change slightly to accommodate nanoTime going backwards, but we already do this to some extent.


Some users have already created such a private nanoTime.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Why not "weakNanoTime" for jdk9?

Andrew Haley
On 03/06/2015 07:35 PM, Martin Buchholz wrote:

> We all know that nanoTime has problems.  Many (most?) users of nanoTime,
> especially for benchmarking or concurrent algorithms, don't really care
> about the monotonicity guarantee and just want a "best-effort"
> "as-efficient-as-possible" version of nanoTime.  Sure, some algorithms in
> java.util.concurrent might need to change slightly to accommodate nanoTime
> going backwards, but we already do this to some extent.
>
> http://shipilev.net/blog/2014/nanotrusting-nanotime/
>
> Some users have already created such a private nanoTime.

Indeed.  See
http://developerblog.redhat.com/2014/06/24/ultra-lightweight-high-precision-logger-for-openjdk/
for an example of an interval timer with sub-nanosecond resolution and
about 30-nanosecond latency.

It'd be nice to be able to do something close to that in pure Java.

I'm not at all sure how Aleksey managed to get 30ns latency from
System.nanoTime().  Maybe the implementation has changed since I
tried it.

Andrew.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Why not "weakNanoTime" for jdk9?

Aleksey Shipilev-2
Hi guys,

On 03/06/2015 11:14 PM, Andrew Haley wrote:
> On 03/06/2015 07:35 PM, Martin Buchholz wrote:
>> We all know that nanoTime has problems.

It would really help if you list what problems weakNanoTime is supposed
to solve.

> Many (most?) users of nanoTime,
>> especially for benchmarking or concurrent algorithms, don't really care
>> about the monotonicity guarantee and just want a "best-effort"
>> "as-efficient-as-possible" version of nanoTime.

I disagree on this premise. In the absence of proper API for CPU
affinity and CPU frequency control, we *do* need monotonicity and
linearity guarantees. Efficiency is a second-order concern here; you can
measure garbage with what you perceive as the nanosecond
precision/latency, but not exactly nanosecond accuracy. And you really
want accuracy, not precision.

Personally, I have doubts you need the single-digit-nanosecond
timestamping. The amount of in-flight ops modern CPUs do at those
timescales greatly blurs the meaning of measured time.


>> Some users have already created such a private nanoTime.
>
> Indeed.  See
> http://developerblog.redhat.com/2014/06/24/ultra-lightweight-high-precision-logger-for-openjdk/
> for an example of an interval timer with sub-nanosecond resolution and
> about 30-nanosecond latency.

I'm curious what does it mean to have sub-nanosecond resolution with 30
nanosecond latency...


> I'm not at all sure how Aleksey managed to get 30ns latency from
> System.nanoTime().  Maybe the implementation has changed since I
> tried it.

As of now, C2 inlines the System.nanoTime() call into the call to
os::javaTimeNanos in OS-specific runtime code, which is then calling
clock_gettime in glibc, which is then turns to Linux's vDSO
__vdso_clock_gettime, and quickly returns.

Juggling the clock type in os::javaTimeNanos...

CLOCK_MONOTONIC (default now):
 Benchmark                         Mode  Cnt       Score   Error  Units
 TimersBench.granularity_nanotime  avgt    5      22.424 ± 0.609  ns/op
 TimersBench.latency_nanotime      avgt    5      21.569 ± 0.341  ns/op

CLOCK_MONOTONIC_RAW:
 Benchmark                         Mode  Cnt       Score    Error  Units
 TimersBench.granularity_nanotime  avgt    5     328.502 ±  7.631  ns/op
 TimersBench.latency_nanotime      avgt    5     332.489 ± 11.013  ns/op

CLOCK_MONOTONIC_COARSE:
 Benchmark                         Mode  Cnt        Score   Error  Units
 TimersBench.granularity_nanotime  avgt    5  3999733.222 ± 0.403  ns/op
 TimersBench.latency_nanotime      avgt    5        7.046 ± 0.328  ns/op

CLOCK_MONOTONIC_RAW is apparently unsupported by my kernel, and goes to
fallback code and real syscall. Maybe what Andrew was seeing before was
the absence of vDSO opts for CLOCK_MONOTONIC.


Thanks,
-Aleksey.



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Why not "weakNanoTime" for jdk9?

Justin Sampson
Aleksey Shipilev wrote:

> It would really help if you list what problems weakNanoTime is
> supposed to solve.

I was talking to Martin about this idea recently so I'll take a shot
at describing why it's appealing to me (with the usual disclaimer
that I know I'm much less of an expert than most other folks here).

The main case I'm interested in is handling timeout calculations in
concurrent operations. The usual case should be that the operation
succeeds without timing out, and if it _does_ time out it's often
after waiting several seconds or minutes, in which case being off
by, say, a few microseconds is not a big deal.

Given those assumptions, we really want the usual case (success) to
be as fast as possible, and especially not to impose any additional
synchronization or volatile accesses. Since strict monotonicity
requires checking some kind of centrally synchronized clock state,
it fails that use case.

Furthermore, in this particular use case, it's trivial to have the
appearance of monotonicity _within_ a particular operation: Just
keep a local variable with the last time seen, and only update it if
the next time seen is greater than the last time seen. No extra
synchronization is required.

The semantics I'm imagining would be for a very fast timer that is
_usually_ monotonic, as long as the current thread stays on one
processor, with occasional blips when switching between processors.
We would still want those blips to be as small as practically
achievable, so I guess there would still have to be some occasional
synchronization to keep the fast timer within some tolerance of the
central system clock.

The way I see it, good concurrency semantics are about acknowledging
the reality of the hardware, and a strictly monotonic clock is
simply not the reality of the hardware when there's more than one
processor involved.

Actually, come to think of it, given an underlying non-monotonic
timer, the weakNanoTime method could easily provide monotonicity on
a per-thread basis without any synchronization overhead. That would
mean most concurrent code wouldn't even have to change to become
tolerant of non-monotonicity. It would just have to be made really
clear to users that different threads might see timer values out of
order relative to each other, though still within some best-effort
tolerance.

Cheers,
Justin

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Why not "weakNanoTime" for jdk9?

David Holmes-6
The VM uses whatever high-resolution "clock" the OS provides it. If
experience shows that clock is not monotonic when it is meant to be then we
added internal guards to ensure time doesn't go backwards (which means
sometimes it stands still which has its own issues). As time goes by and
things like frequency-stable, cross-core synchronized TSC becomes available,
the need for the extra monotonicity guard is reduced, and for those
situations when you know what your platform provides we could have a VM flag
to say "trust the OS timer". I know we have an open bug for that on Solaris.
A new API that simply returns whatever the OS returns may be useful for some
people. However I would not support trying to implement something direct to
the hardware in the VM.

Just be aware that the implementation of these timers varies greatly
depending on the hardware and the OS. And once you throw in virtualization
many more problems arise.

Also we'll start using CLOCK_MONOTONIC_RAW on linux at some point. (There's
a bug open for that too.)

David

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of Justin
> Sampson
> Sent: Saturday, 7 March 2015 10:42 AM
> To: Aleksey Shipilev; Andrew Haley; Martin Buchholz;
> concurrency-interest; core-libs-dev
> Subject: Re: [concurrency-interest] Why not "weakNanoTime" for jdk9?
>
>
> Aleksey Shipilev wrote:
>
> > It would really help if you list what problems weakNanoTime is
> > supposed to solve.
>
> I was talking to Martin about this idea recently so I'll take a shot
> at describing why it's appealing to me (with the usual disclaimer
> that I know I'm much less of an expert than most other folks here).
>
> The main case I'm interested in is handling timeout calculations in
> concurrent operations. The usual case should be that the operation
> succeeds without timing out, and if it _does_ time out it's often
> after waiting several seconds or minutes, in which case being off
> by, say, a few microseconds is not a big deal.
>
> Given those assumptions, we really want the usual case (success) to
> be as fast as possible, and especially not to impose any additional
> synchronization or volatile accesses. Since strict monotonicity
> requires checking some kind of centrally synchronized clock state,
> it fails that use case.
>
> Furthermore, in this particular use case, it's trivial to have the
> appearance of monotonicity _within_ a particular operation: Just
> keep a local variable with the last time seen, and only update it if
> the next time seen is greater than the last time seen. No extra
> synchronization is required.
>
> The semantics I'm imagining would be for a very fast timer that is
> _usually_ monotonic, as long as the current thread stays on one
> processor, with occasional blips when switching between processors.
> We would still want those blips to be as small as practically
> achievable, so I guess there would still have to be some occasional
> synchronization to keep the fast timer within some tolerance of the
> central system clock.
>
> The way I see it, good concurrency semantics are about acknowledging
> the reality of the hardware, and a strictly monotonic clock is
> simply not the reality of the hardware when there's more than one
> processor involved.
>
> Actually, come to think of it, given an underlying non-monotonic
> timer, the weakNanoTime method could easily provide monotonicity on
> a per-thread basis without any synchronization overhead. That would
> mean most concurrent code wouldn't even have to change to become
> tolerant of non-monotonicity. It would just have to be made really
> clear to users that different threads might see timer values out of
> order relative to each other, though still within some best-effort
> tolerance.
>
> Cheers,
> Justin
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Why not "weakNanoTime" for jdk9?

Martin Buchholz-3

Perhaps I shouldn't have tried to do anything on this front, given the cross-system difficulties that especially David has battled for years.  I'm surprised Aleksey is not a fan - I expected Aleksey to want a version of nanoTime more suitable for benchmarking.

I learned about the various "clocks" on linux/posix.  I'm surprised the low-level CLOCKs also promise monotonicity (CLOCK_MONOTONIC).  Perhaps what was really originally intended was that CLOCK_MONOTONIC was immune to the effects of sysadmin action (and also adjustments by NTP would be gradual and preserve monotonicity).

Anyways, having a version of nanoTime that does not promise monotonicity is only useful if there is a significant benefit, probably in reduced overhead.

No consensus - giving up.



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest