[concurrency-interest] tsc register

Roel Spilker r.spilker at topdesk.com
Wed Jan 11 08:02:16 EST 2012


Hi Heinz,

I have another datapoint for you.

We've also observed "counting backwards" in our application end of 2009. 
Unfortunately, at the time and under deadline pressure, we just removed 
the usage and did not record any system information. I'm pretty sure 
about the following:
- An at the time recent Java 1.6
- Most likely an Oracle (well, at the time Sun) JDK running -server
- Most likely 64 bit JVM
- Probably running on Windows 7, 64 bit
- Intel processor, multi-core, possibly with hyperthreading enabled

We did notice that this behavior occurred when between two calls we 
accessed the database. Our assumption at the time was that the blocking 
thread was rescheduled to a different core, resulting in inconsistent 
numbers.

Roel


On 10-1-2012 23:33, Dr Heinz M. Kabutz wrote:
> 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 Professional
> http://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]*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 <mailto: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^(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
>>         <tel: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>  <mailto: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  <mailto:Concurrency-interest at cs.oswego.edu>
>>>>         http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>>
>>>>                    
>>
>>         _______________________________________________
>>         Concurrency-interest mailing list
>>         Concurrency-interest at cs.oswego.edu
>>         <mailto:Concurrency-interest at cs.oswego.edu>
>>         http://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/20120111/be7bf9ab/attachment.html>


More information about the Concurrency-interest mailing list