New candidate JEP: 491: Synchronize Virtual Threads without Pinning

[Alan Bateman]

On 23/10/2024 18:51, Kyle Stiemann wrote:
> Hello,
> I work on the Java Agent team at Contrast Security. Our agent has to 
> track security-relevant data/contexts across threads (including 
> virtual threads). When a thread changes contexts, it pulls from a 
> ConcurrentReferenceHashMap of contexts. On Java 21 with virtual 
> threads, we were getting a deadlock with ConcurrentReferenceHashMap as 
> it uses ReetrantLock. The only way we found to fix this deadlock was 
> to change to use synchronized instead of ReetrantLock in order to pin 
> the current virtual thread to a platform thread until our context 
> switching completed. This was likely because we instrument the 
> ForkJoinPool to track context switches. Since virtual threads are 
> built on ForkJoinPool, we need to make sure our instrumentation always 
> executes on a platform thread to avoid deadlocks. I believe our agent 
> will always need to be able to pin threads while context switching. 
> Other Java agents might need to as well. Changing synchronized to 
> avoid pinning seems like a good idea overall for the JVM, but I think 
> it would be good if this JEP also provides an API to pin and unpin 
> threads (possibly on the JDK Instrumentation object so it's only for 
> agents). Otherwise we'll need to find some other hacky solution (if 
> one even exists) or we won't be able to support security analysis with 
> virtual threads in whichever JVM version implements JEP 491.
>
If I read this correctly, you are instrumenting critical JDK code to 
call out to effectively arbitrary Java code. I doubt this will be 
reliable. In addition to the deadlock issue you mention, you will 
shortly need to deal with the interaction with FJP being in the context 
of the virtual thread, not its carrier, when one virtual threads unparks 
another. There are also subtle issues with arbitrary Java code consuming 
the parking permit and leading to lost wakeup issues.

There has been some prototype exploration into JVMTI events to allow 
callbacks in native agents (not Java agents) execute at scheduling 
points. This is the closest thing that comes to mind when reading your mail.

-Alan