RFR: 8226575: OperatingSystemMXBean should be made container aware

[Mandy Chung]

On 12/6/19 5:59 AM, Bob Vandette wrote:
>> On Dec 6, 2019, at 2:49 AM, David Holmes<David.Holmes at oracle.com>  wrote:
>>
>>
>> src/jdk.management/share/classes/com/sun/management/OperatingSystemMXBean.java
>>
>> The changes to allow for a return of -1 are somewhat more extensive than we have previously discussed. These methods previously were (per the spec) guaranteed to return some (assumably) meaningful value but now they are effectively allowed to fail by returning -1. No existing code is expecting to have to handle a return of -1 so I see this as a significant compatibility issue.

I thought that the error case we are referring to is limit == 0 which 
indicates something unexpected goes wrong.  So the compatibility concern 
should be low.  This is very specific to Metrics implementation for 
cgroup v1 and let me know if I'm wrong.

>> Surely there must always be some information available from the operating environment? I see from the impl file:
>>
>>     // the host data, value 0 indicates that something went wrong while the metric was read and
>>    // in this case we return "information unavailable" code -1.
>>
>> I don't agree with this. If the container metrics are messed up somehow we should either fallback to the host value or else abort with some kind of exception. Returning -1 is not an option here IMO.
> I agree with David on the compatibility concern.  I originally thought that -1 was already a specified return for all of these methods.
> Since the 0 return failure from the Metrics API should only occur if one of the cgroup subsystems is not enabled while others
> are, I’d suggest we keep Daniil’s original logic to fall back to the host value since a disabled subsystem is equivalent to no
> limits.
>

It's important to consider carefully if the monitoring API indicates an 
error vs unavailable and an application should continue to run when the 
monitoring system fails to get the metrics.

There are several choices to report "something goes wrong" scenarios 
(should unlikely happen???):
1. fall back to a random positive value  (e.g. host value)
2. return a negative value
3. throw an exception

#3 is not an option as the application is not expecting this.  For #2, 
the application can filter bad values if desirable.

I'm okay if you want to file a JBS issue to follow up and thoroughly 
look at the cases that the metrics are unavailable and the cases when 
fails to obtain.

>> ---
>>
>> test/hotspot/jtreg/containers/docker/CheckOperatingSystemMXBean.java
>>
>> System.out.println(String.format(...)
>>
>> Why not simply
>>
>> System.out.printf(..)
>>
>> ?

or simply (as I commented [1])
     System.out.format

Mandy
[1] 
https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-December/029930.html