Investigate SpiderMonkey GC rooting performance

[kmcallister]

Servo will do a lot more rooting and unrooting than Gecko, because we have a JS-managed DOM. This is especially the case once we stop using the conservative stack scanner.

SpiderMonkey stores roots in a linked list. We only pop from the end of this list, but it's still the case that linked lists are pretty inefficient in terms of allocations and cache line packing. We should measure the performance and try alternative data structures. A dynamic array (i.e. vector) might work well.

This needs to be compatible with the public SpiderMonkey API, which might mean teaching SpiderMonkey to look in two places for roots — the linked list, and the new data structure. When one of the two is empty (and represented by a NULL pointer) this should have minimal overhead.

[jdm]

To clarify, SpiderMonkey internally uses the types in http://mxr.mozilla.org/mozilla-central/source/js/public/RootingAPI.h such as Rooted<JSObject> extensively. These all use the linked list that sits in the JSContext, so any system we create that does not use said list must either replace it (and thereby play well with SpiderMonkey's current API) or supplement it.

[kmcallister]

We can do this without modifying SpiderMonkey, by rooting just our data structure and teaching SpiderMonkey how to trace it. This is what Gecko does for dictionaries.

See also the existing StackRoots and RootCollection structures in Servo.

[jdm]

SpiderMonkey provides a CustomAutoRooter/AutoGCRooter API which allows custom tracing behaviour.

[KiChjang]

Is this still relevant, given that we have similar looking types in js.rs?

[jdm]

Yep. We're still doing the same rooting strategy as SpiderMonkey (ie. linked lists).