Printable Version of this PageHome PageRecent ChangesSearchSign In

[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