New candidate JEP: 491: Synchronize Virtual Threads without Pinning

Kyle Stiemann kyle.stiemann at contrastsecurity.com
Wed Oct 23 17:51:16 UTC 2024


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.

- Kyle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20241023/8f3bb632/attachment.htm>


More information about the loom-dev mailing list