RDTSCP and System.nanoTime

[David Holmes]

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.

Cheers,
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 processors.
> 
> 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:
> 
> http://www.intel.com/Assets/PDF/manual/253668.pdf
> 
> 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.
> 
> Thanks!
> 
> Jeremy