JavaScript:ActionMonkey: Difference between revisions

Latest revision as of 21:22, 27 April 2021

	THIS PAGE IS OBSOLETE
	This article is in parts, or in its entirety, outdated. Hence, the information presented on this page may be incorrect, and should be treated with due caution. Visit SpiderMonkey.dev for more up to date information.

ActionMonkey was the code-name for a project to integrate Tamarin and SpiderMonkey as part of Mozilla 2.

The goal was to merge SpiderMonkey and Tamarin into a single VM that would implement the ECMAScript Edition 4 standard and could be used by both Adobe and Mozilla. Particulars:

ActionMonkey would continue to support the JSAPI, SpiderMonkey's existing C API, with necessary additions and as few deletions as possible. People currently using SpiderMonkey as a library would be able to install a new copy of the SpiderMonkey libraries, recompile their code, and run it without major changes.
ActionMonkey would have threading support. (See JS_THREADSAFE.)
ActionMonkey would use the tamarin-tracing interpreter and JIT, to run existing JavaScript code (without AS3-style type annotations) fast.
SpiderMonkey's thread safety and property tree were to be integrated/reimplemented in Tamarin.
ActionMonkey was intended to use SpiderMonkey's existing compiler to generate Tamarin bytecode (ABC) for the Tamarin VM to execute. (SpiderMonkey's compiler is faster and contains some Web compatibility quirks that might be tedious to reimplement in a new compiler.)
SpiderMonkey's GC was to be replaced by Tamarin's MMgc, evolved as needed.
Information flow VM support for better security models.

The project was canceled mainly because tamarin-tracing never caught up to SpiderMonkey's speed. Tamarin-tracing also would have needed a lot of other features to be useful on the web:

Support for a dynamic global object.
Support for generators.
Support for other arcane JSAPI features (like split objects) and JS language features
Good support for reentrancy (calling from JS to C++ to JS)
A way to load and run bytecode from memory without going to disk (to implement eval)

@@ Line 1: / Line 1: @@
-'''ActionMonkey''' is the code-name for the project to integrate [[Tamarin]] and [[JavaScript:SpiderMonkey|SpiderMonkey]] as part of [[Mozilla 2]].
+{{OutdatedSpiderMonkey}}
-Want to help?  Write to jason dot orendorff at gmail dot com.  Or visit irc://irc.mozilla.org/jslang and say hi.
+'''ActionMonkey''' was the code-name for a project to integrate [[Tamarin]] and [[JavaScript:SpiderMonkey|SpiderMonkey]] as part of [[Mozilla 2]].
-== Goals ==
+The goal was to merge SpiderMonkey and Tamarin into a single VM that would implement the ECMAScript Edition 4 standard and could be used by both Adobe and Mozilla.  Particulars:
-The goals are:
+* ActionMonkey would continue to support the [http://developer.mozilla.org/en/docs/JSAPI_Reference JSAPI], SpiderMonkey's existing C API, with necessary additions and as few deletions as possible.  People currently using SpiderMonkey as a library would be able to install a new copy of the SpiderMonkey libraries, recompile their code, and run it without major changes.
+* ActionMonkey would have threading support.  (See [http://developer.mozilla.org/en/docs/JS_THREADSAFE JS_THREADSAFE].)
-* Preservation (with necessary additions and as few deletions as possible) of [http://lxr.mozilla.org/mozilla/source/js/src/jsapi.h jsapi.h].
+* ActionMonkey would use the [[Tamarin:Tracing|tamarin-tracing]] interpreter and JIT, to run existing JavaScript code (without AS3-style type annotations) fast.
-* SpiderMonkey's [http://lxr.mozilla.org/mozilla/source/js/src/jslock.h thread safety] and [http://lxr.mozilla.org/mozilla/source/js/src/jsscope.h property tree] integrated/reimplemented in Tamarin.
+* SpiderMonkey's [http://lxr.mozilla.org/mozilla/source/js/src/jslock.h thread safety] and [http://lxr.mozilla.org/mozilla/source/js/src/jsscope.h property tree] were to be integrated/reimplemented in Tamarin.
-* Replacement of SpiderMonkey's decompiler with a better decompiler that can work with [http://hg.mozilla.org/tamarin-central/?file/ef6478309778/core/opcodes.tbl ABC].
+* ActionMonkey was intended to use SpiderMonkey's existing compiler to generate Tamarin bytecode (ABC) for the Tamarin VM to execute.  (SpiderMonkey's compiler is faster and contains some Web compatibility quirks that might be tedious to reimplement in a new compiler.)
-* Replacement of SpiderMonkey's GC with [[Tamarin:MMgc]], evolved as needed.
+* SpiderMonkey's GC was to be replaced by Tamarin's [http://developer.mozilla.org/en/docs/MMgc MMgc], evolved as needed.
-* Replacement of SpiderMonkey's interpreter by an evolved version of Tamarin's.
-* Advanced JIT optimization for hot paths and untyped code, inspired by [http://www.ics.uci.edu/~franz/Site/pubs-pdf/ICS-TR-06-16.pdf Trace Trees].
 * [http://www.cs.cornell.edu/Info/People/jgm/lang-based-security/ Information flow] VM support for better security models.
-== Stage 0 ==
+The project was canceled mainly because tamarin-tracing never caught up to SpiderMonkey's speed.  Tamarin-tracing also would have needed a lot of other features to be useful on the web:
-Replace SpiderMonkey's GC with Tamarin's GC (MMgc).
-* Use MMgc in non-incremental mode to start with.  (It's easier.  Avoid premature optimization.)
-* Use a C wrapper for MMgc instead of building SpiderMonkey as C++, for the moment.
-* Convince the SpiderMonkey and Tamarin build systems to cooperate.
-* Change the few places where SpiderMonkey is directly using malloc() and free() to use a new internal API (lowercase <code>js_malloc</code>).
-** Don't forget realloc/calloc.
-** Hope these can all be macro-defined.
-Retain as many JSAPI functions as possible:
-* Tracing API.  This is used by the cycle collector.
-* API for tracing private data.  DOM objects use this to participate in GC.
-* Rooting API.  This can be implemented in terms of <code>MMgc::GCRoot</code>.
-* Object pinning API.  Same here.
-* XPConnect garbage-collects <code>XPCWrapNative</code> objects and its own data structures.  This needs some more research.
-* <code>JS_IsAboutToBeFinalized()</code> needs to be implemented for MMgc.
-* <code>JS_AddExternalStringFinalizer()</code> needs to be implemented, probably using <code>MMgc::GCFinalizedObject</code>.
-We will, for the moment, lose one thing: the threading model where a single <code>JSRuntime</code> has multiple threads, each with its own <code>JSContext</code>.
-Modify stuff that is not using the JSAPI but is cheating:
-* Change the XPCOM cycle collector (crash of thunder) to use a separate trace phase instead of depending on the SpiderMonkey GC mark phase to generate certain information it needs for cycle detection.
-During this stage, work will be done in the http://hg.mozilla.org/actionmonkey [[Mercurial]] repository.  (This repo is a hard hat area, one step removed from the primary mozilla-central repository.  This is because we expect things will break intermittently.  Also because some of the people working on this aren't CVS committers yet, myself included.  -jorendorff)
-== Stage 1 ==
-More to come.
+* Support for a dynamic global object.
+* Support for generators.
+* Support for other arcane JSAPI features (like split objects) and JS language features
+* Good support for reentrancy (calling from JS to C++ to JS)
+* A way to load and run bytecode from memory without going to disk (to implement eval)