820248 - New DMD: gfx surfaces memory created by gfxPlatform::CreateDrawTargetForBackend are not reported

Status: NEW

(Core :: Graphics, defect)

Description

[Justin Lebar (not reading bugmail)]

In the gallery app process in B2G with the gallery app in the foreground (see attachment 690543 [details]), I see:

> Unreported: 28 blocks in block group 1 of 215
>  1,720,320 bytes (1,612,800 requested / 107,520 slop)
>  13.57% of the heap (13.57% cumulative);  30.72% of unreported (30.72% cumulative)
>  Allocated at
>        malloc /Users/jlebar/code/moz/ff-git/src/memory/build/replace_malloc.c:152 (0x4020b2ae libmozglue.so+0x42ae)
>        moz_malloc /Users/jlebar/code/moz/ff-git/src/memory/mozalloc/mozalloc.cpp:65 (0x40e5adf2 libxul.so+0xc37df2)
>        gfxImageSurface /Users/jlebar/code/moz/ff-git/src/gfx/thebes/gfxImageSurface.cpp:110 (0x419ae7b6 libxul.so+0xa877b6)
>        nsRefPtr<gfxASurface>::assign_with_AddRef(gfxASurface*) /Users/jlebar/code/moz/B2G/objdir-gecko/dist/include/nsAutoPtr.h:846 (0x419c3ac0 libxul.so+0xa9cac0)
>        gfxPlatform::CreateDrawTargetForBackend(mozilla::gfx::BackendType, mozilla::gfx::IntSize const&, mozilla::gfx::SurfaceFormat) /Users/jlebar/code/moz/ff-git/src/gfx/thebes/gfxPlatform.cpp:721 (0x40c5766a libxul.so+0xa9466a)
>        mozilla::RefPtr<mozilla::gfx::DrawTarget>::operator mozilla::gfx::DrawTarget*() const /Users/jlebar/code/moz/B2G/objdir-gecko/dist/include/mozilla/RefPtr.h:137 (0x40c576c8 libxul.so+0xa946c8)
>        operator mozilla::TemporaryRef<mozilla::gfx::DrawTarget><mozilla::gfx::DrawTarget> /Users/jlebar/code/moz/B2G/objdir-gecko/dist/include/mozilla/RefPtr.h:141 (0x40c6e50a libxul.so+0xaab50a)
>        mozilla::RefPtr<mozilla::gfx::DrawTarget>::assign(mozilla::gfx::DrawTarget*) /Users/jlebar/code/moz/B2G/objdir-gecko/dist/include/mozilla/RefPtr.h:145 (0x406a3e42 libxul.so+0x4e0e42)
>        mozilla::dom::HTMLImageElementOrHTMLCanvasElementOrHTMLVideoElement::IsHTMLCanvasElement() const /Users/jlebar/code/moz/B2G/objdir-gecko/dist/include/mozilla/dom/UnionTypes.h:307 (0x406a58aa libxul.so+0x4e28aa)
>        mozilla::dom::CanvasRenderingContext2DBinding::drawImage(JSContext*, JS::Handle<JSObject*>, mozilla::dom::CanvasRenderingContext2D*, unsigned int, JS::Value*) /Users/jlebar/code/moz/B2G/objdir-gecko/dom/bindings/CanvasRenderingContext2DBinding.cpp:1593 (0x40b9a1fe libxul.so+0x9d71fe)
>        mozilla::dom::CanvasRenderingContext2DBinding::genericMethod(JSContext*, unsigned int, JS::Value*) /Users/jlebar/code/moz/B2G/objdir-gecko/dom/bindings/CanvasRenderingContext2DBinding.cpp:3245 (0x40b9b2cc libxul.so+0x9d82cc)

See also bug 820132, another bug where (different, I think) gfxSurfaces are unreported.

Comment 1

[Jet Villegas (inactive)]

Jonathan: Are you still in this neighborhood? Accurate accounting of DrawTarget buffers will really help regression tracking for MemShrink. Can you pick this one up?

Comment 2

[Jet Villegas (inactive)]

Bas: can we get a moz2D API to return the size of the backend surfaces allocated?

Comment 3

[Bas Schouten (:bas.schouten)]

(In reply to Jet Villegas (:jet) from comment #2)
> Bas: can we get a moz2D API to return the size of the backend surfaces
> allocated?

I discussed this Milan. My suggestion for an extension to Moz2D is an abstract MemoryReporter baseclass, that can be implemented and set on the Factory. That baseclass will receive callbacks then when allocations occur, for example:

enum Reason {
  SourceSurfaceCreated,
  DrawTargetCreated
};

RAMAllocated(Reason aReason);

That would allow Gecko to easily track the different types of memory that we use, report them in different manners and possibly make other (for example cache) decisions based on the numbers. I can write that Moz2D patch if we can agree that's something that we want, and help with hooking this up.

Comment 4

[Nicholas Nethercote [inactive]]

Sounds good to me. 

Also, this might be relevant: https://blog.mozilla.org/nnethercote/2013/11/08/libraries-should-permit-custom-allocators/

Comment 5

[Jonathan Watt [:jwatt]]

Hmm. We want to be able to attribute allocations to the Moz2D object that is holding on to the memory. This is necessary for about:memory to be able to report that thing X in nsIDocument Y is using Z amount of memory. Only being able to say "Moz2D allocated X amount of memory in this process" is a lot less useful.