|
|
| Line 1: |
Line 1: |
| '''ActionMonkey''' is the code-name for the project to integrate [[Tamarin]] and [[JavaScript:SpiderMonkey|SpiderMonkey]] as part of [[Mozilla 2]]. | | '''ActionMonkey''' was the code-name for a project to integrate [[Tamarin]] and [[JavaScript:SpiderMonkey|SpiderMonkey]] as part of [[Mozilla 2]]. |
|
| |
|
| Want to help? Write to jason dot orendorff at gmail dot com. Or visit irc://irc.mozilla.org/jslang and say hi.
| | 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: |
|
| |
|
| == Project summary ==
| | * 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].) |
| The goal of ActionMonkey is to merge SpiderMonkey and Tamarin. Particulars:
| | * 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] were to be integrated/reimplemented in Tamarin. |
| * ActionMonkey will 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 should be able to install a new copy of the SpiderMonkey libraries, recompile their code, and run it without major changes. | | * 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.) |
| * ActionMonkey will have threading support. (See [http://developer.mozilla.org/en/docs/JS_THREADSAFE JS_THREADSAFE].) | | * SpiderMonkey's GC was to be replaced by Tamarin's [http://developer.mozilla.org/en/docs/MMgc MMgc], evolved as needed. |
| * We will use the [[Tamarin:Tracing|tamarin-tracing]] interpreter and JIT, so ActionMonkey will 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] will be integrated/reimplemented in Tamarin. | |
| * ActionMonkey will 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 will be replaced by Tamarin's [http://developer.mozilla.org/en/docs/MMgc MMgc], evolved as needed. | |
| * [http://www.cs.cornell.edu/Info/People/jgm/lang-based-security/ Information flow] VM support for better security models. | | * [http://www.cs.cornell.edu/Info/People/jgm/lang-based-security/ Information flow] VM support for better security models. |
|
| |
|
| A beta release is scheduled for the end of 2008.
| | 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: |
| | |
| == Building ActionMonkey ==
| |
| | |
| All ActionMonkey work is happening in the http://hg.mozilla.org/actionmonkey/ and http://hg.mozilla.org/actionmonkey-tamarin/ [[Mercurial]] repositories.
| |
| | |
| (These repositories are 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)
| |
| | |
| === How to build ===
| |
| | |
| You should be able to build a working JS shell or Firefox using these steps. If it doesn't work for you, please [https://bugzilla.mozilla.org/enter_bug.cgi?assigned_to=jorendorff%40mozilla.com&bug_severity=normal&bug_status=NEW&component=Build%20Config&form_name=enter_bug&product=Core&short_desc=ActionMonkey%3A%20build%20is%20broken&version=Other%20Branch file a bug using this link] (you might need to log into Bugzilla first).
| |
| | |
| * First, make sure you can [http://developer.mozilla.org/en/docs/SpiderMonkey_Build_Documentation build SpiderMonkey] on the machine you're going to use. If you can't build SpiderMonkey, you won't be able to build ActionMonkey.
| |
| * Install [http://www.gnu.org/software/autoconf/ autoconf 2.13], and make sure the executable is named <tt>autoconf-2.13</tt>. (In older times, this was optional, but for building ActionMonkey from source, it's required: the source tree includes no pre-generated <tt>configure</tt> script.)
| |
| * Install Python 2.4 or later.
| |
| * Install [http://www.selenic.com/mercurial/wiki/index.cgi/BinaryPackages Mercurial].
| |
| * Install GNU make 3.81 or later.
| |
| * <tt>hg clone http://hg.mozilla.org/actionmonkey</tt>
| |
| * <tt>cd actionmonkey</tt>
| |
| * <tt>python client.py checkout</tt> ''(The <tt>actionmonkey</tt> repository doesn't contain all the source files you need. This Python script grabs all the other source files (from other repositories, both CVS and hg) and puts them into your tree in the right places.)''
| |
| * Then build as you normally would. Note: you '''must''' build with an objdir. (See [http://developer.mozilla.org/en/docs/Configuring_Build_Options#Building_with_an_Objdir].) (Hint: For a quick debug build of <tt>[http://developer.mozilla.org/en/docs/Introduction_to_the_JavaScript_shell js]</tt>, try <tt>cd js/src; make -f Makefile.ref</tt>.)
| |
| | |
| ''Note: If you plan on using Mercurial for active development, you should consider installing a 3-way merge program, as described [http://www.selenic.com/mercurial/wiki/index.cgi/MergeProgram here].''
| |
| | |
| === Common errors ===
| |
| | |
| * <tt>Users/kaitlin/dev/actionmonkey/js/tamarin/manifest.mk:48: *** missing `endif'. Stop.</tt> - You're using an older version of GNU make. Install GNU make 3.81 or later, and make sure you don't still have an old version in your <tt>PATH</tt>.
| |
| | |
| * <tt>no module named subprocess</tt> - You're using an older version of Python to run <tt>client.py</tt>.
| |
| | |
| == Stage 0 ==
| |
| | |
| Replace SpiderMonkey's GC with Tamarin's GC (MMgc). This part is done at last! See the ActionMonkey Stage 0 tracking bug, {{bug|387012}}.
| |
| | |
| With MMgc's conservative stack scanning, several of SpiderMonkey's weirder features have become unnecessary. Weak roots and newborn roots ({{bug|388622}}), local root scopes ({{bug|397041}}), and "extra" args ({{bug|391676}}; see also {{bug|397239}}) are no longer used in SpiderMonkey. Most uses of <code>TempValueRooter</code> have also been deleted ({{bug|391676}}). Some of these features will stick around, because they are public via the JSAPI, and legacy code is using them. Others, like newborn roots, weak roots, and certain <code>TempValueRooter</code> features, are completely gone.
| |
| | |
| == Stage 1 ==
| |
| | |
| Integrate SpiderMonkey more closely with MMgc, and get MMgc ready for XPCOM work. See the ActionMonkey Stage 1 tracking bug, {{bug|393023}}. (Under "Depends on", you can see a list of bugs slated for stage 1.)
| |
| | |
| Stage 1 work includes:
| |
| | |
| * <s>{{bug|392882}} - Fix ActionMonkey Firefox build</s> - ''Done.''
| |
| * <s>{{bug|397080}} - Disable OJI (LiveConnect) in mozilla-central</s> - ''Done.''
| |
| * <s>{{bug|397041}} - Remove unnecessary local root scopes</s> - ''Done.''
| |
| * <s>{{bug|392883}} - Remove gcThingFlags
| |
| ** The type bits: use the C++ vtable, maybe. (Note: The cycle collector sneakily uses these, in <tt>nsXPConnect.cpp</tt>; it will be changed.)
| |
| ** The <code>GCF_LOCK</code> bit: already gone in actionmonkey branch, mainly replaced by allowing MMgc to scan <code>rt->gcLocksHash</code>.
| |
| ** The <code>GCF_MUTABLE</code> bit: move into <code>JSString</code>. Already done in CVS trunk.
| |
| ** The <code>GCF_SYSTEM</code> bit: To be determined.</s> - ''Done.''
| |
| * <s>{{bug|397239}} - Remove "extra" parameter to JS_FN</s> - ''Done.''
| |
| * {{bug|394297}} - Make MMgc thread-safe (as a compile-time option)
| |
| * <s>{{bug|392602}} - Implement a new heuristic for JS_MaybeGC</s> - ''Done.''
| |
| | |
| == Stage 2 ==
| |
| | |
| Incremental GC for Mozilla. See the ActionMonkey Stage 2 tracking bug, {{bug|411563}}.
| |
| | |
| * Make MMgc thread-safe when incremental GC is enabled.
| |
| * Enable incremental GC in Mozilla. This implies adding write barriers to the appropriate places in <tt>js/src</tt>, to make it work with incremental GC.
| |
| | |
| At the end of stage 2, ActionMonkey <s>will merge to mozilla-central. It</s> should have no performance or functionality regressions compared with mozilla-central. ''(We have decided not to merge, as the Mozilla 2 infrastructure isn't ready to handle big check-ins, and it won't be much harder to land all this stuff later. —[[User:Jorend|jorendorff]] 15:31, 31 March 2008 (PDT))''
| |
| | |
| == Stage 3 ==
| |
| | |
| Land XPCOMGC in actionmonkey branch. This is going to be ''interesting'', given the nature of the XPCOMGC patch stack. We need to figure out what this actually means.
| |
| | |
| Then,
| |
| | |
| * Debug.
| |
| * Tune the resulting platform, producing meaningful performance numbers.
| |
| | |
| == Stage 4 ==
| |
| | |
| Merge SpiderMonkey and Tamarin object models. The result will be an ActionMonkey that uses the SpiderMonkey compiler and interpreter, and Tamarin objects and memory management.
| |
| | |
| This will include tasks like:
| |
| | |
| * Build system: link Tamarin (as a static or dynamic library) into ActionMonkey (and the browser).
| |
| * Merge SpiderMonkey's property tree optimization into Tamarin.
| |
| * Merge SpiderMonkey's JS_THREADSAFE handling of property accesses (see [http://developer.mozilla.org/en/docs/SpiderMonkey_Internals:_Thread_Safety SpiderMonkey Internals: Thread Safety]) into Tamarin.
| |
| * Merge SpiderMonkey string optimizations into Tamarin.
| |
| * Compare Tamarin and SpiderMonkey E4X behavior.
| |
| * Determine which JSAPI <code>JS_*Double*</code> functions can be preserved and which must be removed. Patch the entire Mozilla codebase as needed.
| |
| * Change the interpreter to use Tamarin strings.
| |
| * Change the interpreter to use Tamarin-like 64-bit jsvals.
| |
| * Compare Tamarin and SpiderMonkey [[mdc:Core JavaScript 1.5 Reference:Global Objects:Object|<code>Object</code> features]], particularly non-standard features like <code>[[mdc:Core JavaScript 1.5 Reference:Global Objects:Object:watch|Object.watch]]</code>.
| |
| * Figure out what to do when an application calls <code>[[mdc:JS_GetClass|JS_GetClass]]</code> on a plain <code>Object</code>, <code>Array</code>, or <code>Function</code>.
| |
| * Figure out how to support native getters, setters, and <code>[[mdc:JSClass|JSClass]]</code> hooks. (Note in particular the [[mdc:JSAPI:Stored value|stored value]] feature, which affects getters, setters, <code>[[mdc:JSClass.getProperty]]</code> et al, and <code>[[mdc:JS_LookupProperty|JS_LookupProperty]]</code>.)
| |
| * Figure out how to support <code>[[mdc:JSObjectOps|JSObjectOps]]</code> callbacks. ''Or'' reimplement all Mozilla's <code>JSObjectOps</code> on Tamarin's object model. There are not many <code>JSObjectOps</code> implementations in Mozilla:
| |
| | |
| ::Inside SpiderMonkey:
| |
| ::*js_ObjectOps
| |
| ::*js_WithObjectOps
| |
| ::*js_ArrayObjectOps - coming in {{bug|322899}}
| |
| ::*js_SlowArrayObjectOps - same
| |
| ::In xpconnect:
| |
| ::*XPC_WN_WithCall_JSOps
| |
| ::*XPC_WN_NoCall_JSOps
| |
| ::In liveconnect, which is not even built in Mozilla 2:
| |
| ::*JavaArray_ops
| |
| ::*JavaObject_ops
| |
| ::*JavaClass_ops
| |
| | |
| * Implement an adapter class to support Tamarin objects that preserve the <code>JSClass</code> behavior (and <code>JSObjectOps</code> if necessary).
| |
| * Implement support for using <code>[[mdc:JSNative|JSNative]]</code> and <code>[[mdc:JSFastNative|JSFastNative]]</code> native functions in the Tamarin object model.
| |
| * Implement support for SpiderMonkey bytecode functions in the Tamarin object model.
| |
| * Change the interpreter to use Tamarin objects.
| |
| * Make sure jsxdrapi.h works with the new object model.
| |
| * Make sure E4X works with the new object model.
| |
| * Make sure the debugger still works with the new object model.
| |
| * Make sure XPConnect works.
| |
| * Make sure security works.
| |
| * Merge the SpiderMonkey and Tamarin <code>Array</code> implementations.
| |
| * Figure out how to do all the above and still support platforms that tamarin-tracing doesn't support:
| |
| :* Currently TT only supports Intel x86-32 and ARM, which covers the [[mdc:Mozilla Build FAQ|Tier 1 platforms]] except for Mac OS X on PowerPC. But I don't want to slaughter all the tier-2 and tier-3 platforms just because it's convenient. The easiest thing would be to ensure that you can build just the interpreter, with no JIT, on any plain vanilla platform with a decent C++ compiler. People on those platforms can invest in making the vanilla C++ interpreter fast.
| |
| :* 64-bit support is a special problem. As of 3 February 2008, nobody is [[Tamarin:Plans|planning]] to work on that during 2008.
| |
| | |
| It's undecided how all this might land in mozilla-central. I don't think performance regressions can be avoided given the nature of what we're doing here. It seems more sensible to move ahead to Stage 5, in a branch if necessary, than to do ''that much'' tuning of this Frankenstein's monster.
| |
| | |
| == Stage 5 ==
| |
| | |
| (speculative)
| |
| | |
| Merge the <code>tamarin-tracing</code> interpreter and JIT into ActionMonkey. The result will be an ActionMonkey that uses the SpiderMonkey compiler to generate Tamarin bytecode, and uses Tamarin to execute it.
| |
| | |
| One interesting task:
| |
| | |
| * Make JS2 generators work in tamarin-tracing. This may mean desugaring them in the compiler. The alternative is to make the TT VM and JIT support them.
| |
| | |
| Known risks:
| |
|
| |
|
| * We'll likely be the first to use tamarin-tracing in a product. :) | | * Support for a dynamic global object. |
| * tamarin-tracing is not reentrant. The official plan is to "come up with some disgusting hack". We won't know how the performance is until we try it. | | * Support for generators. |
| * tamarin-tracing doesn't have <code>eval</code>. (We'll supply the compiler, of course. But <code>eval</code> also needs: a way to load and run bytecode from memory without going to disk; and support for a dynamic global object.) | | * 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) |