[Soot-list] qustion about loop fusion

[caoj at purdue.edu]

Hi John:

Thanks for your help.

My class file has problem of "Exception in thread "main" 
java.lang.VerifyError: (class: A, method: main signature: ([Ljava/lang/String;)
V) Accessing value from uninitialized register 2". So I use "javap -c" to 
disassemble my class file into the following codes:
javap -c A       
Compiled from "A.java"
class A extends java.lang.Object{
public static void main(java.lang.String[]);
  Code:
   0:   bipush  10
   2:   newarray int
   4:   astore_0
   5:   iconst_0
   6:   istore_1
   7:   iload_2
   8:   bipush  10
   10:  if_icmpge       64
   13:  aload_0
   14:  iload_1
   15:  iload_1
   16:  iastore
   17:  getstatic       #38; //Field java/lang/System.out:Ljava/io/PrintStream;
   20:  new     #18; //class java/lang/StringBuffer
   23:  dup
   24:  invokespecial   #22; //Method java/lang/StringBuffer."<init>":()V
   27:  ldc     #39; //String a[
   29:  invokevirtual   #8; //Method java/lang/StringBuffer.append:
(Ljava/lang/String;)Ljava/lang/StringBuffer;
   32:  iload_2
   33:  invokevirtual   #24; //Method java/lang/StringBuffer.append:(I)
Ljava/lang/StringBuffer;
   36:  ldc     #23; //String ]=
   38:  invokevirtual   #8; //Method java/lang/StringBuffer.append:
(Ljava/lang/String;)Ljava/lang/StringBuffer;
   41:  aload_0
   42:  iload_2
   43:  iaload
   44:  invokevirtual   #24; //Method java/lang/StringBuffer.append:(I)
Ljava/lang/StringBuffer;
   47:  ldc     #7; //String \n
   49:  invokevirtual   #8; //Method java/lang/StringBuffer.append:
(Ljava/lang/String;)Ljava/lang/StringBuffer;
   52:  invokevirtual   #11; //Method java/lang/StringBuffer.toString:()
Ljava/lang/String;
   55:  invokevirtual   #10; //Method java/io/PrintStream.println:
(Ljava/lang/String;)V
   58:  iinc    2, 1
   61:  goto    7
   64:  return

public A();
  Code:
   0:   aload_0
   1:   invokespecial   #35; //Method java/lang/Object."<init>":()V
   4:   return

}

Can you see what problem is? Is there any tutorial for these disassembled 
codes? Thanks.

Attaced is the class file.

Jun Cao

Quoting John Jorgensen <jorgnsn at lcd.uregina.ca>:

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: A.class
Type: application/java
Size: 606 bytes
Desc: not available
Url : http://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20060302/35f4b27c/A-0001.bin