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: Non-tier 1 builders: NSPR usage?

[Cameron Kaiser]

On 1/15/16 5:21 AM, Ted Mielczarek wrote:

Hello,

I'm interested in feedback from anyone out there that's doing builds on
non-Tier 1 platforms. Specifically, I want to know if you build
--with-system-nspr or not. I've got patches[1] to stop using NSPR's
autoconf build system in favor of moz.build files, but I've only made
them support our Tier 1 platforms currently. glandium suggested as a
fallback that on non-Tier 1 platforms we could have the build system
invoke NSPR's configure+make as usual, treating it more like the
--with-system-nspr case. I haven't implemented that, and I was curious
as to what configuration people are actually building in on those
platforms. The other option is to simply require --with-system-nspr on
platforms where our moz.build files don't support building NSPR, but if
folks aren't already doing that that's a bit more of a hassle.


TenFourFox does not (we use in-tree NSPR, with our patches overlaid).

Cameron Kaiser

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

Re: Non-tier 1 builders: NSPR usage?

[Dave Yeo]

Ted Mielczarek wrote:

Hello,

I'm interested in feedback from anyone out there that's doing builds on
non-Tier 1 platforms. Specifically, I want to know if you build
--with-system-nspr or not. I've got patches[1] to stop using NSPR's
autoconf build system in favor of moz.build files, but I've only made
them support our Tier 1 platforms currently. glandium suggested as a
fallback that on non-Tier 1 platforms we could have the build system
invoke NSPR's configure+make as usual, treating it more like the
--with-system-nspr case. I haven't implemented that, and I was curious
as to what configuration people are actually building in on those
platforms. The other option is to simply require --with-system-nspr on
platforms where our moz.build files don't support building NSPR, but if
folks aren't already doing that that's a bit more of a hassle.

-Ted

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



OS/2 is still using the in-tree NSPR which works fine after running 
autoconf on it (or setting a few things in config.site). If we had to we 
could switch to system-nspr

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