JavaScript:ActionMonkey: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
mNo edit summary
(Mark as Outdated)
 
(38 intermediate revisions by 8 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 speedTamarin-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 ===
 
Things work slightly differently in Mercurial-land.  The following might make more sense if you're already familiar with building Mozilla in the old-school CVS world.  But even if you're not, you can give it a try:
 
==== Mac ====
 
* Install Python 2.4 or later.  (<tt>sudo port install python24</tt>)
* Install Mercurial perquisites (ASCIIDOC and a three way merge program) http://www.selenic.com/mercurial/
* Install Mercurial.  (On Mac with MacPorts, <tt>sudo port install mercurial</tt>)
* Install GNU make 3.81 or later.  (<tt>sudo port install gmake</tt>, but watch out: an older version is probably still in your <tt>PATH</tt>.)
* <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.  (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>.)
 
==== Windows ====
 
* Install MozillaBuild, from the [http://developer.mozilla.org/en/docs/Build_Documentation Mozilla build instructions]
* Use xemacs to add the contents of the script at [http://www.selenic.com/mercurial/wiki/index.cgi/MergingManuallyInEditor] to ~/.hgmerge using the command <code>xemacs ~/.hgmerge</code>.
* Run the following command in MozillaBuild to hook up merge functionality:
 
echo -e '[ui]\nmerge = ~/.hgmerge' > ~/.hgrc
chmod +x ~/.hgmerge
 
* Install Mercurial from http://www.selenic.com/mercurial/wiki/index.cgi/BinaryPackages (use the first Windows site), and make sure the "change environment" checkbox in the installer's final page is checked.
<!--* Install GNU make 3.81 or later(<tt>sudo port install gmake</tt>, but watch out: an older version is probably still in your <tt>PATH</tt>.)-->
* Log out of and back into Windows to pick up Mercurial's environment changes.
* <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.  (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>.)
 
==== Linux ====
 
* Make sure you have Python 2.4, Mercurial, and GNU make installed, via whatever system your distribution uses (as well as gcc and g++).
* Use xemacs to add the contents of the script at [http://www.selenic.com/mercurial/wiki/index.cgi/MergingManuallyInEditor] to ~/.hgmerge using the command <code>xemacs ~/.hgmerge</code>.
* Run the following command in MozillaBuild to hook up merge functionality:
 
echo -e '[ui]\nmerge = ~/.hgmerge' > ~/.hgrc
chmod +x ~/.hgmerge
 
* <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.  (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>.)
 
You should be able to build a working JS shell, Firefox, or other app this way.  If it doesn't work for you, please file a bug with "ActionMonkey" in the summary and assign it to <tt>jorendorff</tt>.
 
=== 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).  See [[JavaScript:ActionMonkey:Stage 0 Whiteboard]].
 
 
== Stage 1 ==
 
Integrate SpiderMonkey more closely with MMgc.
 
* Make <code>MMgc::Mark()</code> call SpiderMonkey <code>trace()</code> methods.  The plan is to add a '''per-page type tag''' to MMgc; this takes over the job of the type bits in SpiderMonkey's <code>GCThingFlags</code>.
 
* Get rid of js_GetGCThingFlags. 
** The type bits: move to an MMgc page-level type tag.  (Note:  The cycle collector sneakily uses these, in <tt>nsXPConnect.cpp</tt>; it will be changed.)
** The <code>GCF_LOCK</code> bit: mainly replaced by allowing MMgc to scan <code>rt-&gt;gcLocksHash</code>.  There is also a string optimization that uses this bit.  It's yet to be determined what to do about that.
** The <code>GCF_MUTABLE</code> bit:  move into <code>JSString</code>.
** The <code>GCF_SYSTEM</code> bit:  To be determined.


* Drop weak roots, newborns, and local root scopes (if they're not already gone in stage 0).  These will be replaced by MMgc's conservative stack scanning.
* 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)

Latest revision as of 21:22, 27 April 2021

Ambox outdated.png 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)