cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Jellinghaus <r...@unrealities.com>
Subject Re: Continuation-enabled Rhino status (was: Re: [vote] Starting 2.1-dev)
Date Wed, 10 Apr 2002 19:30:11 GMT
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


Mime
View raw message