"Malloc/Free" Callbacks for Dynamic Off-heap MemorySegments

[Maurizio Cimadamore]

On 20/04/2021 01:50, leerho wrote:
> WRT: if _all_ allocators should have a scope.
>
> From what I see now, you already have all native segment allocators 
> using scope, which makes sense because of the relationship with 
> close() and a possible cleaner. *Please don't require a scope for 
> on-heap allocated segments*. In the case of arrays, their life-time 
> should behave like heap arrays.  When wrapping an existing ByteBuffer, 
> its life-time should be determined by whether the ByteBuffer is direct 
> or not.  Memory-mapped files will always be off-heap so I guess they 
> could require scope.
I think you are misinterpreting: when I say allocators might have a 
scope, I didn't say _which_ scope. An allocator might just be associated 
with the global, always alive scope (which is also the scope attached to 
heap segments).
>
> The structure of our sketches are dynamic structs and the sketch 
> itself really shouldn't really care if its struct is on-heap or 
> off-heap.  As a result, we use segments as intermediate structures 
> when converting an in-memory sketch built with normal java arrays and 
> primitives into a byte array for serialization, for example.  P.S., 
> because our sketches are dynamic structs, we will take advantage of 
> the Union capability extensively!
>
> You are correct that we would like to extend the capabilities of the 
> TrackingAllocator to collect statistics. But adding that into the 
> TrackingAllocator should be easy and could be left to the user.
>
> This does bring up a question: in JDK8, the nio/bits class tracked 
> off-heap memory allocated from ByteBuffer.allocateDirect().  Does the 
> allocation of native segments do the same thing?

Yes, when you allocate off heap with memory segments, the same memory 
limits are being applied and used.

Maurizio

>
> Lee.
>
> On Mon, Apr 19, 2021 at 2:05 AM Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>
>     On 18/04/2021 20:03, leerho wrote:
>>     In order for your proposal to work with /allocate/, the Child
>>     would have to be constructed with /new Child(TrackingAllocator,
>>     MemorySegment) /in order for it to access/allocate. /This is
>>     certainly possible, however, what would be nice (and symmetric)
>>     would be for the child to be able to access /allocate/ via the
>>     scope as well.  Sort of a /scope.addOnAllocate(Runnable) /or
>>     perhaps a /scope/./addOnTrackingAllocator(interface) /that could
>>     handle both/., /But I can see that this is more complex and may
>>     not be practical.
>
>     I see what you mean - in general I don't think this is feasible,
>     as a ResourceScope is more general than for just segments - e.g.
>     it can handle VaList, upcall stubs, etc. So having segment
>     specific stuff in there might be odd.
>
>     Your tracking allocator might also contain a scope (actually we're
>     investigating if _all_ allocators should have a scope which
>     defines their lifecycles) - in which case it should be easier to
>     at least just use the TrackingAllocator always (since from there
>     you can go to the scope). Just an idea.
>
>     My sense here is also that here we're using APIs to intercept
>     calls etc. - but in reality you need something a little bit
>     deeper: ability to collect stats on memory
>     allocation/deallocation. Right now the JDK doesn't give much
>     control over this kind of info, and this is something that (albeit
>     lower priority) we will need to look into sooner or later. If you
>     had such an API, I believe you could just use that directly,
>     instead of trying to recreate it/emulate it from scratch.
>
>     Maurizio
>