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

[Jorn Vernee]

On Mon, 15 Jul 2024 11:29:49 GMT, Rémi Forax <forax at 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