[Soot-list] Seeking proposals for Google Summer Of Code projects

[Bernhard Berger]

Hi Patrick,

I made the experience with Jimple. If you take a look at the steps that are executed if you load jimple files it is not very surprising that it's not faster. I think if we can skip those steps and load/store a binary version containing all information this should be faster (at least for local processing).


Bernhard

Am 17.02.2013 um 04:45 schrieb Patrick Lam <p.lam at ece.uwaterloo.ca>:

> A long time ago, I tried to dump Jimple to disk and re-parse it. It 
> didn't save that much time for me. It shouldn't be hard to give that a 
> try and see if it's actually faster; caching it on the web is only going 
> to be faster if it's faster to read it from disk.
> 
> pat
> 
> On 02/16/2013 01:49 PM, Phil Pratt-Szeliga wrote:
>> Hello,
>> 
>> A project that I was thinking of doing at one time was called the
>> Jimple Web Cache. It is a server online that users can submit an
>> rt.jar. The webserver takes an md5sum of the jar and computes the
>> whole program call graph. It will store the Jimple for the whole
>> program call graph in a database. Then a user can ask for the
>> reachable Jimple and call graph from a certain method and rt.jar
>> md5sum. Raising Java Bytecode to Jimple is a slow step and this could
>> improve whole program analysis performance.
>> 
>> Phil Pratt-Szeliga
>> Syracuse University
>> http://trifort.org/
>> 
>> On Sat, Feb 16, 2013 at 1:39 PM, Marc-Andre Laverdiere-Papineau
>> <marc-andre.laverdiere-papineau at polymtl.ca>  wrote:
>>> Hello,
>>> 
>>> I am just trying to put my 2 cents on that thread...
>>> 
>>> Reading the Spark thesis, it seems to me that the defaults are pretty
>>> good for the fixed point calculation - I don't see much improvements here.
>>> 
>>> The only thing I noticed is that there are fast(er) bit set
>>> implementations, but that's about it.
>>> 
>>> What do you have in mind?
>>> 
>>> Marc-André Laverdière-Papineau
>>> Doctorant - PhD Candidate
>>> 
>>> On 13-02-16 01:25 PM, Phil Pratt-Szeliga wrote:
>>>> Hi Eric
>>>> 
>>>>>> The existing soot class loader loads every type string accessible from
>>>>>> the constant pool when loading methods to bodies. With my new class
>>>>>> loader I only load type strings accessible from a depth first search
>>>>>> walk from entry points described by the user. The also helps with the
>>>>>> dependency problems that can happen if you don't have all of the jars.
>>>>> 
>>>>> This sounds indeed nice to have. I am not sure if it would be a good
>>>>> GSOC project, though, as it sounds like pure integration work.
>>>>> Wouldn't this be just a matter of preparing a proper patch / pull
>>>>> request?
>>>> 
>>>> Okay, I'll look into doing this pull request in maybe a month or so. I
>>>> still have some things to work on. It needs some better data
>>>> structures to execute a fixed-point faster, but yeah, probably not
>>>> enough for a GSOC project.
>>>> 
>>>> Thanks,
>>>> Phil Pratt-Szeliga
>>>> Syracuse University
>>>> http://trifort.org/
>>>> _______________________________________________
>>>> 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
>>> 
>>> 
>> _______________________________________________
>> 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