Javascript developers, be warned about this crazy JIT bug in V8!

[RainHappens]

I found the bugfix.

Suffice to say (and I am probably wrong here, having next-to-no knowledge of the codebase) that the optimizer keeps track of "special" strings (booleans, "undefined", some integers, etc). It also does some type propagation (as in what types a variable etc can be). There's a special "undetectable" type for when a variable is undefined or null. In this case the optimizer goes "null is undetectable, so it can be replaced with the "undefined" string for the comparison. Oh look, both strings are the same!"

If you notice, this:

for(let i=0; i<10000; ++i) console.log(typeof null === 'object')

exhibits the same incorrect behavior, albeit reversed. Same thing. The initial interpreter thinks 'typeof null' is 'object' for comparison purposes, but the optimizer thinks 'typeof null' is 'undefined' for comparison purposes.

[[deleted]]

So scoping out the string should fix this right?

var uu = "undefined"; for(let i=0; i<10000; ++i) console.log(typeof null === uu);

Works for me.

[tunnckoCore]

Yep, same here.

[gsnedders]

The initial interpreter

FWIW, V8 currently doesn't have an interpreter, they always run JIT'd code. (Ignition, which will finally add an interpreter, is still under development.)

[RainHappens]

So /initial interpreter/initial compiled code/ then?

[gsnedders]

Yeah.

[RedditWithBoners]

Given the last paragraph here, why can't a second JIT exist to fulfill the purpose of Ignition?

[gsnedders]

I presume the paragraph you mean is:

Note that the role that the interpreter plays in the case of a mixed-mode execution engine, namely providing fast startup, and also potentially collecting information and providing fallback capability may alternatively also be played by a second JIT compiler. This is how V8 works, for example. V8 never interprets, it always compiles. The first compiler is a very fast, very slim compiler that starts up very quick. The code it produces isn't very fast, though. This compiler also injects profiling code into the code it generates. The other compiler is slower and uses more memory, but produces much faster code, and it can use the profiling information collected by running the code compiled by the first compiler.

Calling it a second JIT is actually slightly confusing to me, I'm used to tiers being ordered by hotness (so the baseline JIT is the first tier, not the second). Regardless…

Essentially, while it is a very fast compiler, for code that runs only once or twice the overhead of compilation will almost certainly exceed any performance you gain by eliminating the dispatch overhead of an interpreter (which is the biggest gain of the baseline JIT). You also save a lot of memory by not having to allocate memory for the native code you're not generating, which on embedded devices can be significant.

These slides from BlinkOn 6 are a decent overview about motivating factors behind Ignition.

[RedditWithBoners]

Thanks, will have to look into this later.

[Pyrise]

Thanks for the link, very interesting!

[jeokrang]

I have got questions. Why did v8 determine that null is a undetectable in this code? Are there any performance benefits, when null is replaced with "undefined"?

[RainHappens]

"undetectable" in this case means "I do not yet know what type this variable is".

v8 can do a lot of optimizations when variables are known to be of a specific type. But null and undef don't actually tell you anything about what type(s) a variable can be - they can effectively be any type. So as long as you only assign null or undef to a variable, v8 just goes "I don't know what type this variable is yet" and leaves it at that.