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

[Afshin Zafari]

On Fri, 31 Oct 2025 14:58:11 GMT, Joel Sikström <jsikstro at openjdk.org> wrote:

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

Thanks for sharing your info. It describes the 2M diff in reserved amount.

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

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