[Soot-list] PackManager.writeOutput() and using Soot classes outside soot.Main

[Eric Bodden]

forgot to copy to the list...

2008/12/5 Eric Bodden <eric.bodden at mail.mcgill.ca>:
> I see. Yes, in that case it may indeed be more convenient to "hack"
> Soot. I don't see how that could break anything. From what I can see
> right now there's no way in Soot to get what you want without changing
> Soot.
>
> Eric
>
> 2008/12/5 Joe Roback <robackja at cs.arizona.edu>:
>> Because running Soot on a small application requires a minimal VM size
>> of 640MB of memory. At this point, our choices are hack up Soot to not
>> release the bodies or spawn soot in other thread, and just have it
>> block when we are done transforming. (spawning in a thread and
>> blocking doesn't release any of soot's memory, obviously)
>>
>> I have no control the overall code layout, and another part of the
>> project is calling our stuff like a library, we just happen to be
>> using soot for the bytecode manipulation (theoretically this backend
>> should be able to use any java bytecode manipulator). So integrating
>> soot.Main into the grand-scheme of things is not really an option.
>>
>> again, we are trying to use SOOT in an unconventional way, so I really
>> not asking for SOOT to make any modifications, etc, just curious,
>> since if we hack up soot and remove that piece, I didn't want to be
>> removing some critical piece.
>>
>> so, thanks for the clarification eric. i appreciate your help.
>>
>> Joe
>>
>> On Fri, Dec 5, 2008 at 5:16 PM, Eric Bodden <eric.bodden at mail.mcgill.ca> wrote:
>>> I agree that it does not really make much sense to release the bodies.
>>> I am not quite sure why this was implemented; maybe somebody was just
>>> being overly tidy.
>>>
>>> On the other hand I am not sure what it would buy you even if you
>>> could turn off the release of bodies. Still, you would have to keep
>>> the VM from terminating so that you can still have access to the
>>> bodies later on. The only difference I could see is that with the
>>> current setup your server code would constantly run within the control
>>> flow of soot.Main, while without the release of bodies you could have
>>> it run "outside". Why would that matter to you?
>>>
>>> Eric
>>>
>>> 2008/12/5 Joe Roback <robackja at cs.arizona.edu>:
>>>> So the real problem with using SootClasses outside soot.Main() is when
>>>> PackManager.writeOutput() is called. PackManager.java, line 394:
>>>>
>>>> releaseBodies( reachableClasses() ); which in turn calls
>>>> m.releaseActiveBody() on each SootMethod... Which set's the activeBody
>>>> = null for all methods. This makes using these classes after soot.Main
>>>> impossible, since they have no active bodies. Soot is exiting, is
>>>> there any reason to set the activeBodies to null? Is there some soot
>>>> option I can use to prevent this?
>>>>
>>>> thanks.
>>>> _______________________________________________
>>>> Soot-list mailing list
>>>> Soot-list at sable.mcgill.ca
>>>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>>>
>>>
>>>
>>>
>>> --
>>> Eric Bodden
>>> Sable Research Group, McGill University, Montréal, Canada
>>> Got an interesting job offer? http://www.bodden.de/hire-me/
>>>
>>>
>>
>
>
>
> --
> Eric Bodden
> Sable Research Group, McGill University, Montréal, Canada
> Got an interesting job offer? http://www.bodden.de/hire-me/
>



-- 
Eric Bodden
Sable Research Group, McGill University, Montréal, Canada
Got an interesting job offer? http://www.bodden.de/hire-me/