SpiderMonkey 1.8 Release Notes

  • Revision slug: SpiderMonkey/1.8
  • Revision title: SpiderMonkey 1.8 Release Notes
  • Revision id: 138129
  • Created:
  • Creator: Jorend
  • Is current revision? No
  • Comment 12 words added

Revision Content

{{ jsapi_minversion_header("1.8 (not yet released)") }}

Known issues

  • In JS_THREADSAFE builds, some objects are not safe to be shared among threads. This includes iterators and generators ({{ bug("349263") }}) and arrays ({{ bug("417501") }}). In short, applications that share objects among threads in such a way that two threads could access an array, iterator, or generator object at the same time should not use SpiderMonkey 1.8.
  • When JavaScript 1.8 support is enabled, the parser accepts some incorrect programs by inserting a semicolon where it should instead throw a SyntaxError.  ({{ bug("384758") }}.)

SpiderMonkey 1.8 does not include the new TraceMonkey JIT or the configure-based build system, both of which are (a) pretty darn awesome and (b) coming in SpiderMonkey 1.8.1.

New JavaScript language features

JavaScript 1.8 adds Array.reduce() and reduceRight(), expression closures, and generator expressions. There is also one obscure non-backwards-compatible change. For details, see New in JavaScript 1.8.

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_SetOperationCallback is a much faster alternative to JS_SetBranchCallback.
  • 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.

Other changes

  • JS_NewDouble is deprecated.  Use JS_NewDoubleValue.
  • js.mak, an old Windows-specific nmake file, has been deleted. It hasn't worked for a long time. It is fairly easy to create a Microsoft Visual Studio project file for SpiderMonkey 1.8 from scratch. (If you would like to contribute and maintain a project file, please feel free to contact the SpiderMonkey team via email, bugzilla, or IRC.) Alternatively, you can install MozillaBuild and run the command make -f Makefile.ref in the js/src directory.

Revision Source

<p>{{ jsapi_minversion_header("1.8 (not yet released)") }}</p>
<h2>Known issues</h2>
<ul> <li>In <code>JS_THREADSAFE</code> builds, <strong>some objects are not safe to be shared among threads</strong>. This includes iterators and generators ({{ bug("349263") }}) and arrays ({{ bug("417501") }}). In short, applications that share objects among threads in such a way that two threads could access an array, iterator, or generator object at the same time should not use SpiderMonkey 1.8.</li> <li>When JavaScript 1.8 support is enabled, the parser accepts some incorrect programs by inserting a semicolon where it should instead throw a SyntaxError.  ({{ bug("384758") }}.)</li>
</ul>
<p>SpiderMonkey 1.8 does not include the new TraceMonkey JIT or the <code>configure</code>-based build system, both of which are (a) pretty darn awesome and (b) coming in SpiderMonkey 1.8.1.</p><h2>New JavaScript language features</h2>
<p>JavaScript 1.8 adds <code>Array.reduce()</code> and <code>reduceRight()</code>, expression closures, and generator expressions. There is also one obscure non-backwards-compatible change. For details, see <a class="internal" href="/en/New_in_JavaScript_1.8" title="en/New in JavaScript 1.8">New in JavaScript 1.8</a>.</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_SetOperationCallback" title="En/SpiderMonkey/JSAPI Reference/JS SetOperationCallback"><code>JS_SetOperationCallback</code></a> is a much faster alternative to <a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JS_SetBranchCallback" title="En/SpiderMonkey/JSAPI Reference/JS SetBranchCallback"><code>JS_SetBranchCallback</code></a>.</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>Other changes</h2>
<ul> <li><a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JS_NewDouble" title="En/SpiderMonkey/JSAPI Reference/JS NewDouble"><code>JS_NewDouble</code></a> is deprecated.  Use <a class="internal" href="/en/SpiderMonkey/JSAPI_Reference/JS_NewDoubleValue" title="En/SpiderMonkey/JSAPI Reference/JS NewDoubleValue"><code>JS_NewDoubleValue</code></a>.</li> <li><code>js.mak</code>, an old Windows-specific <code>nmake</code> file, has been deleted. It hasn't worked for a long time. It is fairly easy to create a Microsoft Visual Studio project file for SpiderMonkey 1.8 from scratch. (If you would like to contribute and maintain a project file, please feel free to contact the SpiderMonkey team via email, bugzilla, or IRC.) Alternatively, you can install <a class="internal" href="/en/Windows_Build_Prerequisites" title="en/Windows Build Prerequisites">MozillaBuild</a> and run the command <code>make -f Makefile.ref</code> in the <code>js/src</code> directory.</li>
</ul>
Revert to this revision