|
|
| (17 intermediate revisions by 4 users not shown) |
| 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. | | * [http://www.cs.cornell.edu/Info/People/jgm/lang-based-security/ Information flow] VM support for better security models. |
|
| |
|
| == Building ActionMonkey ==
| | 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: |
| | |
| 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 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.''
| |
| * {{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>{{bug|397239}} - Remove "extra" parameter to JS_FN</s> - ''Done.''
| |
| * {{bug|394297}} - Make MMgc thread-safe (as a compile-time option)
| |
| * {{bug|392602}} - Implement a new heuristic for JS_MaybeGC
| |
| | |
| == 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 will merge to mozilla-central. It should have no performance or functionality regressions compared with mozilla-central.
| |
| | |
| == 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. (Note: We need 64-bit support in Tamarin at this point, unless we just want to regress those platforms. Nobody is [[Tamarin plans|planning]] to work on this during 2008, as of 3 February 2008.)
| |
| * 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 the "last-retrieved value" behavior of <code>[[mdc:JS_LookupProperty|JS_LookupProperty]]</code>.
| |
| * Figure out how to support native getters, setters, and <code>[[mdc:JSClass|JSClass]]</code> hooks.
| |
| * Figure out how to support <code>[[mdc:JSObjectOps|JSObjectOps]]</code> callbacks. ''Or'' find the people to reimplement all Mozilla's <code>JSObjectOps</code>-level magic on Tamarin's object model.
| |
| * 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.
| |
| * 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.
| |
| * Merge the SpiderMonkey and Tamarin <code>Array</code> implementations.
| |
| | |
| 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 Tamarin 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.
| | * 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) |
