RFR: 8234397: add OS uptime information to os::print_os_info output

David Holmes david.holmes at oracle.com
Mon Nov 25 07:03:06 UTC 2019


Hi Matthias,

On 21/11/2019 9:22 pm, Baesken, Matthias wrote:
> Hi David ,
> 
>>
>> Hi Matthias,
>>
>> On 21/11/2019 7:24 pm, Baesken, Matthias wrote:
>>> Hello,   please review this small addition  to  os::print_os_info  .
>>>
>>> Currently os::print_os_info outputs various interesting OS information,
>>> The output is platforms dependent, on Linux currently the following
>> information is printed :
>>> distro, uname , some important libversions, some limits, load average,
>> memory info, info about /proc/sys , container and virtualization details and
>> steal ticks.
>>> The OS uptime would be a helpful addition.
>>
>> I'd be interested to hear an example of this.
>>
> 
> One example that occurred last week  -  my colleague Christoph and me  were browsing through an hs_err  file of a crash on AIX .
> When looking into the hs_err  we wanted to know the  uptime because  our latest  fontconfig - patches   (for getting rid of the crash)    needed a reboot too to really work .
> Unfortunately we  could not find the info , and we were  disappointed  ( then we noticed the crash is from  OpenJDK and not our internal JVM ).
> 
> 
>>> Bug/webrev :
>>> https://bugs.openjdk.java.net/browse/JDK-8234397
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8234397.1/
>>
>> Can Linux not use the POSIX version?
>>
> 
> Unfortunately the posix code does not give the desired result  on Linux (at least on my test machines).

The comment in the posix code mentions that it doesn't work on macOS but 
doesn't say anything about Linux. Has it been tested on Solaris?

I'm really unsure about this code and am hoping someone more 
knowledgeable in this areas can chime in. I'd be less concerned if there 
was a single POSIX implementation that worked everywhere. :( Though I 
have my general concern about adding yet another potential point of 
failure in the error reporting logic.

Thanks,
David

> Best regards, Matthias
> 


More information about the hotspot-dev mailing list