[15 Sep]
- I ran intra-procedural very-live analysis on SableCC and antlr. Following are the number of instrumentation that can be removed and number of instrumentations that can not be removed.
SableCC
| input | removed | still left |
| Java 1.1 | 2,270,232,483 | 4,815,365,848 |
| Java 1.02 | 1,877,636,122 | 4,361,091,538 |
| SableCC | 9,318,915 | 12,374,145 |
| ... | 1,132,346,183 | 1,411,764,907 |
Antlr
| html.g | 5,007,219 | 4,614,933 |
| stdcparser.g | 6,671,158 | 4,949,768 |
Live variable analysis:
SableCC
| Java 1.1 | 4,474,992,956 | 2,610,605,375 |
| Java 1.02 | 3,920,842,271 | 2,317,885,382 |
So what next? Interprocedural analysis?
- Wanted to calculate the alias pairs from points-to result in JABA. I could find out alias pairs among local variables like (a, b). But it needs a lot of work to find pairs such as (a.f, b.f), (a.f,x).
- Implemented the same for soot. Due to the three-address form of jimple codes that soot works on, there is a local name associated with all field references like a.f, b.f etc.. So it is sufficient to find relationships between locals. I have not run with big programs yet.
- Intra-procedural very-live analysis was getting stuck analyzing a huge method in soot (soot as a subject). I thought it is a memory problem. So I embarked on a 2 days hack to add a preprocessing step. This step produces a stripped CFG, from which all stmts which do not affect the analysis, like algebric operations are removed. This trick helps the flow-sensitive points-to analysis for C significantly as reported by Mike Hind et. al. Thought the situation would be similar for Java. Unfortunately not. Methods are usually so small that it is not worth spending time stripping the CFG of every method. My implementation still gets stuck with soot. It has 10,000 jimple stmts.
Last modified 16 September 2004 at 12:19 am by Saswat Anand |