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

NEW
Unassigned

Status

()

Core
Graphics
4 years ago
10 months ago

People

(Reporter: Justin Lebar (not reading bugmail), Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
ARM
Gonk (Firefox OS)
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [MemShrink:P2])

(Reporter)

Description

4 years ago
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.
(Reporter)

Updated

4 years ago
Whiteboard: [MemShrink]
Whiteboard: [MemShrink] → [MemShrink:P2]

Comment 1

3 years ago
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?
Flags: needinfo?(jwatt)

Comment 2

3 years ago
Bas: can we get a moz2D API to return the size of the backend surfaces allocated?
Flags: needinfo?(bas)
(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.
Flags: needinfo?(bas)
Sounds good to me. 

Also, this might be relevant: https://blog.mozilla.org/nnethercote/2013/11/08/libraries-should-permit-custom-allocators/
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.
Flags: needinfo?(jwatt)

Updated

10 months ago
Summary: New DMD: gfx surfaces created by gfxPlatform::CreateDrawTargetForBackend are not reported → New DMD: gfx surfaces memory created by gfxPlatform::CreateDrawTargetForBackend are not reported
You need to log in before you can comment on or make changes to this bug.