FFM API allocation shootout

Jorn Vernee jorn.vernee at oracle.com
Wed Aug 2 00:35:49 UTC 2023


 > Now that Arena is the star of the show, and can be customized (via 
delegation), it is possible for custom subclasses to do things such as 
track memory usage, reject allocation requests over a certain limit, etc.

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).

Jorn

On 01/08/2023 18:52, Maurizio Cimadamore wrote:
>
> On 01/08/2023 17:19, mail at smogura.eu wrote:
>> * Should all memory allocations even with custom allocators be 
>> tracked - this can be a little bit error prone.
>
> Custom allocators/arenas came up twice.
>
> I don't think custom arenas would defeat the counting - I'd expect 
> most custom arenas (like the PoolArena used in the benchmark) to just 
> delegate to a "true" confined arena under the hood - so, some "tracked 
> allocation would still occur.
>
> The only case where this would not work is if you use an arena that 
> bypasses Unsafe (e.g. MallocArena), using Linker. In that case no 
> NativeMemoryTracking, and no JMX.
>
> Re. custom counters, I believe that a custom arena has freedom to use 
> its own counter, if it so wishes.
>
> So perhaps that's an argument _against_ tracking memory in special 
> ways (and/or setting limits). Now that Arena is the star of the show, 
> and can be customized (via delegation), it is possible for custom 
> subclasses to do things such as track memory usage, reject allocation 
> requests over a certain limit, etc.
>
> If that was the case, a possible plan could be to disentangle arenas 
> from Bits::reserveMemory completely, and maybe, over time, figure out 
> what kind of "common counters" application need.
>
> Maurizio
>
>


More information about the panama-dev mailing list