GC managed variant of 'confined' and 'shared' Arena

some-java-user-99206970363698485155 at vodafonemail.de some-java-user-99206970363698485155 at vodafonemail.de
Wed Nov 27 23:24:38 UTC 2024


Hello,

currently you have to choose between these Arena types:

  * `ofAuto`: Garbage collected, manual cleaning not possible
  * `ofConfined`, `ofShared`: Not garbage collected, manual cleaning
  * (`global`)

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.

Maybe you can work around this by creating a custom Arena for which:

  * a delegate 'confined' or 'shared' Arena exists
  * a `java.lang.ref.Cleaner` is used which closes the delegate Arena
  * the `allocate` method obtains a segment from the delegate, but then
    uses `reinterpret` to attach it to the wrapping custom Arena
  * 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)
  * the `scope` method returns the scope of the delegate Arena

Is that the suggested solution here?


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?


Kind regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20241128/932221d2/attachment.htm>


More information about the panama-dev mailing list