(S) RFR: 8154710: [Solaris] Investigate use of in-memory low-resolution timestamps for Java and internal time API's
charlie.hunt at oracle.com
Fri Apr 29 12:57:37 UTC 2016
> On Apr 29, 2016, at 5:12 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com> 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.
Fwiw, "back in the day" there was a slight gap in perf between Solaris and Windows on SPECjbb2005. That slight gap was attributed to differences in currentTimeMillis overhead.
More information about the core-libs-dev