Closed Bug 1487216 Opened Last year Closed 6 months ago

We don't seem to memory-report parts of display lists

Categories

(Core :: Web Painting, defect, P2)

defect

Tracking

()

RESOLVED FIXED
mozilla69
Tracking Status
firefox69 --- fixed

People

(Reporter: bzbarsky, Assigned: emilio)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [overhead:noted])

Attachments

(1 file)

From a DMD report:

Unreported {
  66 blocks in heap block record 37 of 6,988
  540,672 bytes (540,672 requested / 0 slop)
  Individual block sizes: 8,192 x 66
  0.11% of the heap (26.72% cumulative)
  0.30% of unreported (72.58% cumulative)
  Allocated at {
    #01: replace_malloc(unsigned long) (DMD.cpp:1267, in libmozglue.dylib)
    #02: mozilla::ArenaAllocator<8192ul, 8ul>::Allocate(unsigned long) (ArenaAllocator.h:193, in XUL)
    #03: nsTextFrame::BuildDisplayList(nsDisplayListBuilder*, nsDisplayListSet const&) (nsTextFrame.cpp:4923, in XUL)
    #04: nsIFrame::BuildDisplayListForChild(nsDisplayListBuilder*, nsIFrame*, nsDisplayListSet const&, unsigned int) (ArenaAllocator.h:130, in XUL)
    #05: nsContainerFrame::BuildDisplayListForNonBlockChildren(nsDisplayListBuilder*, nsDisplayListSet const&, unsigned int) (nsIFrame.h:1647, in XUL)
    #06: nsInlineFrame::BuildDisplayList(nsDisplayListBuilder*, nsDisplayListSet const&) (nsInlineFrame.cpp:247, in XUL)
    #07: nsIFrame::BuildDisplayListForChild(nsDisplayListBuilder*, nsIFrame*, nsDisplayListSet const&, unsigned int) (ArenaAllocator.h:130, in XUL)
    #08: DisplayLine(nsDisplayListBuilder*, nsRect const&, nsLineList_iterator&, int, int&, nsDisplayListSet const&, nsBlockFrame*, mozilla::css::TextOverflow*, unsigned int) (nsIFrame.h:1647, in XUL)
  }
}

I would have expected us to report these arenas.  nsPresArena has memory reporting stuff hooked up already.  Presumably we "just" need to memory-report the RetainedDisplayListBuilder and have it report its arena?
There are also other display list allocations in the log, adding up to several MB at least.
Indeed, it looks like we're not reporting this. We previously only had display list memory allocated during painting until RDL made it more permanent, but didn't add tracking.
Priority: -- → P2
Whiteboard: [overhead:noted]
Blocks: 1555886
Assignee: nobody → emilio

For now I added everything to the same bucket, but I wrote this so it should be
easy to add more buckets as needed (either to mArenaSizes, or more specific ones
like the style system has). But this is probably enough for now.

Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7bea9b04f354
Measure memory usage of RDL. r=mattwoodrow,miko
Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69

== Change summary for alert #21394 (as of Mon, 10 Jun 2019 15:20:45 GMT) ==

Improvements:

6% Heap Unclassified windows7-32-shippable opt 38,387,954.33 -> 36,091,129.87
5% Heap Unclassified windows10-64-shippable-qr opt 57,209,667.24 -> 54,083,385.68
5% Heap Unclassified windows10-64-shippable opt 48,806,432.63 -> 46,571,146.74
3% Base Content Heap Unclassified windows10-64-shippable opt 1,608,155.33 -> 1,556,494.00
3% Heap Unclassified macosx1010-64-shippable opt 79,320,935.43 -> 76,822,249.88
3% Heap Unclassified linux64-shippable opt 83,973,257.79 -> 81,410,903.35
3% Base Content Heap Unclassified windows10-64-shippable-qr opt 1,591,473.33 -> 1,545,424.00

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=21394

Regressions: 1560188
You need to log in before you can comment on or make changes to this bug.