Every six weeks, we create a new branch of V8 as part of our release process. Each version is branched from V8’s Git master immediately before a Chrome Beta milestone. Today we’re pleased to announce our newest branch, V8 version 8.5, which is in beta until its release in coordination with Chrome 85 Stable in several weeks. V8 v8.5 is filled with all sorts of developer-facing goodies. This post provides a preview of some of the highlights in anticipation of the release.

Every six weeks, we create a new branch of V8 as part of our release process. Each version is branched from V8’s Git master immediately before a Chrome Beta milestone. Today we’re pleased to announce our newest branch, V8 version 8.4, which is in beta until its release in coordination with Chrome 84 Stable in several weeks. V8 v8.4 is filled with all sorts of developer-facing goodies. This post provides a preview of some of the highlights in anticipation of the release.

In the past we have already been writing about garbage collection for JavaScript, the document object model (DOM), and how all of this is implemented and optimized in V8. Not everything in Chromium is JavaScript though, as most of the browser and its Blink rendering engine where V8 is embedded are written in C++. JavaScript can be used to interact with the DOM that is then processed by the rendering pipeline.

All episodes

Meanwhile in other parts of the Web​

Jason Orendorff from Mozilla published a great in-depth analysis of JS syntactic quirks. Even though the implementation details differ, every JS engine faces the same problems with these quirks.

Introduction​

Thanks to recent work in Chrome and Emscripten, you can now use up to 4GB of memory in WebAssembly applications. That’s up from the previous limit of 2GB. It might seem odd that there was ever a limit - after all, no work was needed to allow people to use 512MB or 1GB of memory! - but it turns out that there are some special things happening in the jump from 2GB to 4GB, both in the browser and in the toolchain, which we’ll describe in this post.

Every six weeks, we create a new branch of V8 as part of our release process. Each version is branched from V8’s Git master immediately before a Chrome Beta milestone. Today we’re pleased to announce our newest branch, V8 version 8.3, which is in beta until its release in coordination with Chrome 83 Stable in several weeks. V8 v8.3 is filled with all sorts of developer-facing goodies. This post provides a preview of some of the highlights in anticipation of the release.

We have a growing number of compilers and other tools that generate or manipulate .wasm files, and sometimes you might want to have a look inside. Maybe you’re a developer of such a tool, or more directly, you’re a programmer targeting Wasm, and wondering what the generated code looks like, for performance or other reasons.

All episodes

In this episode, we’ll go deeper in the definition of the ECMAScript language and its syntax. If you’re not familiar with context-free grammars, now is a good time to check out the basics, since the spec uses context-free grammars to define the language. See the chapter about context free grammars in "Crafting Interpreters" for an approachable introduction or the Wikipedia page for a more mathematical definition.

There is a constant battle between memory and performance. As users, we would like things to be fast as well as consume as little memory as possible. Unfortunately, usually improving performance comes at a cost of memory consumption (and vice versa).

Let’s practice our awesome spec reading skills some more. If you haven’t had a look at the previous episode, now it’s a good time to do so!

All episodes

Ready for part 2?​

A fun way to get to know the spec is to start with a JavaScript feature we know is there, and find out how it’s specified.

Warning! This episode contains copy-pasted algorithms from the ECMAScript spec as of February 2020. They’ll eventually be out of date.

We know that properties are looked up in the prototype chain: if an object doesn’t have the property we’re trying to read, we walk up the prototype chain until we find it (or find an object which no longer has a prototype).

For example:

const o1 = { foo: 99 };
const o2 = {};
Object.setPrototypeOf(o2, o1);
o2.foo;
// → 99

Where’s the prototype walk defined?​

Let’s try to find out where this behavior is defined. A good place to start is a list of Object Internal Methods.

There’s both [[GetOwnProperty]] and [[Get]] — we’re interested in the version that isn’t restricted to own properties, so we’ll go with [[Get]].

Unfortunately, the Property Descriptor specification type also has a field called [[Get]], so while browsing the spec for [[Get]], we need to carefully distinguish between the two independent usages.