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

[Stefan Karlsson]

On Wed, 11 Jan 2023 14:27:44 GMT, Justin King <jcking at openjdk.org> wrote:

> ArrayAllocator with ArrayAllocatorMallocLimit removed is effectively MallocArrayAllocator. Are you suggesting leaving MallocArrayAllocator and MmapArrayAllocator thus update references to ArrayAllocator to be MallocArrayAllocator?

Yes, that was what I wanted.

> As far as APIs, the majority of the codebase uses the macros. IMO consistency would be better and having two ways of doing things doesn't help. But if you feel strongly about it, we can punt and just surgically remove the bare minimum, assuming you clarify your expectation (see above).

I agree about the argument about consistency, so I retract my objection. We can deal with these macros as a separate RFE (if we ever get to it).

I would like to retain the usage of mmapped memory for ZGC to minimize the risk of any surprises for us. ZGC code also tend to initialize as much as possible in the initialization list, so the extra memset that comes after initialization lists sticks out a bit. Could you create a private `ZGranuleMap::allocate_array` function that uses os::reserve_memory/commmit_memory and change the code to be:

inline ZGranuleMap<T>::ZGranuleMap(size_t max_offset) :
    _size(max_offset >> ZGranuleSizeShift),
    _map(allocate_array(_size)) {


Or if you like, I can provide a patch on top of your branch to do that.

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

PR: https://git.openjdk.org/jdk/pull/11931