3 ms·

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 c

by moring 5y ago

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.

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 ago
  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.
- kllrnohj 5y ago
  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 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 ago
    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.

by moring 5y ago

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 ago
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.
kllrnohj 5y ago
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 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 ago
  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.