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

[Uwe Schindler]

On Mon, 15 Jul 2024 09:17:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> One only closing arenas, another set that consumes scoped memory and a third group doing totally unrelated stuff.
>> 
>> Exactly. My general feeling is that the cost of handshaking a thread dominates everything else, so doing improvements around e.g. avoiding unnecessary deoptimization (as in this PR) is not going to help much, even for threads doing unrelated stuff, but I'd be happy to be proven wrong.
>
>> avoiding unnecessary deoptimization (as in this PR) is not going to help much,
> 
> What would definitively help is to somehow reduce the number of threads to handshake when calling close - e.g. have an arena that is shared but only to a *group* of thread. We can do that easily using structured concurrency. But for unstructured code there's not a lot that can be done, as there's no way for the runtime to guess which threads can access segments created by a given arena.

@mcimadamore: FYI, at the moment we are working on grouping mmapped files together (by their index segment file pattern) and use the same arena for multiple index files. Because those are closed together we can use a refcounted aproach. All files of a group (the index segment name) share the same arena and this one is closed after last file in group is closed: https://github.com/apache/lucene/pull/13570

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

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