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

[Uwe Schindler]

On Mon, 15 Jul 2024 15:18:20 GMT, Jorn Vernee <jvernee 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.

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