cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@cup.hp.com>
Subject Re: Continuation-enabled Rhino status (was: Re: [vote] Starting 2.1-dev)
Date Wed, 10 Apr 2002 17:29:20 GMT
Sylvain,

On Wed, 10 Apr 2002 10:14:24 +0200, Sylvain Wallez <sylvain.wallez@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 <ovidiu@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


Mime
View raw message