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