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
