Thu. Jun 4th, 2020

V8 JavaScript Engine v8.3 releases: Google’s open source high-performance JavaScript engine

3 min read

V8 compiles and executes JavaScript source code, handles memory allocation for objects, and garbage collects objects it no longer needs. V8’s stop-the-world, generational, accurate garbage collector is one of the keys to V8’s performance. You can learn about this and other performance aspects in V8 Design Elements.

JavaScript is most commonly used for client-side scripting in a browser, being used to manipulate Document Object Model (DOM) objects for example. The DOM is not, however, typically provided by the JavaScript engine but instead by a browser. The same is true of V8—Google Chrome provides the DOM. V8 does however provide all the data types, operators, objects and functions specified in the ECMA standard.

V8 enables any C++ application to expose its own objects and functions to JavaScript code. It’s up to you to decide on the objects and functions you would like to expose to JavaScript. There are many examples of applications that do this, for example: Adobe Flash and the Dashboard Widgets in Apple’s Mac OS X and Yahoo! Widgets.

Image: slideshare

V8 v8.3 is now officially available.



Faster ArrayBuffer tracking in the garbage collector

Backing stores of ArrayBuffers are allocated outside V8’s heap using ArrayBuffer::Allocator provided by the embedder. These backing stores need to be released when their ArrayBuffer object is reclaimed by the garbage collector. V8 v8.3 has a new mechanism for tracking ArrayBuffers and their backing stores that allows the garbage collector to iterate and free the backing store concurrently to the application. More details are available in this design document. This reduced total GC pause time in ArrayBuffer heavy workloads by 50%.

Bigger Wasm memories

In accordance with an update to the WebAssembly specification, V8 v8.3 now allows modules to request memories up to 4GB in size, allowing more memory-heavy use cases to be brought to platforms powered by V8. Please keep in mind that this much memory might not always be available on a user’s system; we recommend creating memories at smaller sizes, growing them as needed, and gracefully handling failures to grow.


Stores to objects with typed arrays on the prototype chain

According to the JavaScript specification, when storing a value to the specified key we need to lookup the prototype chain to see if the key already exists on the prototype. More often than not these keys don’t exist on the prototype chain, and so V8 installs fast lookup handlers to avoid these prototype chain walks when it is safe to do so.

However, we recently identified a particular scenario where V8 incorrectly installed this fast lookup handler, leading to incorrect behaviour. When TypedArrays are on the prototype chain, all stores to keys which are OOB of the TypedArray should be ignored. For example, in the case below v[2] shouldn’t add a property to v and the subsequent reads should return undefined.

For full updates, please read the release notes here.