This article documents future directions in functionality, design, and coding practices for SpiderMonkey. It can be read as something like an "ideal future state" for the engine. That means the code as it is today won't match this document, and that's OK. Whenever practical, new code and changes should move code closer to the ideal future. And of course, the idea of the future is always evolving in time as things change and we learn more.
Generational and compacting GC
We are converting SpiderMonkey to generational GC with exact rooting. This requires pervasive changes to the internals and the APIs. We expect GGC to have big benefits in reducing nontrivial (>1ms) GC pauses and heap usage, so we're willing to change everything to get it done. We also want to do compacting for further heap usage reductions.
The big change is in new rooting mechanisms. Currently, we use conservative scanning for the stack, which isn't a good fit with moving GC. In the new version, the internals use a new internal rooting API. Final decisions about the external API haven't been made yet, but it will need to change for moving GC.
Most machines that run SpiderMonkey have multiple cores, so parallelism is almost certainly part of our future. It will take some experimentation to build the right set of parallel facilities. During that experimentation, we need to be careful about applying parallelism with discipline and conceptual clarity.
River Trail (bug 801869 and others) is an API for parallel programming JS based on a ParallelArray type and a set of operations, including map and fold. The parallel operation functions take JS functions as callbacks, and run the callback functions in parallel, using either SIMD operations (compiling the callbacks in a special mode), threads, or both. In the SpiderMonkey River Trail threading model:
The SpiderMonkey API is C++.
For the near future, we do not intend to provide a stable API, because too many things need to change for projects like GGC. Also, we will someday want a more modern C++ API. Going forward from now, the API will likely be semi-stable, but there is no guarantee.
There is not yet a clear direction on which files contain the API and what demarcates official API from Gecko backdoors. More discussion is needed.
Practical coding bits
The plan is to make SpiderMonkey not depend on NSPR. The main issue is that SpiderMonkey will need another way to do multithreading.
JS_THREADSAFE is deprecated. The only reason we have it now is so that shells can build without NSPR. Once the NSPR dependency is removed, JS_THREADSAFE should not be used.