JavaScript:ActionMonkey

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/actionmonkey 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.

Stage 0

Replace SpiderMonkey's GC with Tamarin's GC (MMgc).

Details:

• The plan is to hollow out jsgc.c and replace it with a new implementation based on MMgc. The API in jsgc.h will be preserved.
• We'll use MMgc in non-incremental mode to start with. (It's easier. Avoid premature optimization.)
• We'll use a C wrapper for MMgc instead of building SpiderMonkey as C++, for the moment. (Whether jsgc.c itself will be C or C++ isn't yet decided.)

Steps:

• Convince the SpiderMonkey and Tamarin build systems to cooperate.
• Change the few places where SpiderMonkey is directly using stdlib malloc() (malloc, free, realloc, calloc, strdup, etc.) to use a new internal API (lowercase js_malloc).
  • brendan: Hope these can all be macro-defined.
• Look into maybe tweaking some of the APIs in jsgc.h to be friendlier to MMgc. For example, I don't know that `js_GetGCThingFlags()` corresponds to anything in MMgc.
• Team hacking session to reimplement jsgc.c.

Notes on the jsgc.h API:

• Tracing API. (This is used by the cycle collector.)
• API for tracing private data. (DOM objects use this to participate in GC.)
• Rooting API. (No sweat - this can be implemented in terms of MMgc::GCRoot.)
• Object pinning API. (Same here.)
• JS_IsAboutToBeFinalized() needs to be implemented for MMgc.
• JS_AddExternalStringFinalizer() and friends. (We can probably implement these in terms of MMgc::GCFinalizedObject.)

Other notes:

• XPConnect garbage-collects XPCWrapNative objects and its own data structures. This needs some more research. (Brendan thinks this won't affect stage 0 work.)

We will, for the moment, lose one thing: the threading model where a single JSRuntime has multiple threads, each with its own JSContext.

During this stage, work will be done in the http://hg.mozilla.org/actionmonkey Mercurial repository. (This repo is 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)

Stage 1

More to come.