Proposal for Hybrid Threading Model and simpler Async IO

Florian Weimer fweimer at redhat.com
Tue May 6 13:15:31 UTC 2014


On 05/04/2014 02:19 PM, Joel Richard wrote:

> Right now, InputStream.read(byte b[]) is a blocking method. Hence the
> native thread waits until the byte array got filled. With my proposal, the
> underlaying blocking native method (for example
> java.net.SocketInputStream#socketRead0) would not block the native thread
> anymore. Instead, it would call the C function with the _async suffix and
> continue to process another task. As soon the async operation has
> completed, it can then continue with the first task (maybe even in another
> native thread).

You cannot do this without completely redesigning JNI.  You cannot 
resume native code on a different native thread than the one it 
initially ran on because that would change the set of thread-local 
variables, and native code is compiled with the assumption that 
references to thread-local variables are stable (relative to the current 
stack).

On the Java side, you'd likely have to duplicate thread local variables, 
to preserve the current semantics.  Better support for coroutines would 
be nice, but I don't think it's prudent to attempt to provide this 
functionality purely at the JVM layer because of the resulting 
interoperability issues.

-- 
Florian Weimer / Red Hat Product Security Team


More information about the jdk9-dev mailing list