RFR: 8331560: Refactor Hotspot container detection code so that subsystem delegates to controllers
Severin Gehwolf
sgehwolf at openjdk.org
Mon May 6 08:35:22 UTC 2024
Please review this preparatory PR which is an enabler for some bugfix/alignment work (e.g. [JDK-8322420](https://bugs.openjdk.org/browse/JDK-8322420)). The idea is to delegate limit lookup to controllers (`memory`, `cpu`, etc.) from the overarching `CgroupSubsystem` class. This way we can - once the cg type has been detected - "adjust" a controller's path to the limit files when the controller is being created (on init) and then left alone. In this case, the two preparatory entry points are `CgroupUtil::processor_count()` taking a version-agnostic `CgroupCpuController` to do the actual look-up and `CgroupMemoryController::read_memory_limit_in_bytes()` for the same in terms of memory limits.
This enables setting the contoller's path to the interface files (wherever it might be in the hierarchy of it's original cgroup path), look up the limit and "freeze" the path once it found a - lower - limit.
It also ensures that both cgroup versions return `-1` or `-2` (`OSCONTAINER_ERROR`) - in both cases negative - for some notion of unlimited. I.e. it makes the upper bound by the host's physical memory apparent in the version agnostic classes.
Testing:
- [x] GHA
- [x] gtest:cgroupTest tests
- [x] container tests on Linux cgv1 and cgv2 on x86_64
Thoughts?
-------------
Depends on: https://git.openjdk.org/jdk/pull/19060
Commit messages:
- Fix whitespace
- Refactor cgroup controller code
Changes: https://git.openjdk.org/jdk/pull/19085/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19085&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8331560
Stats: 544 lines in 8 files changed: 288 ins; 88 del; 168 mod
Patch: https://git.openjdk.org/jdk/pull/19085.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/19085/head:pull/19085
PR: https://git.openjdk.org/jdk/pull/19085
More information about the hotspot-runtime-dev
mailing list