638
edits
(→How to build: reorder - you really kidna need the prerequisites ''first'') |
(→Stage 4: add more work for jim) |
||
| Line 85: | Line 85: | ||
== Stage 4 == | == Stage 4 == | ||
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. | 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 | This will include tasks like: | ||
* Build system: link Tamarin (as a static or dynamic library) into ActionMonkey (and the browser). | * Build system: link Tamarin (as a static or dynamic library) into ActionMonkey (and the browser). | ||
| Line 97: | Line 95: | ||
* Merge SpiderMonkey string optimizations into Tamarin. | * Merge SpiderMonkey string optimizations into Tamarin. | ||
* Compare Tamarin and SpiderMonkey E4X behavior. | * Compare Tamarin and SpiderMonkey E4X behavior. | ||
* Determine which JSAPI <code>JS_*Double*</code> functions can be preserved and which must be removed. Patch the entire Mozilla codebase as needed. | |||
* Change the interpreter to use Tamarin strings. | |||
* Change the interpreter to use Tamarin jsvals. | |||
* Implement an adapter class to support Tamarin objects that preserve the <code>JSObjectOps</code> and <code>JSClass</code> behavior. | |||
* Change the interpreter to use Tamarin objects. | |||
* Make sure jsxdrapi.h works with the new object model. | |||
* Make sure E4X works with the new object model. | |||
* Make sure the debugger still works with the new object model. | |||
It's undecided how all this might land in mozilla-central. I don't think performance regressions can be avoided given the nature of what we're doing here. It seems more sensible to move ahead to Stage 5, in a branch if necessary, than to try to tune the performance of this Frankenstein's monster. | |||
== Stage 5 == | == Stage 5 == | ||
edits