Chromium, Chrome, Node.js, V8, Crankshaft and bailout reasons
This post is a short summary about all these terms, with a rough description of how V8 works. (It's rather an overview of how Crankshaft works, really.)
Chromium, Chrome, Node.js
Crankshaft and bailouts
The three most important components of Crankshaft are:
- the runtime profiler, which tracks how much time is spent running which parts of code and identifies hot code, i.e. code worth spending time optimizing, and
- the optimizing compiler, which attempts to optimize the previously identified hot code.
When the optimizing compiler gets to work, it makes optimistic assumptions about the code it's optimizing, meaning that it assumes it's optimizable and does its best.
In some cases, the runtime data (e.g. type information) provided by the base compiler to the optimizing compiler didn't cover some (edge) cases and the optimizing compiler sends V8 back to run the base compiler compiled code. This is known as a deopt. Later on, the same hot code will be fed to the optimizing compiler again with more runtime data, and could eventually succeed its optimization attempts. If it fails more than 10 times, it will give up with the following bailout reason: "Optimized too many times"
try...catch statements) it doesn't support, or the code doesn't respect some limits set by the optimizing compiler. In this case, the optimizing compiler will also fall back to the base compiler compiled code. This is known as a bailout (because the optimizing compiler bails out on his optimization attempt), and whenever it happens Crankshaft is kind enough to give us a reason why the bailout happened.
This repo lists all these bailout reasons: V8 bailout reasons. The aim of this project is to provide insights by reproducing most of them, explaining why they happened and how to avoid them.