The nsXULAttribute class keeps a free-list of nsXULAttribute objects, since these are created and destroyed frequently. The free-list itself is never released.
Status: NEW → ASSIGNED
Keywords: mlk, nsbeta3
Target Milestone: --- → M18
This is a big leak, but it's a one-time thing. jud: I'm marking this as Future, but we can pull it back if you think it's an issue for embedding.
Keywords: nsbeta3 → helpwanted
Target Milestone: M18 → Future
sounds a lot like the recycler problem rick isolated in the parser. The "leak" will be cleaned up on shutdown eventually, so the problem here is that we have this "cache" accumulating so much. I'm cc'ing dougt who's looking at memory pressure callbacks. this is probably a candidate.
Target Milestone: Future → mozilla0.9.7
Created attachment 57264 [details] [diff] [review] remove one-off allocator for nsXULAttribute objects This was relevant back in the day when we were trying to squeeze every last ounce of performance out of the XUL content model for the mailnews threadpane. Now, the footprint savings is probably far more important. (Plus, we're doing tons of stuff to get rid of attribute copies, so there ought to be fewer nsXULAttribute objects anyway.)
Why would this be a footprint gain?
Because we never shrink or reclaim the arenas from which nsXULAttribute objects are allocated. See bug 109344, e.g.
*** Bug 109344 has been marked as a duplicate of this bug. ***
Comment on attachment 57264 [details] [diff] [review] remove one-off allocator for nsXULAttribute objects r=shaver. (And a code-size win, to boot!)
Attachment #57264 - Flags: review+
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.