Strange problem with deoptimization on highly concurrent thread-local handshake reported to Apache Lucene

[Maurizio Cimadamore]

On 01/07/2024 22:29, Jorn Vernee wrote:
> Addressing JDK-8290892 would mean that we only need to deoptimize 
> threads that are actually accessing the arena that is being closed. 
> Another possible interim improvement could be to only deoptimize 
> threads that are actually in the middle of accessing a memory segment, 
> not just all threads. That's a relatively low-hanging fruit I noticed 
> recently, but haven't had time to look into yet. I've filed: 
> https://bugs.openjdk.org/browse/JDK-8335480

This seems a good idea!

In my experience, the cost associated with shared arenas has to do with 
the stop-the-world like pause associated with closing a shared arena. 
I'm not sure how much deoptimization and stack walking plays a factor 
_once you have stopped the target thread_.

Thread-local handshake also allow to perform handshake only on a subset 
of threads, which would be handy to avoid stopping the entire world, I 
wonder if maybe in the future some middle-ground API where a set of 
participating threads can be nominated when the arena is constructed 
might come in useful, although I suspect that in most cases (including 
Lucene) the set of threads working on segments produced by a given arena 
is not known before-hand.

Maurizio