[concurrency-interest] tsc register

Mohan Radhakrishnan radhakrishnan.mohan at gmail.com
Thu Jan 12 23:58:00 EST 2012


I meant that since this CR is recent even newer VM's could be affected
? 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 ?

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 :-)

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
>>
>



More information about the Concurrency-interest mailing list