RFR(S): 8196565: AIX: Clean up os::javaTimeNanos according to AIX/PASE specification

David Holmes david.holmes at oracle.com
Thu Feb 1 21:23:59 UTC 2018


On 1/02/2018 11:17 PM, David Holmes wrote:
> Hi Christoph,
> 
> On 1/02/2018 10:06 PM, Langer, Christoph wrote:
>> Hi David,
>>
>> thanks for looking. I'll change my code to use that constant.
>>
>> One question, as I'm currently looking at the os timing functions: Do 
>> you know why in os_solaris.cpp, in os::getTimesSecs(), the 
>> process_real_time value is not taken from the result of times() but 
>> from getTimeNanos()? Otherwise getTimeSecs would be a good candidate 
>> to move to os_posix.cpp ...
> 
> I can only guess that as per the comment the intent was to ensure that 
> "process_real_time" was consistent with other views of time ie 
> os::elapsedTime and os::elapsedCounter.
> 
> The code was added by:
> 
> https://bugs.openjdk.java.net/browse/JDK-6468292
> 
> but there are no enlightening comments in that regard. And I don't know 
> if times() would be using a different timebase than gethrtime().

Actually I think it is also because the return value from times() may 
not be usable due to the potential overflow problem. This is true on 
other platforms too. Linux has an even bigger disclaimer:

On Linux, the "arbitrary point in the past" from which the return value 
of times() is measured has varied across kernel versions.  On Linux 2.4 
and earlier this point is the moment the system was booted.  Since Linux 
2.6, this point is (2^32/HZ) - 300 (i.e., about 429 million) seconds 
before system boot time.  This variability across kernel versions (and 
across UNIX implementations), combined with the fact that the returned 
value may  overflow  the range  of clock_t, means that a portable 
application would be wise to avoid using this value.  To measure changes 
in elapsed time, use gettimeofday(2) instead.

--
David

> David
> -----
> 
>> Best regards
>> Christoph
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Donnerstag, 1. Februar 2018 12:10
>> To: Langer, Christoph <christoph.langer at sap.com>; 
>> hotspot-runtime-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net
>> Subject: Re: RFR(S): 8196565: AIX: Clean up os::javaTimeNanos 
>> according to AIX/PASE specification
>>
>> Hi Christoph,
>>
>> On 1/02/2018 7:11 PM, Langer, Christoph wrote:
>>> Hi,
>>>
>>> please review a fix for the os::javaTimeNanos method on AIX.
>>>
>>> It implements the information we got from the AIX documentation and 
>>> from the IBM folks regarding the behavior of mread_real_time on Pase.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196565
>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8196565.0/
>>
>> I took a look as I was curious :) I recognized the Solaris code for
>> ensuring monotonic time. :) It all seems to do as you describe.
>>
>> One nit - instead of (1000 * 1000 * 1000) you can use:
>>
>> const jlong NANOSECS_PER_SEC      = CONST64(1000000000);
>>
>> from ./hotspot/share/utilities/globalDefinitions.hpp
>>
>> Cheers,
>> David
>>
>>> Thanks & Best regards
>>> Christoph
>>>


More information about the hotspot-runtime-dev mailing list