[Soot-list] Disable Jimple unused variable elimination process
Ben Holland
benjholla at gmail.com
Thu Oct 4 14:16:39 EDT 2018
I've noticed that SOOT does dead code elimination regardless of any
configurations (its harded coded in the default packs). We had experimented
with disabling it at one point, but found it was causing problems in type
inference. If I remember right everything goes through the Jimple
intermediate stage so even just loading bytecode and outputting bytecode
directly went through the default Jimple packs that did dead code
elimination/constant propagation sort of steps (sorry its been a little
while since I looked at this so going on memory). So anyway even "a null
transformation" did not output original bytecode. This was somewhat of a
headache for me for a project I worked on because I wanted to create an
alignment between a program graph we created from Jimple and each Jimple
instruction, but each time SOOT loaded the jimple code into memory it went
through another iteration of the jimple packs and messed up my existing
alignment. I saw I could eventually reach a fixed point around give or take
3 round trips of null transformations., however in the end I opted for a
simpler approach of just loading the original bytecode again with the exact
same configurations and letting SOOT do its thing again in an identical way
to get back to the state of how things looked when the jimple was
originally outputted.
Here was a test my colleague ran. For this example, he used Oracle Java 8
and it did not seem to remove that local variable.
Note that foo1 and foo2 differ by whether the local is used. Note that
there is still an istore_1 instruction. That suggests SOOT/Jimple is
removing it somehow.
Source:
public class Test {
public void foo1() {
int a = method1();
}
public int foo2() {
int a = method1();
return a;
}
public int method1() {
return 0;
}
}
Decompiled:
public void foo1();
descriptor: ()V
flags: ACC_PUBLIC
Code:
stack=1, locals=2, args_size=1
0: aload_0
1: invokevirtual #2 // Method method1:()I
4: istore_1
5: return
LineNumberTable:
line 4: 0
line 5: 5
public int foo2();
descriptor: ()I
flags: ACC_PUBLIC
Code:
stack=1, locals=2, args_size=1
0: aload_0
1: invokevirtual #2 // Method method1:()I
4: istore_1
5: iload_1
6: ireturn
LineNumberTable:
line 8: 0
line 9: 5
On Thu, Oct 4, 2018 at 1:04 PM Chris Shiflet <cshiflet at pjrcorp.com> wrote:
> I hope I'm correct in saying this, but I believe that Eric probably meant
> "javap".
>
>
> Running "javap <class file>" will disassemble the class file, and you can
> see if the Java compiler preserved your variable, "a".
>
>
> Best,
>
> ---Chris
> ------------------------------
> *From:* Soot-list <soot-list-bounces at CS.McGill.CA> on behalf of Eric
> Bodden <eric.bodden at uni-paderborn.de>
> *Sent:* Thursday, October 4, 2018 8:55:38 AM
> *To:* 陳日揚
> *Cc:* soot-list at cs.mcgill.ca
> *Subject:* Re: [Soot-list] Disable Jimple unused variable elimination
> process
>
> Hi again.
>
> This is strange, especially because Soot normally generates Shimple from
> the Jimple representation. Hence, if the variable is not present in Jimple,
> how can it show up in Shimple? I actually wonder whether it’s somehow
> reintroduced by the value numbering that occurs during the SSA generation.
>
> To be sure about the bytecode, would you mind using “javac” to inspect the
> .class file to see whether “a” is present there?
>
> Cheers
> Eric
>
> > On 2. Oct 2018, at 17:07, 陳日揚 <t106598014 at ntut.org.tw> wrote:
> >
> > Hi Eric,
> >
> > Thanks for your reply!
> > I've tried to output Shimple format instead of Jimple, and I found that
> the unused local variable's information was still retained in Shimple
> format("i0" for the following example).
> > So I think those variables are not thrown away by the compiler.
> >
> > Here are the bytecode and the Shimple code of the previous example:
> >
> > Bytecode:
> > public void foo();
> > Code:
> > 0: aload_0
> > 1: invokespecial #2 // Method method1:()I
> > 4: istore_1
> > 5: return
> >
> > Shimple code:
> > public void foo()
> > {
> > X r0;
> > int i0;
> >
> > r0 := @this;
> >
> > i0 = specialinvoke r0.method1();
> >
> > return;
> > }
> >
> > Thank you for your help!
> >
> > Best regard,
> > Andy
> >
> > Eric Bodden <eric.bodden at uni-paderborn.de> 於 2018年10月2日 週二 下午10:16寫道：
> > Hi Andy.
> >
> > Are you sure that those variables are actually not already thrown away
> by the compiler? I would think so, actually. If so, then obviously Soot has
> no way to recover them, except if you analyze the source code.
> >
> > Cheers
> > Eric
> >
> > > On 26. Sep 2018, at 15:42, 陳日揚 <t106598014 at ntut.org.tw> wrote:
> > >
> > > Hi,
> > >
> > > I want to do some analyses in BodyTransformer for Jimple code which
> was transformed from .class files. It seems that Soot've done some
> optimizations like eliminating unused variables in Jimple Body Creation
> phase. I'm wondering can I disable such elimination process so that I can
> get unused variables' informations in Jimple code.
> > >
> > > I've tried disable "Unused Local Eliminator" and "Dead Assignment
> Eliminator" commandline options("-p jb.ulp enabled:false -p jb.dae
> enabled:false"), but the input program below still output Jimple code
> without variable "a"'s information.
> > >
> > > Java source code(compile to .class file before running Soot):
> > > public void foo() {
> > > int a = method1();
> > > }
> > >
> > > Output Jimple code:
> > > public void foo() {
> > > X r0;
> > > r0 := @this: X;
> > > specialinvoke r0.<X: int method1()>();
> > > return;
> > > }
> > >
> > > Thanks a lot !
> > >
> > > Best regard,
> > > Andy
> > > _______________________________________________
> > > Soot-list mailing list
> > > Soot-list at CS.McGill.CA
> > > https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
> >
>
> _______________________________________________
> Soot-list mailing list
> Soot-list at CS.McGill.CA
> https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
> _______________________________________________
> Soot-list mailing list
> Soot-list at CS.McGill.CA
> https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20181004/70676b0c/attachment-0001.html>
More information about the Soot-list
mailing list