Currently, JM code is discarded as soon as IM off thread compilation finishes. This poses a problem if execution is in the middle of a script with multiple loops, as it may be inside a different one from that which an OSR entry was compiled for. This causes execution to continue in the interpreter until the function entry or OSR PC is reached again. The attached patch improves this so that off thread compilation doesn't immediately discard JM code, but keeps it around until it is possible to enter the Ion code. This is done by patching the recompile checks for function entry and the OSR PC so that they trigger destruction of the calling code the next time they are reached. On my machine, this changes SS perf using off thread compilation from a 20ms regression to a 5ms improvement.

Also, with this patch kraken and v8bench show no change or a slight improvement vs. running without off thread compilation.

Comment on attachment 655122 [details] [diff] [review] patch Review of attachment 655122 [details] [diff] [review]: ----------------------------------------------------------------- ::: js/src/methodjit/Compiler.cpp @@ +4023,3 @@ > // Trigger ion compilation if (a) the script has been used enough times for > // this opcode, and (b) the script does not already have ion information > // (whether successful, failed, or in progress off thread compilation). We should update the comment to describe which checks are made and when/why the inline jump is patched to go to the stub. Or maybe just point readers to the comment in DisableScriptAtPC? ::: js/src/methodjit/MethodJIT.h @@ +911,5 @@ > > script->destroyMJITInfo(fop); > } > > +// Cripple any JIT code for the specified script, such that the nxt time Nit: "next"