
Firefox’s New Memory Tool - bpierre
https://hacks.mozilla.org/2015/11/firefoxs-new-memory-tool/
======
EdSharkey
This looks so advanced, Firefox is the best!

I'm very curious to watch how WeakMap behaves and how it is visualized in this
tool!

Speaking of WeakMap, perhaps a Firefox engineer could satisfy my curiosity on
this subject. What is the algorithm Firefox uses to release weakly held
references? Or, perhaps better restated: how aggressive is Firefox in holding
on to weakly referenced objects?

When the majority of new JS memory allocations on a page get placed into
WeakMaps, does Firefox always continue to allocate memory from the host OS, or
is there some threshold where it starts to let things slip? Also, is there any
rhyme or reason to what gets released first from WeakMaps?

Can Firefox run wild like it does with strongly held references, allocating
into WeakMaps until the host OS cannot satisfy new native memory allocation
requests and only then start to release weak references?

Also, how crazy do things get for you when you put lots of DOM objects or,
even worse, GPU-backed memory structures like CanvasPattern into a WeakMap?
Please share cool war stories! ;)

Disclaimer: I have not used WeakMap in any serious capacity, so I don't know
what I'm talking about.

~~~
mnemonik
Up until a couple months ago, it had an O(n^2) marking algorithm that kept
iterating until it got to a fixed point.

Thanks to the hard work of Steve Fink, these days it has an O(n) marking
algorithm. See
[https://bugzilla.mozilla.org/show_bug.cgi?id=1164294](https://bugzilla.mozilla.org/show_bug.cgi?id=1164294)
for the details.

Edit to address your questions more directly:

 _> how aggressive is Firefox in holding on to weakly referenced objects?_

They are just collected at the next GC slice where they are no longer
retained. SpiderMonkey doesn't do anything to try and eagerly collect them. GC
slices generally won't happen until either there has been enough pressure
(allocations) to trigger one or the user is inactive for N amount of time.
There are tons of GC triggering heuristics and some are probably not optimal.
It is on the GC team's TODO list to revisit and clean these up.

 _> does Firefox always continue to allocate memory from the host OS, or is
there some threshold where it starts to let things slip?_

The threshold of how much is allocated before triggering GC grows as the
retained set's size grows. This is bounded by available memory.

Aaaaand I have a meeting I need to go attend.

~~~
EdSharkey
I am eating this up! I love you, man. (Not long stares, cuddling love. Like,
brotherly.)

------
ZenoArrow
This looks like a useful tool, thank you to the team at Mozilla responsible
for this new memory tool.

Also, when watching the introductory video I was surprised that disabling
tracking scripts offered so much potential for reducing memory usage
(depending on the site of course). Is this new feature only available in
private browsing mode, or can it be enabled for standard browsing? Are there
any downsides for the user when disabling tracking scripts all the time?

~~~
mnemonik
Yes, it can be enabled all the time with about:config ->
privacy.trackingprotection.enabled = true

------
sehr
Is this the part of devtools that was built using React & Redux? I remember
hearing something a it that a few weeks ago

~~~
mbrubeck
Yes. You can see the code here:

[https://dxr.mozilla.org/mozilla-
central/source/devtools/clie...](https://dxr.mozilla.org/mozilla-
central/source/devtools/client/memory)

(I think there are other parts of the developer tools that also use React and
Redux, like the debugger.)

~~~
jlongster
Not quite yet, but I'm very close to landing a debugger refactor which uses
redux internally :)
[https://bugzilla.mozilla.org/show_bug.cgi?id=1200798](https://bugzilla.mozilla.org/show_bug.cgi?id=1200798)
And we're going to slow introduce React.

------
aembleton
This looks good. Will it be made available in the regular Firefox Inspector
Element tool any time soon?

~~~
callahad
It should land in the Release channel in 12 weeks (things move from Developer
Edition to Beta to Release every six weeks)

------
robotkilla
Super excited to see this released - perfect timing as I've been working on JS
heavily as of late and have been searching for a good memory debugging tool
and I'm not too big on chrome's option. This looks easier to read and use
overall.

------
kevingadd
This looks amazing, can't wait to see it motivate the v8/blink people to
deliver an equivalent. Storing allocation stacks is essential for
troubleshooting leaks and I've never been able to get anything remotely close
to that on the web.

------
jscheel
I'm really impressed with the new firefox dev tools. I'm still getting several
crashes a day with them though, so maybe this can help internally too :) All
joking aside, this is a great addition.

~~~
mnemonik
Can you file bug(s) with links to the crash report(s) in about:crashes?

Alternatively, you could email me your crash reports (email in profile) and I
could file bug(s) for youe.

------
eveningcoffee
This is very cool.

I wish there is also kind of tool that shows CPU, memory and network usage for
every open page in one place.

------
solidr53
Chrome has had that for at least 2 years now. Sure, Firefox has some
additions, but how is Firefox doing some breakthrough?

[https://developer.chrome.com/devtools/docs/javascript-
memory...](https://developer.chrome.com/devtools/docs/javascript-memory-
profiling)

~~~
ikawe
I wish you'd asked it like this:

Chrome has had memory profiling for at least 2 years.
[https://developer.chrome.com/devtools/docs/javascript-
memory...](https://developer.chrome.com/devtools/docs/javascript-memory-
profiling)

How does Firefox's new profiling feature compare?

~~~
kohlerm
Chrome's tool supports a dominator tree view. Sorry, also I'm excited to see a
memory usage tool for firefox is now available. Supporting a dominator tree
view is IMHO a crucial feature you will need sooner or later for investigating
memory usage issues. The predecessor to the Eclipse Memory Analyzer had that
in 2006/2007.

~~~
jsantell
The dominator tree view[0] is one of the first things being worked on after
release.

[0]
[https://bugzilla.mozilla.org/show_bug.cgi?id=1149367](https://bugzilla.mozilla.org/show_bug.cgi?id=1149367)

