RFR: 8346834: Tests failing with -XX:+UseNUMA due to "NUMA support disabled" warning

Stefan Johansson sjohanss at openjdk.org
Tue Jan 7 15:18:35 UTC 2025


On Tue, 7 Jan 2025 13:46:16 GMT, Swati Sharma <duke at openjdk.org> wrote:

> Hi All,
> 
> A number of tests launch VMs and read the output of the sub-process. The changes in [JDK-8205051](https://bugs.openjdk.org/browse/JDK-8205051) mean the warning message "NUMA support disabled: Only a single NUMA node is available" is printed when running the tests -XX:+UseNUMA on system that only have one node, this breaks several tests. After update in some tests, so far, the failures are with:
> 
> java/util/logging/LoggingDeadlock2.java
> tools/jar/modularJar/Basic.java
> 
> As a fix have changed logging level from "log_warning" to "log_info" when UseNUMA flag is disabled. 
> 
> Thanks,
> Swati Sharma
> Intel

I think this is a bit unfortunate. I saw the comment in the bug around the wording for the flag `UseNUMA`:
> Use NUMA if available

I don't fully agree that it's wrong to issue a warning (just because is says "if available"), it would be wrong to issue an error and terminate the process. I see the warning as a way to inform the user that the performance feature they configured the process to use couldn't be used. If this is instead communicated as a log statement on info-level almost nobody will see it. 

Especially for the newly added case, where we disable NUMA when the cpu and memory nodes mismatch, I think the warning could be helpful to users. 

Looking at `tools/jar/modularJar/Basic.java` I see that it already has code to handle "VM warnings", so adding support for "UL warnings" would likely be fine there. The other test listed above can't handle any type of unexpected logging and also fails with `-Xlog:gc`so adding something like: `-Xlog:all=off` to the child process in that test would avoid a lot of failures caused by unexpected logs.

I don't oppose this change but wanted to share my view on it.

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

PR Comment: https://git.openjdk.org/jdk/pull/22948#issuecomment-2575549218


More information about the hotspot-runtime-dev mailing list