[javaflow] - how to use continuation in JNI boundary

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[javaflow] - how to use continuation in JNI boundary

Cristian Lorenzetto
Hi

I have a similar scenario

public static final class MyCoroutine implements Runnable {

     Continuation c;
     MyCoroutine(){
       c=Continuation.startWith(this);
     }

    @Override
    public void run() {
       native_func(c, new NativeCallback(){  // inside JNI native_func
Continuation.suspend(); is executed before to call callback.

     public static void callback(){
           Continuation.continueWith(MyCoroutine.this);

    }


   });
}

}

could it work?

I might find a way for calling a native method making a stuff and when is
completed, it calls  a callback( NativeCallback) reactiving the coroutine.

Is there a way for doing it?
Reply | Threaded
Open this post in threaded view
|

Re: [javaflow] - how to use continuation in JNI boundary

Torsten Curdt-3
Hey Cristian,

you have to think of javaflow continuations of having multiple ways of
running through the "run" function with different entry and exit points.

What should/will work is:

  run() {
    native_func();
    Continuation.suspend();
    native_func();
    Continuation.suspend();
  }

I am not quite sure what you are trying to do with your setup. Why
callbacks in a continuation world?
Keep in mind that the native code is not instrumented.

cheers,
Torsten
Reply | Threaded
Open this post in threaded view
|

Re: [javaflow] - how to use continuation in JNI boundary

Cristian Lorenzetto
What i think to understand is :

Coroutine can be suspended in a block like run() {
    native_func();
    Continuation.suspend();

  }
because the stack when is suspended is out from native func.
instead if i call suspend inside a JNI c++ class the stack is not visible
from java so probably javaflow dont work.

I have another different question:
run(){
while(!stream.eof()){
   data=read(stream);
  process(data);
}.

stream is synchonized internally waiting until data is not empty.

My question is: normally in synchonized blocks the thread is blocked until
notify but inside a coroutine the class is instrumented for not blocking
the thread but just for suspending the coroutine until notify?












2018-01-20 18:12 GMT+01:00 Torsten Curdt <[hidden email]>:

> Hey Cristian,
>
> you have to think of javaflow continuations of having multiple ways of
> running through the "run" function with different entry and exit points.
>
> What should/will work is:
>
>   run() {
>     native_func();
>     Continuation.suspend();
>     native_func();
>     Continuation.suspend();
>   }
>
> I am not quite sure what you are trying to do with your setup. Why
> callbacks in a continuation world?
> Keep in mind that the native code is not instrumented.
>
> cheers,
> Torsten
>
Reply | Threaded
Open this post in threaded view
|

Re: [javaflow] - how to use continuation in JNI boundary

Torsten Curdt-3
> because the stack when is suspended is out from native func.
> instead if i call suspend inside a JNI c++ class the stack is not visible
> from java so probably javaflow dont work.
>

The short answer to that question is "yes".



> I have another different question:
> run(){
> while(!stream.eof()){
>    data=read(stream);
>   process(data);
> }.
>
> stream is synchonized internally waiting until data is not empty.
>

How is that example even related to javaflow?
What's the goal here?


My question is: normally in synchonized blocks the thread is blocked until
> notify but inside a coroutine the class is instrumented for not blocking
> the thread but just for suspending the coroutine until notify?
>

That doesn't sound quite right.
While it is true that calls to a synchronized function will have to wait
for a lock on "this",
I would not use terms "synchronized" and "blocking" like that.

Maybe let's try give a birds eye view on how javaflow works.

1. On suspend the function will exit but also store state information in
the Continuation object.
2. On resume the library will call the function again, but it will restore
the state and jump to the position after it was suspended.

The synchronization characteristics should not be affected by that.

cheers,
Torsten
Reply | Threaded
Open this post in threaded view
|

Re: [javaflow] - how to use continuation in JNI boundary

Cristian Lorenzetto
this is a problem for me.

My idea is to use many coroutines instead to use many threads because it is
more scalable.
Consider i realize a scheduler in which i can push many coroutines.
Pratically it is a coroutines pool inside the same thread.

When a corotuines is blocked by a wait() instruction it is not necessary to
block the thread but it is sufficient to suspend it.
When a corotuine is suspended , it is taken another  coroutine ready to be
resumed. In this way the thread is never blocked ... and the global
performance will be very hight.

For this reason is important to instrument synchronized blocks.









2018-01-20 19:51 GMT+01:00 Torsten Curdt <[hidden email]>:

> > because the stack when is suspended is out from native func.
> > instead if i call suspend inside a JNI c++ class the stack is not visible
> > from java so probably javaflow dont work.
> >
>
> The short answer to that question is "yes".
>
>
>
> > I have another different question:
> > run(){
> > while(!stream.eof()){
> >    data=read(stream);
> >   process(data);
> > }.
> >
> > stream is synchonized internally waiting until data is not empty.
> >
>
> How is that example even related to javaflow?
> What's the goal here?
>
>
> My question is: normally in synchonized blocks the thread is blocked until
> > notify but inside a coroutine the class is instrumented for not blocking
> > the thread but just for suspending the coroutine until notify?
> >
>
> That doesn't sound quite right.
> While it is true that calls to a synchronized function will have to wait
> for a lock on "this",
> I would not use terms "synchronized" and "blocking" like that.
>
> Maybe let's try give a birds eye view on how javaflow works.
>
> 1. On suspend the function will exit but also store state information in
> the Continuation object.
> 2. On resume the library will call the function again, but it will restore
> the state and jump to the position after it was suspended.
>
> The synchronization characteristics should not be affected by that.
>
> cheers,
> Torsten
>
Reply | Threaded
Open this post in threaded view
|

Re: [javaflow] - how to use continuation in JNI boundary

Torsten Curdt-3
> this is a problem for me.
>

I don't see the problem yet



> My idea is to use many coroutines instead to use many threads because it is
> more scalable.


*nod*


Consider i realize a scheduler in which i can push many coroutines.
> Pratically it is a coroutines pool inside the same thread.
>

Yes, that is possible. The continuations are not bound to threads.



> When a corotuines is blocked by a wait() instruction it is not necessary to
> block the thread but it is sufficient to suspend it.
> When a corotuine is suspended , it is taken another  coroutine ready to be
> resumed. In this way the thread is never blocked ... and the global
> performance will be very hight.
>
> For this reason is important to instrument synchronized blocks.
>

Sorry, but I don't see your point yet.

It's been a while since I wrote that library but...
Frankly speaking I don't see the need for synchronization.
The state is handled per thread and it then creates a new continuation.
There is no mutation an no need for synchronization - unless your code
requires it.
Reply | Threaded
Open this post in threaded view
|

Re: [javaflow] - how to use continuation in JNI boundary

Cristian Lorenzetto
"unless your code
requires it". Yes my code contains synchonized blocks. I used also external
libraries using other synchonized blocks. So i can replace synchonized
blocks manually.

The coroutine runs code using mutex and shared resources.

2018-01-20 23:17 GMT+01:00 Torsten Curdt <[hidden email]>:

> > this is a problem for me.
> >
>
> I don't see the problem yet
>
>
>
> > My idea is to use many coroutines instead to use many threads because it
> is
> > more scalable.
>
>
> *nod*
>
>
> Consider i realize a scheduler in which i can push many coroutines.
> > Pratically it is a coroutines pool inside the same thread.
> >
>
> Yes, that is possible. The continuations are not bound to threads.
>
>
>
> > When a corotuines is blocked by a wait() instruction it is not necessary
> to
> > block the thread but it is sufficient to suspend it.
> > When a corotuine is suspended , it is taken another  coroutine ready to
> be
> > resumed. In this way the thread is never blocked ... and the global
> > performance will be very hight.
> >
> > For this reason is important to instrument synchronized blocks.
> >
>
> Sorry, but I don't see your point yet.
>
> It's been a while since I wrote that library but...
> Frankly speaking I don't see the need for synchronization.
> The state is handled per thread and it then creates a new continuation.
> There is no mutation an no need for synchronization - unless your code
> requires it.
>
Reply | Threaded
Open this post in threaded view
|

Re: [javaflow] - how to use continuation in JNI boundary

Cristian Lorenzetto
synchonized blocks are not used for coroutines but the code inside the
coroutine uses mutexes... so synchonized,wait/notify are present.

For this reason i i want instrument wait/notify ... for replacing normal
mutex parking the thread with a mutex suspending the coroutine

2018-01-20 23:24 GMT+01:00 Cristian Lorenzetto <
[hidden email]>:

> "unless your code
> requires it". Yes my code contains synchonized blocks. I used also
> external libraries using other synchonized blocks. So i can replace
> synchonized blocks manually.
>
> The coroutine runs code using mutex and shared resources.
>
> 2018-01-20 23:17 GMT+01:00 Torsten Curdt <[hidden email]>:
>
>> > this is a problem for me.
>> >
>>
>> I don't see the problem yet
>>
>>
>>
>> > My idea is to use many coroutines instead to use many threads because
>> it is
>> > more scalable.
>>
>>
>> *nod*
>>
>>
>> Consider i realize a scheduler in which i can push many coroutines.
>> > Pratically it is a coroutines pool inside the same thread.
>> >
>>
>> Yes, that is possible. The continuations are not bound to threads.
>>
>>
>>
>> > When a corotuines is blocked by a wait() instruction it is not
>> necessary to
>> > block the thread but it is sufficient to suspend it.
>> > When a corotuine is suspended , it is taken another  coroutine ready to
>> be
>> > resumed. In this way the thread is never blocked ... and the global
>> > performance will be very hight.
>> >
>> > For this reason is important to instrument synchronized blocks.
>> >
>>
>> Sorry, but I don't see your point yet.
>>
>> It's been a while since I wrote that library but...
>> Frankly speaking I don't see the need for synchronization.
>> The state is handled per thread and it then creates a new continuation.
>> There is no mutation an no need for synchronization - unless your code
>> requires it.
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [javaflow] - how to use continuation in JNI boundary

Torsten Curdt-3
I am sorry but I must be missing something here.

The code uses synchronization blocks and mutexes to explicitly make sure
threads don't interfere which each other.
This restriction will be there because of resource sharing and the java
memory model.
Instrumenting wait/notify cannot magically remove that restriction.

Based on queuing theory you can move your bottleneck to your mutexes - but
that's about it.
Reply | Threaded
Open this post in threaded view
|

Re: [javaflow] - how to use continuation in JNI boundary

Cristian Lorenzetto
It is absolutely not true. If a coroutine  execute

synchonized(lock){ lock.wait() }

the lock.wait blocks the thread. Why i have to block the thread if thread
can running other corotuines in the while?
lock.wait must supend the coroutine and resuming another coroutine

2018-01-21 0:23 GMT+01:00 Torsten Curdt <[hidden email]>:

> I am sorry but I must be missing something here.
>
> The code uses synchronization blocks and mutexes to explicitly make sure
> threads don't interfere which each other.
> This restriction will be there because of resource sharing and the java
> memory model.
> Instrumenting wait/notify cannot magically remove that restriction.
>
> Based on queuing theory you can move your bottleneck to your mutexes - but
> that's about it.
>
Reply | Threaded
Open this post in threaded view
|

Re: [javaflow] - how to use continuation in JNI boundary

Torsten Curdt-3
This does not remove the restriction on the synchronization - that still
exists.
The thread could do something else during the wait - but that's another
story.

There just is not automatic suspend on wait.
And it begs the question how such a thing would/should look like.

I am not saying this isn't something that could be interesting to
investigate - but this is just not what javaflow is.
The current javaflow implementation is about state storing and restoring -
not scheduling and pooling.

While you could improve thread usage by implementing thread re-use during
wait, the big problem will still always be the synchronized code.
So it really feels like you are trying to solve a problem from the wrong
end.

Anyway - my 2 cents.
Take them or leave 'em ;)

On Sun, Jan 21, 2018 at 12:36 AM, Cristian Lorenzetto <
[hidden email]> wrote:

> It is absolutely not true. If a coroutine  execute
>
> synchonized(lock){ lock.wait() }
>
> the lock.wait blocks the thread. Why i have to block the thread if thread
> can running other corotuines in the while?
> lock.wait must supend the coroutine and resuming another coroutine
>
> 2018-01-21 0:23 GMT+01:00 Torsten Curdt <[hidden email]>:
>
> > I am sorry but I must be missing something here.
> >
> > The code uses synchronization blocks and mutexes to explicitly make sure
> > threads don't interfere which each other.
> > This restriction will be there because of resource sharing and the java
> > memory model.
> > Instrumenting wait/notify cannot magically remove that restriction.
> >
> > Based on queuing theory you can move your bottleneck to your mutexes -
> but
> > that's about it.
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [javaflow] - how to use continuation in JNI boundary

Cristian Lorenzetto
I read now Loom project is thinking to do exactly what i proposed. But when
it will be available? uhmmm i think i could require years...
I dont know , maybe i could patch the instrumenter

2018-01-21 1:21 GMT+01:00 Torsten Curdt <[hidden email]>:

> This does not remove the restriction on the synchronization - that still
> exists.
> The thread could do something else during the wait - but that's another
> story.
>
> There just is not automatic suspend on wait.
> And it begs the question how such a thing would/should look like.
>
> I am not saying this isn't something that could be interesting to
> investigate - but this is just not what javaflow is.
> The current javaflow implementation is about state storing and restoring -
> not scheduling and pooling.
>
> While you could improve thread usage by implementing thread re-use during
> wait, the big problem will still always be the synchronized code.
> So it really feels like you are trying to solve a problem from the wrong
> end.
>
> Anyway - my 2 cents.
> Take them or leave 'em ;)
>
> On Sun, Jan 21, 2018 at 12:36 AM, Cristian Lorenzetto <
> [hidden email]> wrote:
>
> > It is absolutely not true. If a coroutine  execute
> >
> > synchonized(lock){ lock.wait() }
> >
> > the lock.wait blocks the thread. Why i have to block the thread if thread
> > can running other corotuines in the while?
> > lock.wait must supend the coroutine and resuming another coroutine
> >
> > 2018-01-21 0:23 GMT+01:00 Torsten Curdt <[hidden email]>:
> >
> > > I am sorry but I must be missing something here.
> > >
> > > The code uses synchronization blocks and mutexes to explicitly make
> sure
> > > threads don't interfere which each other.
> > > This restriction will be there because of resource sharing and the java
> > > memory model.
> > > Instrumenting wait/notify cannot magically remove that restriction.
> > >
> > > Based on queuing theory you can move your bottleneck to your mutexes -
> > but
> > > that's about it.
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [javaflow] - how to use continuation in JNI boundary

Torsten Curdt-3
I don't want to discourage you from contributing but...
as also descripted in the Loom proposal already suggests - it's much more
than just patching the Instrumenter.
If you want to re-use the threads you also need to add some kind of pooling
and scheduling mechanism.

On Sun, Jan 21, 2018 at 2:00 AM, Cristian Lorenzetto <
[hidden email]> wrote:

> I read now Loom project is thinking to do exactly what i proposed. But when
> it will be available? uhmmm i think i could require years...
> I dont know , maybe i could patch the instrumenter
>
> 2018-01-21 1:21 GMT+01:00 Torsten Curdt <[hidden email]>:
>
> > This does not remove the restriction on the synchronization - that still
> > exists.
> > The thread could do something else during the wait - but that's another
> > story.
> >
> > There just is not automatic suspend on wait.
> > And it begs the question how such a thing would/should look like.
> >
> > I am not saying this isn't something that could be interesting to
> > investigate - but this is just not what javaflow is.
> > The current javaflow implementation is about state storing and restoring
> -
> > not scheduling and pooling.
> >
> > While you could improve thread usage by implementing thread re-use during
> > wait, the big problem will still always be the synchronized code.
> > So it really feels like you are trying to solve a problem from the wrong
> > end.
> >
> > Anyway - my 2 cents.
> > Take them or leave 'em ;)
> >
> > On Sun, Jan 21, 2018 at 12:36 AM, Cristian Lorenzetto <
> > [hidden email]> wrote:
> >
> > > It is absolutely not true. If a coroutine  execute
> > >
> > > synchonized(lock){ lock.wait() }
> > >
> > > the lock.wait blocks the thread. Why i have to block the thread if
> thread
> > > can running other corotuines in the while?
> > > lock.wait must supend the coroutine and resuming another coroutine
> > >
> > > 2018-01-21 0:23 GMT+01:00 Torsten Curdt <[hidden email]>:
> > >
> > > > I am sorry but I must be missing something here.
> > > >
> > > > The code uses synchronization blocks and mutexes to explicitly make
> > sure
> > > > threads don't interfere which each other.
> > > > This restriction will be there because of resource sharing and the
> java
> > > > memory model.
> > > > Instrumenting wait/notify cannot magically remove that restriction.
> > > >
> > > > Based on queuing theory you can move your bottleneck to your mutexes
> -
> > > but
> > > > that's about it.
> > > >
> > >
> >
>