Welcome to the “UC International Technology” public account, we will provide you with the client, server, algorithm, testing, data, front-end and other related high-quality technical articles, not limited to original and translation.

This month marks not only Chrome’s 10th anniversary, but also V8’s 10th anniversary as open source. This article provides an overview of V8’s major milestones in the secret phase and 10 years since open source.

V8 before open source

When Google hired Lars Bak to build a new JavaScript engine for Chrome in the fall of 2006, it was still a secret Google project. Later, Lars wanted to stay in Denmark and moved back to Aarhus, Denmark, from Silicon Valley. But there was no Google office, and Lars and the project’s first engineers began working on his farm. The new JavaScript engine has been named “V8,” a metaphor for the powerful engine in a muscle car. As the V8 team grew and the developers moved from their farms to modern office buildings in Aarhus, the team focused on building the fastest JavaScript engine on the planet with their own drive.

V8 is open source and continuously improving

On September 2, 2008, Chrome was released and V8 became open source. The original submission date dates back to June 30, 2008. Prior to that, V8 was developed in a private CVS repository. Initially, V8 supported only ia32 and ARM instruction sets, and used SCons as its build system.

In 2009, a new regular expression engine named Irregexp was launched to improve the performance of regular expressions in practice. With the introduction of X64, the number of instruction sets supported increased from two to three. In 2009, the first version of the V8-based Node.js project was released. From the idea of embedding V8 in non-browser projects in the original Chrome, to Node.js, it did! Node.js is now one of the most popular JavaScript ecosystems.

In 2010, V8 introduced a new optimized JIT compiler that significantly improved runtime performance. Crankshaft generated machine code that was twice as fast and 30% smaller than the previous (unnamed) V8 compiler. That same year, V8 added a fourth instruction set: 32-bit MIPS.

Recycling improved dramatically in 2011. The new incremental garbage collector significantly reduces pause times while maintaining excellent peak performance and low levels of memory utilization. V8 paves the way for lightweight Web Workers in Chrome by introducing the concept of quarantine, which allows embeders to launch multiple runtime instances of V8 in a single process. When we switched from SCons to GYP, we migrated the two build systems of V8 for the first time, implementing ES5 strict mode support. At the same time, development work was moved from Aarhus to Munich (Germany), with a lot of cross-team communication with the original Aarhus team under the new leadership.

2012 was a benchmark year for the V8 program. Measured with the Sunspider and Kraken benchmark suites, the team optimised V8 performance through speed sprints. Later, we developed a new benchmark suite called Octane (with V8 Bench at its heart) that brought the highest performance competition to the forefront and facilitated significant improvements in runtime and JIT technology across all major JS engines. One result of these efforts was a switch from random sampling to deterministic count-based techniques when detecting “hot” functions in the V8 runtime analyzer. This reduces the fact that some pages load (or benchmark runs) randomly load much slower than others.

2013 saw a subset of JavaScript called ASm.js. Because ASM.js is limited to statically typed operations, function calls, and heap access with only primitive types, proven ASM.js code can run with predictable performance. We have released a new version of Octane (Octane 2.0) that includes updates to existing benchmarks as well as new benchmarks for use cases like ASM.js. Octane has facilitated the development of new compiler optimizations, such as allocation folding and allocation site-based optimizations, for type conversions and reservations, greatly improving peak performance. As part of this effort, which we call “Handlepocalypse” internally, the V8 Handle API has been completely rewritten to make it easier to use correctly and safely. Also in 2013, Chrome’s Implementation of TypedArrays in JavaScript was moved from Blink to V8.

In 2014, V8 removed some jIT-compiled work from the main thread with concurrent compilation, reducing latency and significantly improving performance. Later that year, we released an initial version of our new optimized compiler for TurboFan. At the same time, our partners ported V8 to three new instruction set architectures: PPC, MIPS64, and ARM64. Following Chromium, V8 moved to another build system, GN. The V8 test infrastructure has been significantly improved and you can now use Tryserver to test every patch on a variety of build machines prior to build. For source control, V8 was migrated from SVN to Git.

2015 was a year of V8 attacks on multiple fronts. We implemented code caching and script flow, greatly speeding up web page load times. The system uses the work of allocating areas during the ISMM 2015 release runtime. Later, we started work on a new interpreter called Ignition. We experimented with the idea of subsets of JavaScript using strong patterns to achieve stronger guarantees and more predictable performance. We re-marked to implement the enhanced pattern, but later found that the benefit was less than the cost. Adding a commit queue greatly improves productivity and stability. V8’s garbage collector has also started working with embedders like Blink to schedule garbage collection during idle periods. Idle garbage collection significantly reduces displayed garbage collection lag and memory consumption. In December, the first WebAssembly prototype was introduced in V8.

In 2016, we released the latest ES2015 (formerly known as “ES6”) feature set (promises, Class Syntax, lexical scoping, deconstruction, etc.), as well as a few ES2016 features. We’re also starting to roll out the new Ignition and TurboFan pipes, which we use to compile and optimize ES2015 and ES2016 features, and send Ignition by default for low-end Android devices. At PLDI 2016, we demonstrated our success with idle garbage collection. We started the Orinoco project, a new primary parallel and concurrent garbage collector for V8 to reduce mainline garbage collection time. We shifted our focus from synthesizing microdatums to measuring and optimizing actual performance. The V8 inspector has been migrated from Chromium to V8 for debugging purposes, allowing any V8 embed (not just Chromium) to use Chrome DevTools to debug JavaScript running in V8. WebAssembly moves from prototype to experimental support, coordinating experimental support for WebAssembly with other browser vendors. V8 won the ACM SIGPLAN Programming language Software Award. And added another platform: S390.

In 2017, we finally completed a major engine overhaul, enabling the new Ignition and TurboFanpipeline by default. This enabled the later removal of crankshafts (130,380 lines of deleted code) and full-codeGen from the code base. We introduced Orinoco V1.0, including concurrent tagging, concurrent scanning, parallel cleanup and parallel compression. We officially consider Node.js the premier V8 embed for Chromium. Since then, V8 patches cannot be released if they do not pass the Node.js test suite. Our infrastructure has support for proper fuzziness testing to ensure that any code produces consistent results regardless of the configuration it is running on.

V8 supports WebAssembly by default in coordinated releases across the industry. We implemented support for JavaScript modules and the full ES2017 and ES2018 feature set (including asynchronous functions, shared memory, asynchronous iterations, REST/Spread properties, and RegExp functionality). We provided native support for JavaScript code coverage, and launched Web Tooling Benchmark to help us measure the impact of V8 optimizations on the performance of actual development tools and the resulting JavaScript. The wrapper traces from JavaScript objects to C++ DOM objects and returns allow us to solve Chrome’s long-standing memory leak problem and effectively handle closure passing of objects on JavaScript and Blink heap. We later used this infrastructure to augment the capabilities of the heap snapshot developer tools.

In 2018, an industry-wide security incident upended what we thought we knew about CPU information security and publicly disclosed the Spectre/Meltdown vulnerability. V8 engineers have conducted extensive aggression research to help understand the threat of managed languages and develop mitigation measures. V8 provides mitigation against Specter and similar side-channel attacks against embedders running untrusted code.

Recently, we released a baseline compiler for WebAssembly called Liftoff, which significantly reduces the startup time of WebAssembly applications while still achieving predictable performance. We released BigInt, a new JavaScript primitive that can implement integers with arbitrary precision. We implemented embedded built-in functions and were able to delay deserialize them, significantly reducing the footprint of V8’s multiple quarantined areas. We can compile script bytecode on a background thread. We started the Unified V8-Blink Heap project to run cross-component V8 and Blink garbage collection synchronously. And this year is not over……

Performance ups and downs of V8

Chrome’s V8 Bench scores over the years show the impact of V8 changes on performance. (We’re using V8 Bench because it’s one of the few benchmarks that can run in the initial Chrome beta.)

Chrome V8 Bench scores from 2008 to 2018

Our score on this benchmark has increased fourfold in the last decade!

However, you may have noticed two performance degradations over the years. Both are interesting because they correspond to major events in V8’s history. The performance degradation in 2015 occurred when V8 released the ES2015 base features. These functions are cross-cutting in the V8 code base, so we focus on correctness rather than performance in the initial release. We accepted these small speed regressions to get new features to developers as quickly as possible. In early 2018, the ghost bug appeared and V8 issued mitigations to protect users from potential attacks, causing performance to degrade again. Fortunately, now that Chrome is releasing site quarantine, we can disable mitigation again to restore performance.

The other chart is that it started to level off around 2013. Does this mean V8 will give up and stop investing in performance optimization? Quite the opposite! The flattening of the chart represents the V8 team’s shift in focus from synthesizing microbenchmarks such as V8 Bench and Octane to optimizing actual performance. V8 Bench is an old benchmark that does not use any modern JavaScript features and is not close to actual production code. Compare to recent Speedometer benchmark suites:

 

Chrome Speedometer 1 scores from 2013 to 2018

While V8 Bench improvements were minimal between 2013 and 2018, our Speedometer 1 score (another) increased by a factor of four over the same period. (We used Speedometer 1 because Speedometer 2 uses modern JavaScript features not yet supported in 2013.)

Today, we have better benchmarks that more accurately reflect modern JavaScript applications, and most importantly, we proactively measure and optimize existing Web applications.

conclusion

Although V8 was originally built for Chrome, it has always been a stand-alone project, with a separate code base and an embedded API that allows any program to execute services using its JavaScript. Over the past decade, the project’s openness has made it a key technology not only for the Web platform, but also in other environments such as Node.js. In the process, the project continued to evolve despite many changes and significant growth.

Initially, V8 supported only two instruction systems. In the last 10 years, eight platforms have been supported: IA32, X64, ARM, ARM64,32 and 64-bit MIPS, 64-bit PPC and S390. V8’s build system was migrated from SCons to GYP to GN. The project moved from Denmark to Germany and now has engineers worldwide, including in London, Mountain View and San Francisco, as well as outside Google contributors from elsewhere. We converted the entire JavaScript compilation pipeline from unnamed components to full-CodeGen (baseline compiler) and Crankshaft (feedback-driven optimized compiler) to Ignition (an interpreter) and TurboFan (a better feedback-driven optimized compiler). V8 went from being just a JavaScript engine to also supporting WebAssembly. The JavaScript language itself evolved from ECMAScript 3 to ES2018; The latest V8 can even implement features beyond ES2018.

The story of the Web is a long and enduring one. Celebrating Chrome and V8’s 10th birthday is a good opportunity to reflect that while this is an important milestone, the story of the Web platform has been going on for more than 25 years. No doubt the Web story will continue for at least a long time. We are committed to ensuring that V8, JavaScript and WebAssembly continue to be interesting characters in stories. We’re very excited to know what’s going to happen in the next decade? Stay tuned!

英文原文 :

https://v8project.blogspot.com/2018/09/10-years.html

UC International Technology is committed to sharing high quality technical articles with you

Please follow our official account and share this article with your friends