RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4]

[Thomas Stuefe]

On Thu, 12 Jan 2023 16:52:50 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> 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.
>> 
>> The padding.inline.hpp usage seems to have one caller which is called once. The other mmap usage in G1 we can convert to mmap using a similar approach to zGranuleMap if that is preferred. That would then be equivalent behavior, it looks like the G1 code uses the page allocation granularity anyway so maybe keeping it mmap is the better way to go here anyway?
> 
> My uninformed opinion (I'm not the G1 code owner) is that it would be fine to use explicit mmap. I'd love the complexity reduction this patch brings.

> @tstuefe @backwaterred I'd like to see this RFE revived. Do we know if anyone is using the `ArrayAllocatorMallocLimit` flag in any production environment today?
> 
> It seems unlikely to me, as you'd need to explicitly specify `-XX:+UnlockExperimentalVMOptions` in the command-line.
> 
> And, if this option had been useful (for the AIX port, for example), it would have been changed to a non-experimental (with proper `_pd` support) option over the past 10 years.

@iklam I'm fine with removing the ArrayAllocator.

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

PR Comment: https://git.openjdk.org/jdk/pull/11931#issuecomment-1557662211