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

[Joe Roback]

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/
>
>