Closed Bug 576726 Opened 10 years ago Closed 8 years ago consumes lots of layout memory


(Core :: Layout, defect)

Not set



Tracking Status
blocking2.0 --- -


(Reporter: vlad, Unassigned)




(1 file)

I've been playing around with, which is a browser-based game.  It doesn't use canvas or anything, instead does everything with straight html and css.  When I have a city view open with some number of buildings, (say ~40 or so), about:memory reports a lot of "layout/all" memory, which is the size of the presshell arenas.  Typically, closing that tab causes that number to drop by 200+MB.  Would be good to understand why we're chewing up so much memory here.
Can we try breaking that info up by size class or something?  That might give us some idea of what sort of objects we're talking about here.
Sure, though I'm not sure how -- I think it'd be better to try something like massif or sewardj's work at this point
With trace-malloc and diffbloatdump it's pretty straightforward to build a tree of allocation stacks accounting for a difference.  I'll give it a try.
Sure.  The more we can learn about the actual callers of AllocateFromShell here, the better.
Hmmm.  It seems to both want a login and say I'm using too old a version of Firefox; that's more than I want to deal with right now.  (Maybe in the morning.)
The latter part you can ignore; the former you can just create a free EA account.  I can also just send you my account info as well, if you ping me on irc tomorrow.
So it turns out trace-malloc is semi-broken on Linux right now (bug 576776) -- I'll try rerunning in a bit with it unbroken.  (I did manage to reproduce the large memory usage, although I'm not sure whether it required advancing sufficiently in the game or playing it for a little while.)

But even with it broken, it's clear that we're accumulating huge amounts of style data and rule nodes.  (What's less clear is whether we're also accumulating huge numbers of frames.  That's why I'd like to rerun.)
It seems like getting the really large numbers requires playing for a while.  However, after just a little bit, it seems like I can in fact get to large numbers of content nodes, frames, and style contexts (e.g., 225K of div elements, 305K of block frames, 130K of placeholder frames, 82K of scroll frames, 300K of nsStyleDisplay, 211K of nsStyleContext, 177K of nsResetStyleData, 170K of nsRuleNode, 115K of nsStylePosition).  Probably worth seeing how that changes over time while playing the game.
This tree shows the differences in allocations between just having loaded the game and having played it for a while (mostly building buildings).  (The total increase in malloc heap in that time was 168 MB.)

I'm not sure what's up with that display list.
Some thoughts:

 * I'm not sure what's up with the display list

 * the increase in style structs seems to outpace the increase in frames -- I could imagine that happening if they're doing something like continually appending new style rules to a style sheet, all of which match the same element, but each of which wins for only a short time until overridden by the one after it.  However, that explanation doesn't fit with there being 4.2 megs of allocation from PL_DHashTableOperate within nsRuleNode::Transition, since that implies one rule node with a very large number of children -- but I don't see how that happens without an equivalent increase in the number of elements and frames.
Also, the 27 megs of nsCSSCompressedDataBlock shows that most of the style rules seem to be related to the 'background-position' property (since the top call stack, by far -- 24 megs of it -- goes through nsIDOMCSS2Properties_SetBackgroundPosition).
Just realized I could look at what type of style rules were being created -- there were 278K of NS_NewCSSStyleRule allocations and 164K of nsCSSDeclarations allocated in CSSParserImpl::ParseDeclarationBlock, entirely created from ParseStyleAttribute (on various types of HTML elements).

I don't understand why these numbers are so much smaller than the numbers of data blocks.
Is this the same problem as Bug 573235? Also is it still being worked on? Because Minefield is leaking a ton of memory and at the end of it when there is no memory left it just crashes. And it's no fun having Minefield crash several times a day because you missed the moment where you had to reload.
David, are the numbers in comment 12 the number of allocations, or the allocated memory?  If the latter, could it be that the page is mutating rules, causing us to allocate data blocks over and over again?  Or is this only measuring steady-state?
blocking2.0: --- → ?
They're the allocated memory at a particular time.

The calltree deltas are computed by:
 * storing allocation stacks along with all allocations (what trace-malloc does)
 * dumping the allocation stacks for all live allocations after starting the game
 * playing for a bit
 * dumping the allocation stacks again
 * building a tree of the two dumps (much like a refcount balance tree, but rooted at malloc instead of main), using size of allocations (but times -1 for the first dump so as to show only the difference between the two)
Hmm.  Is it possible that the data blocks just have a lot of stuff in them, hence take up a lot of memory?
Could this bug please block the final Gecko 2.0? It might be a special case but it is a rather serious issue and with Firefox 3.6.x not showing this behaviour we might be seeing a lot of complaining after Fx 4.0 is released.
In recent nightlies, lordofultima doesn't work at all, reporting an "unexpected script error", fwiw.
According to that's because we disabled remote XUL.
(In reply to comment #19)
> According to
> that's because we disabled remote XUL.

Seems to be working fine now...  But I have trouble reproducing the memory usage issue.
Minusing until someone can reproduce
blocking2.0: final+ → -
The fix for bug 625434 might well fix this.
Depends on: 625434
vlad, are you still seeing this?
Closed: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 573235
You need to log in before you can comment on or make changes to this bug.