(adding back hotspot-dev - still heed a hs/runtime reviewer)
Hi Roger,
On 30/04/2016 12:19 AM, Roger Riggs wrote:
Hi,
This change seems fine to me; though barely observable only in a microcosm.
Thanks for the review.
(I was going to make the same comment as Daniel, logging now uses higher
resolution timestamps).
Good to know.
Thanks,
David
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
