Re: i++ in Java

Sorry, but I was very confused. It has been a while since I looked at our
bytecode rewriter, and it seemed that I presented my problem completely wrong.




<skip>
The actual problem is the following:


public class Test {
    String str="";
    public void incrementStr() {
          str +="a";
      }
}


The str+="a" statement in translated into:
This is translated into:
      0 new #5 <Class java.lang.StringBuffer>
      3 dup
      4 aload_0
      5 dup_x2
      6 getfield #10 <Field java.lang.String str>
      9 invokestatic #12 <Method java.lang.String valueOf(java.lang.Object)>
    12 invokespecial #8 <Method java.lang.StringBuffer(java.lang.String)>
    15 ldc #2 <String "a">
    17 invokevirtual #9 <Method java.lang.StringBuffer append(java.lang.String)>
    20 invokevirtual #11 <Method java.lang.String toString()>
    23 putfield #10 <Field java.lang.String str>


So dup_x2 at line 5 is the shitty instruction that I don't want.




Note compiling str = str + a; leads to code without stack insertions


      0 aload_0
      1 new #5 <Class java.lang.StringBuffer>
      4 dup
      5 aload_0
      6 getfield #10 <Field java.lang.String str>
      9 invokestatic #12 <Method java.lang.String valueOf(java.lang.Object)>
    12 invokespecial #8 <Method java.lang.StringBuffer(java.lang.String)>
    15 ldc #2 <String "a">
    17 invokevirtual #9 <Method java.lang.StringBuffer append(java.lang.String)>
    20 invokevirtual #11 <Method java.lang.String toString()>
    23 putfield #10 <Field java.lang.String str>
</skip>


I am pretty convinced that javac doesn't offer any options to programmers to
keep the compiler from putting dupx_2 instructions into the generated bytecode?


Does anybody has an exhaustive list of all the cases where javac generates
dup_x1 and dupx_2 instructions?


Sorry for the confusion again


Eddy Truyen.


Steven Carroll wrote:


> Eddy Truyen wrote:
>
> > Hi there,
> >
> > javac compiles statements like i++, i-- and similar to optimized byte
> > code. This means that the resulting bytecodes are not the same when
> > compiling i=i+1;
> > Is their anyway to turn this off?
> > I looked and at first glance their seems to be an option -O to optimize
> > the compiler, but no option that leads to compiling only 'clean' code
> > without dupx statements that insert elements within the Java stack
>
> Dupx statements are used for more than just optimizations. say you
> have the sequence:
>
> new java/lang/String
> dup
> invokevirtual (some string function) // note invokevirtual takes the object
> off the stack
> invokevirtual (some other string function)
>
> The only way I can think of to perform the same optimization is:
>
> new java/lang/String
> astore_0
> aload_0
> invokevirtual (Some string function)
> aload_0
> invokevirtual (some other string function)
>
> I don't really think that's any cleaner, so I doubt there is an option
> to do that. Java Bytecode is a stack based architecture, so naturally
> the generated code is stack like and doesn't do all that loading and
> storing that is common in load/store architectures.
>
> As far as i++ goes, iinc (the optimized bytecode you refer to)is
> pretty straightforward. You are correct though. I was surprised that
> i = i + 1 is not translated to the same thing as i++. javac is not
> known for its powerful optimization though.
>
> STEVE

Return to the comp.compilers page.
Search the comp.compilers archives again.