[concurrency-interest] tsc register

Mohan Radhakrishnan radhakrishnan.mohan at gmail.com
Thu Jan 12 07:19:57 EST 2012


This CR http://cr.openjdk.java.net/~johnc/7117303/webrev.0/ is quite recent.

Mohan

On Thu, Jan 12, 2012 at 10:28 AM, David Holmes <davidcholmes at aapt.net.au> wrote:
> Hotspot uses the available OS high-resolution nominally monotonic time
> source if it exists, else it falls back to a time-of-day source (which is
> not monotonic). It should be very rare (ie only really old systems) to not
> have a monotonic timesource available.
>
> Solaris had a number of bugs in this area (because unlike the other OSes
> that dropped use of the TSC due to its instability, Solaris decided to force
> it to be stable and synchronized - and occasionally they failed) and so a
> guard was added to ensure it was actually monotonic.
>
> On Windows if the TSC is being used without using the external
> utilities/drivers to sync it then QueryPerformanceCounter can be
> non-monotonic. Similarly on Linux if you set your clocksource to be TSC
> instead of HPET (and the TSC is not synchronized) then CLOCK_MONOTONIC can
> also exhibit non-monotonic behaviour.
>
> See bug 6458294 for some info. Sadly, back in November 2006 I reported that
> we would add the guard logic on all platforms, but it never happened.
>
> All-in-all clocks/counters/timers are a general mess.
>
> David
>
> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Dr Heinz M.
> Kabutz
> Sent: Wednesday, 11 January 2012 8:33 AM
> To: dholmes at ieee.org
> Cc: Concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] tsc register
>
> 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>
> 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 | Consulting Member of Technical Staff | 602.333.9091
>> Oracle PSR Engineering | 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
>>
>>
>>
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> 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
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>



More information about the Concurrency-interest mailing list