Treehydra goes Push and Pop
27 May 2008After writing a ton of docs and working through other Dehydra 0.9 blockers, I decided to cool off by doing some actual analyses. Before I get to that, I’d like to say that the last big task is to setup a buildbot for Dehydra on Linux/OSX. Thanks to yet another awesome contribution from Vlad, that’s mostly done.
So I got working on GC-safety static analysis. Originally we tried to define a complete spec before writing a single line of code. That turned to be a bad idea and resulted in a spec full of bugs. This time we are defining the analysis incrementally and as a surprise reward, it already caught a bug.
Pushing and Popping Our Way
SpiderMonkey has a lot of complex code doing applying Push/Pop-like operations on variables in a function-local manner. Examples of functions that this analysis would look at are: JS_PUSH_TEMP_ROOT/JS_POP_TEMP_ROOT and JS_LOCK/JS_UNLOCK. See bug for more. Essentially, this will help with “code must flow through here” comments on “out:” goto labels that inhabit the SpiderMonkey source.
This is an example of control-flow-sensitive analysis. It impossible without a compiler-like view of the code that Treehydra provides. It also helps to have a scalable algorithm to iterate the CFG. Luckily, David Mandelin wrote such a beast by implementing ESP for his outparam analysis. David factored-out the ESP analysis and made it available for reuse. See esp_lock.js in the test suite for an example of how to write control-flow sensitive analyses. locks_valid*.cc and locks_bad*.cc illustrate the code patterns that can be scanned for.
So if you know of any further push/pop patterns in the rest of Moz that can be checked in this manner, leave a comment.
PS. This is yet another account of Treehydra rocking the static analysis world. Exposing the slightly scary, but awesome GCC gutts via JavaScript allows one to perform precise static analyses in a civilized manner. What could be more fun?
3 Responses to “Treehydra goes Push and Pop”
May 28th, 2008 at 5:14 am
I have a feeling that all this is going to make Fx 4 so much more awesome… wouldn’t it be an idea to keep track of all the nifty things like performance gains and resolved bugs that are due to these tools / the code refactoring for Mozilla 2?
Keep us posted
May 28th, 2008 at 1:25 pm
There may be constraints in layout which are statically verifiable using CFG analysis: perhaps some of the constraints on frame reflow, see docs in http://mxr.mozilla.org/firefox/source/layout/generic/nsIFrame.h
It will take real layout hackers to formulate them precisely, but I think we can enforce certain things there.
June 30th, 2008 at 3:19 pm
nsI[Thread]JSContextStack::Push/Pop would be another one that’d be good to pay attention to.