Implement static rooting analysis

[Yves]

The problem

One major problem of exact stack rooting is that unsafe rooting is hard to detect. A problem can stay hidden in most cases when garbage collection runs on the predefined schedule but when the game triggers an extra GC because of low memory or other reasons, it can suddenly trigger such bugs.

Existing solution: dynamic rooting analysis

Dynamic rooting analysis (using the GC_Zeal flag as described in ​JSRootingGuide) allows testing with increased garbage collection frequency. Unfortunately, with maximum frequency it's very slow and makes it impractical to test the whole game. I've interrupted it after about one hour when loading a map with GC_ZEAL set to 2,10 (It didn't start the match in that time and that's not even the highest frequency). We might run some replays with these settings from time to time on an unused computer (or a VM on a server), but an alternative way of finding problems is needed. Especially for tests cases like GUI scripts that currently require active input.

New (additional) solution: static rooting analysis

Mozilla uses static analysis to find potential rooting issues. It might be something we can use too. The best information so far is this:

Source: ​Articel: Clawing Our Way Back To Precision

Brian Hackett implemented the static analysis based on his sixgill framework. It operates as a GCC plugin that monitors all compilation and sends off the control flow graph to a server that records everything in a set of databases, from which a series of Javascript programs pull out the data and analyze it for rooting hazards.

I'll most likely have to ask Steve Fink or Brian Hackett because I couldn't find any sources or documentation for the GCC plugin, the server part or the Javascript scripts mentioned in this description.

[Yves]

Steve Fink has shown me how to setup the static rooting analysis in two productive (and quite long) IRC sessions. Thanks a lot! I've documented most information in the wiki: StaticRootingAnalysis

I would say the static analysis is not absolutely essential for us, but it's definitely a nice and helpful tool. Internally, SpiderMonkey doesn't always use the rooted types (for performance reasons). In this case such a tool is much more important than for us. Still, we should aim for integrating it in our build process so that everyone can use it without a long setup procedure. There are still cases where a rooting issue in our code could be hard to find and where the static analysis could make the search a lot easier.

[Stan]

@Yves any update on this with SM31 ?

[Yves]

I should have a look when we also have the Linux slave for Jenkins and I should probably check manually if there are any new rooting hazards now.