[concurrency-interest] tsc register

Nathan Reynolds nathan.reynolds at oracle.com
Tue Jan 10 11:20:35 EST 2012

The tsc register on older processors did not increment at the same 
rate.  If a core slept or slowed down then the tsc register would stop 
or slow down its increments.  More modern processors guarantee that tsc 
register increments at a fixed frequency.  If you are working on Linux, 
cpuinfo (?) could report the const_tsc flag.  This means that the 
processor and OS recognize that this feature is on the processor.

The tsc register is not synchronized across sockets.  This is something 
Oracle has asked Intel to enhance many times.  It is a very difficult 
problem to solve.  However, more modern Linux kernels will (?) 
synchronize the tsc register at startup so that it is impossible to read 
the tsc register on two different cores and see that the 2^(n)^(d) value 
is smaller.  This does not mean that the tsc register is synchronized.  
It only means that two threads running on different cores will hopefully 
never see the tsc "move backwards".

There is no guarantee that once the tsc register is synchronized across 
sockets that it will remain so.  Some processors are hot swappable.  The 
newly added processor is not going to have the correct tsc register 
value.  Furthermore, the OS is free to reset the tsc value at any time.

If I understand correctly, the HotSpot JVM will guarantee that 
System.nanoTime() never moves backwards.  It reads the tsc register with 
each call (?).  It the compares the read value with the last read 
value.  If the read value is < the last read value, then the last read 
value is returned.  If the read value is > the last read value, then the 
last read value is updated and the read value is returned.  Updating the 
last read value requires a CAS.  This CAS can lead to scalability 
bottlenecks if System.nanoTime() is called too frequently.  I am not 
sure if a better algorithm has been devised to fix this CAS contention.  
I kind of remember it being talked about.

I think the JVMs will default to more stable clock sources with worse 
resolution for nanoTime() if tsc is not behaving well.

Nathan Reynolds 
<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> | 
Consulting Member of Technical Staff | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology

On 1/10/2012 5:03 AM, Dr Heinz M. Kabutz wrote:
> Only if you use System.nanoTime().  Time difference might even be
> negative if the thread is swapped between different cores.
> On 10/01/2012, Mohan Radhakrishnan<radhakrishnan.mohan at gmail.com>  wrote:
>> Hi,
>> One more question from the novice and for the novice.
>> I see these points in Dr. click's PPT. Can I know why ? I ask this
>> here because it seems to
>> involve multiple cores. Maybe the jvm forums are better suited for this.
>> Does this mean that we get wrong time values if threads run on
>> different cores ?
>> But cannot use, e.g. X86's "tsc" register
>> ? Value not coherent across CPUs
>> ? Not consistent, e.g. slow ticking in low-power mode
>> ? Monotonic per CPU – but not per-thread
>> Thanks,
>> Mohan
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120110/2fabc09c/attachment.html>

More information about the Concurrency-interest mailing list