JavaScript:ActionMonkey: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| Line 23: | Line 23: | ||
* 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. | * 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 MMgc in non-incremental mode to start with. (It's easier. Avoid premature optimization.) | ||
* We'll | * We'll build SpiderMonkey as C++, and some key types (<code>JSObject</code>, <code>JSString</code>) will become classes. This is unavoidable because MMgc's API for finalization is to subclass <code>MMgc::GCFinalizedObject</code>. | ||
More details: [[JavaScript:ActionMonkey:Stage 0 Whiteboard]] | More details: [[JavaScript:ActionMonkey:Stage 0 Whiteboard]] | ||
| Line 31: | Line 31: | ||
* Change the few places where SpiderMonkey is directly using stdlib <code>malloc()</code> (<code>malloc</code>, <code>free</code>, <code>realloc</code>, <code>calloc</code>, <code>strdup</code>, etc.) to use a new internal API (lowercase <code>js_malloc</code>). | * Change the few places where SpiderMonkey is directly using stdlib <code>malloc()</code> (<code>malloc</code>, <code>free</code>, <code>realloc</code>, <code>calloc</code>, <code>strdup</code>, etc.) to use a new internal API (lowercase <code>js_malloc</code>). | ||
** brendan: Hope these can all be macro-defined. | ** brendan: Hope these can all be macro-defined. | ||
* Team hacking session to reimplement jsgc.c. | * Team hacking session to reimplement jsgc.c. | ||
| Line 45: | Line 44: | ||
* 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.) | * 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>. (Firefox doesn't use this.) | ||
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 19:29, 15 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/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.
Stage 0
Replace SpiderMonkey's GC with Tamarin's GC (MMgc). Bug 387012 – ActionMonkey stage 0 tracking bug
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 build SpiderMonkey as C++, and some key types (
JSObject,JSString) will become classes. This is unavoidable because MMgc's API for finalization is to subclassMMgc::GCFinalizedObject.
More details: JavaScript:ActionMonkey:Stage 0 Whiteboard
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 (lowercasejs_malloc).- brendan: Hope these can all be macro-defined.
- 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 ofMMgc::GCFinalizedObject.)
Other notes:
- XPConnect garbage-collects
XPCWrapNativeobjects 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. (Firefox doesn't use this.)
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.