JavaScript:ActionMonkey: Difference between revisions
(Stage 2 -- merge point) |
(added note about objdir) |
||
Line 31: | Line 31: | ||
* <tt>cd 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.)'' | * <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. | * 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>.) | ||
* To build on Windows, use [http://developer.mozilla.org/en/docs/Windows_Build_Prerequisites mozillabuild]. | * To build on Windows, use [http://developer.mozilla.org/en/docs/Windows_Build_Prerequisites mozillabuild]. |
Revision as of 21:10, 8 January 2008
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.
Goals
The goals are:
- Preservation (with necessary additions and as few deletions as possible) of jsapi.h.
- SpiderMonkey's thread safety and property tree integrated/reimplemented in Tamarin.
- Replacement of SpiderMonkey's decompiler with a better decompiler that can work with ABC.
- Replacement of SpiderMonkey's GC with Tamarin: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 Trace Trees.
- Information flow VM support for better security models.
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).
- 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.)
- To build on Windows, use mozillabuild.
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 scanrt->gcLocksHash
. - The
GCF_MUTABLE
bit: move intoJSString
. Already done in CVS trunk. - The
GCF_SYSTEM
bit: To be determined.
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
Stage 2
Incremental GC for Mozilla.
- 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.
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
(speculative)
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 would 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.
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.