Bug ID: JDK-8292541 [Metrics] Reported memory limit may exceed physical machine memory

Versions (Unresolved/Resolved/Fixed)

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.

JDK 11	JDK 17	JDK 20
11.0.18Fixed	17.0.6Fixed	20 b13Fixed

This is the equivalent core-libs bug for Hotspot's JDK-8292083. When the container memory exceeds the physical host's memory, the Java metrics reporting is wrong. Example (on a host with 32GB physical memory):

# podman run --memory 36G --memory-swap 36G --rm -ti -v $(pwd)/build/linux-x86_64-server-release/images/jdk/:/opt/jdk:z fedora:36
[root@71845cef857a /]# /opt/jdk/bin/java -XshowSettings:system -version
Operating System Metrics:
    Provider: cgroupv1
    Effective CPU Count: 8
    CPU Period: 100000us
    CPU Quota: -1
    CPU Shares: -1
    List of Processors, 8 total: 
    0 1 2 3 4 5 6 7 
    List of Effective Processors, 8 total: 
    0 1 2 3 4 5 6 7 
    List of Memory Nodes, 1 total: 
    0 
    List of Available Memory Nodes, 1 total: 
    0 
    Memory Limit: 36.00G
    Memory Soft Limit: Unlimited
    Memory & Swap Limit: 36.00G
    Maximum Processes Limit: 2048

openjdk version "20-internal" 2023-03-21
OpenJDK Runtime Environment (build 20-internal-adhoc.sgehwolf.jdk-jdk)
OpenJDK 64-Bit Server VM (build 20-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)

Expected 'Memory Limit: 32.00G' instead of the reported 'Memory Limit: 36.00G'

A pull request was submitted for review. URL: https://git.openjdk.org/jdk8u-dev/pull/220 Date: 2023-01-03 11:46:29 +0000
03-01-2023
Fix Request (11u) Same justification as 17u, above. Thanks!
05-09-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/1355 Date: 2022-09-05 11:44:52 +0000
05-09-2022
Fix Request (17u) I would like to backport this to 17u as we have seen it in the wild and want to get the fix out to 17u customers. Patch applies clean, the added tests fail in 17u master prior to patch and pass afterwards. Thanks!
05-09-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/652 Date: 2022-09-05 10:39:00 +0000
05-09-2022
Changeset: 9a0d1e7c Author: Jonathan Dowland <jdowland@openjdk.org> Committer: Severin Gehwolf <sgehwolf@openjdk.org> Date: 2022-08-26 16:22:14 +0000 URL: https://git.openjdk.org/jdk/commit/9a0d1e7ce86368cdcade713a9e220604f7d77ecf
26-08-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/10017 Date: 2022-08-25 09:50:44 +0000
25-08-2022
Same issue, but with the OS MX bean: [root@67d40c833987 /]# /opt/jdk/bin/jshell \| Welcome to JShell -- Version 20-internal \| For an introduction type: /help intro jshell> com.sun.management.OperatingSystemMXBean os = (com.sun.management.OperatingSystemMXBean) java.lang.management.ManagementFactory.getOperatingSystemMXBean(); os ==> com.sun.management.internal.OperatingSystemImpl@69663380 jshell> os.getTotalMemorySize() $2 ==> 38654705664 Should be 33258033152, actual 38654705664.
17-08-2022
Work-around is to use -XX:-UseContainerSupport, but that's not great as the default is turned on and it makes little sense to run with containers support but with memory/cpu limits greater than the host system the container runs on.
17-08-2022

Relates :	JDK-8299858 - [Metrics] Swap memory limit reported incorrectly when too large
Relates :	JDK-8300119 - CgroupMetrics.getTotalMemorySize0() can report invalid results on 32 bit systems
Relates :	JDK-8292083 - Detected container memory limit may exceed physical machine memory