Proposal for Hybrid Threading Model and simpler Async IO

[Jeremy Manson]

FWIW, we're looking at doing this internally by implementing the whole kit
and kaboodle in native code.  We're going to intercept all low-level
blocking calls to libc so that they just result in a change to a different
stack.  Requires approximately no Java-level changes (unless you want
control over which stack you switch to, which is an easy addition).

I spent a fair bit of time working on this last year, but had to
back-burner it for a while in favor of some other work.  There is a *lot*
of demand from our server developers, who all loathe the existing async IO
APIs.  We'll probably circle back to it by the end of the year.

Jeremy


On Tue, May 6, 2014 at 6:15 AM, Florian Weimer <fweimer at redhat.com> wrote:

> 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
>