[Soot-list] question about Soot optimization

[Eric Bodden]

Hi Mu.

I guess you could easily implement such an optimization yourself. I
don't think there's any default optimization of that kind implemented
in Soot.

Setting a field to be volatile (or not) can be achieved just by
setting the appropriate modifiers.

Eric

On 25 April 2012 19:30, Mu Zhang <muzhang82 at gmail.com> wrote:
> Hi,
>
> Thank you for the reply.
>
> I understand that such optimization is not sound in general sense when
> taking multi-threading into consideration. However, since the instance is
> introduced and only used in instrumentation, it is possible for me to
> guarantee that it's not subject to parallel access.
>
> Given that as the hypothesis, is there a way to optimize specific instance
> field by telling Soot to do so? Does Soot support setting a certain field to
> be "volatile" or something equivalent?
>
> Mu
>
>
> On Wed, Apr 25, 2012 at 4:53 AM, Tobias Gutzmann <tobias.gutzmann at lnu.se>
> wrote:
>>
>> Hi,
>>
>> I don't think that's entirely true, Eric. Such an optimization should be
>> allowed as long as "b" is not "volatile"
>> See table 17.4 at the JVM spec:
>> http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4
>> It's not exactly the same, but a similar situation.
>>
>> /Tobias
>>
>> On 2012-04-25 10:38, Eric Bodden wrote:
>> > Hi Mu.
>> >
>> > The optimization you propose is not sound in multi-threaded programs.
>> > The field's value could have been modified between both assignments,
>> > which would make the second assignment necessary.
>> > My guess is that, since usually Soot has no knowledge about whether
>> > your program is multi-threaded or not, or which parts of it may be, it
>> > assumes the worst and hence does not apply the optimization.
>> >
>> > Eric
>> >
>> > On 25 April 2012 01:29, Mu Zhang<muzhang82 at gmail.com>  wrote:
>> >> Hi,
>> >>
>> >> I have a question about Soot optimization. I'm writing a program to
>> >> instrument Java bytecode and using Soot to remove redundant code.
>> >> However, I
>> >> found Soot was not able to optimize the instrumented code in some
>> >> cases.
>> >> Here is an example and the redundant instructions are in black:
>> >>
>> >> public int cryptWrapper(int, tester.BoolWrapper, tester.BoolWrapper,
>> >> tester.BoolWrapper)
>> >>      {
>> >>          tester.B r0;
>> >>          int i0, i1, $i2;
>> >>          tester.BoolWrapper r1, r2, r3;
>> >>          boolean z0, z1, z3, z4;
>> >>
>> >>          r0 := @this: tester.B;
>> >>          i0 := @parameter0: int;
>> >>          r1 := @parameter1: tester.BoolWrapper;
>> >>          r2 := @parameter2: tester.BoolWrapper;
>> >>          r3 := @parameter3: tester.BoolWrapper;
>> >>          z0 = r2.<tester.BoolWrapper: boolean b>;
>> >>          z1 = r1.<tester.BoolWrapper: boolean b>;
>> >>          z3 = r3.<tester.BoolWrapper: boolean b>;
>> >>          $i2 = r0.<tester.B: int key>;
>> >>          i1 = i0 ^ $i2;
>> >>          z4 = z1 | 0;
>> >>          r2.<tester.BoolWrapper: boolean b>  = z0;
>> >>          r1.<tester.BoolWrapper: boolean b>  = z1;
>> >>          r3.<tester.BoolWrapper: boolean b>  = z4;
>> >>          return i1;
>> >>      }
>> >>
>> >> Basically, z0 is assigned with r2.b and later is assigned to r2.b
>> >> without
>> >> any modification in between. I was wondering if it is because Soot
>> >> considers
>> >> r2.b to be an object field with side-effects and thus doesn't optimize
>> >> it.
>> >> If that is true, I'm curious to know how Soot determine whether a local
>> >> has
>> >> side-effects or not. Does it simply consider all objects have
>> >> side-effects?
>> >> Also, is there a way to trick Soot and bypass the check, so that it can
>> >> optimize some certain instructions that may have side-effects?
>> >>
>> >> Thanks,
>> >>
>> >> Mu
>> >>
>> >> _______________________________________________
>> >> 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
>



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