RFR: 8260262: Use common code in function unmap_shared() in perfMemory_posix.cpp

[Thomas Stuefe]

On Mon, 9 Aug 2021 17:16:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to use common code in function unmap_shared() in perfMemory_posix.cpp, to fix JDK-8260262.  The change calls munmap() directly to deallocate the memory because functions mmap_create_shared() and mmap_attach_shared() call mmap() directly to allocate the memory.
>> 
>> The change was tested by running Mach5 tiers 1-2 on Linux, MacOS, and Windows, and Mach5 tiers 3-5 on Linux x64 and MacOS x64.
>> 
>> Note that testing on AIX is needed.
>> 
>> Thanks, Harold
>
> src/hotspot/os/posix/perfMemory_posix.cpp line 1036:
> 
>> 1034:   }
>> 1035: #else
>> 1036:   os::release_memory(addr, bytes);
> 
> Why doesn't AIX call munmap with os::release_memory() and then do this NMT tracking?

I'm not sure I understand what you are proposing.

The old code was incorrect since it used raw `::mmap()` to map perf memory, but used `os::release_memory()` to release it. This was asymmetric and assumed the underlying implementation for os::reserve/release... uses mmap, which is not always true. The patch corrects this by coupling raw ::mmap with raw ::munmap, and do NMT tracking accordingly.

Arguably, one could factor out mmap+NMT and munmap+NMT in os_posix.cpp. We probably have a number of places where this would be needed. E.g. polling pages and such. But I guess that was out of scope for this issue.

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

PR: https://git.openjdk.java.net/jdk/pull/4995