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