a0viedo / demystifying-js-engines

A list of resources about JavaScript engines

This is a list of resources I used to learn about virtual machines in general, from an architecture point of view to optimizations and garbage collection strategies. I've also put together some parts into a talk format, you can see the video here (slides).

Contributions are very welcome!

Table of Contents generated with DocToc

• Virtual machines
  • JavaScript Engines
    • V8
    • JavaScriptCore
    • ChakraCore
    • SpiderMonkey
    • Benchmarks
  • Inline caches
  • Garbage collection

Emoji	Represents
📊	Blog post
📄	White paper
💻	Code
🎤	Podcast
🎥	Slides
📝	Documentation

Virtual machines

• 🎥 Dynamic Compilation and Adaptive Optimization in Virtual Machines - Stephen Fink, David Grove, and Michael Hind
• 📄 On-stack replacement - Soman and Krintz
• 📄 Optimizing Dynamically-Typed Object-Oriented Languages With Polymorphic Inline Caches - Hölzle, Chambers and Ungar
• 📄 Adaptive optimization for self: reconciling high performance with exploratory programming - Hölzle
• 📄 A Survey of Adaptive Optimization in Virtual Machines - Arnold, Fink, Grove, Hind and Sweeney
• 📄 A Simple Graph-Based Intermediate Representation - Click
• 📄 Combining Analyses, Combining Optimizations - Click
• 📄 A Brief History of Just-In-Time - Aycock

JavaScript Engines

V8

• 📊 A tour of V8 garbage collection - Jay Conrod
• V8 perf - Thorsten Lorenz
• 🎥 TurboFan JIT Design - Ben L. Titzer
• 📊 Sea of Nodes - Fedor Indutny
• 📊 Digging into TurboFan JIT - V8's blog
• 📊 Jank Busters Part One - V8's blog
• 📊 JavaScript and V8’s TurboFan - Ariya Hidayat
• 📄 Instrumenting V8 to Measure the Efficacy of Dynamic Optimizations on Production Code - Maass and Shafer
• 📊 V8 resources - Vyacheslav Egorov
• 📊 V8: Behind the Scenes (November Edition) - Benedikt Meurer
• 📊 The story of a V8 performance cliff in React - Benedikt Meurer and Mathias Bynens

JavaScriptCore

• 📊 Introducing FTL JIT - Webkit blog
• 📊 Introducing B3 JIT compiler - Webkit blog
• 📝 Bare Bones Backend - Webkit Documentation
• 📝 B3 Assembly IR - Webkit Documentation
• 📝 B3 IR - Webkit Documentation
• 📝 FTL JIT - Webkit Documentation
• 📊 Inside javascriptcore's low-level interpreter - Andy Wingo's blog

ChakraCore

• 💻 List of performance hint descriptions - ChakraCore's repository
• 🎤 Chakra, Microsoft's Open Source JavaScript Engine - JavaScriptAir
• 📝 ChakraCore Architecture overview - ChakraCore's wiki

SpiderMonkey

• 📊 Compacting Garbage Collection in SpiderMonkey - Mozilla Hacks
• 📊 SpiderMonkey Internals - MDN
• 📊 IonMonkey: Evil on your behalf - Mozilla's JavaScript blog
• 📊 IonMonkey: Optimizing Away - Mozilla's JavaScript blog
• 📊 The Unofficial Incomplete Spidermonkey Bibliography - Matthew Gaudet

Benchmarks

• Introducing the JetStream Benchmark Suite
• Sunspider
• Octane
• Kraken
• Dromaeo
• AreWeFastYet?
• Web Tooling Benchmark

Inline caches

• 📊 PICing on JavaScript for fun and profit - Chris Leary

Garbage collection

• 📄 On-the-fly Garbage Collection: An Exercise in Cooperation - Dijkstra, Lamport, Martin, Scholten, and Steffens
• 📊 Back to basic: Series on dynamic memory management - MSDN
• Memory Management Reference
• 📄 A non-recursive list compacting algorithm - Cheney
• 📄 Generation Scavenging - Ungar
• 📄 Reconciling Responsiveness with Performance in Pure Object-Oriented Languages - Hölzle and Ungar
• 📄 Garbage Collection in an Uncooperative Environment - Boehm
• 📄 Garbage Collection with Ambiguous Roots - Bartlett
• 📄 Quantifying the Performance of Garbage Collection vs. Explicit Memory Management - Hertz and Berger
• 📄 'Infant Mortality' and Generational Garbage Collection - Baker
• 📄 Fast Conservative Garbage Collection - Shahriyar, Blackburn and McKinley

Exploitation

• 📊 Introduction to SpiderMonkey exploitation - Axel "0vercl0k" Souchet
• 📊 Attacking JavaScript Engines: A case study of JavaScriptCore and CVE-2016-4622 - Samuel Groß
• 📊 Weaponization of a JavaScriptCore Vulnerability - RET2's blog
• 📊 Don't Follow The Masses: Bug Hunting in JavaScript Engines - Dimitri Fourny and Moritz Jodeit
• 📊 A journey into IonMonkey: root-causing CVE-2019-9810 - Axel "0vercl0k" Souchet
• 📊 Introduction to TurboFan -Jeremy Fetiveau

demystifying-js-engines's Issues

Add more info about SpiderMonkey

They've changed JITs a few times now...why? TracingJITs are not a thing anymore?

[V8] Why I+TF?

Disclaimer: This are my assumptions and I'm not based in any direct information from the team behind V8.

Why I think they made the switch to Ignition + TurboFan

In the old days, when Lars Bak was still the Team Lead on V8's team he mentioned that it was to favor simplicity to use source code as an intermediate representation (minute 38) and directly compile to native code as the first step in the pipeline. At that time it made a lot of sense and was V8's way to execute source code for many years.
I believe that the efforts that started back then with pretty much all JavaScript engines was, and for some it might still be, to compete in terms of performance with the most advanced compilers of all time. And I think for a big part they succeeded: type-specializing JIT compilers were a huge advance on JavaScript performance. For many years the most complex JavaScript engines engaged on a race for writing the best complementing JIT compilers, that's were AWFY appeared and showed that the difference between all of them was a little bit more subtle.

Fast-forward a couple of years mobile devices sums up to a few billions, making some big companies (Google among them) to think in terms of mobile first. That's what Ignition was designed to do, to play an important role in memory-constrained devices (the average mobile device). At the same time, they were re-thinking the ways on how to measure if a JavaScript engine is faster or precisely better. Suddenly it made much more sense to measure how the web is being used, to inspect and decipher how the most popular websites are built, and the premise was if you optimize for that, you would be optimizing for most common use cases.

These last moves are not necessarily a setback for C-like performance code running on a JavaScript engine because of the evolution from ASM.js to WebAssembly. Now all the browsers can share the common goal of optimizing a statically typed language, something that could be fun to watch.

---

Some resources to read:

• Retiring Octane
• Ignition Design Doc
• Why we Need WebAssembly

[V8] About TurboFan

Acording to AWFY, V8 without Crankshaft it's not getting any closer in terms of performance. Are they planning to move all the optimizations or they act as complementary optimizing compilers?

[JSC] Add more info

There're a few links only