Questions regarding VirtualThread pinning JDK21 vs loom EA build

[Christian Ortlepp]

Hi,

I recently watched Alan Batemans talk on VirtualThreads at this years 
FOSDEM 
(https://fosdem.org/2024/schedule/event/fosdem-2024-3255-virtual-thread-s-next-steps/). 
It cleared up some questions, but also left me with some new ones.

First, regarding pinning on monitor-enter: Before this talk was 
published I already stumbled onto this Issue when testing 
VirtualThreads. I was very surprised to see that this limitation was not 
mentioned in the JEP (along with the other  pinning causes) or any other 
official communication (Or did I just miss something?). And this kind of 
pinning of course also does not trigger the stacktrace dumps from 
"-Djdk.tracePinnedThreads=full". The latter is probably due to the fact 
that it would spam the log so much that the tool would be useless to 
begin with, but why was this limitation not as publicly disclosed as the 
other ones? It seems to me that pinning on monitor-enter has the same 
performance-degrading characteristics as pinning while monitor enter, 
and the same safety issues too (i.e. the possibility to easily introduce 
deadlocks that would not occur using platform threads). Lastly, did I 
understand you correctly that the current EA build not only fixes 
parking-while-holding-a-monitor but also pinning-on-monitor-enter?

Second, in the FOSDEM talk Alan showed FileChannel.open()/read() as an 
example of filesystem I/O that expands the parallelism of the ForkJoin 
scheduler. Now FileChannel is a java.nio.* API. I was under the 
impression that java.nio.* works gracefully with the current 
VirtualThread implementation, since in java.nio.* the actual blocking is 
done by the background nio threadpool and not the caller. From your 
example I assume that not to be the case. Is it possible to (easily) 
distinct which methods in java.nio.* execute the I/O call themselves, 
and which delegate this action to the nio pool?

Third, regarding io_uring: Are only "functional" problems the cause for 
io_uring not being available as of now (i.e. difficult implementation of 
io_uring interface in the JDK) or also quirks/problems of the io_uring 
API itself, especially security-wise. I read that google actually 
disabled io_uring on many of their production systems due to security 
concerns 
(https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html). 
Is this also a concern to the JDK/loom team?


Best Regards,

Christian Ortlepp