Closed Bug 410678 Opened 12 years ago Closed 5 years ago

Linux Footprint

Categories

(Core Graveyard :: GFX, defect)

x86
Linux
defect
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: sayrer, Unassigned)

References

Details

(Keywords: memory-footprint)

Attachments

(5 files)

Attached file massif data
Attached is a massif data and a graph of one run throught the talos pageset.

The primary memory hogs seem to be Linux font code, and some of our hashtables. I'll need to rerun this with some more functions listed as allocators, but I suspect we'll find it's the cycle collector creating these hashtables.

The good news is that the Frame/Node arenas and the gfx image cache seem to shink, and the cycle collector does kick in and collapse most of the "other" category.
Attachment #295263 - Attachment is patch: false
Attachment #295263 - Attachment mime type: text/plain → image/png
We know we can reduce some of the cairo allocations (at least the non-Xlib-surface ones which we haven't looked at (we haven't looked at the cairo font code either))

The cycle collector does create very large hashtables.  There is a bug on file to try to avoid realloc churn on them but we discussed their size and couldn't come up with a significantly smaller solution.
Talking with stuart, next step is to run this over multiple runs, and see if the font stuff remains unbounded.

As for the cycle collector, we can experiment with alternative hashtable implementations to see if we can shrink it.
(In reply to comment #3)
> As for the cycle collector, we can experiment with alternative hashtable
> implementations to see if we can shrink it.

google::dense_hash_foo could cut out the stored keyHash.

Radix tree might be even better (faster too). Depends on the distribution of addresses used as keys. That could be studied without actually implementing a radix tree, just by counting "pages".

/be
Attaching patch to produce this data in case other people want to try.
(In reply to comment #4)
> (In reply to comment #3)
> > As for the cycle collector, we can experiment with alternative hashtable
> > implementations to see if we can shrink it.
> 
> google::dense_hash_foo could cut out the stored keyHash.

Sayrer pointed out that I meant sparse, not dense, of course.

/be
On my machine, last I checked (a few months ago), pango loads about half a meg of stuff into RAM per font loaded.  (Bold and Italic variants count as separate fonts.)  A substantial part of that is the gpos and gsub tables loaded into an in-memory representation via harfbuzz.  (One would think this could be done by just mmap-ing the font file.)

(In reply to comment #2)
> The cycle collector does create very large hashtables.  There is a bug on file
> to try to avoid realloc churn on them

bug 407454
Keywords: footprint
Version: unspecified → Trunk
Attached image 3 runs of the pageset
looks like massif got a little confused on this one, but still useful
Attachment #295334 - Attachment is patch: false
Attachment #295334 - Attachment mime type: text/plain → image/png
We're definitely leaking moz_drawing_surfaces (and therefore GTK stuff). This can be shown in any leak tool, and grows with each page visited.
(In reply to comment #10)
> We're definitely leaking moz_drawing_surfaces (and therefore GTK stuff). This
> can be shown in any leak tool, and grows with each page visited.

Mind filing a separate bug on that and requesting blocking, please?
Filed bug 411030.
Product: Core → Core Graveyard
Depends on: 449356
This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX.

[Mass-change filter: graveyard-wontfix-2014-09-24]
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.