Closed
Bug 513326
Opened 15 years ago
Closed 12 years ago
Despecialize cached methods in branded scopes to avoid O(n^2) traps
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
People
(Reporter: brendan, Unassigned)
Details
See bug 367425 for a similar bug that dates back to the property tree, due to getters and setters bound in a constructor pattern to (unjoined, new on each ctor call) closure instances. (The getter and setter case cannot be despecialized -- we need the exact getter stored in the property, not just some slot value that varies per object. To fix this we'd need getters and setters stored in object slots instead of property meta-data. I still hope that the fix for bug 471214 combined with the recent closure optimizations will take the heat off, but we could end up needing to move getters and setters into slots at some point. Fodder for bug 367425, anyway.) For cached/JITted methods, despecializing is easy since there's a backing-store slot holding the same value that is memoized in the cache (or in the property tree once bug 471214 is fixed). But we need to do it, with some reasonable way to decide the threshold. The JIT's MAX_BRANCHES and the property tree's kids-chunk linear search complexity limits look relevant. Anyone cc'ed should feel free to steal this bug. /be
Reporter | ||
Comment 2•15 years ago
|
||
The patch for bug 536564 addressed this by analyzing two popular JS patterns, instead of counting proptree kids. /be
Reporter | ||
Comment 3•15 years ago
|
||
Throwing into general@js.bugs pool, this one is not a burning issue but fair game for anyone looking to improve SpiderMonkey to avoid overspecialization. /be
Assignee: brendan → general
Comment 4•12 years ago
|
||
Branding was removed.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•