(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 8:35 AM, Daniel Fuchs <daniel.fuchs at 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