The bug show up in sunspider 3d-raytrace, but is likely to appear in many other benchmarks. The following spew is produced by executing a debug build with JMFLAGS=scripts,recompile IONFLAGS=scripts,inlining environment variables. [jaeger] Recompile recompiling script (file "./tests/sunspider-1.0/3d-raytrace.js") (line "160") (length "312") (usecount="10240") [jaeger] Recompile interpreter rejoin (file "./tests/sunspider-1.0/3d-raytrace.js") (line "160") (op js_this_str) (opline "161") [Scripts] Analyzing script ./tests/sunspider-1.0/3d-raytrace.js:160 (0x7f211530ddd8) (usecount=10240) (maxloopcount=0) [jaeger] Recompile recompiling script (file "./tests/sunspider-1.0/3d-raytrace.js") (line "244") (length "181") (usecount="4458") [jaeger] Recompile interpreter rejoin (file "./tests/sunspider-1.0/3d-raytrace.js") (line "244") (op "call") (opline "249") [jaeger] Recompile recompiling script (file "./tests/sunspider-1.0/3d-raytrace.js") (line "189") (length "871") (usecount="7694") [jaeger] Recompile interpreter rejoin (file "./tests/sunspider-1.0/3d-raytrace.js") (line "189") (op "call") (opline "193") The goal is to prevent such recompilation each time a sub-function got Ion-compiled. The reason why functions at line 244 and 189 are getting recompiled is loop invariant & bounds check which /somehow/ ensure that its arguments are not indirectly modified by checking if the current function is inlineable(*). When we generate a IonStub, we check that the current JM function is uninlineable. PS: (*) This might also have some weird interaction with the Native stubs too.

This patch should hopefully not have big side effects except removing a few JM compilations. I do not expect any noticeable kraken or v8 improvement, and I noticed a 1ms on sunspider over 196.7ms — 0.5ms from 3d-raytrace and 0.5ms from 3d-cube.

Comment on attachment 664600 [details] [diff] [review] Prevent JM recompilation when generating Ion stubs. https://hg.mozilla.org/integration/mozilla-inbound/rev/ec211607e914