Why not "weakNanoTime" for jdk9?

[Aleksey Shipilev]

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.