[Soot-list] question about Soot optimization

[Mu Zhang]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20120425/9dc0da05/attachment.html