RFR: JDK-8287011: Improve container information [v3]

[Thomas Stuefe]

On Fri, 3 Jun 2022 15:15:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> I'm really not fond of this increased API surface for properties which are only supported on one version, but not the other. The idea would be to use those for printing in `os_linux`, right? Could we not move the implementation detail to the version specific classes? I.e. define `virtual void print_version_specific_info(outputStream* st) = 0` here and in `osContainer_linux.hpp` then only call `OSContainer::print_version_specific_info(st)` in `os_linux` and be done with it? This would avoid the empty stub implementations in the version specific classes...

We can do something much simpler. We can just expose the memory controller path and let `os::print_container_info()` read the files directly. Like we do e.g. with /proc/meminfo.

The really useful thing OsContainer does is figuring out the controller path. Wrt to hs-err printing and VM.info, I am not so interested in its v1-v2-agnostic abstraction. I just want to know the values of the files in that directory, verbatim.

If `os::print_container_info` were to access those files directly, we would not need to discuss which values are deemed useful or not. We just can print whatever we want without broadening the API surface. And I don't have to do the mental gymnastics to backtrace the v1-v2-abstraction numbers to their real platform meaning.

In short, I think abstractions are useful to programmatically base decisions on hotspot and java code. But for error analysis, I prefer the raw values with their exact names.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8991