These release notes are an incomplete draft and were initially seeded from the (now-defunct) 1.8.8 release notes, which were themselves seeded from the 1.8.5 release notes, so lots of the information here isn't actually new to SpiderMonkey 17.
The Mozilla JavaScript team is pleased to announce the release of SpiderMonkey 17. You can download full source code here: https://ftp.mozilla.org/pub/mozilla.org/js/mozjs17.0.0.tar.gz (MD5 checksum: 20b6f8f1140ef6e47daa3b16965c9202).
SpiderMonkey 17 is the JavaScript engine that shipped in Firefox 17. It continues to improve performance over previous SpiderMonkey releases, with ongoing JIT compilation work and with the introduction of type inference to enable faster JITted code. It also contains new language and API features described in detail below.
Please let us know about your experiences with this release by posting in the mozilla.dev.tech.js-engine newsgroup. Or file bugs at bugzilla.mozilla.org under Product: Core, Component: JavaScript engine.
— 25 March 2013
Platform support
SpiderMonkey 17 is supported on all the platforms where Firefox 17 runs.
SpiderMonkey 17 includes a just-in-time compiler (JIT) that compiles JavaScript to machine code, for a significant speed increase. It is supported on x86, x86_64, and ARM architectures. On some other platforms (SPARC, MIPS), the JIT is provided but not supported. On all other platforms the JIT is simply disabled; JavaScript code runs in an interpreter, as in previous versions. It's the same language, just not as fast.
Migrating to SpiderMonkey 17
The following features in earlier versions of SpiderMonkey have been dropped.
- The
JSRESOLVE_CLASSNAME
andJSRESOLVE_WITH
resolve flags (passed to JSClass.resolve whenJSClass.flags
contains JSCLASS_NEW_RESOLVE) have been removed.
SpiderMonkey 17 is not binary-compatible with previous releases, nor is it source-code compatible. Many JSAPI types, functions, and callback signatures have changed, though most of them still have the same names and do the same things. Applications will need significant changes, but most of those changes will be detected by the C/C++ compiler, so they are easy to detect and updating the code is a fairly straightforward job. Here is a list of the most significant changes.
- A significant number of
typedef
s of built-in types, or of types which are now standardized, have been removed.
These and other changes are explained in detail below.
New JavaScript language features
JavaScript 17 includes significant updates to language features, yo.
typedef
Changes
Many types have been removed from the JSAPI and replaced with simpler alternatives. Including jsapi.h
provides all these types, but more-specific headers also provide these types if you wish to use them in other code.
Obsolete typedef |
Replacement type | Provided by |
---|---|---|
|
uint8_t , int8_t , uint16_t , int16_t , uint32_t , int32_t , uint64_t , int64_t |
mozilla/StdInt.h |
uintN , intN |
unsigned (also known as unsigned int ), int |
N/A |
jsdouble |
double |
N/A |
JSUintn , JSIntn |
unsigned (also known as unsigned int ), int |
N/A |
JSPackedBool |
N/A | N/A |
jsrefcount |
N/A | N/A |
The fixed-size integer types are defined in one of the following ways:
- If the environment variable
MOZ_CUSTOM_STDINT_H
is set, that file will be included to provide definitions for these types. The file must conform to the standard C99<stdint.h>
header interface in all respects, providing all that header's types and macro definitions. (The msstdint project includes an implementation of this header for Microsoft Visual Studio which demonstrates what the C99 interface looks like.) - Otherwise, if the compiler doesn't provide a usable
<stdint.h>
header, a custom implementation shipped with the SpiderMonkey source is used. Currently only versions of Visual Studio prior to 2010 (also known as version 10) are known to be deficient in this manner, so the custom implementation (which is compatible with the one shipped in Visual Studio 2010 and later) is only invoked for those compilers. - Otherwise
<stdint.h>
is used.
The environment variable is provided as a solution for embedders whose code requires particular definitions of those types, and those particular definitions are incompatible with the standard definitions or the custom implementation needed for older versions of Visual Studio. In the long run we anticipate removing the environment variable-based overriding when we drop support for versions of Visual Studio prior to 2010. In the meantime MOZ_CUSTOM_STDINT_H
is intended to function as a bridge to always using the standard header.
For more information on the fixed-size integer types changes, see this blog post.
New C APIs
...list and link to new APIs here...
New C++ helpers
While JSAPI remains a C API, the engine is now implemented in C++. Some C++ helpers have been introduced into the API, to help embedders writing C++ projects. Please note that SpiderMonkey reserves the JS:: namespace for itself.
...list new C++ helpers here...
Obsolete APIs
...list obsolete methods/structs/APIs here...
Deleted APIs
- JS_GET_CLASS (use
JS_GetClass
instead) JS_ConstructObject
andJS_ConstructObjectWithArguments
(preferably useJS_New
instead, or use this reimplementation as a short-term fix)- JS_NewCompartmentAndGlobalObject (Use JS_NewGlobalObject instead.)
- JSPD_ARGUMENT
- JSVAL_IS_OBJECT() (use !JSVAL_IS_PRIMITIVE(v) to detect objects and JSVAL_IS_NULL(v) to detect null).
- JS_IsScriptFrame
- JSCLASS_NEW_RESOLVE_GETS_START flag
- JS_NewNumberValue
- JS_FinalizeStub
- JS_ClearNewbornRoots
- JSCLASS_MARK_IS_TRACE flag
- JS_SetScriptStackQuota
API changes
Break out and discuss all API changes here...
JSClass
Prototype has changed
A number of optional members have been removed from the JSCLass Prototype.
JSClass
Callback changes
Many of the JSClass callbacks such as JSResolveOP
, JSEnumerateOp
and JSPropertyOp
, have a type change on their arguments to JSHandleObject
, JSHandleId
, JSHandleMutableObject
etc. Atleast for the C API this wraps an extra pointer around these objects, so you would cast the argument to JSObject**
, in the callback function.
Removal of JSContext*
parameters to many methods
The JS_GetClass
method now takes only a JSObject*
, where previously it also required a JSContext*
in threadsafe builds. (The JS_GET_CLASS macro abstracting away this difference has accordingly been removed.)
Garbage Collection functions now take runtime argument
Most garbage collection functions now take a runtime argument instead of a context. The one exception to this is JS_MaybeGC
which still takes a context as argument.
JavaScript shell changes
Detail added/removed methods here...
Known Issues
Detail any known issues here...
Future Direction
INCLUDE-FOLLOWUP-ON-EXPERIMENTAL-LIBRARY-VERSIONING-SCHEME-HERE
SpiderMonkey embedders should also be aware that
- Mozilla has no plans to keep the JSAPI, nor the JSDBGAPI stable for embedders. We have chosen to concentrate on performance and correctness as primary concerns instead.
- The team is considering the removal of TinyIDs
- JS_THREADSAFE is going away, with future versions supporting only thread-safe builds
- A new debugging API is on the way to replace JSD.
- In the future every API is going to take Handles instead of raw pointers. Exact Stack Rooting is requirement for a (moving) Generational Garbage Collector.
Release Notes Errata
This is a list of changes which need to be made to the release notes ASAP. Feel free to fix any problems you spot -- this is a Wiki!
- Don't add anything here -- this is for after the release notes are completed. :-)