# V8 The V8 JavaScript engine This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## How we made JSON.stringify more than twice as fast DevFeed: [How we made JSON.stringify more than twice as fast]() Original publisher: [Read original article]() Author: Patrick Thier Published: 2025-08-04T00:00:00Z Content type: article Language: en Sources: [V8]() Topics: [modern web development](), [Web Development]() Tags: [ascii](), [data](), [internals](), [javascript](), [json](), [optimization](), [performance]() ### AI overview The article explains V8 optimizations that make JSON.stringify more than twice as fast. It covers a side-effect-free iterative fast path and specialized handling for one-byte and two-byte strings. ### Source excerpt JSON.stringify is a core JavaScript function for serializing data. Its performance directly affects common operations across the web, from serializing data for a network request to saving data to localStorage. A faster JSON.stringify translates to quicker page interactions and more responsive applications. That's why we're excited to share that a recent engineering effort has made JSON.stringify in V8 more than twice as fast. This post breaks down the technical optimizations that made this improvement possible. A Side-Effect-Free Fast Path # The foundation of this optimization is a new fast path built on a simple premise: if we can guarantee that serializing an object will not trigger any side effects, we can use a much faster, specialized implementation. A "side effect" in this context is anything that breaks the simple, streamlined traversal of an object. This includes not only the obvious cases like executing user-defined code during serialization, but also more subtle internal operations that might trigger a garbage collection cycle. For more details on what exactly can cause side effects and how you can avoid them, see Limitations. As long as V8 can determine that serialization will be free from these effects, it can stay on this highly-optimized path. This allows it to bypass many expensive checks and defensive logic required by the general-purpose serializer, resulting in a significant speedup for the most common types of JavaScript objects that represent plain data. Furthermore, the new fast path is iterative, in contrast to the recursive general-purpose serializer. This architectural choice not only eliminates the need for stack overflow checks and allows us to quickly resume after encoding changes, but also allows developers to serialize significantly deeper nested object graphs than was previously possible. Handling different String Representations # Strings in V8 can be represented with either one-byte or two-byte characters. If a string contains only AS ## Speculative Optimizations for WebAssembly using Deopts and Inlining DevFeed: [Speculative Optimizations for WebAssembly using Deopts and Inlining]() Original publisher: [Read original article]() Author: Daniel Lehmann and Matthias Liedtke Published: 2025-06-24T00:00:00Z Content type: article Language: en Sources: [V8]() Topics: [WebAssembly](), [V8](), [JIT](), [Google Chrome](), [Compiler](), [JavaScript](), [Dart]() Tags: [benchmarks](), [code](), [compiler](), [dart](), [google-chrome](), [internals](), [javascript](), [jit](), [webassembly]() ### AI overview This V8 blog post describes speculative call_indirect inlining and deoptimization support for WebAssembly, shipped with Google Chrome M137. The optimizations use runtime feedback to generate better machine code, improving WebAssembly execution, especially for WasmGC programs. Dart microbenchmarks showed average speedups above 50%, while larger applications and benchmarks improved by 1% to 8%. ### Source excerpt In this blog post, we explain two optimizations for WebAssembly that we recently implemented in V8 and that shipped with Google Chrome M137, namely speculative call_indirect inlining and deoptimization support for WebAssembly. In combination, they allow us to generate better machine code by making assumptions based on runtime feedback. This speeds up WebAssembly execution, in particular for WasmGC programs. On a set of Dart microbenchmarks for example, the speedup by the combination of both optimizations is more than 50% on average, and on larger, realistic applications and benchmarks shown below the speedup is between 1% and 8%. Deoptimizations are also an important building block for further optimizations in the future. Background # Fast execution of JavaScript relies heavily on speculative optimizations. That is, JIT-compilers make assumptions when generating machine code based on feedback that was collected during earlier executions. For example, given the expression a + b, the compiler can generate machine code for an integer addition if past feedback indicates that a and b are integers (and not strings, floating point numbers, or other objects). Without making such assumptions, the compiler would have to emit generic code that handles the full behavior of the + operator in JavaScript, which is complex and thus much slower. If the program later behaves differently and thus violates assumptions made when generating the optimized code, V8 performs a deoptimization (or deopt, for short). That means throwing away the optimized code and continuing execution in unoptimized code (and collecting more feedback to possibly tier-up again later). In contrast to JavaScript, fast execution of WebAssembly hasn't required speculative optimizations and deopts. One reason is that WebAssembly programs can already be optimized quite well because more information is statically available as e.g., functions, instructions, and variables are all statically typed. Another reason is that ## Giving V8 a Heads-Up: Faster JavaScript Startup with Explicit Compile Hints DevFeed: [Giving V8 a Heads-Up: Faster JavaScript Startup with Explicit Compile Hints]() Original publisher: [Read original article]() Author: Marja Hölttä Published: 2025-04-29T00:00:00Z Content type: article Language: en Sources: [V8]() Topics: [V8](), [JavaScript](), [Chrome](), [Web app](), [Web Development]() Tags: [chrome](), [javascript](), [main-thread](), [performance](), [speed](), [thread](), [web-app](), [web-developers]() ### AI overview The article explains how V8 chooses between eager and deferred JavaScript compilation and how Explicit Compile Hints can improve startup performance. It describes Chrome 136 support for selecting individual files for eager compilation, while warning that compiling too much can increase time and memory use. ### Source excerpt Getting JavaScript running fast is key for a responsive web app. Even with V8's advanced optimizations, parsing and compiling critical JavaScript during startup can still create performance bottlenecks. Knowing which JavaScript functions to compile during the initial script compilation can speed up web page loading. When processing a script loaded from the network, V8 has to choose for each function: either compile it immediately ("eagerly") or defer this process. If a function that hasn't been compiled is later called, V8 must then compile it on demand. If a JavaScript function ends up being called during page load, compiling it eagerly is beneficial, because: During the initial processing of the script, we need to do at least a lightweight parse to find the function end. In JavaScript, finding the function end requires parsing the full syntax (there are no shortcuts where we could count the curly braces - the grammar is too complex). Doing the lightweight parsing first and the actual parsing afterwards is duplicate work. If we decide to compile a function eagerly, the work happens on a background thread, and parts of it are interleaved with loading the script from the network. If we instead compile the function only when it's being called, it's too late to parallelize work, since the main thread cannot proceed until the function is compiled. You can read more about how V8 parses and compiles JavaScript in here. Many web pages would benefit from selecting the correct functions for eager compilation. For example, in our experiment with popular web pages, 17 out of 20 showed improvements, and the average foreground parse and compile times reduction was 630 ms. We're developing a feature, Explicit Compile Hints, which allows web developers to control which JavaScript files and functions are compiled eagerly. Chrome 136 is now shipping a version where you can select individual files for eager compilation. This version is particularly useful if you have a "core file" wh ## Land ahoy: leaving the Sea of Nodes DevFeed: [Land ahoy: leaving the Sea of Nodes]() Original publisher: [Read original article]() Author: Darius Mercadier Published: 2025-03-25T00:00:00Z Content type: article Language: en Sources: [V8]() Topics: [Compiler](), [V8](), [JavaScript](), [WebAssembly](), [Graphs]() Tags: [architectures](), [asm](), [blog-post](), [compiler](), [internals](), [javascript](), [performance](), [technical](), [webassembly]() ### AI overview This V8 developer article explains the project's move away from the Sea of Nodes intermediate representation toward the more traditional Control-Flow Graph representation used by Turboshaft. It describes the migration status across the JavaScript and WebAssembly compiler pipelines and introduces the historical limitations and technical debt associated with Crankshaft. ### Source excerpt V8's end-tier optimizing compiler, Turbofan, is famously one of the few large-scale production compilers to use Sea of Nodes (SoN). However, since almost 3 years ago, we've started to get rid of Sea of Nodes and fall back to a more traditional Control-Flow Graph (CFG) Intermediate Representation (IR), which we named Turboshaft. By now, the whole JavaScript backend of Turbofan uses Turboshaft instead, and WebAssembly uses Turboshaft throughout its whole pipeline. Two parts of Turbofan still use some Sea of Nodes: the builtin pipeline, which we're slowly replacing by Turboshaft, and the frontend of the JavaScript pipeline, which we're replacing by Maglev, another CFG-based IR. This blog post explains the reasons that led us to move away from Sea of Nodes. The birth of Turbofan and Sea of Nodes # 12 years ago, in 2013, V8 had a single optimizing compiler: Crankshaft. It was using a Control-Flow Graph based Intermediate Representation. The initial version of Crankshaft provided significant performance improvements despite still being quite limited in what it supported. Over the next few years, the team kept improving it to generate even faster code in ever more situations. However, technical debt was starting to stack up and a number of issues were arising with Crankshaft: It contained too much hand-written assembly code. Every time a new operator was added to the IR, its translation to assembly had to be manually written for the four architectures officially supported by V8 (x64, ia32, arm, arm64). It struggled with optimizing asm.js, which was back then seen as an important step towards high-performance JavaScript. It didn't allow introducing control flow in lowerings. Put otherwise, control flow was created at graph building time, and was then final. This was a major limitation, given that a common thing to do when writing compilers is to start with high-level operations, and then lower them to low-level operations, often by introducing additional control flow. Consi ## Turbocharging V8 with mutable heap numbers DevFeed: [Turbocharging V8 with mutable heap numbers]() Original publisher: [Read original article]() Author: Victor Gomes, the bit shifter Published: 2025-02-25T00:00:00Z Content type: article Language: en Sources: [V8]() Topics: [Code]() Tags: [benchmark](), [benchmarks](), [internals](), [javascript](), [optimization](), [performance](), [random]() ### AI overview This article explains a V8 optimization for mutable heap numbers that improves JavaScript performance in the JetStream2 async-fs benchmark by reducing allocation pressure and enabling faster integer arithmetic. ### Source excerpt At V8, we're constantly striving to improve JavaScript performance. As part of this effort, we recently revisited the JetStream2 benchmark suite to eliminate performance cliffs. This post details a specific optimization we made that yielded a significant 2.5x improvement in the async-fs benchmark, contributing to a noticeable boost in the overall score. The optimization was inspired by the benchmark, but such patterns do appear in real-world code. The target async-fs and a peculiar Math.random # The async-fs benchmark, as its name suggests, is a JavaScript file system implementation, focusing on asynchronous operations. However, a surprising performance bottleneck exists: the implementation of Math.random. It uses a custom, deterministic implementation of Math.random for consistent results across runs. The implementation is: let seed; Math.random = (function() { return function () { seed = ((seed + 0x7ed55d16) + (seed << 12)) & 0xffffffff; seed = ((seed ^ 0xc761c23c) ^ (seed >>> 19)) & 0xffffffff; seed = ((seed + 0x165667b1) + (seed << 5)) & 0xffffffff; seed = ((seed + 0xd3a2646c) ^ (seed << 9)) & 0xffffffff; seed = ((seed + 0xfd7046c5) + (seed << 3)) & 0xffffffff; seed = ((seed ^ 0xb55a4f09) ^ (seed >>> 16)) & 0xffffffff; return (seed & 0xfffffff) / 0x10000000; }; })(); The key variable here is seed. It's updated on every call to Math.random, generating the pseudo-random sequence. Crucially, here seed is stored in a ScriptContext. A ScriptContext serves as a storage location for values accessible within a particular script. Internally, this context is represented as an array of V8's tagged values. On the default V8 configuration for 64-bit systems, each of these tagged values occupies 32 bits. The least significant bit of each value acts as a tag. A 0 indicates a 31-bit Small Integer (SMI). The actual integer value is stored directly, left-shifted by one bit. A 1 indicates a compressed pointer to a heap object, where the compressed pointer value is incremented by o ## Introducing the WebAssembly JavaScript Promise Integration API DevFeed: [Introducing the WebAssembly JavaScript Promise Integration API]() Original publisher: [Read original article]() Author: Francis McCabe, Thibaud Michaud, Ilya Rezvov, Brendan Dahl Published: 2024-07-01T00:00:00Z Content type: tutorial Language: en Sources: [V8]() Topics: [WebAssembly](), [API](), [Promise](), [JavaScript](), [Web APIs](), [Programming]() Tags: [api](), [apis](), [code](), [javascript](), [web](), [web-apis](), [webassembly]() ### AI overview This article introduces the WebAssembly JavaScript Promise Integration (JSPI) API. JSPI enables WebAssembly applications designed around synchronous APIs to work with asynchronous JavaScript and Web APIs by suspending execution during asynchronous operations and resuming it when they complete. The approach requires few changes to the WebAssembly application and is illustrated with development guidance and examples. ### Source excerpt The JavaScript Promise Integration (JSPI) API allows WebAssembly applications that were written assuming synchronous access to external functionality to operate smoothly in an environment where the functionality is actually asynchronous. This note outlines what the core capabilities of the JSPI API are, how to access it, how to develop software for it and offers some examples to try out. What is 'JSPI' for? # Asynchronous APIs operate by separating the initiation of the operation from its resolution; with the latter coming some time after the first. Most importantly, the application continues execution after kicking off the operation; and is then notified when the operation completes. For example, using the fetch API, Web applications can access the contents associated with a URL; however, the fetch function does not directly return the results of the fetch; instead it returns a Promise object. The connection between the fetch response and the original request is reestablished by attaching a callback to that Promise object. The callback function can inspect the response and collect the data (if it is there of course). On the other hand, many cases C/C++ (and many other languages) applications are originally written against a synchronous API. For example, the Posix read function does not complete until the I/O operation is complete: the read function blocks until the read is complete. However, it is not permitted to block the browser's main thread; and many environments are not supportive of synchronous programming. The result is a mismatch between the desires of the application programmer for a simple to use API and the wider ecosystem that requires I/O to be crafted with asynchronous code. This is especially a problem for existing legacy applications that would be expensive to port. The JSPI is an API that bridges the gap between synchronous applications and asynchronous Web APIs. It works by intercepting Promise objects returned by asynchronous Web API functions a ## WebAssembly JSPI has a new API DevFeed: [WebAssembly JSPI has a new API]() Original publisher: [Read original article]() Author: Francis McCabe, Thibaud Michaud, Ilya Rezvov, Brendan Dahl Published: 2024-06-04T00:00:00Z Content type: release Language: en Sources: [V8]() Topics: [Web platform](), [web-standards](), [C++]() Tags: [api](), [c-plus-plus](), [integration](), [javascript](), [release](), [web-apis](), [webassembly]() ### AI overview WebAssembly JSPI has a new API in Chrome M126. The update removes explicit Suspender objects, replaces WebAssembly.Function-based wrappers with dedicated functions and constructors, and suspends calls only when a JavaScript function returns a Promise. ### Source excerpt WebAssembly's JavaScript Promise Integration (JSPI) API has a new API, available in Chrome release M126. We talk about what has changed, how to use it with Emscripten, and what is the roadmap for JSPI. JSPI is an API that allows WebAssembly applications that use sequential APIs to access Web APIs that are asynchronous. Many Web APIs are crafted in terms of JavaScript Promise objects: instead of immediately performing the requested operation, they return a Promise to do so. On the other hand, many applications compiled to WebAssembly come from the C/C++ universe, which is dominated by APIs that block the caller until they are completed. JSPI hooks into the Web architecture to allow a WebAssembly application to be suspended when the Promise is returned and resumed when the Promise is resolved. You can find out more about JSPI and how to use it in this blog post and in the specification. What is new? # The end of Suspender objects # In January 2024, the Stacks sub-group of the Wasm CG voted to amend the API for JSPI. Specifically, instead of an explicit Suspender object, we will use the JavaScript/WebAssembly boundary as the delimiter for determining what computations are suspended. The difference is fairly small but potentially significant: when a computation is to be suspended, it is the most recent call into a wrapped WebAssembly export that determines the 'cut point' for what is suspended. The implication of this is that a developer using JSPI has a little less control over that cut point. On the other hand, not having to explicitly manage Suspender objects makes the API significantly easier to use. No more WebAssembly.Function # Another change is to the style of the API. Instead of characterizing JSPI wrappers in terms of the WebAssembly.Function constructor, we provide specific functions and constructors. This has a number of benefits: It removes dependency on the Type Reflection Proposal. It makes tooling for JSPI simpler: the new API functions no longer need to ## The V8 Sandbox DevFeed: [The V8 Sandbox]() Original publisher: [Read original article]() Author: Samuel Groß Published: 2024-04-04T00:00:00Z Content type: article Language: en Sources: [V8]() Topics: [Vulnerabilities](), [C++](), [Processes]() Tags: [c-plus-plus](), [chrome](), [javascript](), [memory-safety](), [process](), [sandbox](), [security](), [vulnerabilities]() ### AI overview V8 Sandbox is presented as a lightweight in-process sandbox that has entered Chrome's Vulnerability Reward Program. The article explains how it contains memory corruption in V8 and why it is needed for V8's memory-safety challenges. ### Source excerpt After almost three years since the initial design document and hundreds of CLs in the meantime, the V8 Sandbox -- a lightweight, in-process sandbox for V8 -- has now progressed to the point where it is no longer considered an experimental security feature. Starting today, the V8 Sandbox is included in Chrome's Vulnerability Reward Program (VRP). While there are still a number of issues to resolve before it becomes a strong security boundary, the VRP inclusion is an important step in that direction. Chrome 123 could therefore be considered to be a sort of "beta" release for the sandbox. This blog post uses this opportunity to discuss the motivation behind the sandbox, show how it prevents memory corruption in V8 from spreading within the host process, and ultimately explain why it is a necessary step towards memory safety. Motivation # Memory safety remains a relevant problem: all Chrome exploits caught in the wild in the last three years (2021 - 2023) started out with a memory corruption vulnerability in a Chrome renderer process that was exploited for remote code execution (RCE). Of these, 60% were vulnerabilities in V8. However, there is a catch: V8 vulnerabilities are rarely "classic" memory corruption bugs (use-after-frees, out-of-bounds accesses, etc.) but instead subtle logic issues which can in turn be exploited to corrupt memory. As such, existing memory safety solutions are, for the most part, not applicable to V8. In particular, neither switching to a memory safe language, such as Rust, nor using current or future hardware memory safety features, such as memory tagging, can help with the security challenges faced by V8 today. To understand why, consider a highly simplified, hypothetical JavaScript engine vulnerability: the implementation of JSArray::fizzbuzz(), which replaces values in the array that are divisible by 3 with "fizz", divisible by 5 with "buzz", and divisible by both 3 and 5 with "fizzbuzz". Below is an implementation of that function in C++. J ## WebAssembly JSPI is going to origin trial DevFeed: [WebAssembly JSPI is going to origin trial]() Original publisher: [Read original article]() Author: Francis McCabe, Thibaud Michaud, Ilya Rezvov, Brendan Dahl Published: 2024-03-06T00:00:00Z Content type: tutorial Language: en Sources: [V8]() Topics: [WebAssembly](), [API](), [Chrome](), [Web APIs](), [Promise]() Tags: [api](), [chrome](), [garbage-collection](), [pre-release](), [web-apis](), [webassembly]() ### AI overview WebAssembly's JavaScript Promise Integration (JSPI) API is entering a Chrome M123 origin trial. It lets sequential code compiled to WebAssembly access asynchronous Web APIs by suspending a WebAssembly application when a Promise is returned and resuming it when the Promise resolves. The article explains the Emscripten requirement, origin-trial registration options, standardization status, and performance caveats related to spawned computations and garbage collection. ### Source excerpt WebAssembly's JavaScript Promise Integration (JSPI) API is entering an origin trial, with Chrome release M123. What that means is that you can test whether you and your users can benefit from this new API. JSPI is an API that allows so-called sequential code - that has been compiled to WebAssembly - to access Web APIs that are asynchronous. Many Web APIs are crafted in terms of JavaScript Promises: instead of immediately performing the requested operation they return a Promise to do so. When the action is finally performed, the browser's task runner invokes any callbacks with the Promise. JSPI hooks into this architecture to allow a WebAssembly application to be suspended when the Promise is returned and resumed when the Promise is resolved. You can find out more about JSPI and how to use it here and the specification itself is here. Requirements # Apart from registering for an origin trial, you will also need to generate the appropriate WebAssembly and JavaScript. If you are using Emscripten, then this is straightforward. You should ensure that you are using at least version 3.1.47. Registering for the origin trial # JSPI is still pre-release; it is going through a standardization process and will not be fully released until we get to phase 4 of that process. To use it today, you can set a flag in the Chrome browser; or, you can apply for an origin trial token that will allow your users to access it without having to set the flag themselves. To register you can go here, make sure to follow the registration signup process. To find out more about origin trials in general, this is a good starting place. Some potential caveats # There have been some discussions in the WebAssembly community about some aspects of the JSPI API. As a result, there are some changes indicated, which will take time to fully work their way through the system. We anticipate that these changes will be soft launched: we will share the changes as they become available, however, the existing API wi ## Static Roots: Objects with Compile-Time Constant Addresses DevFeed: [Static Roots: Objects with Compile-Time Constant Addresses]() Original publisher: [Read original article]() Author: Olivier Flückiger Published: 2024-02-05T00:00:00Z Content type: article Language: en Sources: [V8]() Topics: [V8](), [JavaScript](), [Chrome](), [JIT](), [C++]() Tags: [bootstrapping](), [c-plus-plus](), [chrome](), [javascript](), [jit](), [performance]() ### AI overview This article explains V8 static roots, which give frequently used immutable objects compile-time constant addresses in the read-only heap. It describes how V8 bootstraps that heap into a snapshot, uses pointer compression to place it predictably, and improves performance across the VM, especially for C++ code and built-in functions. ### Source excerpt Did you ever wonder where undefined, true, and other core JavaScript objects come from? These objects are the atoms of any user defined object and need to be there first. V8 calls them immovable immutable roots and they live in their own heap - the read-only heap. Since they are used constantly, quick access is crucial. And what could be quicker than correctly guessing their memory address at compile time? As an example, consider the extremely common IsUndefined API function. Instead of having to look up the address of the undefined object for reference, what if we could simply check if an object's pointer ends in, say, 0x61 to know if it is undefined. This is exactly what the V8's static roots feature achieves. This post explores the hurdles we had to take to get there. The feature landed in Chrome 111 and brought performance benefits across the whole VM, particularly speeding up C++ code and builtin functions. Bootstrapping the Read-Only Heap # Creating the read-only objects takes some time, so V8 creates them at compile time. To compile V8, first a minimal proto-V8 binary called mksnapshot is compiled. This one creates all the shared read-only objects as well as the native code of builtin functions and writes them into a snapshot. Then, the actual V8 binary is compiled and bundled with the snapshot. To start V8 the snapshot is loaded into memory and we can immediately start using its content. The following diagram shows the simplified build process for the standalone d8 binary. Once d8 is up and running all the read-only objects have their fixed place in memory and never move. When we JIT code, we can e.g., directly refer to undefined by its address. However, when building the snapshot and when compiling the C++ for libv8 the address is not known yet. It depends on two things unknown at build time. First, the binary layout of the read-only heap and second, where in the memory space that read-only heap is located. How to Predict Addresses? # V8 uses pointer compre