1452189 - Add memory reporting for FontFace::mUnicodeRange

Status: NEW

(Core :: Layout: Text and Fonts, defect, P4)

Description

[Ted Campbell [:tcampbell]]

On giant google docs documents, I see 20+ MB of heap-unclassified from gfxCharacterMap data. I'm having trouble following the ownership graph of from nsDocument to FontFace and not sure where best place to put reporting is. Can someone familiar with FontFace add reporting or offer suggestions how to iterate over FontFace from nsDocument (just user fonts is probably enough).

Example DMD Report:

Unreported {
  217,600 blocks in heap block record 2 of 16,691
  6,963,200 bytes (6,963,200 requested / 0 slop)
  Individual block sizes: 32 x 217,600
  1.97% of the heap (8.55% cumulative)
  8.45% of unreported (36.71% cumulative)
  Allocated at {
    #01: mozilla::dmd::AllocCallback (z:\build\build\src\memory\replace\dmd\dmd.cpp:1211)
    #02: replace_malloc (z:\build\build\src\memory\replace\dmd\dmd.cpp:1264)
    #03: moz_xmalloc (z:\build\build\src\memory\mozalloc\mozalloc.cpp:71)
    #04: gfxSparseBitSet::SetRange (z:\build\build\src\gfx\thebes\gfxfontutils.h:198)
    #05: mozilla::dom::FontFace::GetUnicodeRangeAsCharacterMap (z:\build\build\src\layout\style\fontface.cpp:856)
    #06: mozilla::dom::FontFaceSet::FindOrCreateUserFontEntryFromFontFace (z:\build\build\src\layout\style\fontfaceset.cpp:1076)
    #07: mozilla::dom::FontFaceSet::FindOrCreateUserFontEntryFromFontFace (z:\build\build\src\layout\style\fontfaceset.cpp:961)
    #08: mozilla::dom::FontFace::CreateUserFontEntry (z:\build\build\src\layout\style\fontface.cpp:424)
    #09: mozilla::dom::FontFace::DoLoad (z:\build\build\src\layout\style\fontface.cpp:436)
    #10: mozilla::dom::FontFace::Load (z:\build\build\src\layout\style\fontface.cpp:412)
    #11: mozilla::dom::FontFaceBinding::load_promiseWrapper (z:\build\build\src\obj-firefox\dom\bindings\fontfacebinding.cpp:1348)
    #12: mozilla::dom::GenericPromiseReturningBindingMethod (z:\build\build\src\dom\bindings\bindingutils.cpp:3074)
    #13: js::InternalCallOrConstruct (z:\build\build\src\js\src\vm\interpreter.cpp:467)
    #14: js::Call (z:\build\build\src\js\src\vm\interpreter.cpp:535)
    #15: js::ForwardingProxyHandler::call (z:\build\build\src\js\src\proxy\wrapper.cpp:176)
    #16: js::CrossCompartmentWrapper::call (z:\build\build\src\js\src\proxy\crosscompartmentwrapper.cpp:358)
    #17: js::proxy_Call (z:\build\build\src\js\src\proxy\proxy.cpp:769)
    #18: js::InternalCallOrConstruct (z:\build\build\src\js\src\vm\interpreter.cpp:449)
    #19: js::jit::DoCallFallback (z:\build\build\src\js\src\jit\baselineic.cpp:2380)
    #20: ??? (???:???)
  }
}

Comment 1

[Cameron McCormack (:heycam)]

nsDocument owns its FontFaceSet, which owns all the FontFace objects inside it.

gfxCharacterMap objects are already measured in gfxFontEntry::AddSizeOfExcludingThis, so I guess this might be a case of @font-face rules that haven't been used to load a font?  To avoid double counting these objects, maybe you could count FontFace::mUnicodeRange only if we haven't created an mUserFontEntry yet?  (Or maybe just check that mUnicodeRange's refcount is 1?)

Comment 2

[Ted Campbell [:tcampbell]]

Needinfo myself to add my failed attempt at this in case someone can determine the problem (or a better way). I'm not actively working on this, but it remains a significant source of heap-unclassified.

Comment 3

[Ted Campbell [:tcampbell]]

I lost the code..

Roughly, I tried to iterated through the |mozilla::dom::FontFaceSet::mRuleFaces| / |mNonRuleFaces| from the document and excluding gfxCharacterMaps that were marked as shared. I kept running into timeout issues where the memory reporting took too long and the report was blank.