Actually, all of those cases will be compiled with Ion. The variables having values of different types only becomes an issue if the change happens after compilation.

Like, for example, if a function accepts an argument, and the first 100,000 times the function is called, the argument is an integer, and the 100,001th time, the function is called with a string, then it’ll lead to some minor slowdown as the function is recompiled.

Having arrays with values of different types doesn’t prevent ion compilation either.

In general, the best plan is to write clear, readable, well-designed javascript code. That’s the kind of code that both we and the other JS teams are going to be trying to optimize.

Cheers.

For example, I gather from the above if I were to initiate a variable as a boolean but later in the function assign a string to it that would bump the function out of the fast running compiled code, is that correct?

How about arrays, are they more likely to get compiled and stay that way if every element is of the same type?

How about objects being passed to functions as parameters, should they always have the same members or are only the members the function uses important?

This is the kind of guidance that would be useful to someone like myself who writes JavaScript scripts but doesn’t really understand what the interpreter does under the hood.

Thanks.

If you’re really curious, there’s some some ascii-art and long comments in BaselineIC.h in the sources

I admit I was thinking “inlined code” instead of “inline cache”, so I am sorry I was imagining Baseline as a crazy hybrid of TraceMonkey and Sun’s Hotspot VM. So, every JS operation or byte-code is implemented as an inline cache with stub functions, Baseline uses the stubs to quickly chain those ICs together in a freaky “function pointer linked list” or something, and then the whole chain is executed in sequence because the stubs are already filled in with the next needed IC. More or less it?

And that should mean that any dynamism is handled by modifying the chain (add/remove/swap ICs and stubs) or the individual “links” (e.g. your example with the CALL IC). This keeps Baseline from ever fully invalidating code, while limiting IC explosion, right?

Thanks for clarifying baseline’s relationship with type inference, and upon rereading both posts, I now realize that most of the savings comes from disabling JM and using a system that is smarter and more efficient about using the existing type inference system.

I never advocated getting rid of the interpreter, I just wondered if there was a way to keep it portable, readable and hackable, with slightly better performance than it has. Not turn it into something it isn’t.

And I’m sorry that I find all this really fascinating, and thank you all for your hard work!

The new status quo is
Cold = Interpreter (which will always be improved and shouldn’t go away)
Room Temperature to Hot = Baseline which can provide type info to prepare Ion, if needed
Boiling to the Sun = Ion + TI

I agree that some data on how “hot” popular website JS functions are, from the perspective of the JS engines would be really neat. I bet there’s already some kind of instrumentation in place to do this.

Odinmonkey is a separate compiler that reuses parts of Ion to statically compile a (restricted but mostly compatible) subset of JavaScript called “asm.js” into really fast, very type stable, machine code. I am hoping this compilation is off the main thread, already, lol. JS developers have to specifically ask for OdinMonkey by including a special directive in function declarations that is easily ignored by JS engines that don’t understand asm.js. So, everyone can opt-in to better performance, for certain types of code, without breaking the web.

Cold = Interpreter
Luke-Warm or Hot and Unstable = Baseline
Warm and Stable = Jaegar
Burning Hot and Stable = Ion

So, long-term is the plan to deprecate Jaegar? My hunch would be that type-stable code tends to be either cold/luke-warm or burning hot, and not so much warm.

Side note: Would be interesting, if someone made histograms of popular website JS heuristics.

We test heavily with the default settings, so there may be issues with different tunings that fuzzing and other testing didn’t pick up. If we were to make this a tunable setting, then it’s something that would have to be tested to the same extent that the default is, and that takes away precious testing resources from the default configuration.

Also, from the measurements that we’ve run, changing the constant here back and forth (even from 10 to 0) doesn’t really make a big difference except in pathological cases.

2. The main JS compiles once, but that’s because it uses ICs to implement almost every op. The fallback-stub (last stub that does the default slowpath) for each IC chain implements logic to add new IC stubs. This is pretty straightforward IC design. We make some design choices here to make the IC chains more introspectable.

3. We limit the size of caches. For some caches, we generalize stubs as the chain grows. For example, with Call IC chains, we start off attaching IC stubs which store the actual callee function that’s being invoked. However, if a lot of callees are being called at that site, then the callee-specific stubs are removed, and a generic call stub is added.

4. We don’t use the caches to store TI information. We interface with TI by calling the usual VM functions to update TI’s data structures. However, since this is a slow C++ call, we use an IC to record what types have already been added to a type-set, so that we can avoid calling the slowpath most of the time.

5. The less memory will come about less because of baseline specifically, and more because baseline allows us to disable Jaeger, and disabling Jaeger allows us to remove some of the memory-heavy structures that Jaeger needs.

The interpreter is great as a portable, flexible environment where the team can prototype and implement new features without having to worry about how it’ll be jitted or optimized. It allows the feature people to do their work without being bogged down by optimization details, and the JIT people can come in later and make those features run fast.

You Mozilla people are a bit too clever for me. At this point, it’s worth asking if there’s any way to improve the interpreter’s performance?