[concurrency-interest] tsc register
vitalyd at gmail.com
Tue Jan 10 11:49:56 EST 2012
from openjdk os_Linux.cpp os::javaTimeNanos seems to either use Linux
monotonic clock, if available, or falls back on gettimeofday() with scaling
I think Cliff Click mentions that System.currentTimeMillis was optimized to
avoid a syscall each time by instead reading some cached value that's
updated in the background (or something like that) but I'm not sure if
that's just in Azul or hotspot as well.
On Jan 10, 2012 11:34 AM, "Nathan Reynolds" <nathan.reynolds at oracle.com>
> You could be right. I am just going on what I hear and memory. Both of
> which are faulty.
> I was under the impression that the HotSpot JVM used tsc directly if it
> determines that it is stable and works well. If not, then it defaults down
> to the OS clock source.
> Nathan Reynolds<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds>| Consulting Member of Technical Staff |
> Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
> On 1/10/2012 9:27 AM, Vitaly Davidovich wrote:
> I thought JVM (hotspot at least) uses the os monotonic clock source (if
> present) rather than reading tsc directly and then doing its own
> On Jan 10, 2012 11:24 AM, "Nathan Reynolds" <nathan.reynolds at oracle.com>
>> 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 |
>> 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> <radhakrishnan.mohan at gmail.com> wrote:
>> 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
>> Concurrency-interest mailing listConcurrency-interest at cs.oswego.eduhttp://cs.oswego.edu/mailman/listinfo/concurrency-interest
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest