jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tonimenen <>
Subject Re: Performance OpenJDK compared with SunJDK
Date Wed, 14 Dec 2011 21:47:30 GMT
Thanks all for the contribution to the issue,

Next week I will launch again the same test, and I will add GCLogs to Jmeter, and I will compare
GC results for both cases to see if really the JVM is working different.



El 14/12/2011, a las 16:40, Peter Lin <> escribió:

> Great discussion by the way.
> Before I talked to henrik, I had no clue how complex timers are in the
> JVM. It was too much info to fit in my brain and got GC-ed. I can only
> imagine what Azul is seeing with their hardware.
> On Wed, Dec 14, 2011 at 10:33 AM, Kirk <> wrote:
>> Well, I'm not sure why he's seeing a difference in performance. I've not spoken to
Henrik about timers so I can't comment on what he's telling you. I can only say that there
is currently an open CR w.r.t monotonic timers and there is some discussion on the subject
in the CR. I've also spoken to Cliff Click about Azul timers and to point to the confusion
here.. he was certain that the JDK was using the TSC, something that I was told by Charlie
Hunt wasn't the case. So I went digging to find out which of these two was right. Turns out
the answer is pretty complicated as it really depends on the OS and what the hardware has.
RedHat was the last to touch the OpenJDK timer code and they did so only in the Linux build
and only to have the high res timer used if it was available.
>> Not a very clear picture.. and all of these timers come with their own set of faults..
which could be worked around if only we knew which one was being used  ;-)
>> And to add to the confusion is thread scheduler efficiency which comes into play....
and I'm very suspicious of hypervisor interference with thread scheduling.Azul has found some
very very weird (almost harmonic) interference patterns that can adversely  affect the ability
to utilize cores. Without access to proper counters it's almost impossible to say for sure
whats going on.
>> Regards,
>> Kirk
>> On Dec 14, 2011, at 4:09 PM, Peter Lin wrote:
>>> thanks kirk for digging up those details.
>>> My memory is faulty, but that is basically what henrik told me back in
>>> 2006/2007. I had noticed a difference between System.currentTimeMillis
>>> and System.nanoTime on all JVM (sun, jrockit, ibm). Digging deeper,
>>> henrik explained to me that windows uses the high performance timer,
>>> which is considerably faster than linux timer.
>>> I agree that more threads results in more pressure on the thread scheduler.
>>> what got me curious is the user sees a difference between openJDK and
>>> sunJDK. perhaps there is some other process running on that linux
>>> system contributing to the extra CPU load.
>>> On Wed, Dec 14, 2011 at 10:00 AM, Kirk <> wrote:
>>>>> Unfortunately it turns out that nanoTime drifts quite badly relative
>>>>> to currentTimeMillis, so currentTimeMillis has to be used to anchor
>>>>> that drift.
>>>>> Otherwise the times just don't add up properly.
>>>>> The JMeter property "sampleresult.useNanoTime" can be set to "false"
>>>>> to disable the use of nanoTime.
>>>> Right, if nanoTime in Windows uses a TSC I would expect drift especially
on newer processors. Not all cores receive all clocks and since the value in the TSC * CPu
frequency is the current time, not having an accurate count of clocks would cause drift. currentTimeMillis
relying on a RTC would have smaller amounts of drift which would only be noticed between machines
(which would be correct with NTP). So your correction of drift would be consistent with this.
On Solaris, the drift between the TOD clock and the TSC is correct after a 1ms drift 125us
at a time. I think MS has attempted something similar (due to complaints from gamers) but
I'm not aware of the details.
>>>> Regards,
>>>> Kirk
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message