JDK-8292984 : Refactor internal container-related interfaces for clarity
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 20
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: linux
  • Submitted: 2022-08-26
  • Updated: 2023-07-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8292083 - Detected container memory limit may exceed physical machine memory
Description
In https://github.com/openjdk/jdk/pull/9880, we had a discussion about the organisation of the layers of abstraction internal to hotspot implementing Linux cgroups support. In particular these two comments by Thomas Stuefe illustrate the problem:

 * https://github.com/openjdk/jdk/pull/9880#issuecomment-1227566514
 * https://github.com/openjdk/jdk/pull/9880#issuecomment-1228339437

What follows is my summary, any deviations or mistakes are my own.

The entry-points to the code we are concerned with are `os::physical_memory()` and `os::available_memory()`.

Underneath those, in the Linux code, we have `os::Linux` providing `physical_memory()` and `available_memory()`, and a separate set of classes for cgroups information, fronted by `OSContainer`.

For total memory, the Linux implementation of `os::physical_memory()` calls into both the `Linux` and `OSContainer` classes to determine the answer. However, `OSContainer` also calls back into the `Linux` class.

For available memory, the Linux implementation of `os::available_memory()` calls solely to `Linux::available_memory()`, which in turn calls `OSContainer`. Again, `OSContainer` calls back into the `Linux` class.

The inconsistency between those two approaches, combined with the layering violation of `OSContainer` calling to `Linux`, serves to make this hard to follow.

Relatedly, `OSContainer` is implemented in terms of a family of other classes: `CgroupSubsystem`, `CgroupV1Subsystem` and `CgroupV2Subsystem`. Perhaps `OSContainer` and `CgroupSubsystem` could be merged to simplify this.
Comments
A simple cleanup would be to pass in the relevant physical info down from OSContainer to lower levels using parameters.
26-08-2022
The reason OSContainer exists is that it was originally designed with a broader scope. I.e. support other type of containers, like kata containers or the like (non-cgroups based).
26-08-2022