[Soot-list] SOAP workshop summary

[Aaloan Miftah]

Hi,

> by optimizing how Soot creates Jimple
I've attached the asm based builder I use to generate Jimple. There is a noticeable increase in performance (mainly because the jb phase has less to do).

Aaloan


________________________________
 From: Patrick Lam <plam at sable.mcgill.ca>
To: "Soot-list at sable.mcgill.ca" <Soot-list at sable.mcgill.ca> 
Sent: Saturday, June 16, 2012 9:55 PM
Subject: [Soot-list] SOAP workshop summary
 
Hi all,

At PLDI last week in Beijing, we ran the SOAP workshop, bringing
together Soot users for an invited talk, 8 contributed talks on
applications and extensions of Soot, and a discussion on the future of
Soot. Workshop organizers included Eric Bodden, Bruno Dufour, Laurie
Hendren, Patrick Lam, and Elena Sherman (who instigated the idea, but
could not attend). I counted up to 27 non-organizer participants in
the audience for the workshop.

Anders Moeller gave an invited talk in two parts. The first part
described his use of Soot for performing string analysis on Java
programs, while the second part discussed something completely
different, a tour-de-force of static analysis for inferring types in
JavaScript code.

The string analysis extracted a subset of the Jimple IR, eventually
converting it into regular expressions summarizing potential values
for string variables.  This raises a relevant question for the Soot
community: how could Soot better support this style of analysis, which
extracts facts from a Soot IR into a custom IR and then performs
analysis on that IR?  The string analysis code required thousands of
lines of code to create its own IR. Upon further reflection, I believe
that the LogicBlox pointer analysis by Martin Bravenboer works the
same way; it extracts pointer facts from Soot and then munges them.
Could we implement some sort of domain-specific language to make this
easy?

The workshop included two broad categories of contributed talks:
infrastructure talks and application talks. Eric led off the
contributed talks with a description of an implementation of the IFDS
whole-program analysis framework and concluded the talks by explaining
how Soot now supports the invokedynamic framework. Other
infrastructure talks included an assessment, by Dacong (Tony) Yan, of
how Soot could support summary-based whole-program analysis; and a
description, by Alexandre Bartel, of a new Soot front-end for reading
Dalvik bytecode.

On the application side, we saw custom implementations of the
fundamental compiler analyses, reaching defs (demand-driven) and
side-effects (with an escape-analysis filter), as well as a novel
static analysis for determining collection disjointness, and a welcome
voice from outside the PL community describing a DB-related Soot use.
Ju Qian described a side-effect analysis which used the Gay and
Steensgaard escape analysis to sharpen its results, while Longwen Lu
presented a demand-driven interprocedural reaching definitions
analysis. I presented a static analysis to gather facts about when
Java collections were disjoint, i.e. shared no objects, assuming
standard semantics for the collection API. Finally, Karthik
Ramachandra shared how he was able to use Soot for a domain-specific
analysis, optimizing database applications, for instance by combining
(remote, and hence expensive) queries.

The final session of the workshop was a discussion of Soot's future
directions. I didn't take notes, but others did. I hope that someone
(hi, Eric!) can post a detailed summary of the discussions. A majority
of the discussion participants were hoping for better Soot
performance, perhaps through serialization of Soot state, or by
optimizing how Soot creates Jimple. We also talked about overhauling
Soot, and there was some excitement about starting over and creating a
better Soot. I am personally skeptical about big-bang rewrites and
wary of the second-system effect, so I think that the most likely path
to success is in aggressive refactoring. We would definitely need to
reduce the amount of global state (which would, as a beneficial
side-effect, ease parallelization). Soot refactoring transformations
may be interesting in their own right, when generalized, as original
research.

Overall, I'm pleased with the way the workshop turned out and think that
it was a productive exercise. I'd like to thank all the participants and
organizers for contributing to the success of the workshop!

  - Patrick Lam
_______________________________________________
Soot-list mailing list
Soot-list at sable.mcgill.ca
http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20120617/39cb2fe9/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asm.tar.gz
Type: application/x-gzip
Size: 11499 bytes
Desc: not available
Url : http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20120617/39cb2fe9/attachment-0001.gz