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

[Patrick Lam]

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