Spawn proposal strawman
brendan at mozilla.com
Thu May 21 16:44:36 PDT 2009
On May 21, 2009, at 4:15 PM, Kris Kowal wrote:
> Upon further reflection, I'm not sure that parse(program:String):AST
> would serve the purpose of fast sandboxing. The intent of splitting
> parse and execute is to reduce the cost of execution, so that modules
> can be reused in many small sandboxes.
Implementations can do ccache(1)-style compiled-results-caching.
> Having parse produce a
> (mutable) AST, and then leaving execute to translate the AST for the
> interpreter might constrain our options for producing the desired
> performance. It might be better to have a compile() routine that
> returns an opaque, engine-specific Program object that can in turn be
> executed multiple times.
SpiderMonkey used to have a Script object you could create via s = new
Script(source), or s = Script.compile(source) -- then you'd s.exec()
to run the script. It was eval split in two. That made it pure evil,
since the implementation couldn't analyze for it easily to deoptimize
the calling code so that its scope could be used. We had code to
deoptimize at runtime, but that was many years ago, when we didn't
I don't think we want any such primitives split from eval's guts,
although if we were to have these, the eval-as-container idea Mark
started and you ran with does have appeal, since eval is already a
quasi-keyword that implementations must recognize: eval.
Anyway, AST serialization is what I'm working on (back burner this
week). Beyond that is a cliff....
More information about the es-discuss