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

[Maurizio Cimadamore]

Hi,
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.

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).

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.

Maurizio

On 27/11/2024 23:24, some-java-user-99206970363698485155 at vodafonemail.de 
wrote:
>
> 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/bb68862b/attachment-0001.htm>