Releasing MemorySegments eagerly and efficiently

[Benoit Daloze]

Hello panama-dev,

We are looking at migrating from Unsafe off-heap methods to Panama/MemorySegment.
While migrating we hit a blocker for replacing Unsafe#freeMemory() calls.

Specifically, we are implementing various languages like Python and Ruby which have their own Pointer/Buffer-like abstractions (i.e. they support reading/writing various native types at some offset, allocation, freeing, etc).
Some of these pointers have a known size/length and some don't (and those that don't are allowed to read/write anywhere, as if they had infinite length).

Some pointers/buffers themselves have auto-release semantics and some don't (e.g. when they come back from a native call), regardless of that these languages allow freeing them eagerly, e.g. https://www.rubydoc.info/gems/ffi/1.16.3/FFI/Pointer#free-instance_method

Freeing eagerly is crucial to avoid excessive resource consumptions (especially if the allocations are big). It's similar to the problem of running out of file descriptors when not closing them explicitly, hence closing explicitly is best, otherwise one might run out of memory.

Looking at the docs, there is no MemorySegment#free()/close() or so, and this seems intentional based on https://cr.openjdk.org/~mcimadamore/panama/why_lifetimes.html

Instead, some Arenas can be close()'d.
Looking at Arena docs, of all 4 builtin arena types, only Confined and Shared are allowed to be closed explicitly/eagerly.
In general those pointer abstractions can be accessed by multiple threads, so Confined wouldn't work.

Using a Shared Arena per pointer/buffer allocation seems very expensive both in footprint (need to keep various objects alive vs just a long with Unsafe) and in performance (though I have not benchmarked it yet against allocateMemory+freeMemory).
If also doesn't feel right because those allocations are supposed to be individual memory allocations, not a whole arena/pool allocation.

Therefore, what can be used to be able to free individual MemorySegment efficiently in this context?

Maybe the Automatic arena should have a way to free explicitly a MemorySegment?
I think it would make sense, as while auto-release semantics are convenient, it's always good practice to release such native resources eagerly rather than wait for GC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20250217/d1c25ef6/attachment.htm>