12% slower with -j: for (i = 0; i < 500000; ++i) { typeof nosuchvar; } TRACEMONKEY=verbose says: abort: 4991: failed to find property Abort recording (line 1, pc 11): JSOP_NAME. I believe that using "typeof" to test for the existence of a variable is fairly common, so this is likely to affect real-world scripts.

Not fixed yet and JM is barely faster than interpreter here: v8: 13 ms -m: 183 ms interp: 188 ms -j: 222 ms

This affects peacekeeper. The ripple tests use typeof and if I switch it out with an equivalent limit check (and comment out the canvas render function), it almost doubles the speed (27 fps to 51 fps). Their typeof code is: if (typeof(this.data[x]) != "undefined" && typeof(this.data[x][y]) != "undefined") This is on Windows XP

Comment 2 sounds like a different bug.

Current JS shell numbers: Interp: 194.542 ms -j: 221.246 ms -m: 177.820 ms -m -n: 190.815 ms Looks like this is still an issue in the JM+TI world.

Also, d8 runs this in 18ms.

Current JS shell numbers: Interp: 174 ms Baseline: 86 ms IM: 94 ms d8: 3 ms So we're finally faster with our jit than without. Yay, I guess. Except our optimizing jit is slower than our baseline jit. Oh, and more than 30x slower than v8. Boo, I guess.

FWIW, IONFLAGS=aborts complains about "Unsupported opcode: popv", which prevents Ion compilation.

Jandem, you worked on making other uses of typeof fast (e.g. bug 606648). Do you think there's something useful we can do here? The numbers haven't really changed much: 77ms vs. 4ms in v8.

So from the pov of the JIT, we're just doing a GetNameCache. A profiler says that js::jit::NameIC::update is taking almost all the time, most of it calling js::LookupName. Looks like NameIC just has no missing-property version; there's a IsCacheableNameReadSlot and a IsCacheableNameCallGetter but nothing like the IsCacheableNoProperty case we have for getprop.

(In reply to Boris Zbarsky [:bz] from comment #9) > A profiler says that js::jit::NameIC::update is taking almost all the time, > most of it calling js::LookupName. Looks like NameIC just has no > missing-property version; there's a IsCacheableNameReadSlot and a > IsCacheableNameCallGetter but nothing like the IsCacheableNoProperty case we > have for getprop. Yup that would help. If cache.isTypeOf(), attach a stub that guards on the shapes on the scope chain and then returns undefined.

Comment on attachment 8698645 [details] [diff] [review] Part 2 - TrackedOptimizations update for new IC type. Review of attachment 8698645 [details] [diff] [review]: ----------------------------------------------------------------- Thank you.

Comment on attachment 8698643 [details] [diff] [review] Part 1 - Implement TypeOfNoSuchVar Ion IC. Review of attachment 8698643 [details] [diff] [review]: ----------------------------------------------------------------- Sorry for the delay. Great patch, thanks for fixing this old bug!

https://hg.mozilla.org/integration/mozilla-inbound/rev/989883d9a10a https://hg.mozilla.org/integration/mozilla-inbound/rev/8554cdd93607

https://hg.mozilla.org/mozilla-central/rev/989883d9a10a https://hg.mozilla.org/mozilla-central/rev/8554cdd93607