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

[Andrew Haley]

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?

On some 32-bit systems this PR moves memory sizes from 64 bits, where they can't overflow, to 32 bits, where they can. While I've looked at this carefully, I can't exclude the possibility that overflow may occur.

While we could pick through every change line by line, wouldn't it be safer simply to stay with 64-bit sizes on all systems?

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

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