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

Langer, Christoph christoph.langer at sap.com
Thu Nov 28 10:54:31 UTC 2019


Hi Matthias,

I'd like to see the uptime information in hs_err files.

I, however, would rather like to see a more readable output like "OS uptime 10 days 3:10". I understand that's some more formatting effort but on the other hand you'd not need floating point calculations.

As for os_windows.cpp: Why don't you spend a os::win32::print_uptime_info(st); method to align with the other implementations?

Best regards
Christoph

> -----Original Message-----
> From: hotspot-dev <hotspot-dev-bounces at openjdk.java.net> On Behalf Of
> Baesken, Matthias
> Sent: Donnerstag, 28. November 2019 10:02
> To: Schmidt, Lutz <lutz.schmidt at sap.com>; David Holmes
> <david.holmes at oracle.com>; 'hotspot-dev at openjdk.java.net' <hotspot-
> dev at openjdk.java.net>
> Subject: RE: 8234397: add OS uptime information to os::print_os_info output
> 
> Hi Lutz,  I adjusted the days calculation,  new webrev :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8234397.2/
> 
> Best regards, Matthias
> 
> 
> 
> > Matthias,
> >
> > your change looks good to me overall. Please note: I'm not a Reviewer!
> >
> > I feel the urge to complain about one thing, though:
> > When calculating the uptime in days, you divide the time retrieved from
> the
> > system (usually seconds or milliseconds) by a large number. Why do you
> > force that number to be a float? I would prefer the denominator to be an
> > "int" value.
> >
> > Rationale: floats (32bits) are very limited in precision, only y6 to 7 decimal
> > digits. At least in the windows case, where you obtain milliseconds from
> the
> > system, your denominator is 86,400,000. At first glance, that does not fit
> into
> > a float mantissa. What saves you here are the prime factors "2" (10 in total).
> > As a result, you only need 17 mantissa bits to represent the denominator.
> >
> > Thanks,
> > Lutz
> >
> > On 25.11.19, 09:06, "hotspot-dev on behalf of Baesken, Matthias"
> <hotspot-
> > dev-bounces at openjdk.java.net on behalf of matthias.baesken at sap.com>
> > wrote:
> >
> >     >
> >     > 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?
> >     >
> >
> >     Hi David,  it works on Solaris .
> >     I think I should adjust the comment (saying macOS AND Linux) .
> >
> >     Best regards, Matthias
> >
> >
> >     > >
> >     > > 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