Re: Dominator tree memory analysis now in Nightly

[Helen Holmes]

There's actually a bug on file 
with designs that I'd like to implement for exposing panels better than
they currently. (If you look at the mockups, not dissimilar to what Nick's
suggesting!)

As for whether or not we should always expose the Memory tool on a clean
install, I think we're hoping to drive the answers to those questions with
better data. I believe Jordan created an etherpad
 that probably
needs some love when it comes to thinking about what telemetry probes we
want to add and who owns what data in devtools. As far as I currently know:
the memory is not on by default in release and it might be in both dev
edition and nightly (Jeff would know for certain as resident Telemetry
King).

On Thu, Jan 14, 2016 at 6:12 PM, Gijs Kruitbosch 
wrote:

> On 14/01/2016 23:01, Nick Fitzgerald wrote:
>
> On Thu, Jan 14, 2016 at 2:49 PM, Jared Wein  wrote:
>
>> Also, what is the plan for making tools like the Memory view appear in a
>> default install? In other words, without having to go to the Settings. I
>> worry that users may not know to click on the Settings and just think that
>> other browsers offer more tools than we do.
>>
>
> ​This is a good conversation to have, but I don't have any good answers.
> We have a lot of panels in the devtools, many of which are fairly niche,
> and it isn't clear how to simultaneously give them visibility and not
> overwhelm users.
>
> Console, debugger, performance: these panels are ​a clear "always show" to
> me. The web audio tool is very niche and so I don't think it would make
> sense to show it by default. The memory tool falls in between in my mind.
> I'm open to suggestions!
>
> We could add a [...] or similar button at the end with a dropdown for the
> other tools? With some TBD as to whether that enables them permanently or
> just for that site and/or how to toggle that.
> (pulling in Helen because I think she might have better ideas :-) )
>
> ~ Gijs
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dominator tree memory analysis now in Nightly

[Helen Holmes]

Apologies everyone, Jared pointed out that I didn't actually link to the
bug correctly: Bug 1238982

https://bugzilla.mozilla.org/show_bug.cgi?id=1238982

On Fri, Jan 15, 2016 at 7:10 AM, Helen Holmes  wrote:

> There's actually a bug on file 
> with designs that I'd like to implement for exposing panels better than
> they currently. (If you look at the mockups, not dissimilar to what Nick's
> suggesting!)
>
> As for whether or not we should always expose the Memory tool on a clean
> install, I think we're hoping to drive the answers to those questions with
> better data. I believe Jordan created an etherpad
>  that probably
> needs some love when it comes to thinking about what telemetry probes we
> want to add and who owns what data in devtools. As far as I currently know:
> the memory is not on by default in release and it might be in both dev
> edition and nightly (Jeff would know for certain as resident Telemetry
> King).
>
> On Thu, Jan 14, 2016 at 6:12 PM, Gijs Kruitbosch  > wrote:
>
>> On 14/01/2016 23:01, Nick Fitzgerald wrote:
>>
>> On Thu, Jan 14, 2016 at 2:49 PM, Jared Wein  wrote:
>>
>>> Also, what is the plan for making tools like the Memory view appear in a
>>> default install? In other words, without having to go to the Settings. I
>>> worry that users may not know to click on the Settings and just think that
>>> other browsers offer more tools than we do.
>>>
>>
>> ​This is a good conversation to have, but I don't have any good answers.
>> We have a lot of panels in the devtools, many of which are fairly niche,
>> and it isn't clear how to simultaneously give them visibility and not
>> overwhelm users.
>>
>> Console, debugger, performance: these panels are ​a clear "always show"
>> to me. The web audio tool is very niche and so I don't think it would make
>> sense to show it by default. The memory tool falls in between in my mind.
>> I'm open to suggestions!
>>
>> We could add a [...] or similar button at the end with a dropdown for the
>> other tools? With some TBD as to whether that enables them permanently or
>> just for that site and/or how to toggle that.
>> (pulling in Helen because I think she might have better ideas :-) )
>>
>> ~ Gijs
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dominator tree memory analysis now in Nightly

[Gijs Kruitbosch]

On 14/01/2016 23:01, Nick Fitzgerald wrote:
On Thu, Jan 14, 2016 at 2:49 PM, Jared Wein > wrote:


Also, what is the plan for making tools like the Memory view
appear in a default install? In other words, without having to go
to the Settings. I worry that users may not know to click on the
Settings and just think that other browsers offer more tools than
we do.


​This is a good conversation to have, but I don't have any good 
answers. We have a lot of panels in the devtools, many of which are 
fairly niche, and it isn't clear how to simultaneously give them 
visibility and not overwhelm users.


Console, debugger, performance: these panels are ​a clear "always 
show" to me. The web audio tool is very niche and so I don't think it 
would make sense to show it by default. The memory tool falls in 
between in my mind. I'm open to suggestions!
We could add a [...] or similar button at the end with a dropdown for 
the other tools? With some TBD as to whether that enables them 
permanently or just for that site and/or how to toggle that.

(pulling in Helen because I think she might have better ideas :-) )

~ Gijs
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dominator tree memory analysis now in Nightly

[Nick Fitzgerald]

On Sat, Jan 16, 2016 at 5:41 AM, Philip Chee  wrote:

> This is great! Is there a way of expanding/collapsing the whole tree?
> Thunderbird uses "\" (collapse) and "*" (expand).
>

​You can use ALT+click on an arrow to expand a​ whole subtree. However,
because after a certain depth we start incrementally loading sub-trees,
those incrementally loaded subtrees will not be auto-expanded. In general,
the dominator trees are too large to eagerly display in the UI; there is an
item in the tree for every node in the heap graph that we snapshot'd.



>
> Nitpick: The columns don't appear to be resizeable.
>
>
That is a pretty unfortunate screenshot. ​We have a bug in flight to ensure
that the columns are wide enough​:
https://bugzilla.mozilla.org/show_bug.cgi?id=1224201

If we can always ensure that the minimum cell size in the table is large
enough to display the number contained within, then I'm not convinced we
need resizing. Perhaps we can take this discussion to that bug, or a new
one?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dominator tree memory analysis now in Nightly

[Philip Chee]

On 15/01/2016 05:50, Nick Fitzgerald wrote:
> Hi folks!
> 
> Dominator trees give you fine-grained insight into memory retention.
> 
> In a graph rooted by some node R, a node A is said to dominate B iff
> every path to B starting from R passes through A. In the context of a
> heap graph, another way to say this would be that A is retaining B:
> if the garbage collector found A to be unreachable and eligible for
> reclaiming, than B would also be unreachable and eligible for
> reclaiming.
> 
> We also use this to calculate the "true" memory cost of a node in the
> heap graph. This is the "retained size" and contrasts with the naive
> "shallow size". For example, imagine a large binary tree where there
> are no outside references into subtrees, only to the root. The root
> node itself has a small shallow size: a left branch pointer, a value,
> and a right branch pointer. However, it is retaining the whole rest
> of this large tree's structure, and so its retained size is
> significant.
> 
> Here is a screenshot of the dominator tree (combined with allocation
> stack tracking) in action to debug the memory overhead of loading
> large source files in a CodeMirror editor:
> http://i.imgur.com/sGsVJb9.png
> 
> And here is a reminder of how to enable to memory tool within the
> devtools: http://i.imgur.com/hEPTqrT.png
> 
> If you would like to use this tool for the whole runtime rather than
> scoped to a single tab, use the browser toolbox. Here are
> instructions for enabling and using the browser toolbox: 
> https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox
> 
> Please try it out, give me your feedback, and file bugs in the
> "Firefox" product and "Developer Tools: Memory" component!
> 
> My thanks to the folks who reviewed patches for this feature: Jordan 
> Santell, Steve Fink, Boris Zbarsky, and Jim Blandy.
> 
> Cheers,
> 
> Nick

This is great! Is there a way of expanding/collapsing the whole tree?
Thunderbird uses "\" (collapse) and "*" (expand).

Nitpick: The columns don't appear to be resizeable.


Here is how the Browser Toolbox looks like in SeaMonkey!
https://bug1223341.bmoattachments.org/attachment.cgi?id=8708680

Phil

-- 
Philip Chee , 
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dominator tree memory analysis now in Nightly

[Kyle Huey]

This is awesome.  We've talked about how much we've wanted this since the
early days of MemShrink back in 2011.  Thanks to everyone who was involved.

- Kyle

On Thu, Jan 14, 2016 at 1:50 PM, Nick Fitzgerald 
wrote:

> Hi folks!
>
> Dominator trees give you fine-grained insight into memory retention.
>
> In a graph rooted by some node R, a node A is said to dominate B iff every
> path to B starting from R passes through A. In the context of a heap graph,
> another way to say this would be that A is retaining B: if the garbage
> collector found A to be unreachable and eligible for reclaiming, than B
> would also be unreachable and eligible for reclaiming.
>
> We also use this to calculate the "true" memory cost of a node in the heap
> graph. This is the "retained size" and contrasts with the naive "shallow
> size". For example, imagine a large binary tree where there are no outside
> references into subtrees, only to the root. The root node itself has a
> small shallow size: a left branch pointer, a value, and a right branch
> pointer. However, it is retaining the whole rest of this large tree's
> structure, and so its retained size is significant.
>
> Here is a screenshot of the dominator tree (combined with allocation stack
> tracking) in action to debug the memory overhead of loading large source
> files in a CodeMirror editor: http://i.imgur.com/sGsVJb9.png
>
> And here is a reminder of how to enable to memory tool within the
> devtools: http://i.imgur.com/hEPTqrT.png
>
> If you would like to use this tool for the whole runtime rather than
> scoped to a single tab, use the browser toolbox. Here are instructions for
> enabling and using the browser toolbox:
> https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox
>
> Please try it out, give me your feedback, and file bugs in the "Firefox"
> product and "Developer Tools: Memory" component!
>
> My thanks to the folks who reviewed patches for this feature: Jordan
> Santell, Steve Fink, Boris Zbarsky, and Jim Blandy.
>
> Cheers,
>
> Nick
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dominator tree memory analysis now in Nightly

[Robert O'Callahan]

On Fri, Jan 15, 2016 at 12:01 PM, Nick Fitzgerald 
wrote:

> Console, debugger, performance: these panels are ​a clear "always show" to
> me. The web audio tool is very niche and so I don't think it would make
> sense to show it by default. The memory tool falls in between in my mind.
> I'm open to suggestions!
>

Why not make them context-sensitive? Show the Web Audio tool if the page
uses Web Audio, Shader Editor if the page uses WebGL, Canvas if the page
has a 2D canvas, Storage if the page uses IndexedDB, Memory if the page
uses memory :-). Well, for memory, use some heuristic like if the page
spends more than 16ms in a single GC.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dominator tree memory analysis now in Nightly

[Brian Grinstead]

> On Jan 14, 2016, at 3:01 PM, Nick Fitzgerald  wrote:
> Also, what is the plan for making tools like the Memory view appear in a 
> default install? In other words, without having to go to the Settings. I 
> worry that users may not know to click on the Settings and just think that 
> other browsers offer more tools than we do.
> 
> ​This is a good conversation to have, but I don't have any good answers. We 
> have a lot of panels in the devtools, many of which are fairly niche, and it 
> isn't clear how to simultaneously give them visibility and not overwhelm 
> users.
> 
> Console, debugger, performance: these panels are ​a clear "always show" to 
> me. The web audio tool is very niche and so I don't think it would make sense 
> to show it by default. The memory tool falls in between in my mind. I'm open 
> to suggestions!

There are some designs in flight that would make selecting a non-default panel 
much easier by adding an arrow after the last one, which would open a popup 
with all panels available.  So you could avoid a trip to the settings panel.  
I’ve filed a bug 1239859 for this since I couldn’t find another one on file.

Brian
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dominator tree memory analysis now in Nightly

[Nick Fitzgerald]

Reply inline below.

On Thu, Jan 14, 2016 at 2:49 PM, Jared Wein  wrote:

> From your screenshot, there are a lot of instances of "objects > Array",
> "objects > Object", etc. Is the a way to display the variable name used for
> those objects?
>

​The node might not be in a JS variable (eg​ is a C++ implementation detail
that is not exposed to JS) or it might be referred to by many variables in
different parts of the JS code or it might be referred to not by any
variables in the JS code, but by something in the C++ world.

So, I think the "real" (or at least more general) solution is to show the
first N shortest paths from the GC roots to the thing. This is the next
feature I will be working on for the memory tool. I wanted to do dominator
trees first because it tells you which objects to pay attention to; the
shortest paths will tell you more about how a specific object is kept
alive. It didn't make sense to do the latter before the former.

Stay tuned!


> Also, what is the plan for making tools like the Memory view appear in a
> default install? In other words, without having to go to the Settings. I
> worry that users may not know to click on the Settings and just think that
> other browsers offer more tools than we do.
>

​This is a good conversation to have, but I don't have any good answers. We
have a lot of panels in the devtools, many of which are fairly niche, and
it isn't clear how to simultaneously give them visibility and not overwhelm
users.

Console, debugger, performance: these panels are ​a clear "always show" to
me. The web audio tool is very niche and so I don't think it would make
sense to show it by default. The memory tool falls in between in my mind.
I'm open to suggestions!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Dominator tree memory analysis now in Nightly

[Nick Fitzgerald]

Hi folks!

Dominator trees give you fine-grained insight into memory retention.

In a graph rooted by some node R, a node A is said to dominate B iff every
path to B starting from R passes through A. In the context of a heap graph,
another way to say this would be that A is retaining B: if the garbage
collector found A to be unreachable and eligible for reclaiming, than B
would also be unreachable and eligible for reclaiming.

We also use this to calculate the "true" memory cost of a node in the heap
graph. This is the "retained size" and contrasts with the naive "shallow
size". For example, imagine a large binary tree where there are no outside
references into subtrees, only to the root. The root node itself has a
small shallow size: a left branch pointer, a value, and a right branch
pointer. However, it is retaining the whole rest of this large tree's
structure, and so its retained size is significant.

Here is a screenshot of the dominator tree (combined with allocation stack
tracking) in action to debug the memory overhead of loading large source
files in a CodeMirror editor: http://i.imgur.com/sGsVJb9.png

And here is a reminder of how to enable to memory tool within the devtools:
http://i.imgur.com/hEPTqrT.png

If you would like to use this tool for the whole runtime rather than scoped
to a single tab, use the browser toolbox. Here are instructions for
enabling and using the browser toolbox:
https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox

Please try it out, give me your feedback, and file bugs in the "Firefox"
product and "Developer Tools: Memory" component!

My thanks to the folks who reviewed patches for this feature: Jordan
Santell, Steve Fink, Boris Zbarsky, and Jim Blandy.

Cheers,

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform