SpiderMonkey 1.8.5 Release Notes

  • Revision slug: SpiderMonkey/1.8.5
  • Revision title: SpiderMonkey 1.8.5 Release Notes
  • Revision id: 72741
  • Created:
  • Creator: Wesgarland
  • Is current revision? No
  • Comment 731 words added, 324 words removed

Revision Content

{{ jsapi_minversion_header("1.8.5") }}

draft();

The Mozilla JavaScript team is pleased to announce the release of SpiderMonkey 1.8.5. You can download full source code here: http://ftp.mozilla.org/pub/mozilla.org/js/js-1.8.0-rc1.tar.gz (MD5 checksum: xxx).

SpiderMonkey 1.8.5 is the JavaScript engine that shipped in Firefox 4.0. It is much faster than SpiderMonkey 1.8, implements ES-5 (ECMA 262, 5th Edition), and contains a many 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.

—22 March 2011

Known issues

SpiderMonkey 1.8.5 has two JIT compilers, code named TraceMonkey and JaegerMonkey. These engines compile interpreter byte code to your CPU's native machine language, for a significant speed increase.  Both JITs support x86, x86_64 and ARM architectures. TraceMonkey also runs on Sparc and Power PC, however these targets are no longer maintained by Mozilla.  The interpreter remains architecture-agnostic. 

There is one known functional regression in 1.8.5: support for extended class methods (in particular, JSEqualityOp) has been dropped. Additionally, the creation of multithreaded JS programs which race against the same objects (e.g. those using the JS shell's scatter() function) are now explicitly not supported.

Migrating to SpiderMonkey 1.8

SpiderMonkey 1.8.5 is not binary-compatible with previous releases, nor is it source-code compatible. Many of the significant performance improvements achieved with SpiderMonkey 1.8.5 required significant changes to the engine's internals, including base data types, garbage collection strategy, and function call semantics. While these changes seem very comprehensive, most embeddings will find that the changes most affect calls into the engine; base functionality remains mostly the same. This means that embedders migrating to SpiderMonkey 1.8.5 will be able to port their programs with little or no algorithmic refactoring.

SpiderMonkey 1.8.5 also includes the configure-based build system, introduced shortly after active development on the engine moved from CVS to Mercurial.

New JavaScript language features

JavaScript 1.8.5 adds support for ECMAScript-5, including ES-5 strict mode. For details, see New in JavaScript 1.8.5. It also ships with js-ctypes, a foreign-function interface for priviledged JavaScript.

Garbage Collection

SpiderMonkey 1.8.5 replaces introduces a conservative stack-scanning garbage collector. Unlike the exact garbage collector, the new garbage collector will scan the C stack and registers in your embedding, looking for bits that it can treat as potential GC roots. The approach eliminates the need for the JS_EnterLocalRootScope API, and in many cases the need to explicitly root GC things or use the "root as you go" approach popular with earlier SpiderMonkey releases.  Since this is a conservative collector, it will often find "garbage" addresses which can trigger warnings from certain code analysis tools.  If you are running valgrind on your embedding, be sure to build SpiderMonkey with the --enable-valgrind option to suppress superflous error messages triggered by the garbage collector.  This also means that objects will be finalized in a non-deterministic order in SpiderMonkey 1.8.5. This is not a bug, and, any embedding which depends upon deterministic finalization is fatally flawed.

Compartments

SpiderMonkey 1.8.5 introduces the concept of compartments. A compartment is a global object, a context, and a set of related objects with no outside references (CrossCompartment wrappers excepted). The new garbage collector can perform per-container garbage collection, which can be a significant performance improvement for certain workloads.  No compartment may execute JS code or call into JSAPI two OS threads at the same time.

JSAPI Type Changes

The base data type, jsval, which represents all possible values in JavaScript, has changed from 32- to 64-bit, and the underlying representation has changed from a C integer type to a C struct. This change to a struct means that certain tricks, such as writing switch statements in C with jsval cases are no longer legal. Additionally, because not all fields are used by all jsvals, it is no longer safe to compare jsvals as though they were C values. Instead, jsvals should be converted to their C equivalents with the appropriate JSVAL_TO_* macro and then compared.

JSAPI no longer represents floating-point numbers (and integers more than 31 bits long) as pointers to jsdouble; instead, the jsdouble value is directly stored in the jsval.  This affects macros like DOUBLE_TO_JSVAL and JSVAL_TO_DOUBLE, which now operate directly on jsdouble rather than jsdouble pointers.

Previous SpiderMonkey versions usually represented integer values smaller than 2^31 as jsvals encoding jsint; e.g. so that JSVAL_IS_INT was true. While this was never specified behaviour, it is no longer true; numeric values which are integers are frequently encoded as jsdouble inside the jsval.  Embedders must be careful when converting numbers from jsvals into C.

JSExtendedClass has been removed from the API entirely.

Previous SpiderMonkey versions could freely interchange jsid and jsval. They are no longer copatible; using  JS_ValueToId and JS_IdToValue to convert between the two is mandatory.

Global Object Changes

Global objects have been specialized, and must be be created with either JS_NewGlobalObject or JS_NewCompartmentAndGlobalObject.  JS_NewObject and JS_NewObjectWithGivenProto remain the correct interfaces for creating other objects. Global objects must also have the JSCLASS_GLOBAL_FLAGS flag set. Merely setting JSCLASS_IS_GLOBAL is insufficient.


Native Function Calling Conventions

Previous versions of JSAPI supported two types of native functions -- JSNative and JSFastNative.  The so-called "Slow Natives" are no longer supported; as such JSFastNative has been renamed to JSNative and relevant interfaces have been updated accordingly. Embedders converting functions from old-JSNative to new-JSNative (JSFastNative) should study the JSFastNative documentation thoroughly, and pay particular that they do not reference negative indices of argv in SpiderMonkey 1.8.5; the JS_CALLEE, JS_THIS, etc macros must be used instead.

New JSAPI features

It has been a couple years since SpiderMonkey 1.7 was released, and many improvements have been made to the JSAPI. However, one of the most important advances for JSAPI application developers is that the documentation is much improved. See the JSAPI User Guide and the JSAPI Reference.

  • Native functions may implement the new callback signature JSFastNative instead of JSNative. JSFastNative can be significantly faster, but applications that use SpiderMonkey's fine-grained security features should heed the warning in its API documentation.
  • New macros JS_FS, JS_FN, and JS_FS_END are recommended for populating JSFunctionSpec arrays.
  • JS_NewObjectWithGivenProto is exactly like JS_NewObject except that it doesn't use a default prototype object if you pass NULL. Instead the object is created with no prototype.
  • JS_AlreadyHasOwnProperty and friends are new functions for examining an object without triggering resolve hooks.
  • It was possible to configure SpiderMonkey 1.7 to treat C/C++ char strings as UTF-8 by compiling with a non-default compiler option. In SpiderMonkey 1.8, it is no longer necessary to make a special build to get this behavior. Applications can turn on UTF-8 at run time by calling JS_SetCStringsAreUTF8.
  • JS_EncodeString is a new variation on JS_GetStringBytes that returns a newly allocated, writable buffer which the application must JS_free.
  • JS_ReportAllocationOverflow can be used (instead of JS_ReportOutOfMemory) to indicate that the script is trying to do something that would require more memory than the implementation is designed to handle. The main difference is that JS_ReportAllocationOverflow throws an exception which the application may catch.
  • JS_ThrowStopIteration throws the appropriate StopIteration exception object for the given context.
  • Two new context options can be used with JS_SetOptions: JSOPTION_RELIMIT, which causes extremely long-running regular expression searches to fail with an error, and JSOPTION_ANONFUNFIX, which bans anonymous functions from appearing anyplace where a statement could appear, such as in the argument to eval().
  • Functions that were JS_THREADSAFE-only in SpiderMonkey 1.7 (JS_BeginRequest, for example) are now present, but do nothing, in non-JS_THREADSAFE builds. This is to help applications share and reuse code regardless of whether they use threads.
  • There are two new JSExtendedClass hooks, JSExtendedClass.iteratorObject and JSExtendedClass.wrappedObject. Both are documented but obscure.

Many new memory management features have been added as well.

  • The new function JS_SetScriptStackQuota limits the size of the JavaScript stack.
  • Two new functions, JS_SetGCZeal and JS_DumpHeap, aim to help developers debug GC-related problems. These functions are only present in DEBUG builds. JS_SetGCZeal is especially helpful. When GC zeal is enabled, GC happens extremely frequently. This makes GC-related problems easier to reproduce, reveals GC problems that you may not have noticed before, and causes GC-safety bugs to surface much closer to their cause. JS_DumpHeap dumps parts of the GC heap and can help detect leaks.
  • A new GC parameter, JSGC_STACKPOOL_LIFESPAN, controls how eagerly SpiderMonkey returns unused memory back to the system.
  • The new function JS_SetExtraGCRoots provides another way to protect values from garbage collection.
  • There is a new set of APIs for integrating SpiderMonkey's garbage collector with other memory management systems. These APIs are undocumented but fairly stable. The APIs include the new JSTraceOp callback.

New JavaScript shell functions

There are a few new built-in functions in the JavaScript shell, mostly useful for testing.  countHeap, dumpHeap, gcparam, gczeal, and stackQuota are related to memory management.  sleep and scatter, defined in JS_THREADSAFE builds only, are for testing thread-safety.

Revision Source

<p>{{ jsapi_minversion_header("1.8.5") }}</p>
<pre class="script" style="font-size: 16px;">draft();</pre>
<div class="note" style="color: black;">
<p>The Mozilla JavaScript team is pleased to announce the release of <strong>SpiderMonkey 1.8.5</strong>. You can download full source code here: <a class=" external" href="http://ftp.mozilla.org/pub/mozilla.org/js/js-1.8.0-rc1.tar.gz">http://ftp.mozilla.org/pub/mozilla.org/js/js-1.8.0-rc1.tar.gz</a> (MD5 checksum: <code>xxx</code>).</p>
<p>SpiderMonkey 1.8.5 is the JavaScript engine that shipped in Firefox 4.0. It is much faster than SpiderMonkey 1.8, implements ES-5 (<a class=" external" href="http://people.mozilla.org/~jorendorff/es5.html" title="http://people.mozilla.org/~jorendorff/es5.html">ECMA 262, 5th Edition</a>), and contains a many new language and API features, described in detail below.</p>
<p>Please let us know about your experiences with this release by posting in the <a class=" link-news" href="news://news.mozilla.org/mozilla.dev.tech.js-engine">mozilla.dev.tech.js-engine newsgroup</a>. Or, file bugs at <a class=" link-https" href="https://bugzilla.mozilla.org/">bugzilla.mozilla.org</a> under Product: Core, Component: JavaScript engine.</p>
<p>—22 March 2011</p>
</div>
<h2>Known issues</h2>
<p>SpiderMonkey 1.8.5 has two JIT compilers, code named TraceMonkey and JaegerMonkey. These engines compile interpreter byte code to your CPU's native machine language, for a significant speed increase.  Both JITs support x86, x86_64 and ARM architectures. TraceMonkey also runs on Sparc and Power PC, however these targets are no longer maintained by Mozilla.  The interpreter remains architecture-agnostic. </p>
<p>There is one known functional regression in 1.8.5: support for extended class methods (in particular, JSEqualityOp) has been dropped. Additionally, the creation of multithreaded JS programs which race against the same objects (e.g. those using the JS shell's scatter() function) are now explicitly not supported.</p>
<h2>Migrating to SpiderMonkey 1.8</h2>
<p>SpiderMonkey 1.8.5 is not binary-compatible with previous releases, nor is it source-code compatible. Many of the significant performance improvements achieved with SpiderMonkey 1.8.5 required significant changes to the engine's internals, including base data types, garbage collection strategy, and function call semantics. While these changes seem very comprehensive, most embeddings will find that the changes most affect calls into the engine; base functionality remains mostly the same. This means that embedders migrating to SpiderMonkey 1.8.5 will be able to port their programs with little or no algorithmic refactoring. </p>
<p>SpiderMonkey 1.8.5 also includes the <code>configure</code>-based build system, introduced shortly after active development on the engine moved from CVS to Mercurial.</p>
<h2>New JavaScript language features</h2>
<p>JavaScript 1.8.5 adds support for ECMAScript-5, including ES-5 strict mode. For details, see <a class="internal" href="/en/JavaScript/New_in_JavaScript/1.8.5" title="en/JavaScript/New in JavaScript/1.8.5">New in JavaScript 1.8.5</a>. It also ships with <a href="/en/js-ctypes" title="https://developer.mozilla.org/en/js-ctypes">js-ctypes</a>, a foreign-function interface for priviledged JavaScript.</p>
<h2>Garbage Collection</h2>
<p>SpiderMonkey 1.8.5 replaces introduces a conservative stack-scanning garbage collector. Unlike the exact garbage collector, the new garbage collector will scan the C stack and registers in your embedding, looking for bits that it can treat as potential GC roots. The approach eliminates the need for the JS_EnterLocalRootScope API, and in many cases the need to explicitly root GC things or use the "root as you go" approach popular with earlier SpiderMonkey releases.  Since this is a conservative collector, it will often find "garbage" addresses which can trigger warnings from certain code analysis tools.  If you are running valgrind on your embedding, be sure to build SpiderMonkey with the --enable-valgrind option to suppress superflous error messages triggered by the garbage collector.  This also means that objects will be finalized in a non-deterministic order in SpiderMonkey 1.8.5. This is not a bug, and, any embedding which depends upon deterministic finalization is fatally flawed.</p>
<h2>Compartments</h2>
<p>SpiderMonkey 1.8.5 introduces the concept of compartments. A compartment is a global object, a context, and a set of related objects with no outside references (CrossCompartment wrappers excepted). The new garbage collector can perform per-container garbage collection, which can be a significant performance improvement for certain workloads.  No compartment may execute JS code or call into JSAPI two OS threads at the same time.</p>
<h2>JSAPI Type Changes</h2>
<p>The base data type, jsval, which represents all possible values in JavaScript, has changed from 32- to 64-bit, and the underlying representation has changed from a C integer type to a C struct. This change to a struct means that certain tricks, such as writing switch statements in C with jsval cases are no longer legal. Additionally, because not all fields are used by all jsvals, it is no longer safe to compare jsvals as though they were C values. Instead, jsvals should be converted to their C equivalents with the appropriate JSVAL_TO_* macro and then compared.</p>
<p>JSAPI no longer represents floating-point numbers (and integers more than 31 bits long) as pointers to jsdouble; instead, the jsdouble value is directly stored in the jsval.  This affects macros like DOUBLE_TO_JSVAL and JSVAL_TO_DOUBLE, which now operate directly on jsdouble rather than jsdouble pointers.</p>
<p>Previous SpiderMonkey versions usually represented integer values smaller than 2^31 as jsvals encoding jsint; e.g. so that JSVAL_IS_INT was true. While this was never specified behaviour, it is no longer true; numeric values which are integers are frequently encoded as jsdouble inside the jsval.  Embedders must be careful when converting numbers from jsvals into C.</p>
<p>JSExtendedClass has been removed from the API entirely.</p>
<p>Previous SpiderMonkey versions could freely interchange jsid and jsval. They are no longer copatible; using  JS_ValueToId and JS_IdToValue to convert between the two is mandatory.</p>
<h2>Global Object Changes</h2>
<p>Global objects have been specialized, and must be be created with either JS_NewGlobalObject or JS_NewCompartmentAndGlobalObject.  JS_NewObject and JS_NewObjectWithGivenProto remain the correct interfaces for creating other objects. Global objects must also have the JSCLASS_GLOBAL_FLAGS flag set. Merely setting JSCLASS_IS_GLOBAL is insufficient.</p>
<br>
<h2>Native Function Calling Conventions</h2>
<p>Previous versions of JSAPI supported two types of native functions -- JSNative and JSFastNative.  The so-called "Slow Natives" are no longer supported; as such JSFastNative has been renamed to JSNative and relevant interfaces have been updated accordingly. Embedders converting functions from old-JSNative to new-JSNative (JSFastNative) should study the <a href="/en/JSFastNative" title="https://developer.mozilla.org/en/JSFastNative">JSFastNative</a> documentation thoroughly, and pay particular that they do not reference negative indices of argv in SpiderMonkey 1.8.5; the JS_CALLEE, JS_THIS, etc macros must be used instead. </p>
<h2>New JSAPI features</h2>
<p>It has been a couple years since SpiderMonkey 1.7 was released, and many improvements have been made to the JSAPI. However, one of the most important advances for JSAPI application developers is that the documentation is much improved. See the <a class="internal" href="/En/SpiderMonkey/JSAPI_User_Guide" title="En/SpiderMonkey/JSAPI User Guide">JSAPI User Guide</a> and the <a class="internal" href="/en/SpiderMonkey/JSAPI_Reference" title="En/SpiderMonkey/JSAPI Reference">JSAPI Reference</a>.</p>
<ul> <li>Native functions may implement the new callback signature <a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JSFastNative" title="En/SpiderMonkey/JSAPI Reference/JSFastNative"><code>JSFastNative</code></a> instead of <a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JSNative" title="En/SpiderMonkey/JSAPI Reference/JSNative"><code>JSNative</code></a>. <code>JSFastNative</code> can be significantly faster, but applications that use SpiderMonkey's fine-grained security features should heed the warning in its API documentation.</li> <li>New macros <a class="internal" href="/En/SpiderMonkey/JSAPI_Reference/JS_FS" title="en/SpiderMonkey/JSAPI Reference/JS FS"><code>JS_FS</code></a>, <a class="internal" href="/En/SpiderMonkey/JSAPI_Reference/JS_FS" title="en/SpiderMonkey/JSAPI Reference/JS FS"><code>JS_FN</code></a>, and <a class="internal" href="/En/SpiderMonkey/JSAPI_Reference/JS_FS" title="en/SpiderMonkey/JSAPI Reference/JS FS"><code>JS_FS_END</code></a> are recommended for populating <a class="internal" href="/En/SpiderMonkey/JSAPI_Reference/JSFunctionSpec" title="En/SpiderMonkey/JSAPI Reference/JSFunctionSpec"><code>JSFunctionSpec</code></a> arrays.</li> <li><a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JS_NewObject" title="En/SpiderMonkey/JSAPI Reference/JS NewObject"><code>JS_NewObjectWithGivenProto</code></a> is exactly like <a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JS_NewObject" title="En/SpiderMonkey/JSAPI Reference/JS NewObject"><code>JS_NewObject</code></a> except that it doesn't use a default prototype object if you pass <code>NULL</code>. Instead the object is created with no prototype.</li> <li><a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JS_AlreadyHasOwnProperty" title="En/SpiderMonkey/JSAPI Reference/JS AlreadyHasOwnProperty"><code>JS_AlreadyHasOwnProperty</code></a> and friends are new functions for examining an object without triggering resolve hooks.</li> <li>It was possible to configure SpiderMonkey 1.7 to treat C/C++ <code>char</code> strings as UTF-8 by compiling with a non-default compiler option. In SpiderMonkey 1.8, it is no longer necessary to make a special build to get this behavior. Applications can turn on UTF-8 at run time by calling <a class="internal" href="/En/SpiderMonkey/JSAPI_Reference/JS_CStringsAreUTF8" title="En/SpiderMonkey/JSAPI Reference/JS CStringsAreUTF8"><code>JS_SetCStringsAreUTF8</code></a>.</li> <li><a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JS_GetStringBytes" title="En/SpiderMonkey/JSAPI Reference/JS GetStringBytes"><code>JS_EncodeString</code></a> is a new variation on <a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JS_GetStringBytes" title="En/SpiderMonkey/JSAPI Reference/JS GetStringBytes"><code>JS_GetStringBytes</code></a> that returns a newly allocated, writable buffer which the application must <a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JS_malloc" title="En/SpiderMonkey/JSAPI Reference/JS malloc"><code>JS_free</code></a>.</li> <li><a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JS_ReportOutOfMemory" title="En/SpiderMonkey/JSAPI Reference/JS ReportOutOfMemory"><code>JS_ReportAllocationOverflow</code></a> can be used (instead of <a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JS_ReportOutOfMemory" title="En/SpiderMonkey/JSAPI Reference/JS ReportOutOfMemory"><code>JS_ReportOutOfMemory</code></a>) to indicate that the script is trying to do something that would require more memory than the implementation is designed to handle. The main difference is that <code>JS_ReportAllocationOverflow</code> throws an exception which the application may catch.</li> <li><a class="internal" href="/En/SpiderMonkey/JSAPI_Reference/JS_ThrowStopIteration" title="en/SpiderMonkey/JSAPI Reference/JS ThrowStopIteration"><code>JS_ThrowStopIteration</code></a> throws the appropriate <code>StopIteration</code> exception object for the given context.</li> <li>Two new context options can be used with <a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JS_SetOptions" title="En/SpiderMonkey/JSAPI Reference/JS SetOptions"><code>JS_SetOptions</code></a>: <a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JS_SetOptions" title="En/SpiderMonkey/JSAPI Reference/JS SetOptions"><code>JSOPTION_RELIMIT</code></a>, which causes extremely long-running regular expression searches to fail with an error, and <a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JS_SetOptions" title="En/SpiderMonkey/JSAPI Reference/JS SetOptions"><code>JSOPTION_ANONFUNFIX</code></a>, which bans anonymous functions from appearing anyplace where a statement could appear, such as in the argument to <code>eval()</code>.</li> <li>Functions that were <a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JS_THREADSAFE" title="En/SpiderMonkey/JSAPI Reference/JS THREADSAFE"><code>JS_THREADSAFE</code></a>-only in SpiderMonkey 1.7 (<a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JS_BeginRequest" title="En/SpiderMonkey/JSAPI Reference/JS BeginRequest"><code>JS_BeginRequest</code></a>, for example) are now present, but do nothing, in non-<code>JS_THREADSAFE</code> builds. This is to help applications share and reuse code regardless of whether they use threads.</li> <li>There are two new <a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JSExtendedClass" title="En/SpiderMonkey/JSAPI Reference/JSExtendedClass"><code>JSExtendedClass</code></a> hooks, <a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JSExtendedClass.iteratorObject" title="En/SpiderMonkey/JSAPI Reference/JSExtendedClass.iteratorObject"><code>JSExtendedClass.iteratorObject</code></a> and <a class="internal" href="/En/SpiderMonkey/JSAPI_Reference/JSExtendedClass.wrappedObject" title="En/JSExtendedClass.wrappedObject"><code>JSExtendedClass.wrappedObject</code></a>. Both are documented but obscure.</li>
</ul>
<p>Many new memory management features have been added as well.</p>
<ul> <li>The new function <a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JS_SetScriptStackQuota" title="En/SpiderMonkey/JSAPI Reference/JS SetScriptStackQuota"><code>JS_SetScriptStackQuota</code></a> limits the size of the JavaScript stack.</li> <li>Two new functions, <a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JS_SetGCZeal" title="En/SpiderMonkey/JSAPI Reference/JS SetGCZeal"><code>JS_SetGCZeal</code></a> and <a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JS_DumpHeap" title="En/SpiderMonkey/JSAPI Reference/JS DumpHeap"><code>JS_DumpHeap</code></a>, aim to help developers debug GC-related problems. These functions are only present in <code>DEBUG</code> builds. <code>JS_SetGCZeal</code> is especially helpful. When GC zeal is enabled, GC happens extremely frequently. This makes GC-related problems easier to reproduce, reveals GC problems that you may not have noticed before, and causes GC-safety bugs to surface much closer to their cause. <code>JS_DumpHeap</code> dumps parts of the GC heap and can help detect leaks.</li> <li>A new <a class="internal" href="/En/SpiderMonkey/JSAPI_Reference/JS_GetGCParameter" title="En/SpiderMonkey/JSAPI Reference/JS GetGCParameter">GC parameter</a>, <code>JSGC_STACKPOOL_LIFESPAN</code>, controls how eagerly SpiderMonkey returns unused memory back to the system.</li> <li>The new function <a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JS_SetExtraGCRoots" title="En/SpiderMonkey/JSAPI Reference/JS SetExtraGCRoots"><code>JS_SetExtraGCRoots</code></a> provides another way to protect values from garbage collection.</li> <li>There is a new set of APIs for integrating SpiderMonkey's garbage collector with other memory management systems. These APIs are undocumented but fairly stable. The APIs include the new <code><a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JSTraceOp" title="en/SpiderMonkey/JSAPI Reference/JSTraceOp">JSTraceOp</a></code> callback.</li>
</ul>
<h2>New JavaScript shell functions</h2>
<p>There are a few new <a class="internal" href="/En/SpiderMonkey/Introduction_to_the_JavaScript_shell#Built-in_functions" title="En/SpiderMonkey/Introduction_to_the_JavaScript_shell#Built-in_functions">built-in functions in the JavaScript shell</a>, mostly useful for testing.  <code>countHeap</code>, <code>dumpHeap</code>, <code>gcparam</code>, <code>gczeal</code>, and <code>stackQuota</code> are related to memory management.  <code>sleep</code> and <code>scatter</code>, defined in <a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JS_THREADSAFE" title="en/SpiderMonkey/JSAPI Reference/JS THREADSAFE"><code>JS_THREADSAFE</code></a> builds only, are for testing thread-safety.</p>
Revert to this revision