<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>Hi,<br>
      when it comes to deallocation, I think you can summarize the
      situation with efficient, shared, safe: pick two.</p>
    <p><br>
      You can have safe and efficient deallocation with confined access
      (or, in the future, structured access).</p>
    <p><br>
    </p>
    <p>You can have safe, but less efficient shared deallocation with
      eithe letting the GC do the work (reachability-base automatic
      arena) or having some more expensive handshake when the arena is
      closed (shared arena).</p>
    <p><br>
    </p>
    <p>You can have _unsafe_ efficient shared allocation: just wrap
      malloc/free using the Linker API, and then use
      MemorySegment::reinterpret to resize he unsafely allocated
      segments accordingly. This will give you something closer to the C
      feel but it is (as C is), unsafe (reinterpret is a restricted
      method).<br>
    </p>
    <p><br>
    </p>
    <p>(There's also solution in the middle - by having pooling arenas
      you can greatly reduce the cost of malloc/free -- but your mileage
      might vary as those solutions will typically only work best if
      your memory allocation is somewhat structured -- e.g. if
      allocation occurs in a code block).</p>
    <p><br>
    </p>
    <p>What you end up using is up to you (and your requirements). The
      FFM API supports all the above -- but of course the Arena API,
      that is designed to be a safe API only gives you access to safe
      way to allocate/deallocate segments.</p>
    <p><br>
    </p>
    <p>Maurizio<br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 17/02/2025 16:19, Benoit Daloze
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:SJ2PR10MB7598DFD817526BD41CD488248FFB2@SJ2PR10MB7598.namprd10.prod.outlook.com">
      
      <style type="text/css" style="display:none;">P {margin-top:0;margin-bottom:0;}</style>
      <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        Hello panama-dev,</div>
      <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        <br>
      </div>
      <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        We are looking at migrating from Unsafe off-heap methods to
        Panama/MemorySegment.</div>
      <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        While migrating we hit a blocker for replacing
        Unsafe#freeMemory() calls.</div>
      <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        <br>
      </div>
      <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        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).</div>
      <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        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).</div>
      <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        <br>
      </div>
      <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        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.
        <a href="https://www.rubydoc.info/gems/ffi/1.16.3/FFI/Pointer#free-instance_method" id="OWA5bf8ac37-78a9-ec4c-935b-da2e81a96692" class="OWAAutoLink moz-txt-link-freetext" moz-do-not-send="true">
https://www.rubydoc.info/gems/ffi/1.16.3/FFI/Pointer#free-instance_method</a></div>
      <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        <br>
      </div>
      <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        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.</div>
      <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        <br>
      </div>
      <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        Looking at the docs, there is no MemorySegment#free()/close() or
        so, and this seems intentional based on
        <a href="https://cr.openjdk.org/~mcimadamore/panama/why_lifetimes.html" id="OWAfc1a7c26-05c9-642a-783c-17481aab96a7" class="OWAAutoLink moz-txt-link-freetext" moz-do-not-send="true">
          https://cr.openjdk.org/~mcimadamore/panama/why_lifetimes.html</a></div>
      <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        <br>
      </div>
      <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        Instead, some Arenas can be close()'d.</div>
      <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        Looking at Arena docs, of all 4 builtin arena types, only
        Confined and Shared are allowed to be closed explicitly/eagerly.</div>
      <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        In general those pointer abstractions can be accessed by
        multiple threads, so Confined wouldn't work.</div>
      <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        <br>
      </div>
      <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        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).<br>
        If also doesn't feel right because those allocations are
        supposed to be individual memory allocations, not a whole
        arena/pool allocation.</div>
      <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        <br>
      </div>
      <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        Therefore, what can be used to be able to free individual
        MemorySegment efficiently in this context?</div>
      <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        <br>
      </div>
      <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        Maybe the Automatic arena should have a way to free explicitly a
        MemorySegment?</div>
      <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        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.</div>
    </blockquote>
  </body>
</html>