RFR: 8365606: Container code should not be using jlong/julong

[Stefan Karlsson]

On Fri, 5 Sep 2025 17:24:58 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this refactoring to the container code in Hotspot to no longer use `jlong` and `julong`. Instead this patch proposes to move to `size_t` and `ssize_t` types. In a similar manner as was done with the `os::xxx` APIs in [JDK-8357086](https://bugs.openjdk.org/browse/JDK-8357086). With this patch the use of `OSCONTAINER_ERROR` (`-2`) is largely gone. It's not terribly useful to have to warrant the many special cases throughout the code.
> 
> In this patch failure handling is being done by returning a boolean for success/failure of reading a value from the interface files. The notion of "not supported" is being folded into `-1` (unlimited for limit values, not supported for usage values). Note that the code already treated `-1` and `-2` similarly. The few cases where `-2` was actually used was in `VM.info` output or `hserr` files. Where `-2` was being treated as "not supported". However, file-reading errors would also fall into the `-2` bucket making the "not supported" case not 100% distinguishable either. The simplification here proposes to do away with `-2` (other than in traces) and fold it into the `-1` (unlimited) bucket as that's how the code has been handling those values (even prior to this patch).
> 
> Testing:
> - [x] GHA (tier1)
> - [x] cgroup gtests and hotspot container tests on cgroup v1 and cgroup v2 (no regressions noted).
> 
> Thoughts?

FYI, I've realized that the change in JDK-8357086 to use a size_t to represent the amount of physical memory is problematic for 32-bit JVMs running on 64-bit OSes (or if physical address extensions are used on 32-bit OSes). I've created JDK-8367485 for that issue. We might want to figure out the path forward with that issue before going too far with this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/27125#issuecomment-3283906424