Closed
Bug 518441
Opened 15 years ago
Closed 13 years ago
perhaps repeated deep bailing should eventually blacklist
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: luke, Unassigned)
Details
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.
Comment 1•15 years ago
|
||
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.
Comment 2•13 years ago
|
||
Obsolete with the removal of tracejit.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•