On https://v8.dev/docs/ignition we can see that:
Ignition is a fast low-level register-based interpreter written using the backend of TurboFan
on https://docs.google.com/document/d/11T2CRex9hXxoJwbYqVQ32yIPMh0uouUZLdyrtmMoL44/edit?ts=56f27d9d#
The aim of the Ignition project is to build an interpreter for V8 which executes a low-level bytecode, thus enabling run-once or non-hot code to be stored more compactly in bytecode form.
The interpreter itself consists of a set of bytecode handler code snippets, each of which handles a specific bytecode and dispatches to the handler for the next bytecode. These bytecode handlers
To compile a function to bytecode, the JavaScript code is parsed to generate its AST (Abstract Syntax Tree). The BytecodeGenerator walks this AST and generates bytecode for each of the AST nodes as appropriate.
Once the graph for a bytecode handler is produced it is passed through a simplified version of Turbofan’s pipeline and assigned to the corresponding entry in the interpreter table.
So it seems that Ignition job is to take bytecode generated by BytecodeGenerator convert it to bytecode handlers and execute it through Turbofan
.
But here:
and here:
You can see that it is ignition that produces bytecode.
What is more, in this video https://youtu.be/p-iiEDtpy6I?t=722 Ignition is said to be a baseline compiler.
So what's it? A baseline compiler? A bytecode interpreter? An AST to bytecode transformer?
This image seems to be most appropriate:
where ignition is just an interpreter and everything before is no-name bytecode generator/optimizer thing.
V8 developer here.
On https://v8.dev/docs/ignition we can see that:
Ignition is a fast low-level register-based interpreter written using the backend of TurboFan
Yes, that sums it up. To add a little more detail:
Once the graph for a bytecode handler is produced it is passed through a simplified version of Turbofan’s pipeline and assigned to the corresponding entry in the interpreter table.
So it seems that Ignition job is to take bytecode generated by BytecodeGenerator convert it to bytecode handlers and execute it through Turbofan
This section of the design document talks about generating the Bytecode Handlers, which happens "ahead of time" (i.e. when V8 is compiled) using parts of Turbofan. At runtime, bytecode is not converted to handlers, it is "handled" (=run, executed, interpreted) by the existing fixed set of handlers, and Turbofan is not involved.
What is more, in this video https://youtu.be/p-iiEDtpy6I?t=722 Ignition is said to be a baseline compiler.
At that moment, the talk is referring to the general idea that all modern JavaScript engines have a "baseline compiler" (in a very general, conceptual sense -- I agree that the slide could have made that clearer). Note that the slide does not say anything about Ignition. The next slide says that Ignition fills that role in V8. So more accurate would be to say "Ignition takes the place of a baseline compiler" or "Ignition is a baseline execution engine". Or you could redefine your terms slightly and say "Ignition is a compiler that produces bytecode and then interprets it".
ignition is just an interpreter and everything before is no-name bytecode generator/optimizer thing
That slide shows the "Interpreter" box as part of the "Ignition Bytecode Pipeline". The Bytecode Generator/Optimizer are also part of Ignition.
As I mentioned in a comment, sadly some of the docs are out of date, including the one with your first graphic above. Full-codegen and Crankshaft are no longer used at all, it's purely parsing and Ignition + TurboFan. (you've removed the image from the outdated docs that sadly are still linked by some of the V8 docs)
Ignition is a high-speed bytecode interpreter.
V8's parser produces Ignition bytecode. That bytecode is executed (interpreted) by Ignition. Code that only runs once (startup code and such) or isn't run often stays at the bytecode level and continues to be executed by Ignition.
"Hot" code goes to the second phase, where TurboFan kicks in: TurboFan's input is the same bytecode that Ignition interprets (rather than source code, as it was with Crankshaft), which it then aggressively compiles to highly-optimized machine code that runs directly (rather than being interpreted).
This article goes into the motivations for moving off Full-codegen and Crankshaft (memory savings in the former case, difficulty implementing and in particular optimizing language features in the second). The design of TurboFan also helps the V8 authors minimize the amount of platform-specific code they have to write (by having an intermediate representation, which amongst other things they can also use to write Ignition's bytecode handlers).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With