Hi,
This change seems fine to me; though barely observable only in a microcosm.
(I was going to make the same comment as Daniel, logging now uses higher
resolution timestamps).
Roger
On 4/29/2016 9:46 AM, charlie hunt wrote:
On Apr 29, 2016, at 8:35 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote:
Hi Aleksey,
On 29/04/16 12:12, Aleksey Shipilev wrote:
On 04/29/2016 01:05 PM, David Holmes wrote:
On 29/04/2016 7:50 PM, Aleksey Shipilev wrote:
On 04/29/2016 02:09 AM, David Holmes wrote:
This change is small in nature but somewhat broad in scope. It "affects"
the implementation of System.currentTimeMillis() in the Java space, and
os::javaTimeMillis() in the VM. But on Solaris only.
I say "affects" but the change will be unobservable other than in terms
of performance.
Observable enough to me.
:) Any apps you can think of that might show benefit from this?
Theoretically, this might affect heavily logging apps. IIRC, SPECjbb2000
was affected by currentTimeMillis performance. But, I see no reason in
trying to justify the change, apart from the targeted microbenchmark.
If by "logging" you mean java.util.logging then this should have no
effect as logging now calls os::javaTimeSystemUTC (through java.time),
to get more precise time stamps.
best regards,
— daniel
I think Alexey means getting timestamps via System.currentTimeMillis() and
internal JVM’s os::javaTimeMillis(), (which could have included logging). That
was the intention with my comment wrt SPECjbb2005, (of which was of similar
flavor as SPECjbb2000). The good news (to me anyway) is SPECjbb2000 and
SPECjbb2005 have been retired in favor of SPECjbb2015.
hths,
charlie
-Aleksey
