762040 - automatically sum leaf nodes for "Other measurements" categories

Status: RESOLVED WONTFIX

(Toolkit :: about:memory, defect)

Description

[Nathan Froyd [:froydnj]]

This has come up in a couple of about:memory bugs that I've touched, and bug 711130 takes a stab at doing this for some JS engine measurements.  I think it'd be nicer if the about:memory page did this auto-magically so you only had to add one bit of code in a memory reporter, rather than two.

Magic flag on the leaf node?  Something else?

Comment 1

[Justin Lebar (not reading bugmail)]

I think the obvious way to do this would be to have the memory reporter return, in addition to a name, an "aggregate name".  So, for example, the reporter with name

  explicit/js/compartment(...)/gc-heap/objects/function    (A)

might return an "aggregate name" of

  js-other/gc-heap/objects/function.                       (B)

The problem is, this would be a pretty big change to the memory reporter interface; you'd likely have to touch a lot of unrelated code.

But my insight is that you only care about this kind of aggregation for multi-reporters.  Single reporters are already "aggregated" by their placement in the explicit tree.

But if you're already a multi-reporter, this is a simple problem to solve: Instead of sending one memory report (say, for (A)), send two, (A) and (B).  about:memory will sum all of the (B) reports.

Comment 2

[Nicholas Nethercote [inactive]]

> But my insight is that you only care about this kind of aggregation for
> multi-reporters.

Yes.  And not necessarily all multi-reporters.

> But if you're already a multi-reporter, this is a simple problem to solve:
> Instead of sending one memory report (say, for (A)), send two, (A) and (B). 
> about:memory will sum all of the (B) reports.

That would work.  The downside is that there'll be more string traffic between C++ and JS which will increase memory consumption.

Comment 3

[Nicholas Nethercote [inactive]]

> > But if you're already a multi-reporter, this is a simple problem to solve:
> > Instead of sending one memory report (say, for (A)), send two, (A) and (B). 
> > about:memory will sum all of the (B) reports.
> 
> That would work.

Oh wait!  It won't work right now, because about:memory currently disallows dups in "Other Measurements".  But bug 760352 will lift that restriction.

Comment 4

[Justin Lebar (not reading bugmail)]

> But bug 760352 will lift that restriction.

Yes, my thought exactly.  If we wanted to do this before that, we could lift that restriction, but since that bug is gated on my review anyway...  :)

Comment 5

[Nicholas Nethercote [inactive]]

I think the right way to fix this is not with some automatic mechanism, but just by factoring the code in the right way.  In bug 760352 patch 2 I changed the JS reporters so that the compartment-specific "Other measurements" matched exactly the compartment-specific "explicit" measurements.  This meant I was able to reuse the same code to print both sets of measurements;  I just had to parameterize the ReportCompartmentStats() function to take a path prefix.  We can do similar things with the DOM/layout memory.

Comment 6

[Nicholas Nethercote [inactive]]

There are various ways to make this kind of code nice, which are currently employed. Magic flags on leaf nodes and the like aren't going to happen.