FFM API allocation shootout

[Brian S O'Neill]

On 2023-08-01 05:53 PM, Maurizio Cimadamore wrote:
> 
> But I'd like to ask a control question: let's assume that 
> Bits::reserveMemory was free (or that we found some way to make it much 
> less expensive), would opinion then shift towards having a single JDK 
> parameter to control all off-heap memory allocation?
> 
> Or is it still the case that, as Arena can be customized, custom arenas 
> might decide to track memory how they wish, and we should not bias the 
> API against this or that particular way of tracking memory usage ?
> 

My understanding is that the reserveMemory call is primarily intended to 
manage off-heap memory which should be cleaned up via garbage 
collection. It can force full collections to help free up memory, which 
is generally a bad thing. Memory which isn't automatically freed 
shouldn't be tracked in a fashion that makes it look like running a full 
GC would have any effect. The MaxDirectMemorySize parameter should only 
apply to memory which is automatically managed.

If the reserveMemory functionality was split up such that allocations 
could be tracked only for reporting purposes, it should still support 
custom counters to help identify which components are hogging all the 
memory.