Proposal for Hybrid Threading Model and simpler Async IO

Joel Richard ri.joel at
Fri May 2 16:34:34 UTC 2014


Recently I have researched a little about how different languages implement
async IO because I wanted to implement a high scalability web server. When
I looked at Google Go, I realized that the common callback approach is
actually just a language-level workaround to fix a VM issue.

So I wondered how it could be possible to implement something similar to
goroutines for the JVM. Here are my thoughts: There should be a class
ThreadRoutine which implements the Runnable interface. If you use any (so
far) blocking methods in it (like Thread.sleep, network/file system IO,
Object.wait and synchronization) it uses however not the blocking native
implementation, but an async version of it. While it waits for the method
to complete, it can run another ThreadRoutine in the same native thread.
This means that all ThreadRoutines can share a small native thread pool. If
longer computations have to be done, the developer can either call
Thread.yield() from time to time or just moves the computation to a
classical thread.

With such an approach it would be much easier to write highly scalable
server software* and it would make it even possible to run most existing
libraries with minimal changes as asynchronous IO libraries. Basically,
they would just have to make sure that they call Thread.yield() in longer
computationally intensive loops and don't start additional normal threads.
Last but not least, the behavior of existing threads wouldn't be changed at

* The advantage of async IO compared to blocking IO is that it doesn’t
require expensive thread context switches and that it needs less memory
(because fewer threads allocate less memory for stacks).

As mentioned above, this would require implementing an asynchronous version
of all blocking native methods. I am not that familiar with JNI nor C, but
I think this could by achieved by allowing the developer to define a second
C function with the _async suffix which calls a callback instead of
returning a value. If the Java native method is called in a normal thread,
the old C function is called and otherwise the _async version of it. Since
Java already supports async IO with NIO, I think it should be technically
possible to implement asynchronous versions for almost all of the currently
blocking native functions. If an operating system doesn't support certain
non-blocking operations, it could just block a special thread instead (as
far as I know Go does it similar).

What do you think about this idea? Has something like that been discussed

Regards, Joel

P.S. I wasn't sure which mailing list is the correct for such an idea. If
it is completely wrong here, please forward it.

More information about the jdk9-dev mailing list