The nsXULAttribute class keeps a free-list of nsXULAttribute objects, since these are created and destroyed frequently. The free-list itself is never released.
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.
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.
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!)
Fix checked in.