The following code: for (var i=0; i<100; ++i) 'abcd'.replace('a', new Date); will record successfully (str_replace will js_Invoke, but since Date.toString is a fast native, it will not reenter the interpreter), but deep bail on trace (str_replace will js_LeaveTrace before js_Invoke). In fact, it will deep bail 100 times, with all the cost involved. If the above 'replace' was deeper in the trace, the cost for reconstructing interpreter frames every iteration it seems could easily dominate the total execution time. (Although this seems related, this will not be fixed by bug 517329) I propose we use some sort of eventual blacklisting, like we do with repeated failed recording attempts. I'm guessing there are key cases where we don't want to blacklist too eagerly, so perhaps we could come up with a good heuristic that prevents us from being overly pessimistic.
This is going to be pretty heuristic-y: deep bailing at the end of a long and very-profitable trace -- even if done "every time" -- might pay off too.
Obsolete with the removal of tracejit.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.