Proposal for Hybrid Threading Model and simpler Async IO

[Joel Richard]

Hi Jeremy,

Thank you very much for sharing this with us. Would you mind to elaborate
on your work a little bit further? I am particularly interested in answers
for the following questions:

How do you save the stack state before executing a pausing call and then be
able to resume the same program flow on another thread? What changes have
you applied to JNI? Can you tell us already something about the performance
and scalability characteristic? Are there already any plans to contribute
your work to the OpenJDK or will that remain an internal project?

Thanks, Joel


On Tue, May 6, 2014 at 11:33 PM, Jeremy Manson <jeremymanson at google.com>wrote:

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