EA builds with changes to object monitor implementation to avoid pinning with virtual threads

[Alan Bateman]

On 17/02/2024 12:32, masoud parvari wrote:
> Thanks Alan for the detailed explanation. This reminds me of Java 21 
> deadlock scenarios when obtaining a lock both outside and inside a 
> synchronized block by some number of threads greater than machine 
> cores, could potentially cause deadlock.
>
> I still have one question though. This deadlock scenario (a burst of 
> virtual threads at startup with a mix of class loading (which comes 
> with pinning) and resource loading from the same JAR files) is not 
> happening on 21 and latest 23-ea. I suspect because Forkjoinpool 
> creates more thread to compensate for pinning? Would you please 
> shed some light on this?
>

In JDK 21, the two threads doing getResourceAstream (#119 and #123) 
would not have released the carrier when they blocked on the monitor in 
Zipfile.getEntry.  They pinned their carriers. With the EA builds, they 
do release the underlying carrier threads to do other work. This just 
means that other scheduled virtual threads get to run and block in 
nl.trifork.qti.model.processing.expression.general.BaseValue.<init> with 
a native frame on the stack. So with JDK 21, it was possible to exit the 
monitor for the ZipFile and #119 or #123 would continue. With the EA 
builds, neither can continue as there is no carrier available. This is 
not your doing of course. BaseValue.<init> is probably resolving a 
reference to a class and this is the call through the VM.

I think the summary here is that addressing the issue with object 
monitors pinning is great but the hoorays may be short lived as the spot 
light moves to other cases where carriers are pinned, and specifically 
native frames due to resolving references to classes in the constant 
pool and the resulting class loading, or class initializers. There are 
some ideas around this that may provide some relief on these cases. We 
had to shake out issues with object monitors first.

-Alan