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

[Daniel Fuchs]

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

>
> -Aleksey
>