nsXULAttribute::gFreeList is leaked

RESOLVED FIXED in mozilla0.9.7

Status

()

Core
XUL
P3
normal
RESOLVED FIXED
18 years ago
10 years ago

People

(Reporter: Chris Waterson, Assigned: Chris Waterson)

Tracking

(Blocks: 1 bug, {footprint, helpwanted, mlk})

Trunk
mozilla0.9.7
x86
Windows NT
footprint, helpwanted, mlk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Assignee)

Description

18 years ago
The nsXULAttribute class keeps a free-list of nsXULAttribute objects, since
these are created and destroyed frequently. The free-list itself is never released.
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Keywords: mlk, nsbeta3
Target Milestone: --- → M18
(Assignee)

Comment 1

18 years ago
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

Comment 2

18 years ago
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.

Updated

18 years ago
Keywords: footprint

Updated

17 years ago
Blocks: 92580
(Assignee)

Updated

16 years ago
Blocks: 104400

Updated

16 years ago
No longer blocks: 92580
(Assignee)

Updated

16 years ago
Blocks: 109344
(Assignee)

Comment 3

16 years ago
Pulling back.
Target Milestone: Future → mozilla0.9.7
(Assignee)

Comment 4

16 years ago
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.)
(Assignee)

Updated

16 years ago
Keywords: patch
Why would this be a footprint gain?
(Assignee)

Comment 6

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

Comment 7

16 years ago
*** 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+
(Assignee)

Comment 9

16 years ago
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Updated

10 years ago
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.