5 ms·
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.
by jpgvm 5y ago
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).
- kaba0 5y agoThe 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.
- kllrnohj 5y agoMaybe 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 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 5y agoVery 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.