RDTSCP and System.nanoTime
David.Holmes at oracle.com
Fri Aug 13 16:29:24 PDT 2010
Jeremy Manson said the following on 08/14/10 03:52:
> If the TSC is reliable, and we know its rate, then currentTimeMillis
> can be calculated by taking the time the usual way once at (roughly)
> the same time as you read the TSC. You can then figure out the time
> later by simply reading the TSC and doing arithmetic. You would want
> to resynchronize pretty often, but not more than, say, once every few
I have no problem with the OS doing this, but I wouldn't want the VM to
have to do it. :)
> I read "IA32_TSC_AUX provides a 32-bit field that is initialized by
> privileged software with a signature value (for example, a logical
> processor ID)." as meaning that it had to be a value unique to that
> processor, but now that you mention it, I'm not sure where "signature"
> is defined. Presumably, something very definite and/or well-defined
> is done by Linux and Windows.
True even if not a processor id it likely has to be unique to a processor.
> It sounds as if the best thing to do is wait and see how these
> features get implemented. There are probably kernel people we can
I'm sure if you search lkml there will be some existing discussions on
> On Thu, Aug 12, 2010 at 1:37 PM, David Holmes <David.Holmes at oracle.com> wrote:
>> Hi Jeremy,
>> nanoTime has always been implemented using the highest-resolution time
>> source exposed by the OS, so as soon as Linux uses a reliable-TSC (for
>> CLOCK_MONOTONIC) the VM would utilize it. (Solaris jumps through hoops to
>> make the TSC "reliable").
>> Doing a CPU specific nanoTime could be entertained if it were worthwhile.
>> (But people have more issues with currentTimeMillis() performance than
>> nanoTime in general).
>> It's a pity that Intel didn't also make the frequency available as
>> calculating that is a PITA. :)
>> Also note:
>> "IA32_TSC_AUX provides a 32-bit field that is initialized by privileged
>> software with a signature value (for example, a logical processor ID)."
>> the content of the aux reg is not required to be a processor id. I don't see
>> anything that tells you how to find out what it actually is.
>> David Holmes
>> Jeremy Manson said the following on 08/13/10 04:01:
>>> Hi folks,
>>> Motivation: the overhead of System.nanoTime and
>>> System.currentTimeMillis on Linux is pretty awful if you are trying to
>>> use them frequently.
>>> The motivation for not replacing System.nanoTime with a RDTSC-based
>>> approach was, as I understand it, based on two things:
>>> 1) The older timestamp counters were processor-cycle based, and shut
>>> down when the system was in power-savings mode, and
>>> 2) It used to be impossible to compensate for TSC drift between
>>> The Nehalem architecture seems to have fixed these problems with
>>> Invariant TSC (which runs at a constant rate regardless of power
>>> state) and support for the IA32_TSC_AUX register (which tells you what
>>> CPU you are using when you read the counter). See section 16.11.1 and
>>> 16.11.2 of:
>>> I don't see code that looks like this in os_linux.cpp, so I was
>>> wondering if you guys had any plans to support it.
More information about the hotspot-runtime-dev