RFR: 8364741: [asan] runtime/ErrorHandling/PrintVMInfoAtExitTest.java fails because output differs slightly

[Matthias Baesken]

On Fri, 31 Oct 2025 12:55:15 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/ErrorHandling/PrintVMInfoAtExitTest.java line 32:
>> 
>>> 30:  * @modules java.base/jdk.internal.misc
>>> 31:  * @requires vm.flagless
>>> 32:  * @requires !vm.asan
>> 
>> Instead of disabling the test entirely, could we check for `Java Heap` or (`Java Heap` and `committed=65536KB`)? I'm not too fussed either way, but this seems like a useful sanity test to have so maybe we could just refactor it a bit. @afshin-zafari does asan ever impact the `committed` memory in NMT?
>
> The unexpected value is for `reserved` and not `committed`. But any way, ASAN should/could not impact internal NMT memory regions, at least directly.
> The question here is why there is extra 2048K bytes in reserved memory, comparing with non-asan build?

It is a little bit surprising indeed.
We set
`"-Xmx64M", "-Xms64M",`
in the test, so a higher reserved value  is a bit strange but still we get it this way (on Linux x86_64)

-                 Java Heap (reserved=67584KB, committed=65536KB)
                            (mmap: reserved=67584KB, committed=65536KB, at peak)


@tstuefe  do you maybe have an idea / explanation why with ASAN-enabled binaries we get a higher value for 'reserved'?
The test expects
`output_detail.shouldContain("Java Heap (reserved=65536KB, committed=65536KB)");`
(and from what I see we get this otherwise when testing on our large set of OS/CPU platforms)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28055#discussion_r2481355578