Continuation mechanism in RIFE?

[liu chang]

Hi all,

I'm quite new here so execuse me if this is FAQ.

As I understand RIFE supports some form of continuation using pure
Java, and in the process rife needs to be able to clone the stack. But
I also understand that java forbids the inspection of the stack by a
running program. So, how is stack cloning exactly done in rife? What
exactly does the bytecode manipulator do? Are there any limitations or
potential problems regarding effeciency etc? And how extensible is the
approach to other frameworks/languages? Implementing continuation in
pure java isn't easy, so maybe there is some research paper that talks
about the rife approach?

I looked through the rife site but found no mention of this. And I
have no clue where to start looking in the rife-continuation source
code :P Some general hints are greatly appreciated. :)

Liu Chang

[Geert Bevin]

Hi Lui,

> As I understand RIFE supports some form of continuation using pure
> Java, and in the process rife needs to be able to clone the stack. But
> I also understand that java forbids the inspection of the stack by a

Indeed.

> running program. So, how is stack cloning exactly done in rife? What
> exactly does the bytecode manipulator do? Are there any limitations or

For the variable stack, the bytecode manipulation adds the required  
instructions to maintain a parallel stack that mimics the standard  
Java stack. It is this stack that is cloned.

> potential problems regarding effeciency etc? And how extensible is the

It turns out to be very efficient as long as you don't put a huge  
amount of data in your local variable stack. We've used it on large  
production sites without any negative impact.

> approach to other frameworks/languages? Implementing continuation in

It can and work is underway to make this reusable with the RIFE/
Continuations sub-project.

> pure java isn't easy, so maybe there is some research paper that talks
> about the rife approach?

Some has been inspired by what is explained here:
http://www.cs.kuleuven.ac.be/~eddy/BRAKES/brakes.html

> I looked through the rife site but found no mention of this. And I

Indeed, there's no detailed documentation about it available (yet).

> have no clue where to start looking in the rife-continuation source
> code :P Some general hints are greatly appreciated. :)

On a small side-note, RIFE/Continuations as an independent project is  
considered experimental as it's a quick attempt at extracting the  
continuations engine for use inside other frameworks, like for  
example WebWork. RIFE itself hasn't reintegrated the extracted  
continuations source code yet, so the engine inside RIFE is more  
stable for the moment.

Best regards,

Geert

--
Geert Bevin                       Uwyn bvba
"Use what you need"               Avenue de Scailmont 34
http://www.uwyn.com               7170 Manage, Belgium
gbevin[remove] at uwyn dot com    Tel [phone]

PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net

[liu chang]

On 1/25/06, Geert Bevin <gbevin@...> wrote:

> Hi Lui,
>
> > As I understand RIFE supports some form of continuation using pure
> > Java, and in the process rife needs to be able to clone the stack. But
> > I also understand that java forbids the inspection of the stack by a
>
> Indeed.
>
> > running program. So, how is stack cloning exactly done in rife? What
> > exactly does the bytecode manipulator do? Are there any limitations or
>
> For the variable stack, the bytecode manipulation adds the required
> instructions to maintain a parallel stack that mimics the standard
> Java stack. It is this stack that is cloned.
>
> > potential problems regarding effeciency etc? And how extensible is the
>
> It turns out to be very efficient as long as you don't put a huge
> amount of data in your local variable stack. We've used it on large
> production sites without any negative impact.
>
> > approach to other frameworks/languages? Implementing continuation in
>
> It can and work is underway to make this reusable with the RIFE/
> Continuations sub-project.
>
> > pure java isn't easy, so maybe there is some research paper that talks
> > about the rife approach?
>
> Some has been inspired by what is explained here:
> http://www.cs.kuleuven.ac.be/~eddy/BRAKES/brakes.html
>
> > I looked through the rife site but found no mention of this. And I
>
> Indeed, there's no detailed documentation about it available (yet).
>
> > have no clue where to start looking in the rife-continuation source
> > code :P Some general hints are greatly appreciated. :)
>
> On a small side-note, RIFE/Continuations as an independent project is
> considered experimental as it's a quick attempt at extracting the
> continuations engine for use inside other frameworks, like for
> example WebWork. RIFE itself hasn't reintegrated the extracted
> continuations source code yet, so the engine inside RIFE is more
> stable for the moment.
>
> Best regards,
>
> Geert
>

Hi Geert, thanx for the quick reply.

I just read the brakes paper that was linked from your post, kinda
like one that I've read,
http://homepage.mac.com/t.sekiguchi/paper/ehbook01.pdf, though it uses
exception instead of normal return :)

I looked into the EngineClassLoader class which i believe is the main
class loader? It seems to me that only classes Element and
ElementAware are modified to handle continuation. While this looks
great for performance reasons it puzzles me a lot. What happens if
there're non-element classes on the stack? How can the continuation
captured correctly and restored later when these classes are not
"coorperating"? Or does the operation of rife somehow guarantees that
only Elements will be on the stack? (sorry I'm not very familiar with
the workings of rife)

btw my name is "Liu" not "Lui" :P

Thanks again Geert for the great work of Rife :)

Liu Chang

> --
> Geert Bevin                       Uwyn bvba
> "Use what you need"               Avenue de Scailmont 34
> http://www.uwyn.com               7170 Manage, Belgium
> gbevin[remove] at uwyn dot com    Tel [phone]
>
> PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
> Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net
>
>
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://lists.uwyn.com/mailman/listinfo/rife-devel
>

[Geert Bevin]

Hi Liu,

> Hi Geert, thanx for the quick reply.
>
> I just read the brakes paper that was linked from your post, kinda
> like one that I've read,
> http://homepage.mac.com/t.sekiguchi/paper/ehbook01.pdf, though it uses
> exception instead of normal return :)

RIFE uses exceptions too.

> I looked into the EngineClassLoader class which i believe is the main
> class loader?

Indeed.

> It seems to me that only classes Element and
> ElementAware are modified to handle continuation. While this looks
> great for performance reasons it puzzles me a lot. What happens if
> there're non-element classes on the stack? How can the continuation
> captured correctly and restored later when these classes are not
> "coorperating"? Or does the operation of rife somehow guarantees that
> only Elements will be on the stack? (sorry I'm not very familiar with

RIFE currently only supports continuations in the entrance methods of  
elements. We wrote experimental code to restore the method call  
stack, but that has been erased a while ago to first focus on making  
the current case work perfectly.

RIFE will also only support byte-code instrumentation in elements.  
This makes sense as a web application framework since elements are  
the building blocks and will create the business logic of the entire  
application. RIFE also knows the singular entry point, which is very  
convenient to restore the call and variable stack. There is nothing  
that would prevent you from applying the same process to all your  
classes, but it will create a huge overhead.

> the workings of rife)
>
> btw my name is "Liu" not "Lui" :P

Actually, I meant to write Liu, but Lui came out ... sorry about that.

> Thanks again Geert for the great work of Rife :)
>
> Liu Chang
>
>> --
>> Geert Bevin                       Uwyn bvba
>> "Use what you need"               Avenue de Scailmont 34
>> http://www.uwyn.com               7170 Manage, Belgium
>> gbevin[remove] at uwyn dot com    Tel [phone]
>>
>> PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
>> Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net
>>
>>
>> _______________________________________________
>> Rife-devel mailing list
>> Rife-devel@...
>> http://lists.uwyn.com/mailman/listinfo/rife-devel
>>
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://lists.uwyn.com/mailman/listinfo/rife-devel
>

--
Geert Bevin                       Uwyn bvba
"Use what you need"               Avenue de Scailmont 34
http://www.uwyn.com               7170 Manage, Belgium
gbevin[remove] at uwyn dot com    Tel [phone]

PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net

[liu chang]

On 1/25/06, Geert Bevin <gbevin@...> wrote:

> Hi Liu,
>
> > Hi Geert, thanx for the quick reply.
> >
> > I just read the brakes paper that was linked from your post, kinda
> > like one that I've read,
> > http://homepage.mac.com/t.sekiguchi/paper/ehbook01.pdf, though it uses
> > exception instead of normal return :)
>
> RIFE uses exceptions too.
>
> > I looked into the EngineClassLoader class which i believe is the main
> > class loader?
>
> Indeed.
>
> > It seems to me that only classes Element and
> > ElementAware are modified to handle continuation. While this looks
> > great for performance reasons it puzzles me a lot. What happens if
> > there're non-element classes on the stack? How can the continuation
> > captured correctly and restored later when these classes are not
> > "coorperating"? Or does the operation of rife somehow guarantees that
> > only Elements will be on the stack? (sorry I'm not very familiar with
>
> RIFE currently only supports continuations in the entrance methods of
> elements. We wrote experimental code to restore the method call
> stack, but that has been erased a while ago to first focus on making
> the current case work perfectly.
>
> RIFE will also only support byte-code instrumentation in elements.
> This makes sense as a web application framework since elements are
> the building blocks and will create the business logic of the entire
> application. RIFE also knows the singular entry point, which is very
> convenient to restore the call and variable stack. There is nothing
> that would prevent you from applying the same process to all your
> classes, but it will create a huge overhead.
>
> > the workings of rife)
> >
> > btw my name is "Liu" not "Lui" :P
>
> Actually, I meant to write Liu, but Lui came out ... sorry about that.
>

Right. I'm looking through the relevant code and it's becoming clearer. Thanks.

> > Thanks again Geert for the great work of Rife :)
> >
> > Liu Chang
> >
> >> --
> >> Geert Bevin                       Uwyn bvba
> >> "Use what you need"               Avenue de Scailmont 34
> >> http://www.uwyn.com               7170 Manage, Belgium
> >> gbevin[remove] at uwyn dot com    Tel [phone]
> >>
> >> PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
> >> Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net
> >>
> >>
> >> _______________________________________________
> >> Rife-devel mailing list
> >> Rife-devel@...
> >> http://lists.uwyn.com/mailman/listinfo/rife-devel
> >>
> > _______________________________________________
> > Rife-devel mailing list
> > Rife-devel@...
> > http://lists.uwyn.com/mailman/listinfo/rife-devel
> >
>
> --
> Geert Bevin                       Uwyn bvba
> "Use what you need"               Avenue de Scailmont 34
> http://www.uwyn.com               7170 Manage, Belgium
> gbevin[remove] at uwyn dot com    Tel [phone]
>
> PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
> Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net
>
>
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://lists.uwyn.com/mailman/listinfo/rife-devel
>