RFR: 8371408: [Linux] VM.info output for container information is confusing [v2]
David Holmes
dholmes at openjdk.org
Fri Dec 12 01:43:51 UTC 2025
On Thu, 11 Dec 2025 15:41:47 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:
>> Hi everyone,
>>
>> The current `VM.info` printout for container limits can be made clearer and easier to read. The original formatting was designed around cgroup v1, directly mirroring its file names and conventions. Since then, most environments have transitioned to cgroup v2. While the output is still correct, its readability suffers. For example, memory metrics have a `_in_bytes` suffix, but the printed values are actually in kilobytes with a `k` suffix.
>>
>> This PR removes the `_in_*` suffixes from metric names and adds appropriate units (e.g. `kB`, `us`) directly to the values. At the same time, I have also improved the formatting of the output so that all values and units are column-aligned, similar to the `/proc/meminfo` section immediately above in the `VM.info` printout.
>>
>>
>> Here is the container printout before:
>>
>> container (cgroup) information:
>> container_type: cgroupv1
>> cpu_cpuset_cpus: 0-15
>> cpu_memory_nodes: 0-1
>> active_processor_count: 16, but overridden by -XX:ActiveProcessorCount 8
>> cpu_quota: 1600000
>> cpu_period: 100000
>> cpu_shares: no shares
>> cpu_usage_in_micros: 2648091
>> memory_limit_in_bytes: 4194304 k
>> memory_and_swap_limit_in_bytes: 8388608 k
>> memory_soft_limit_in_bytes: unlimited
>> memory_throttle_limit_in_bytes: unavailable
>> memory_usage_in_bytes: 61116 k
>> memory_max_usage_in_bytes: 61116 k
>> rss_usage_in_bytes: 56332 k
>> cache_usage_in_bytes: 1880 k
>> kernel_memory_limit_in_bytes: unlimited
>> kernel_memory_usage_in_bytes: 1584 k
>> kernel_memory_max_usage_in_bytes: 1644 k
>> maximum number of tasks: unlimited
>> current number of tasks: 17
>>
>>
>> And here it is after:
>>
>> container (cgroup) information:
>> container_type: cgroupv1
>> cpu_cpuset_cpus: 0-15
>> cpu_memory_nodes: 0-1
>> active_processor_count: 8 (from -XX:ActiveProcessorCount)
>> cpu_quota: 1600000
>> cpu_period: 100000
>> cpu_shares: no shares
>> cpu_usage: 2648091 us
>> memory_limit: 4194304 kB
>> memory_and_swap_limit: 8388608 kB
>> memory_soft_limit: unlimited
>> memory_throttle_limit: unavailable
>> memory_usage: 61116 kB
>> memory_max_usage: 61116 kB
>> rss_usage: 56332 kB
>> cache_usage: 1880 kB
>> kernel_memory_limit: unlimited
>> kernel_memory_usage: 1584 kB
>> kernel_memory_max_usage: ...
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
>
> cross-compile fix
That looks good. A couple of queries below.
Thanks
src/hotspot/os/linux/osContainer_linux.cpp line 308:
> 306: os::snprintf_checked(value_str, longest_value, metric_fmt<T>::fmt, value);
> 307: st->print("%s: %*s", metrics, max_length - static_cast<int>(strlen(metrics)) - 2, value_str); // -2 for the ": "
> 308: st->print_cr(unit[0] != '\0' ? " %s" : "", unit);
Might a format checker complain about passing `unit` in the case there is no actual format specifier provided?
src/hotspot/os/linux/osContainer_linux.cpp line 315:
> 313: if (res.value() != value_unlimited) {
> 314: if (res.value() >= 1024) {
> 315: print_container_metric(st, metrics, res.value() / K, "kB");
Pre-existing, but does this assume the value will always be a multiple of K?
src/hotspot/os/linux/os_linux.cpp line 2450:
> 2448: assert(i > 0, "must be");
> 2449: if (ActiveProcessorCount > 0) {
> 2450: OSContainer::print_container_metric(st, "active_processor_count", ActiveProcessorCount, "(from -XX:ActiveProcessorCount)");
Is it worth still reporting the true processor count in this case? You can infer it from `cpu_cpusets_cpus`
-------------
Marked as reviewed by dholmes (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/28766#pullrequestreview-3569922128
PR Review Comment: https://git.openjdk.org/jdk/pull/28766#discussion_r2612579655
PR Review Comment: https://git.openjdk.org/jdk/pull/28766#discussion_r2612583695
PR Review Comment: https://git.openjdk.org/jdk/pull/28766#discussion_r2612578764
More information about the hotspot-runtime-dev
mailing list