RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2]

[Uwe Schindler]

On Sat, 13 Jul 2024 16:43:16 GMT, Rémi Forax <forax at openjdk.org> wrote:

> Knowing that all the segments are freed during close() is something you may want. But having the execution time of close() be linear with the number of threads is also problematic. Maybe, it means that we need another kind of Arena that works like shared() but allow the freed to be done asynchronously (ofSharedAsyncFree ?).
> 
> Note that the semantics of ofSharedAsyncFree() is different from ofAuto(), ofAuto() relies on the GC to free a segment so the delay before a segment is freed is not time bounded if the application has enough memory, the memory of the segment may never be reclaimed. With ofSharedAsyncFree(), the segments are freed by the last thread, so while this mechanism is not deterministic, it is time bounded.

That's a great suggestion! In our case we just want the index files open as soon as possible, but not on next GC (which will be horrible and brings us back into the times of DirectByteBuffer). The problem with GC is that the Arena/MemorySegments and so on are tiny objects which will live for very long time, especially when they were used for quite some time (like an index segment of an Lucene index).

Of course for testing purposes in Lucene we could use `ofShared()` (to make sure all mmapped files are freeed, especially on Windows as soon as index is close), but in production environments we could offer the option to use delayed close to improve throughput.

Uwe

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2227305407