[Soot-list] Jimplification via ASM , was: SOAP workshop summary

[Eric Bodden]

Hello Aaloan.

Could you tell me a bit more about this code? For instance, how well
was it tested? Does it convert all bytecodes (including Java 7's
invokedynamic) into Jimple? How about bytecode attributes?

@Patrick: Is the ASM license compatible with Soot's LGPL?

Best wishes,
Eric


On 18 June 2012 02:18, Aaloan Miftah <aaloanmiftah at yahoo.com> wrote:
> 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
>
>
>
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>



-- 
Eric Bodden, Ph.D., http://bodden.de/
Head of Secure Software Engineering Group at EC SPRIDE
Principal Investigator in Secure Services at CASED
Tel: +49 6151 16-75422    Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt