[concurrency-interest] tsc register

Vitaly Davidovich vitalyd at gmail.com
Tue Jan 10 11:27:55 EST 2012

I thought JVM (hotspot at least) uses the os monotonic clock source (if
present) rather than reading tsc directly and then doing its own
On Jan 10, 2012 11:24 AM, "Nathan Reynolds" <nathan.reynolds at oracle.com>

>  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ⁿᵈ 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> <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 listConcurrency-interest at cs.oswego.eduhttp://cs.oswego.edu/mailman/listinfo/concurrency-interest
> _______________________________________________
> 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/fe27b96e/attachment.html>

More information about the Concurrency-interest mailing list