0

The reason I asked this question is that if I write a Javascript where there is no hot code in it (therefore it won't need to be optimized by TurboFan, aka short running script), so when I run this Javascript, I assume it will go through the following process:

js code (ignition)-> bytecode -> codeStubHandler(TurboFan IR) -> assembly code

And the assembly code generated for all the builtins declared in builtins-definition.h is in a file called embedded.S.

so every bytecode has a handler to generate assembly code for them directly? is my understanding right? At least this is what I saw when I was debugging through the script.

Please help me verify.

Zhe Li
  • 23
  • 4

1 Answers1

0

Ignition does not compile JavaScript to assembly. It is an interpreter after all. It creates bytecode, then interprets that bytecode (via bytecode handlers).

The bytecode handlers are a special class of what we call "built-ins". They are generated at V8 build time, and embedded into the binary. They do not generate assembly code at runtime.

Interpretation means that the bytecode handlers themselves are executed. It does not mean that any assembly code is produced at runtime.

Only optimized compilation (with Turbofan) creates Turbofan IR at runtime.

jmrk
  • 34,271
  • 7
  • 59
  • 74
  • Thanks for the clearification! so for executing short running script (no optimized compilation), the process should be js code (ignition)-> bytecode -> codeStubHandler(typecode handler) -> assembly code(generated at compile-time). One further question, when I use print-built-code to find out what has been called, there are other builtin types as well other than just bytecode handler type, is it because they are called from bytecode handler builtins? – Zhe Li Feb 24 '21 at 16:18
  • The process is: JS code -> bytecode -> interpretation. No assembly code is generated. `--print-builtin-code` doesn't tell you what was called, only what exists. Yes, the bytecode handlers can call other builtins. – jmrk Feb 24 '21 at 18:36