[concurrency-interest] tsc register

Thu Jan 12 16:39:26 EST 2012

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

Yes but I don't see the relevance. As it says there the VM code was assuming a monotonic time source but was using os::javaTimeMillis which is most definitely not monotonic.

David
-----

> 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
> >
> 
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> 