[concurrency-interest] tsc register

Nathan Reynolds nathan.reynolds at oracle.com
Tue Jan 10 17:32:42 EST 2012


Hmm... maybe I am thinking of JRockit that uses tsc.  I could be very 
wrong though.  Maybe I am thinking of HotSpot Sparc implementation.

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 3:16 PM, David Holmes wrote:
> And with guards against a buggy OS not giving correct monotonic time.
> David
>
>     -----Original Message-----
>     *From:* David Holmes [mailto:davidcholmes at aapt.net.au]
>     *Sent:* Wednesday, 11 January 2012 8:15 AM
>     *To:* Vitaly Davidovich; Nathan Reynolds
>     *Cc:* Concurrency-interest at cs.oswego.edu
>     *Subject:* RE: [concurrency-interest] tsc register
>
>     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ⁿᵈ
>             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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120110/ff52953d/attachment.html>


More information about the Concurrency-interest mailing list