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

[Joel Sikström]

On Fri, 31 Oct 2025 13:07:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> 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)

I'm just spitballing here based on my experience listening to @xmas92 talk about ASAN in ZGC. Could it be that ASAN is reserving memory at the lower end of the virtual address space, making it difficult to get zero-based Compressed Oops. In that case, we need som extra memory to "efficiently implement null checks.", which turns out to be 2M in this case, which looks like an extra large page.
https://github.com/openjdk/jdk/blob/8236800deb5b99a027b0944f6c512c0f31d030df/src/hotspot/share/memory/memoryReserver.cpp#L612-L614

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

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