RFR: 8365606: Container code should not be using jlong/julong
Stefan Karlsson
stefank at openjdk.org
Wed Sep 10 09:05:15 UTC 2025
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?
Please don't keep jlong.
I propose that you follow what was done in 8357086: Instead of returning one value that either holds the size value or the error, split it into two return values and make the error handling explicit.
If there are cases where the function should return a limit and the container code imposes no limit, then I "think" returning `SIZE_MAX` is probably better than propagating a error code.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/27125#issuecomment-3274010496
More information about the hotspot-dev
mailing list