45353 - nsXULAttribute::gFreeList is leaked

Status: RESOLVED FIXED

(Core :: XUL, defect, P3)

Description

[Chris Waterson]

The nsXULAttribute class keeps a free-list of nsXULAttribute objects, since
these are created and destroyed frequently. The free-list itself is never released.

Comment 1

[Chris Waterson]

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.

Comment 2

[Judson Valeski]

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.

Comment 3

[Chris Waterson]

Pulling back.

Comment 4

[Chris Waterson]

Attachment: 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.)

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Why would this be a footprint gain?

Comment 6

[Chris Waterson]

Because we never shrink or reclaim the arenas from which nsXULAttribute objects
are allocated. See bug 109344, e.g.

Comment 7

[Cathleen]

*** Bug 109344 has been marked as a duplicate of this bug. ***

Comment 8

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 57264 [details] [diff] [review]
remove one-off allocator for nsXULAttribute objects

r=shaver.  (And a code-size win, to boot!)

Comment 9

[Chris Waterson]

Fix checked in.