OperatingSystemMXBean unaware of container memory limits

[Andrew Azores]

Hi Bob (and all),

On Fri, 2019-06-21 at 08:50 -0400, Bob Vandette wrote:
> > 
> Fixing the existing OS Mbean is pretty straight forward.  Just have
> each method call the new Metrics API, check for error returns
> in case this API is not supported on this platform and if success,
> return result, otherwise call existing logic.
> 

I've had free time to circle back to this issue lately, so I've
prepared a patch which modifies the OperatingSystemMXBean as you've
described here. This seems to work perfectly well for
getTotalPhysicalMemorySize, getFreePhysicalMemorySize, and
getTotalSwapSpaceSize. getFreeSwapSpaceSize looks at a glance to be
implementable by comparing Metrics' getMemoryAndSwapUsage,
getMemoryUsage, and getMemoryAndSwap limit, but the implementation
would only provide an approximation (and not necessarily accurately)
since the amount of memory/swap used would likely change in between or
due to subsequent calls to the Metrics API.

Also, I'm not sure that there are reasonable equivalents for all of the
other metrics implemented in
jdk.management/unix/classes/com/sun/management/internal/OperatingSystem
Impl.java available from Metrics or elsewhere which make sense in a
containerized environment (ex. getCommittedVirtualMemorySize).

So, before I proceed much further with this patch, does anyone have
input on how these issues should be handled such that the
OperatingSystemMXBean is self-consistent wrt its container awareness?

-- 
Andrew Azores
Software Engineer, OpenJDK Team
Red Hat