[concurrency-interest] tsc register

Vitaly Davidovich vitalyd at gmail.com
Tue Jan 10 17:39:06 EST 2012

That's right, there were bugs reported against it, e.g.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6458294 and the
discussion there for when nanoTime can break its contract.
On Jan 10, 2012 5:33 PM, "Dr Heinz M. Kabutz" <heinz at javaspecialists.eu>

> **
> What is interesting is that we have had reports of System.nanoTime()
> sometimes counting backwards.  Has nanoTime() always been monotonic?  If
> so, I need to follow up on the claims.  I've heard it from two sources, but
> it might just be hearsay.
> Regards
> Heinz
> --
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java(tm) Specialists' Newsletter"
> Sun Java Champion
> IEEE Certified Software Development Professionalhttp://www.javaspecialists.eu
> Tel: +30 69 72 850 460
> Skype: kabutz
> On 1/11/12 12:14 AM, David Holmes wrote:
> Correct. Hotspot uses/relies-on the high-resolution monotonic time source
> of the OS, else falls back to plain time-of-day. It never uses the TSC
> directly.
> David Holmes
> -----Original Message-----
> *From:* concurrency-interest-bounces at cs.oswego.edu [
> mailto:concurrency-interest-bounces at cs.oswego.edu<concurrency-interest-bounces at cs.oswego.edu>
> ]*On Behalf Of *Vitaly Davidovich
> *Sent:* Wednesday, 11 January 2012 2:28 AM
> *To:* Nathan Reynolds
> *Cc:* Concurrency-interest at cs.oswego.edu
> *Subject:* Re: [concurrency-interest] tsc register
>  I thought JVM (hotspot at least) uses the os monotonic clock source (if
> present) rather than reading tsc directly and then doing its own
> adjustments?
> On Jan 10, 2012 11:24 AM, "Nathan Reynolds" <nathan.reynolds at oracle.com>
> wrote:
>> 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
>>   ------------------------------
> _______________________________________________
> Concurrency-interest mailing listConcurrency-interest at cs.oswego.eduhttp://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120110/71b67326/attachment-0001.html>

More information about the Concurrency-interest mailing list