JavaScript:ActionMonkey: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
mNo edit summary
(→‎Stage 0: update)
Line 19: Line 19:
Replace SpiderMonkey's GC with Tamarin's GC (MMgc).
Replace SpiderMonkey's GC with Tamarin's GC (MMgc).


* Use MMgc in non-incremental mode to start with.  (It's easier.  Avoid premature optimization.)
Details:
* Use a C wrapper for MMgc instead of building SpiderMonkey as C++, for the moment.
* 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.
* Convince the SpiderMonkey and Tamarin build systems to cooperate.
* Change the few places where SpiderMonkey is directly using malloc() and free() to use a new internal API (lowercase <code>js_malloc</code>).
* Change the few places where SpiderMonkey is directly using stdlib malloc() (malloc, free, realloc, calloc, strdup, etc.) to use a new internal API (lowercase <code>js_malloc</code>).
** Don't forget realloc/calloc.
** brendan: Hope these can all be macro-defined.
** 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.


Retain as many JSAPI functions as possible:
Notes on the jsgc.h API:
* Tracing API.  This is used by the cycle collector.
* Tracing API.  (This is used by the cycle collector.)
* API for tracing private data.  DOM objects use this to participate in GC.
* API for tracing private data.  (DOM objects use this to participate in GC.)
* Rooting API.  This can be implemented in terms of <code>MMgc::GCRoot</code>.
* Rooting API.  (No sweat - this can be implemented in terms of <code>MMgc::GCRoot</code>.)
* Object pinning API.  Same here.
* Object pinning API.  (Same here.)
* XPConnect garbage-collects <code>XPCWrapNative</code> objects and its own data structures.  This needs some more research.
* <code>JS_IsAboutToBeFinalized()</code> needs to be implemented for MMgc.
* <code>JS_IsAboutToBeFinalized()</code> needs to be implemented for MMgc.
* <code>JS_AddExternalStringFinalizer()</code> needs to be implemented, probably using <code>MMgc::GCFinalizedObject</code>.
* <code>JS_AddExternalStringFinalizer()</code> and friends.  (We can probably implement these in terms of <code>MMgc::GCFinalizedObject</code>.)
 
Other notes:
* XPConnect garbage-collects <code>XPCWrapNative</code> 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 <code>JSRuntime</code> has multiple threads, each with its own <code>JSContext</code>.
We will, for the moment, lose one thing: the threading model where a single <code>JSRuntime</code> has multiple threads, each with its own <code>JSContext</code>.
Modify stuff that is not using the JSAPI but is cheating:
* Change the XPCOM cycle collector (crash of thunder) to use a separate trace phase instead of depending on the SpiderMonkey GC mark phase to generate certain information it needs for cycle detection.


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)
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)

Revision as of 14:35, 6 July 2007

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.

Retrieved from "https://wiki.allizom.org/index.php?title=JavaScript:ActionMonkey&oldid=61307"