RFR: 8292206: TestCgroupMetrics.java fails as getMemoryUsage() is lower than expected

[Ioi Lam]

On Tue, 20 Dec 2022 10:44:35 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> The `testMemoryUsage()` test scenario queries the total memory usage of all processes of the current Linux user, including other concurrently running jtreg test cases. Even if the current process allocates 256MB of ram, it's possible for other dying processes to release much more than that amount. Therefore, it's not possible to guarantee that `Metrics.getMemoryUsage()` would return a higher number.
>> 
>> I am removing this test scenario for now as I don't see it providing any actual value.
>> 
>> If we want to have more in-depth functional tests for the `Metrics.getMemoryXXX()` APIs, we need to do it inside a container in a more controlled setting.
>
>> I am removing this test scenario for now as I don't see it providing any actual value.
> 
> I disagree. It seems useful in the docker/container case as there are APIs in the JDK reporting those metrics and it wouldn't be tested otherwise.
> 
> Note that this test is also being used by `TestSystemMetrics.java`. Entrypoint in the `TestSystemMetrics` case is `main()` (over entrypoint `testAll()` via `TestCgroupMetrics`).
> 
>> If we want to have more in-depth functional tests for the `Metrics.getMemoryXXX()` APIs, we need to do it inside a container in a more controlled setting.
> 
> That's what the above mentioned `TestSystemMetrics.java` does. I take it that test is not problematic? If so, we should just not invoke `testMemoryUsage()` when invoked from `TestCgroupMetrics`.

Thanks @jerboaa and @dholmes-ora for the review.

Tested with tier5 container tests in our CI.

-------------

PR: https://git.openjdk.org/jdk/pull/11734