[Soot-list] qustion about loop fusion

John Jorgensen jorgnsn at lcd.uregina.ca
Thu Mar 2 00:15:09 EST 2006


>>>>> "caoj" == Jun Cao <caoj at purdue.edu> writes:

    caoj> What I do in the loop fusion is to delete some stmts
    caoj> between two adjacent loops. And I also relpace first
    caoj> gotostmt of first loop with first gotostmt of second
    caoj> loop. I am wondering where the error comes from. Do I
    caoj> need to do other work for this simple case?  Thanks.

The most straightforward way that such a transformation could
introduce a verification error would be if the deleted statements
included the initialization of some local variable that might be
read later on in the method (though I didn't notice any such
deleted initialization in the jimple you posted).

Note that the conservative assumptions of the verifier's dataflow
analysis means that it might think that there is a control flow
path that leads to the local being read before being initialized,
even though a more sophisticated analysis could prove the path
could not be taken.  For example, I suspect (though I haven't
reread the spec to confirm the suspicion) that with code like
this:

  i0 = 0
  if i0 > 10 goto label3
  i1 = 4
  label3:
  return i1

the verifier would not be smart enough to see that conditional
branch to label3 can never taken.  So if no assignment to i1
occurred before these instructions, the verifier would think that
the return instruction might try to read i1 before it had ever
been assigned a value, and it would raise a VerifyError.

If you don't already know about the bytecode verifier, it's
described in section 4.9 of the VM specification
<http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html#88597>

There's also a description of my experience with transformations
which might generate unverifiable code in sections 2.6 and 3.4 of
the technical report on analyzing exceptional control flow in
soot
<http://www.sable.mcgill.ca/publications/techreports/#report2003-3>,
but the VM specification is probably a clearer explanation.

    caoj> How do I examine the the bytecode in the output class
    caoj> file? 

The method that you will certainly have available to you is 

  javap -c <classname>

since javap comes with J2SE. See "javap -help" for details.

There are probably other classfile disassemblers available; I've
tried using D-Java, <http://mrl.nyu.edu/~meyer/jvm/djava/>, whose
major feature is that it can produce files which can be fed to
the jasmin assembler.



More information about the Soot-list mailing list