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

David Holmes david.holmes at oracle.com
Fri Apr 29 22:57:26 UTC 2016


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



More information about the core-libs-dev mailing list