Opened 10 years ago

Last modified 9 years ago

#2415 closed task

Scripting transition to exact stack rooting and moving GC — at Version 5

Reported by: Yves Owned by: Yves
Priority: Must Have Milestone: Alpha 18
Component: Core engine Keywords: Spidermonkey
Cc: Patch:

Description (last modified by Yves)

Depends on

#2416
#1886
#2428

What is rooting?

Javascript uses garbage collection to detect unused variables and objects that can be deleted. If you use a jsval/JS::Value/CScriptVal or any other variables that point to storage managed by the garbage collector, you need to root it. Rooting tells the garbage collector that this value is still in use and can't be overwritten by something else.

What is exact stack rooting

Currently (with v1.8.5 and v24), SpiderMonkey scans the stack for anything that looks like a pointer to a GC thing. This is called conservative stack scanning. It prevents the garbage collector from deleting an unrooted jsval you use in a function for example.

Future versions will not support that stack scanning anymore and require exact rooting instead. Exact stack rooting means the programmer is responsible for keeping the garbage collector informed about every GC thing he uses on the stack.

What is a moving GC

A moving GC can change the location in memory where a script value is stored. Moving the object a JSObject* points to invalidates the JSObject pointer for example. Instead of just rooting a value once and using as many pointers to it as you need, you now have to inform the garbage collector about every pointer to the value because it has to change that pointer if it moves the value.

Why do we need this?

There's more work to do for the rooting, the code looks a little bit uglier and failing to do it properly causes crashes and security holes. Why do we want this? The reasons and some more technical background is explained very well in this blog post.

Honestly, I'm not quite convinced that the efforts are worth the benefits. Anyway, support for conservative stack scanning will be dropped in one of the next releases and we are basically forced to make this transition.

How do we tackle this?

The API needed for exact stack rooting is already available in SpiderMonkey V24. Also functionality to find issues and features requiring exact stack rooting can be enabled already in V24. After the upgrade (#1886) we can start the transition to exact rooting step by step while keeping track of the remaining number of reported rooting hazards. The linked resources explain some features that can be used to detect and report such rooting hazards. As soon as everything is done, we can enable features that rely on exact stack rooting.

Time frame

I've heard that Mozilla plans to drop support for conservative stack scanning by ESR31, which will be released around July 2014. After a short IRC discussion with some of the developers it seems possible that they can delay it a bit and give us more time for the transition (there's nothing definitive though).

Resources

Blog post explaining technical background and reasons
SpiderMonkey MDN GC Rooting Guide
SpiderMonkey MDN Exact Stack Rooting
Partially outdated GC documentation

Change History (5)

comment:1 by Yves, 10 years ago

Description: modified (diff)

comment:2 by Yves, 10 years ago

In 14724:

Removes ValueCloner.

Fixes #2416
Refs #2415
Refs #1886

comment:3 by Yves, 10 years ago

Status: newassigned

comment:4 by Yves, 10 years ago

In 14733:

Reverts r14724. Structured clones don't support cyclic references in SpiderMonkey v1.8.5.
SpiderMonkey v24 supports it and I'll add this change to #1886 instead.

Refs #2416
Refs #2415
Refs #1886

comment:5 by Yves, 10 years ago

Description: modified (diff)
Note: See TracTickets for help on using tickets.