Re: Continuation-enabled Rhino status (was: Re: [vote] Starting 2.1-dev)

[Ovidiu Predescu <ov...@cup.hp.com>]

Sylvain,

On Wed, 10 Apr 2002 10:14:24 +0200, Sylvain Wallez <sy...@anyware-tech.com> wrote:

> Ovidiu Predescu wrote:
> 
> <snip/>
> 
> >Please do a cvs update and check out the calculator sample again. I've
> >reverted back to using callCC in JavaScript instead of a new API, a
> >Continuation object, provided by Christopher Oliver in his modified
> >Rhino engine. I need to test the later a bit more before using it.
> >
> 
> Ovidiu, can you tell us the status of the work of Christopher Oliver, as 
> the continutation-enabled Rhino becomes a critical part of the flow engine :
> - are sources available ?
> - under which licence (same MPL as Rhino)
> - is it/will it be integrated into the main Rhino code base ?

Christopher's work is available in source form from:

ftp://ftp.primaryinterface.com/pub/rhino/rhino1_5R4pre-callCC.zip

The package also contains a pre-built, ready to use, jar file. The
license is still MPL, and I don't think is possible to change it.

At this point, the primary maintainers of Rhino seem to be concerned
with two things:

- the performance implications of the continuations code has on the
interpreted engine.

- the fact that continuations are available in interpreted mode
only.

Rhino has two ways of running JavaScript scripts. The first one is
translating the script in a structure of internal objects, which are
then "executed". The second approach, a lot faster that the first one,
translates the JavaScript scripts in internal Java classes, which are
compiled to bytecodes on-the-fly and executed as normal Java code.

Adding support for continuations in the compiler mode is not possible,
due to the impossibility to manipulate the Java stack frame.

I believe at this point, Norris Boyd and other Rhino maintainers are
waiting for the continuations code to stabilize, and have all the bugs
removed. In the past month Christopher came up with new versions every
other day almost ;-). Some of them had major bugs, and unless somebody
like us tests the code extensively it may be difficult to remove them.

One of the implications for us is that once Schecoon is merged onto
the main trunk, we'll have to use this engine instead of the 1.5R3
version we currently use.

I certainly hope Christopher's work will get into the main trunk, so
that we're not stuck with an unsupported version.

Another alternative, which I still need to explore, is to continue the
development on the language I proposed a while ago. This will give us
much more control over what features we need, and we can possibly have
more optimizations implemented. Rhino is much slower when it comes to
continuations than SISC, the Scheme interpreter I was initially used
in Schecoon.

And there are certain optimizations which can be done to minimize the
size of the captured continuations, which are simply not possible in
Rhino without major changes. Controlling what gets captured in a
continuation at the language level would also help developers a
lot. For example it would be nice to have language constructs that
tell that a variable's value should not be captured in a continuation,
and how its value could be restored after the continuation is
resurrected. At this point this is just some food for thought, I need
to look more closely into these issues.

Greetings,
-- 
Ovidiu Predescu <ov...@cup.hp.com>
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Continuation-enabled Rhino status (was: Re: [vote] Starting 2.1-dev)

[Sylvain Wallez <sy...@anyware-tech.com>]

Ovidiu Predescu wrote:

>Sylvain,
>
>On Wed, 10 Apr 2002 10:14:24 +0200, Sylvain Wallez <sy...@anyware-tech.com> wrote:
>
>>Ovidiu Predescu wrote:
>>
>><snip/>
>>
>>>Please do a cvs update and check out the calculator sample again. I've
>>>reverted back to using callCC in JavaScript instead of a new API, a
>>>Continuation object, provided by Christopher Oliver in his modified
>>>Rhino engine. I need to test the later a bit more before using it.
>>>
>>Ovidiu, can you tell us the status of the work of Christopher Oliver, as 
>>the continutation-enabled Rhino becomes a critical part of the flow engine :
>>- are sources available ?
>>- under which licence (same MPL as Rhino)
>>- is it/will it be integrated into the main Rhino code base ?
>>
>
>Christopher's work is available in source form from:
>
>ftp://ftp.primaryinterface.com/pub/rhino/rhino1_5R4pre-callCC.zip
>

Cool.

>The package also contains a pre-built, ready to use, jar file. The
>license is still MPL, and I don't think is possible to change it.
>

MPL is good. I was wondering if it was something else.

>At this point, the primary maintainers of Rhino seem to be concerned
>with two things:
>
>- the performance implications of the continuations code has on the
>interpreted engine.
>
>- the fact that continuations are available in interpreted mode
>only.
>
>Rhino has two ways of running JavaScript scripts. The first one is
>translating the script in a structure of internal objects, which are
>then "executed". The second approach, a lot faster that the first one,
>translates the JavaScript scripts in internal Java classes, which are
>compiled to bytecodes on-the-fly and executed as normal Java code.
>
>Adding support for continuations in the compiler mode is not possible,
>due to the impossibility to manipulate the Java stack frame.
>
>I believe at this point, Norris Boyd and other Rhino maintainers are
>waiting for the continuations code to stabilize, and have all the bugs
>removed. In the past month Christopher came up with new versions every
>other day almost ;-). Some of them had major bugs, and unless somebody
>like us tests the code extensively it may be difficult to remove them.
>

Classical chicken-and-egg problem : people don't want to use something 
that's not stable, and that thing needs users to stabilize. Let's 
stabilize it with Cocoon !

>One of the implications for us is that once Schecoon is merged onto
>the main trunk, we'll have to use this engine instead of the 1.5R3
>version we currently use.
>

If the compiled engine is still available in the patched version, then 
this should be no problem : use interpreted mode for the flow, and 
compiled mode everywhere else.

>I certainly hope Christopher's work will get into the main trunk, so
>that we're not stuck with an unsupported version.
>
>Another alternative, which I still need to explore, is to continue the
>development on the language I proposed a while ago. This will give us
>much more control over what features we need, and we can possibly have
>more optimizations implemented. Rhino is much slower when it comes to
>continuations than SISC, the Scheme interpreter I was initially used
>in Schecoon.
>
>And there are certain optimizations which can be done to minimize the
>size of the captured continuations, which are simply not possible in
>Rhino without major changes. Controlling what gets captured in a
>continuation at the language level would also help developers a
>lot. For example it would be nice to have language constructs that
>tell that a variable's value should not be captured in a continuation,
>and how its value could be restored after the continuation is
>resurrected. At this point this is just some food for thought, I need
>to look more closely into these issues.
>

That would be an equivalent of the "transient" keyword for local variables.

Sylvain

-- 
Sylvain Wallez
  Anyware Technologies                  Apache Cocoon
  http://www.anyware-tech.com           mailto:sylvain@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Continuation-enabled Rhino status (was: Re: [vote] Starting 2.1-dev)

[Rob Jellinghaus <ro...@unrealities.com>]

At 11:30 AM 4/10/2002 -0800, Rob Jellinghaus wrote:
>At 10:29 AM 4/10/2002 -0700, Ovidiu Predescu wrote:
>>Adding support for continuations in the compiler mode is not possible,
>>due to the impossibility to manipulate the Java stack frame.
>
>This places a lower bound on the speed of any continuation-based Cocoon 
>web application.

Oops, I meant "upper bound" :-)

Cheers!
Rob



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Continuation-enabled Rhino status (was: Re: [vote] Starting 2.1-dev)

[Jason Foster <ja...@uwaterloo.ca>]

> For example it would be nice to have language constructs that
> tell that a variable's value should not be captured in a continuation,
> and how its value could be restored after the continuation is
> resurrected.

A portion of this can be handled by the "volatile" and "transient" reserved 
words, that currently do not have any particular semantics.

The ECMAScript 4 proposal also includes support for "getters" and "setters"
  that could possibly be hooked into the continuation system to deal with 
the "restoring after resurrection" problem, much like Java2 reference 
objects.

OK, I'm a little fixated on JavaScript :)  That's because I understand 
immediately how to solve a problem in that style of language.  I've stared 
at a few books describing Scheme and the like, and so far I'm (sort of) 
comfortable writing the Towers of Hanoi but the thought of doing "real" 
coding fills me with dread.

Jason Foster


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Continuation-enabled Rhino status (was: Re: [vote] Starting 2.1-dev)

[Rob Jellinghaus <ro...@unrealities.com>]

At 02:01 PM 4/10/2002 -0700, Ovidiu Predescu wrote:
>Perl, Python, PHP and lots of other interpreted languages out there
>are successfully used to drive very large Web sites. None of them
>compiles anything to C, they all interpret the scripts that describe
>the Web application.
>
>Some of these Web applications have tens of thousands of lines of
>code, all interpreted. I haven't noticed any problem accessing sites
>like Slashdot (Perl), Yahoo Maps! (Python), Yahoo Store! (Common
>Lisp), and many others.

All good points, and well made :-)

Cheers,
Rob



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Continuation-enabled Rhino status (was: Re: [vote] Starting 2.1-dev)

[Rob Jellinghaus <ro...@unrealities.com>]

At 10:29 AM 4/10/2002 -0700, Ovidiu Predescu wrote:
>Rhino has two ways of running JavaScript scripts. The first one is
>translating the script in a structure of internal objects, which are
>then "executed". The second approach, a lot faster that the first one,
>translates the JavaScript scripts in internal Java classes, which are
>compiled to bytecodes on-the-fly and executed as normal Java code.
>
>Adding support for continuations in the compiler mode is not possible,
>due to the impossibility to manipulate the Java stack frame.

This places a lower bound on the speed of any continuation-based Cocoon web 
application.

I would steer clear of using a non-compilable technology in any 
sufficiently large-scale web site.  Hence, this ower bound on the flow 
engine's speed may imply an upper bound on the scale of Cocoon deployments 
using the continuation-based flow engine.

It is also curious how this performance constraint is so at odds with 
Cocoon's general predilection to compile everything whenever possible, for 
maximum throughput.

It pains me to say all this, as I think continuations are elegant as hell 
and Ovidiu's work seems quite impressive, but I do not believe that 
continuations will become efficiently implementable in the JVM (or in 
JVM-based languages) anytime in the next few years.  Hence, I do not think 
that continuations should become the main focus of Cocoon's flow support, 
if Cocoon has scalability as a primary design goal.

Cheers,
Rob



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org