[Soot-list] qustion about loop fusion

John Jorgensen jorgnsn at lcd.uregina.ca
Thu Mar 2 12:00:18 EST 2006


    caoj> Can you see what problem is? Is there any tutorial for
    caoj> these disassembled codes?

Thee authoritative source for information on the disassembled
codes is the description of the Java Virtual Machine Instruction
Set in the JVM specification:

 http://java.sun.com/docs/books/vmspec/2nd-edition/html/Instructions.doc.html

One tutorial I know of (10 years old, but the information it
talks about probably still holds) is:

  http://www.artima.com/underthehood/bytecode.html

It's part of a series of "Under the Hood" articles at

  http://www.artima.com/underthehood/index.html

whose author also wrote a book about the VM:

  http://www.artima.com/insidejvm/blurb.html

But any experience with any assembly language is probably enough
to understand the problem with your disassembled class, which
occurs first at the instruction labeled "7:"

    caoj> public static void main(java.lang.String[]);
    caoj>   Code:
    caoj>    0:   bipush  10
    caoj>    2:   newarray int
    caoj>    4:   astore_0
    caoj>    5:   iconst_0
    caoj>    6:   istore_1
    caoj>    7:   iload_2

"iload_2" means load from local variable 2 onto the expression
stack(like loading from a machine register).  But the method has
never stored anything into local 2, so the verifier is correct
to warn you that the method will read from an uninitialized
variable.

>From the rest of the code, it seems clear that instruction "7:"
should be "iload_1", that is, load the value from local 1 onto
the stack (to act as the loop counter), not local 2.  Similarly
instructions 32:

    caoj>    32:  iload_2

and 42:

    caoj>    42:  iload_2

should be "iload_1" instead, and instruction 58:

    caoj>    58:  iinc    2, 1

which increments local 2 should increment local 1 (i.e. "iinc 1, 1") 
instead.

I suspect that when your transformation fuses the two loops, it
fails to ensure that all references to the loop index variable in
instructions from the second loop get changed to refer to the
loop index variable for the first loop instead.  

The necessity of doing that might not be clear in your example,
where the two loops both call their index variable "i".  But part
of Soot's analysis will notice that the two uses of the index
variable are entirely independent (i.e., that the final value of
i after the first loop is ignored by the second loop) and will
split the two uses into two corresponding variables.


More information about the Soot-list mailing list