On Wed, 11 Jan 2023 14:49:59 GMT, Thomas Stuefe <stu...@openjdk.org> wrote:
>> 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) To follow up on @tstuefe comment - and the one that I tried to say in the bug was that we added this MmapArrayAllocate feature for some G1 marking bits that used so much memory that hit the Solaris _sbrk issue. Maybe @stefank and @tschatzl remember this issue. Maybe it's ok for AIX, then removing this code is a good change. Maybe the G1 usages need a mmap implementation though. ------------- PR: https://git.openjdk.org/jdk/pull/11931
