<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>Hi,<br>
      the workaround you suggest (e.g. use a custom arena wrapping a
      shared arena + Cleaner) would be the correct way to do this. Note
      that the underlying arena would need to be shared, because a
      Cleaner typically runs in a thread that is different from the
      thread that created the arena, and if that thread needs to be able
      to call Arena::close... you need a shared arena.</p>
    <p>We used to have confined/shared variants that accepted a Cleaner,
      so that they allowed for both explicit and automatic deallocation.
      This feature was not used very often (if at all), and we removed
      it when we started allowing custom Arena implementations (around
      Java 20).</p>
    <p>Note that registering an Arena with a Cleaner can be quite
      expensive. IIRC Netty has something similar [1], but only when
      certain options are specified. This seems the kind of thing you
      want to do while testing your application, but not sure you want
      to do this in production.<br>
    </p>
    <p>Maurizio<br>
    </p>
    <div class="moz-cite-prefix">On 27/11/2024 23:24,
      <a class="moz-txt-link-abbreviated" href="mailto:some-java-user-99206970363698485155@vodafonemail.de">some-java-user-99206970363698485155@vodafonemail.de</a> wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:1f64f3ac-87fb-4382-8187-a21c21da5c9d@vodafonemail.de">
      
      <p>Hello,</p>
      <p>currently you have to choose between these Arena types:<br>
      </p>
      <ul>
        <li>`ofAuto`: Garbage collected, manual cleaning not possible<br>
        </li>
        <li>`ofConfined`, `ofShared`: Not garbage collected, manual
          cleaning</li>
        <li>(`global`)<br>
        </li>
      </ul>
      <p>This is a bit inconvenient for an application which wants to
        free memory as soon as possible (`ofConfined` / `ofShared`).
        Because if it forgets to close the Arena in some call paths, it
        causes a memory leak. Ideally you would always use
        try-with-resources, but that is not possible in all situations.
        So a combination of both manual closing and GC tracking would be
        useful in some situations.<br>
      </p>
      <p>Maybe you can work around this by creating a custom Arena for
        which:</p>
      <ul>
        <li>a delegate 'confined' or 'shared' Arena exists</li>
        <li>a `java.lang.ref.Cleaner` is used which closes the delegate
          Arena</li>
        <li>the `allocate` method obtains a segment from the delegate,
          but then uses `reinterpret` to attach it to the wrapping
          custom Arena</li>
        <li>the `close` method calls `cleanable.clean()` (and to satisfy
          throwing IllegalStateException on double close maybe an
          AtomicBoolean tracking the state; cannot directly call `close`
          on delegate because during GC Cleaner might then encounter an
          IllegalStateException when it calls `close` as well)</li>
        <li>the `scope` method returns the scope of the delegate Arena<br>
        </li>
      </ul>
      <p>Is that the suggested solution here?</p>
      <p><br>
      </p>
      <p>Or would it make sense if the JDK provided such Arena variants,
        respectively added a method for marking a 'confined' or 'shared'
        Arena to be managed by garbage collection?</p>
      <p><br>
      </p>
      <p>Kind regards<br>
      </p>
    </blockquote>
  </body>
</html>