I'm curious about

> There are situations when the VM cannot suspend a virtual thread, in which case it is said to be pinned. Currently, there are two:

> When a native method is currently executing in the virtual thread (even if it is calling back into Java)

Does that mean any kind of native code is currently paying some extra cost due to the possibility of being blocking? What if I e.g. want to call a library that is known to be non-blocking, or make a syscall that is non-blocking which is not pre-wrapped by the Java standard library? E.g. a library that allows to offer interacting with a BPF map comes to my mind. Is there maybe an escape hatch for virtual thread aware java libraries, where they can tell the runtime that they want to call native code without extra guardrails and overhead?

I suspect that this is not about the possibility of blocking, but rather that native code needs a native stack (not on the Java heap) and execution state that cannot be suspended like Java code can.

If you have "short" native methods, like in a typical async I/O library, this is not a problem. They cannot be suspended while in there, but they repeatedly go back to Java code where they can be suspended.

So your scenario is only really a concern with a long-running but non-blocking native method, say, a physics library that does lots of computations. The answer is most likely: Don't run that in a virtual thread.

I/O from JNI is very rare in JVM world. I think the most common cases are going to be really CPU intensive libs like compression and encryption implementations. But yeah, just run these on a native thread pool (which you should probably do anyway).

Also all of the existing JVM IO is done with JNI. How do you think java.io is implemented itself? Of course Loom can change those implementations, but strictly speaking JNI is currently extremely common for Java IO. How big of a task supporting virtual threads for the Java libraries remains to be seen, especially for the unofficial extensions like the sun.nio.* package