RFR: 8292541: [Metrics] Reported memory limit may exceed physical machine memory [v5]

[Severin Gehwolf]

On Thu, 25 Aug 2022 16:15:53 GMT, Jonathan Dowland <jdowland at 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 at 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