On Mon, 15 Jul 2024 09:17:31 GMT, Maurizio Cimadamore <mcimadam...@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
