On Thu, 25 Aug 2022 16:15:53 GMT, Jonathan Dowland <jdowl...@openjdk.org> wrote:
>> When the container memory exceeds the physical host's memory, the Java >> metrics reporting is wrong. >> >> https://bugs.openjdk.org/browse/JDK-8292541 >> >> This is the equivalent core-libs fix for Hotspot's >> [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083) >> (https://github.com/openjdk/jdk/pull/9880) > > Jonathan Dowland has updated the pull request incrementally with one > additional commit since the last revision: > > Add a log-line for total physical memory > > This is relied upon for tests in > test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java Sorry, but this last change is a hack. src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 532: > 530: } > 531: jlong phys_mem = os::Linux::physical_memory(); > 532: log_trace(os, container)("total physical memory: " JLONG_FORMAT, > phys_mem); This won't work reliably as expected without the change in #9880 which changes what `os::Linux::physical_memory()` reports (it's set to the container limit via `OSContainer::init()` without #9880 causing weird output). I believe this should not be integrated as-is. $ sudo podman run --rm -ti --memory 1G -v $(pwd)/./build/linux-x86_64-server-fastdebug/images/jdk:/opt/jdk:z fedora:36 [root@7494fe07f76b /]# /opt/jdk/bin/java -Xlog:os+container=trace -version 2>&1 | grep os,container | grep 'total physical memory' [0.001s][trace][os,container] total physical memory: 33258033152 [0.063s][trace][os,container] total physical memory: 1073741824 Yes, this works, because `firstMatch()` is being used, but it's an ugly hack which we should avoid. ------------- Changes requested by sgehwolf (Reviewer). PR: https://git.openjdk.org/jdk/pull/10017
