Exact stack rooting is now enabled by default on desktop builds of firefox.

What this Means
===============
SpiderMonkey will no longer scan the stack for live roots; you must now
wrap all GC thing pointers that live on the stack across a GC in the
JS::Rooted template for SpiderMonkey to see them. See the comments in
js/public/RootingAPI.h and the guide on the developer wiki[1] for
further details. All currently existing instances in the browser build
have been updated; the hazard analysis build on TBPL, SM(Hf), will catch
any future pushes that break this invariant.

Why Do We Need This
===================
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.

Fixing SM(Hf) Failures
======================
If you do happen to introduce a rooting issue, the SM(Hf) build will
help you track it down and fix it. SM(Hf) runs on all pushes that feed
into m-c and is available in the default set that is run on try. It is
also available individually through the Try Chooser as "browser rooting
analysis" (-p linux64-br-haz).

Once the build is complete and has reported a failure, click on the
|results| link in the lower right pane of tbpl, then click on
hazards.txt.gz to get the list. Each hazard report includes the name of
the problematic variable, the call that might GC, including the file and
line number, and the live range of the unrooted variable in question.
Please read the wiki guide[2] or ask in #jsapi if you have any questions.


Thanks to everyone who helped the project get to this point! In the next
few weeks we'll be getting the hazard analysis running on mobile and b2g
and deploying exact rooting on our remaining platforms.

Cheers,
Terrence

1- https://developer.mozilla.org/en-US/docs/SpiderMonkey/GC_Rooting_Guide
2- https://wiki.mozilla.org/Javascript:SpiderMonkey:ExactStackRooting

On 1/17/14 3:24 PM, Terrence Cole wrote:
> Exact stack rooting is now enabled by default on desktop builds of firefox.

*standing ovation forever*

-j

On 01/17/2014 01:24 PM, Terrence Cole wrote:
> Exact stack rooting is now enabled by default on desktop builds of firefox.

I've never heard of a major project escaping from conservative GC once
it had entered that state of sin; nor have I heard of anyone
implementing a moving collector after starting with a non-moving collector.

So, doing *both* is impressive. I hope it pays off big!

On 1/17/2014 4:24 PM, Terrence Cole wrote:
> Exact stack rooting is now enabled by default on desktop builds of firefox.

Does this mean that the moving GC is also enabled, or is that a later step?

If we see an increase in the crash rate for nightly builds, is it likely
that they will share a signature, or will this mainly expose itself as
memory corruption, which typically don't have useful crash
stacks/signatures? Are there ways for users who are seeing crashes to
turn on extra debugging (memory poisoning in the GC, for example) in
order to make crashes more reliable?

The stability team will be watching crash-stats closely over the next week.

--BDS

On 01/18/2014 07:08 AM, Benjamin Smedberg wrote:
> On 1/17/2014 4:24 PM, Terrence Cole wrote:
>> Exact stack rooting is now enabled by default on desktop builds of
>> firefox.
> Does this mean that the moving GC is also enabled, or is that a later step?

No, moving GC is a later step. We are targeting moving GC to land in the
next cycle so that we can more easily separate the problems.

> If we see an increase in the crash rate for nightly builds, is it likely
> that they will share a signature, or will this mainly expose itself as
> memory corruption, which typically don't have useful crash
> stacks/signatures?

The second, although stacks will probably have a relatively tight
cluster too. Specifically, a crash here will manifest as use-after-free,
generally through some specific, local GC pointer variable.

> Are there ways for users who are seeing crashes to
> turn on extra debugging (memory poisoning in the GC, for example) in
> order to make crashes more reliable?

Great question! We have a tool called "GC zeal" in builds with
--enable-gc-zeal and in all debug builds unconditionally. It adds a
small runtime overhead, but gives us fine-grained control over when GC's
happen and adds several verification modes for debugging specific
problems. I was under the impression that nightlys had this enabled, but
I am not seeing it there now.

> The stability team will be watching crash-stats closely over the next week.

Thanks for keeping an eye out!

-Terrence

> --BDS
>

----- Original Message -----
> Great question! We have a tool called "GC zeal" in builds with
> --enable-gc-zeal and in all debug builds unconditionally. It adds a
> small runtime overhead, but gives us fine-grained control over when GC's
> happen and adds several verification modes for debugging specific
> problems. I was under the impression that nightlys had this enabled, but
> I am not seeing it there now.

Nightly has compartment checking enabled, which may be what you are thinking of.

Andrew

On 1/18/14, 9:04 AM, Terrence Cole wrote:
> Great question! We have a tool called "GC zeal" in builds with
> --enable-gc-zeal and in all debug builds unconditionally. It adds a
> small runtime overhead, but gives us fine-grained control over when GC's
> happen and adds several verification modes for debugging specific
> problems. I was under the impression that nightlys had this enabled, but
> I am not seeing it there now.

Are there (inexpensive) runtime sanity checks that could be enabled in
all Nightly release builds? The Nightly channel already has extra checks
enabled that make it inappropriate for benchmarking, like
--enable-profiling and some ref counting checks that will MOZ_CRASH.


chris

On 1/17/14 1:24 PM, Terrence Cole wrote:
> SpiderMonkey will no longer scan the stack for live roots; you must now
> wrap all GC thing pointers that live on the stack across a GC in the
> JS::Rooted template for SpiderMonkey to see them. See the comments in
> js/public/RootingAPI.h and the guide on the developer wiki[1] for
> further details. All currently existing instances in the browser build
> have been updated; the hazard analysis build on TBPL, SM(Hf), will catch
> any future pushes that break this invariant.

Great work! My only question: do JIT backends need to be adjusted for
this? I assume not, but I want to make sure.

Cameron Kaiser

On Fri, Jan 17, 2014 at 3:22 PM, Jim Blandy <ji...@mozilla.com> wrote:
>
> I've never heard of a major project escaping from conservative GC once it
> had entered that state of sin; nor have I heard of anyone implementing a
> moving collector after starting with a non-moving collector.

There's no better way to answer the question "has X been done?" than
proclaiming loudly on the internet that "X has never been done!"

I did this by quoting Jim in a blog post [1] and was promptly informed
that both Racket and Mono have done this.

But who cares? This is a fantastic achievement, and I eagerly
anticipate the changes it will enable.

Nick

[1] https://blog.mozilla.org/nnethercote/2014/01/20/a-big-step-towards-generational-and-compacting-gc/

You are correct, there should be no extra work. The codegen bits should
be running in a context that cannot GC.

> Cameron Kaiser
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform