
A big step towards Firefox generational and compacting GC - cpeterso
https://blog.mozilla.org/nnethercote/2014/01/20/a-big-step-towards-generational-and-compacting-gc/
======
doctorpangloss
From Terrence Cole:

>Exact rooting is required for us to use GC algorithms that relocate objects
in memory. It will allow us to implement compacting GC to save memory and
generational GC to push our performance to the next level.

For a comprehensive overview of a good open source GC, check out Mono's
description of theirs:

[http://www.mono-project.com/Generational_GC](http://www.mono-
project.com/Generational_GC)

Browser GC is really tricky. The browser provides all sorts of complicated
native services, like a flexible rendering engine (you know, HTML), recording
audio, LocalStorage—really complex stuff implemented efficiently in C++ and
with cross-platform support. All of these native objects can be
accessed/instantiated from Javascript. Hence the GC is especially well tuned,
on top of the security requirements around dealing with untrusted code running
trusted code in general. It's a big undertaking for sure.

------
saurabhnanda
Please excuse my naivety, but I have only recently gotten interested in
compilers, memory management, etc. [1]

Can someone please explain to me why GC isn't implemented as a library that
can be used by any runtime/VM? We recently had a generational GC land in Ruby
2.1 Few languages out there specially target JVM because of its GC story.
Wouldn't everyone benefit from a common code-base with rock-solid GC
algorithms & implementations? Analogous to crypto libraries.

[1] After getting sick of the fact that all the "new age" languages use shit-
loads of resources for, essentially, achieving trivialities. We were able to
do the same things using 386 PCs with a few megs or RAM for which, today, we
need 2 GHz multi-core CPUs and 8 GB of RAM.

PS: Not trying to downplay the work done in bringing better memory management
to Firefox. I would really appreciate Firefox not using up 1.3GB of memory --
that was one of the reasons I had to fork out INR 5,000 for an extra 8GB of
RAM recently.

~~~
vidarh
The hard part is not the high level algorithm - most of the common ones can be
prototyped for toy systems in trivial numbers of lines.

The hard part is system interactions. E.g. the GC needs a way to identify all
the "roots" (references from outside the heap, such as registers, the stack,
or pointers that may have been retained by external libraries etc.).

It also needs a way to identify which parts of an object are pointers and this
varies with language. "Generic" GC's like Boehm's solve this by assuming
you've done nothing to obscure the pointer, and then assumes everything that
_could_ be a pointer into the heap is, but this fails miserably for any
language implementation that uses bits for type tagging, for example, and
retains too much memory in many other situations because it isn't precisely
determining which fields are pointers.

Then you have issues like threading models (threading and GC are intimately
linked, as if you don't block all threads during marking or moving/collection,
you have all kinds of additional exciting issues to deal with to ensure you
don't break things)

~~~
saurabhnanda
Thank you for the replies. A follow-up question, how does any GC/runtime/VM
know which parts of the memory are actual data vis-a-vis pointers to other
parts of the memory? Some sort of global pointer table, perhaps? If so, why
cant the hypothetical GC lib define an API to share said pointer-table?

------
nickik
Wow, that must have been a lot of freaking work. Testing this must be
nightmare, if you have on native pointer left the browser could essentially
randomly crash.

Pretty cool stuff. I really want to see the performance changes the GC can
get.

~~~
venomsnake
Isn't that problem right in the domain of automated testing and static code
analysis?

~~~
evilpie
We do both, but it's still very tideous. After a while the dynamic analysis
only caught false postives (something on the stack looked like a pointer). The
static analysis had to be updated when new potential hazardous cases became
obvious.
[https://wiki.mozilla.org/Javascript:SpiderMonkey:ExactStackR...](https://wiki.mozilla.org/Javascript:SpiderMonkey:ExactStackRooting)

~~~
AndrewDucker
You've got a typo in your URL there - missing 'n' in 'rooting'

------
afsina
Is this the equivalent work of Oilpan project for Chromium-Blink?
[https://groups.google.com/a/chromium.org/d/msg/blink-
dev/59f...](https://groups.google.com/a/chromium.org/d/msg/blink-
dev/59fb1FIirx0/u1EV00Ca5sgJ)

Doc: [https://docs.google.com/document/d/1y7_0ni0E_kxvrah-
QtnreMlz...](https://docs.google.com/document/d/1y7_0ni0E_kxvrah-
QtnreMlzCDKN3QP4BN1Aw7eSLfY/edit)

~~~
pcwalton
No, Oilpan is different; it's a garbage collector for C++ objects, while exact
rooting is for JS objects. Oilpan has more in common with the XPCOM cycle
collector in purpose (although the approach is different), which Firefox has
had for several years now but which WebKit has had no equivalent to.

~~~
DannyBee
Right, and on the flip side, V8 has had a generational, incremental JS
collector for quite a while :)

~~~
mccr8
For what its worth, it looks like v8 has had incremental GC since 2011 (
[http://blog.chromium.org/2011/11/game-changer-for-
interactiv...](http://blog.chromium.org/2011/11/game-changer-for-
interactive.html) and generational GC for longer) while Firefox has had IGC
since 2012 (
[https://blog.mozilla.org/javascript/2012/08/28/incremental-g...](https://blog.mozilla.org/javascript/2012/08/28/incremental-
gc-in-firefox-16/) ).

------
sliverstorm
Can anyone comment on what this will mean for Firefox in rough terms? Less
bloat in long-running processes? Less memory usage in general?

~~~
kevingadd
The eventual introduction of compacting and generational collection will:

Dramatically reduce the cost of GC for short-lived objects ( _dramatically_ ,
to the point of producing something like 5-10x wins on some of the stupidly
tuned microbenchmarks typically used to compare JS runtimes)

Reduce typical heap fragmentation (essential for long-running processes -
imagine a facebook/gmail tab left open for days)

Potentially improve computational performance (compacting your GC heap will
improve memory locality in some scenarios, which means the CPU cache can be
used more efficiently, which will make JS code manipulating small objects much
faster)

Reduce average GC pause duration and reduce the frequency of GC pauses

In summary, generational collection is a big win for the things users tend to
care about, if you look at what the advantages mean for applications.
Compacting is less important, but tends to be nice too.

------
ksec
Still waiting for e10sM2. I hope after this is finish and done they can move
on to it.

Firefox really needs some help in its snappiness area.

~~~
Ygg2
To be honest I haven't noticed it being sluggish, except when loading a 10
tabs when waking from hibernate. These days Chrome chokes with same amount of
tabs that FF deals with easily.

Chrome does sometimes win with the JS demos (mainly that 3D period table
demo).

~~~
agumonkey
Chrome wins on psychology, it's uber fast on start and with few tabs, then it
gets a bit slower than firefox, which is relatively constant in its non-
snappiness (it's not slow but you notice tiny lags in the UI regularly)

~~~
Ygg2
To be honest I haven't noticed that it's non-snappy (I am on Nightly but use
Regular at home). I'm bit biased towards Mozilla, but I don't think it is
lacks much polish. Chrome dev tools are better, but the gap is closing in that
area.

~~~
ksec
Fan boys will try to tell you otherwise. But lets just admit Firefox is slower
then Chrome. Its a fact. Even though i have been an Firefox users for longer
then a decade.

Try Opening "Tab from Other devices". Firefox will stall. Try using Feedly and
open link in a new tab, Feedly will suddenly response very slowly. There are
also other page loading performance which Blink/Webkit leads. Not to mention
Google's way of implementing advance preloading technique which seems to win
as well, even though Firefox has something similar.

Yes I understand the geeks and tech cares about DRM. Yes I understand about
implementation of Web Standard and Freedom. But most users dont. When ever i
see users complaining about why not switch to Chrome on their computer. I just
say no. I FORCED the usage of Firefox on 100s of computer in the office. If
not, I bet users would choose a Chrome anyday.

So the point is, Mozilla needs to seriously think about its execution model.
It needs to be efficient and not spread itself thin.

~~~
Ygg2
I admit I am a bit of a Fan boy.

However, I recall trying FF on my laptop and being slow, then switching to
Chrome and it being super fast. When I updated to Nightly, the speed was about
the as Chrome.

DRM and other things be damned, I can't notice a difference between Firefox
and Chrome in performance. And I bought my computer 3 years ago.

I can't remember when Chrome subjectively outperformed Firefox. And the
objective measures are usually about the same.

~~~
nikbackm
Maybe you used a new, fresh and bloat-free profile when running the Nightly?

Could perhaps explain the speed difference.

~~~
Ygg2
No, both were fresh installs without plugins. Nightly ran at significantly
faster speed than Regular on that laptop.

On my regular comp the difference was non-noticable. Even with all the
plugins.

