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

[leerho]

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.

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?

Lee.

On Mon, Apr 19, 2021 at 2:05 AM Maurizio Cimadamore <
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
>