On Tue, 10 Jan 2023 22:50:11 GMT, Justin King <jck...@openjdk.org> wrote:
>> Remove abstraction that is a holdover from Solaris. Direct usages of >> `MmapArrayAllocator` have been switched to normal `malloc`. The >> justification is that none of the code paths are called from signal >> handlers, so using `mmap` directly does not make sense and is potentially >> slower than going through `malloc` which can potentially re-use memory >> without making any system calls. The remaining usages of `ArrayAllocator` >> and `MallocArrayAllocator` are equivalent. > > Justin King has updated the pull request incrementally with one additional > commit since the last revision: > > Initialize memory to zero in zGranuleMap > > Signed-off-by: Justin King <jck...@google.com> Curious, I always thought we do ArrayAllocator - using mmap for larger allocations - to prevent memory retention for libc variants whose allocators are "grabby", i.e. which don't promptly return memory to the OS on free(). E.g. because they only use sbrk (Solaris, AIX), or are just cautious about returning memory (glibc). Glibc's retention problem is only relevant for fine-grained allocations, so for glibc this is probably fine. This leaves at least AIX as a potential problem. @backwaterred, does the AIX libc malloc() still exclusively use the data segment ? Does free'd memory still stick to the process? (While writing this, I remember that we at SAP even rewrote Arena allocation to use mmap for AIX, because large compile arenas caused lasting RSS increase, so it has definitely been a problem in the past) ------------- PR: https://git.openjdk.org/jdk/pull/11931
