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

Severin Gehwolf sgehwolf at openjdk.org
Fri Nov 14 15:11:02 UTC 2025


> Please review this revised version of getting rid of `jlong` and `julong` in internal HotSpot code. The single remaining usage is using `os::elapsed_counter()` which I think is still ok. This refactoring is for the container detection code to (mostly) do away with negative return values.
> 
> It gets rid of the trifold-use of return value: 1.) error, 2) unlimited values 3) actual numbers/values/limits. Instead, all container related values are now being read from the interface files as `uint64_t` and afterwards interpreted in the way that make sense for the API implementations. For example, `cpu` values will essentially be treated as `int`s as before, potentially returning a negative value `-1` for unlimited. For memory sizes the type `physical_memory_size_type` has been chosen. When there is no limit for a specific memory size a value `value_unlimited` is being returned.
> 
> All error cases have been changed to returning `false` in the API functions (and no value is being set in the passed in reference for the value). The effect of this is that all container related functions now return a `bool` and require a reference to be passed in for the `value` that is being asked for.
> 
> All usages of the API have been changed to use the revised API. There is no more usages for `OSCONTAINER_ERROR` (`-2) in HotSpot code.
> 
> While working on this, I've noticed that there are still some calls deep in the cgroup subsystem code to query "machine" info (e.g. `os::Linux::active_processor_count()`). I've filed [JDK-8369503](https://bugs.openjdk.org/browse/JDK-8369503) to get this cleaned-up as this patch was already getting large.
> 
> Testing (looking good):
> - [x] GHA
> - [x] All container tests (including problem listed ones) on Linux x86_64 with cg v1 and cg v2. See [this comment](https://github.com/openjdk/jdk/pull/27743#issuecomment-3390060127) below.
> - [x] Some ad-hoc manual testing in containers using JFR (`jdk.SwapSpace` event) and `VM.info` diagnostic command.
> 
> Thoughts? Opinions?

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:

 - Merge branch 'master' into jdk-8365606-jlong-julong-refactor
 - Add space in trace log
 - Merge branch 'master' into jdk-8365606-jlong-julong-refactor
 - One more comment fix
 - Extract OSContainer::available_swap_in_bytes()
 - Simplify os::used_memory()
 - Fix os::active_processor_count()
 - os::free_memory => use 'value' directly
 - os::available_memory() => use 'value' directly
 - Fix pids_max printing in VM.info
 - ... and 15 more: https://git.openjdk.org/jdk/compare/5d65c23c...9a5f3eb5

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

Changes: https://git.openjdk.org/jdk/pull/27743/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27743&range=05
  Stats: 1308 lines in 16 files changed: 514 ins; 106 del; 688 mod
  Patch: https://git.openjdk.org/jdk/pull/27743.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27743/head:pull/27743

PR: https://git.openjdk.org/jdk/pull/27743


More information about the hotspot-jfr-dev mailing list