4

The major JavaScript engines of web browsers and nodeJS have had just-in-time compilers for years.

I was just watching a video on Compiler Explorer showing the assembly code output by many compilers for various CPUs.

This reminded me that I've been curious about the code generated by the JS engines' jits.

Do any of those engines have ways for us to see that low-level generated code?

(If this is out of place on SO please feel free to migrate it to the correct SE site.)

Mamun
  • 66,969
  • 9
  • 47
  • 59
hippietrail
  • 15,848
  • 18
  • 99
  • 158
  • 1
    The video you were watching was probably Matt Godbolt's talk at CppCon2017: [“What Has My Compiler Done for Me Lately? Unbolting the Compiler's Lid"](https://youtu.be/bSkpMdDe4g4). It's good :) – Peter Cordes Dec 29 '17 at 02:27

2 Answers2

5

For V8, there is a flag --print-opt-code, which prints generated optimized assembly code for each function that gets optimized. Note that functions only get optimized when they're "hot", not right away, so for a short "hello, world" style program the flag won't print anything. You can make functions "hot" by calling them a lot.

In older versions, there was a --print-code flag for unoptimized code, but since the baseline (non-optimizing) compiler has been replaced by an interpreter, there is no unoptimized code any more. You can print the generated bytecode with --print-bytecode.

If you're using Chrome, you can specify flags to be passed to V8 by wrapping them in --js-flags, e.g. --js-flags="--print-opt-code".

jmrk
  • 34,271
  • 7
  • 59
  • 74
  • 1
    [Turbolizer](https://github.com/v8/v8/tree/master/tools/turbolizer) may also be of interest (see also [this copy](https://github.com/thlorenz/turbolizer) which has a hosted version). – Timmmm Jan 27 '20 at 14:29
0

One thing you can always do is interrupt your program while it's running, using a debugger.

If it's spending most of its time in JIT-compiled code, then chances are the current instruction-pointer value (RIP) will be inside some JIT-compiled machine code, which your debugger will disassemble for you. (Or at least the part after the current RIP: x86 machine code uses variable-length instructions, so there's no reliable way to go backwards. You might single-step until you reach a backwards branch to get to the top of a loop.)

But without any way to figure out which function name you're seeing JITed asm for, this is probably not very useful unless you only have one hot loop (e.g. in an artificial test / microbenchmark).

Having the JIT engine print the asm as it generates it (@jmrk's answer) is much more usable; I only mention this technique because it works without any support from the JIT engine, so it can work on anything.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847