MozillaWiki

JavaScript:ActionMonkey

Revision as of 21:32, 18 May 2008 by Deliriousgreen (talk | contribs) (→‎Building ActionMonkey: add extra /'s at end of links)

ActionMonkey is the code-name for the project to integrate Tamarin and 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.

Project summary

The goal of ActionMonkey is to merge SpiderMonkey and Tamarin. Particulars:

  • ActionMonkey will 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 should be able to install a new copy of the SpiderMonkey libraries, recompile their code, and run it without major changes.
  • ActionMonkey will have threading support. (See JS_THREADSAFE.)
  • We will use the tamarin-tracing interpreter and JIT, so ActionMonkey will run existing JavaScript code (without AS3-style type annotations) fast.
  • SpiderMonkey's thread safety and 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 MMgc, evolved as needed.
  • Information flow VM support for better security models.

A beta release is scheduled for the end of 2008.

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 file a bug using this link (you might need to log into Bugzilla first).

  • First, make sure you can 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 autoconf 2.13, and make sure the executable is named autoconf-2.13. (In older times, this was optional, but for building ActionMonkey from source, it's required: the source tree includes no pre-generated configure script.)
  • Install Python 2.4 or later.
  • Install Mercurial.
  • Install GNU make 3.81 or later.
  • hg clone http://hg.mozilla.org/actionmonkey
  • cd actionmonkey
  • python client.py checkout (The actionmonkey 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 [1].) (Hint: For a quick debug build of js, try cd js/src; make -f Makefile.ref.)

Note: If you plan on using Mercurial for active development, you should consider installing a 3-way merge program, as described here.

Common errors

  • Users/kaitlin/dev/actionmonkey/js/tamarin/manifest.mk:48: *** missing `endif'. Stop. - 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 PATH.
  • no module named subprocess - You're using an older version of Python to run client.py.

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 TempValueRooter 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 TempValueRooter 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:

  • bug 392882 - Fix ActionMonkey Firefox build - Done.
  • bug 397080 - Disable OJI (LiveConnect) in mozilla-central - Done.
  • bug 397041 - Remove unnecessary local root scopes - Done.
  • bug 392883 - Remove gcThingFlags
    • The type bits: use the C++ vtable, maybe. (Note: The cycle collector sneakily uses these, in nsXPConnect.cpp; it will be changed.)
    • The GCF_LOCK bit: already gone in actionmonkey branch, mainly replaced by allowing MMgc to scan rt->gcLocksHash.
    • The GCF_MUTABLE bit: move into JSString. Already done in CVS trunk.
    • The GCF_SYSTEM bit: To be determined. - Done.
  • bug 397239 - Remove "extra" parameter to JS_FN - Done.
  • bug 394297 - Make MMgc thread-safe (as a compile-time option)
  • bug 392602 - Implement a new heuristic for JS_MaybeGC - 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 js/src, 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. (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. —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 SpiderMonkey Internals: Thread Safety) into Tamarin.
  • Merge SpiderMonkey string optimizations into Tamarin.
  • Compare Tamarin and SpiderMonkey E4X behavior.
  • Determine which JSAPI JS_*Double* 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 Object features, particularly non-standard features like Object.watch.
  • Figure out what to do when an application calls JS_GetClass on a plain Object, Array, or Function.
  • Figure out how to support native getters, setters, and JSClass hooks. (Note in particular the stored value feature, which affects getters, setters, mdc:JSClass.getProperty et al, and JS_LookupProperty.)
  • Figure out how to support JSObjectOps callbacks. Or reimplement all Mozilla's JSObjectOps on Tamarin's object model. There are not many JSObjectOps 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 JSClass behavior (and JSObjectOps if necessary).
  • Implement support for using JSNative and JSFastNative 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 Array 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 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 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 tamarin-tracing 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. :)
  • 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.
  • tamarin-tracing doesn't have eval. (We'll supply the compiler, of course. But eval also needs: a way to load and run bytecode from memory without going to disk; and support for a dynamic global object.)
Retrieved from "https://wiki.allizom.org/index.php?title=JavaScript:ActionMonkey&oldid=93703"