On Mon, 15 Jul 2024 15:18:20 GMT, Jorn Vernee <jver...@openjdk.org> wrote:
> > > This is what I was thinking of as well. close() on a shared arena can be > > > called by any thread, so it would be possible to have an executor service > > > with 1-n threads that is dedicated to closing memory. > > > > > > This delays both the closing of the Arena and the freeing of the segments, > > so bugs may be not discovered if the arena is accessed in between the time > > the thread pool is notified and the time the close() is effectively called. > > Closing the arena is what requires the handshake, which is where the majority > of the cost is. I don't see the point in closing synchronously, but then > freeing the memory asynchronously, since the latter is relatively cheap. I think the idea is to trigger the handshake async and then close after the handshake (in a callback when hadshake finishs). This is only a problem if you for example want to delete a mmapped file on Windows. This won't work as long as the memory is mmapped, but in all other cases. So there should be the option to allow async close() [if client supports it], but the defaulkt should be synchronized. I think this is what @forax suggested. But anyways: Using a separate extra thread is a good idea. I proposed this for Apache Solr and Elasticsearch people are checking their code at moment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228760782
