FFM API allocation shootout

[Maurizio Cimadamore]

On 02/08/2023 01:35, Jorn Vernee wrote:
> I think this is an interesting direction, and seems like the right one 
> to me.
>
> I wonder if we can find a way to 're-expose' Bits::reserve/unreserve, 
> so that custom arenas could still tie into that mechanism if they so 
> wish to. Maybe we can add some kind of combinator like 
> Arena::trackingArena(Arena) that can be used to adapt an existing 
> Arena to add tracking on top. (although, potentially someone could 
> call this multiple times and get duplicate tracking, which is not great).

What you propose (tracking combinator) is interesting. What I was 
actually thinking is for the custom arena to define its own JMX entity 
to do its own kind of reporting. E.g. maybe attaching to 
Bits::reserve/unreserve doesn't have to be the only way by which an 
arena can tell the rest of the world how much memory it's using.

I guess I'd still like to understand whether _conceptually_ off-heap 
memory usage via Arena should be subject to the same limit as those 
associated with direct buffers.

I mean, I take it that, if it's a choice between performance and 
tracking, most developers who chimed in seem all to be converging 
towards disentangling Arenas from Bits::reserveMemory (so that we can 
get better allocation performance).

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 ?

Cheers
Maurizio