[concurrency-interest] tsc register

David Holmes davidcholmes at aapt.net.au
Fri Jan 13 00:13:08 EST 2012


Mohan Radhakrishnan writes:
> I meant that since this CR is recent even newer VM's could be affected

That CR has nothing to do with the TSC.

> ? I think if I were to set the thread affinity using JNI and
> continuosly run java threads then that is the test case. Am I right ?

If you bind a thread to a given core (using JNI) and that thread reads the TSC then it should always be reading the same TSC. But remember there are two issues with using the basic TSC: synchronization across processors and stability of the frequency of updates. Thread affinity only addresses one part.
 
> I am mostly interested in tyring to understand and explain a test to
> others. We do run some heavy batch schedulers in a critical banking
> application on multiple cores using Jdk 5 on HP-UX. The problem is
> that we haven't seen any problem. Sometimes when these types of
> financial applications fail we assume something and restart them.

???
 
> As was pointed out such timer failures are extremely rare on multiple
> cores even if they happen and newer hardware is better. That is what I
> have understood :-)

Unsynchronized TSC is not at all extremely rare - quite the contrary, if you have a multi-core/multi-processor system that does not support the latest synchronized TSC hardware, or else does not run special TSC-synchronizing software, then you have unsynchronized TSC.

David Holmes
------------

> Thanks,
> Mohan
> 
> On Fri, Jan 13, 2012 at 3:09 AM, David Holmes 
> <davidcholmes at aapt.net.au> wrote:
> > 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
> >>
> >
> 
> _______________________________________________
> 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