(S) RFR: 8154710: [Solaris] Investigate use of in-memory low-resolution timestamps for Java and internal time API's

[charlie hunt]

> 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.
> 
> -Aleksey

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.

Charlie