On Mon, 15 Jul 2024 11:29:49 GMT, Rémi Forax <fo...@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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228756598
