(S) RFR: 8154710: [Solaris] Investigate use of in-memory low-resolution timestamps for Java and internal time API's
daniel.fuchs at oracle.com
Fri Apr 29 13:35:44 UTC 2016
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.
More information about the core-libs-dev