JavaScript:SpiderMonkey:LongTermPlans

The technical plans described below are long-term goals for SpiderMonkey. We aren't necessarily actively working toward completion of any of them. We do try to fix bugs in the short term, in ways that will make these plans easier, or will not get in their way.

If you're interested in any sort of architectural bug-fixing, feel free to work on any of these projects. Some are easier, some are harder and further-reaching, some would have been done already but for their requiring wider-spread changes, without immediate gain. For more details on any of these plans, ask questions in #jsapi.

Object representation

Empowering proxies

Proxies right now are highly entangled with the engine. Working with them often requires diving into friend APIs. As we make no promises about friend APIs remaining anything close to stable, this makes it tricky to use them. We want to gradually change the JSAPI so that if you want an object with any sort of "special" behavior, you implement it as a proxy.

As part of this plan, JSClass will gradually die. The idea of classes is in the middle of deprecation in ECMAScript, so this is a natural step to make. We will still support objects with customized property-lookup, property-getting, property-setting, etc. behavior. These will simply be hooks defined as part of the proxy definition interface, not tied to something named JSClass.

Property/element splitting

...

VM

Remove JSContext as a concept

Historically a JSContext included state necessary to run JS code. These days, most such state is instead stored in JSRuntime, and some state is stored per-compartment or per-global object or per-zone. If we can move all such information out of JSContext, we should be able to get rid of it entirely. JSRuntime or global/compartment-centric methods would expose all the same information.

Add a warning mechanism distinct from the error-reporting mechanism

Reporting a warning right now requires creating an error type, an error message reporter, and other inanities. Warnings should be reporting in a distinct manner from exceptions and shouldn't use the same overloaded mechanism.

Remove error reporting, replace it with exception-catching mechanisms

We currently have both error-reporting, and exception-throwing, error mechanisms. Two is too many. We need to come up with a coherent story for how to deal with all of this, that plays naturally to JS semantics. That probably means that errors should be dealt with only in terms of exception objects. And as far as extracting the information currently in a JSErrorReport goes, that should probably be exposed through a method that takes in a value/object and returns the right data if a usable Error object was passed, or some sort of plausible, partial substitute if not.

JIT

Refactor CodeGenerator to clearly separate architecture-agnostic/specific methods

Cross-backend CodeGenerator methods are implemented in all the separate backends, now (or sometimes in x86-shared backends). These methods are freely intermixed with methods defined only for a single architecture. If we threw some templates, protected inheritance, etc. at this, it should be possible to separate cross-architecture (but possibly defined in architecture-specific files) methods from architecture-specific methods. It's unclear how this could be done. Maybe private inheritance, plus using statements in the architecture-specific CodeGenerator base classes? This problem (of writing a patch, only to find on submission to try that an arch-specific method was mistakenly used) crops up pretty often for new-ish JIT hackers, so it'd be nice to fix it.

JSAPI improvements

Create a clean, fully-C++ API

Most of the JSAPI is old, C-style JS_* functions. These functions' APIs often aren't particularly simple, clean ways to implement those behaviors. A pleasant C++ API that reads more simply, and doesn't necessarily expose operations through hundreds of freestanding methods, would be nice. We've incrementally introduced such APIs at lower levels -- see for example JS::Value -- but we haven't done anything yet at higher levels. Mostly this is a matter of inertia, and of API design being a bunch of hard work that's off the critical path for Firefox. We'd probably welcome help from embedders and the like with special interest and expertise in designing nice, clean C++ APIs for this stuff. (Do note, however, that we still require an exception-safe API -- true/false return values to indicate success will still probably be necessary.)

Replace jschar with char16_t

Recent changes mean that SpiderMonkey's historical jschar type is identical to char16_t (an emulated typedef in older compilers). We should cut out the middle man and just use char16_t directly. This is mostly a large search-and-replace operation on Gecko and JSAPI headers. (Although as a short-term compatibility hack, we may still want to preserve a jschar typedef for the short run, maybe in SpiderMonkey 31, with full removal in 38.)

Replace const char* with const char16_t*

C string APIs were historically pretty convenient. These days, though, with the recent addition of MOZ_UTF16, it's easy to write UTF-16 strings in source code. APIs that take C strings now, should be converted to take 16-bit-wide strings and lengths. This potentially eliminates an inflate operation and reduces the number of different string types to think about. It also makes non-ASCII strings be handled by the default case, which is good for correctness.

Removal of the jsval typedef in favor of JS::Value

jsval and JS::Value are identical. As part of moving more fully to cleaner C++, we should get rid of jsval. Doing so requires cleaning all use of jsval from Gecko -- not hard, but again, just not on anyone's critical path. (Embedders can easily adapt to this by adding typedef JS::Value jsval; to their code as a temporary fix, if needed.)

JSNative's signature will be changed to accept const JS::CallArgs&

The current arguments to JSNative are pretty error-prone. Passing a single class-based argument, that asserts correctness of use, would be preferable -- for correctness checking for sure, and possibly for greater performance (passing one argument being faster than passing two, potentially). We've introduced a helper structure, JS::CallArgs, for this purpose, that can be created from the arguments passed to a JSNative. It's trivial to create such a structure inside every method, then only interact with the arguments through that. New code should use JS::CallArgs exclusively.

Once all of Gecko has switched to JS::CallArgs, we can consider switching JSNative to use it as a parameter -- probably const CallArgs& -- with a minimum of effort. (Unfortunately this effort will involve touching every function implementing the JSNative signature. At least with every function already working in terms of JS::CallArgs, such a patch won't need to touch function logic when it does so.) This is a prerequisite to any such experimentation, or changes to JSNative.