On: Java Virtual Threads Preview

[jpgvm]

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).

[kllrnohj → jpgvm]

Maybe maybe not. If you want to take advantage of things like io_uring you're going to be doing that with a JNI lib. Such as this Netty incubator support for it https://github.com/netty/netty-incubator-transport-io_uring

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

[jpgvm → kllrnohj]

Very likely such a thing will be pinned to a few OS threads and then interact with a virtual thread pool to farm out work.

In general most Java I/O is native because it's "sufficiently fast" for such things. Netty is the exception rather than the rule in this regard.

[kaba0 → jpgvm]

The only thing I can think of where it may come up is interacting with OpenGL? But that will also be mapped to a single thread.