Re: i++ in Java

Eddy Truyen <>
10 Feb 2000 01:13:37 -0500

          From comp.compilers

Related articles
i++ in Java (Eddy Truyen) (2000-02-05)
Re: i++ in Java (Steven Carroll) (2000-02-05)
Re: i++ in Java (Eddy Truyen) (2000-02-10)
Re: i++ in Java (Eddy Truyen) (2000-02-10)
| List of all articles for this month |

From: Eddy Truyen <>
Newsgroups: comp.compilers
Date: 10 Feb 2000 01:13:37 -0500
Organization: UNI-C
References: 00-02-021 00-02-025
Keywords: Java, architecture

Tnx for the info.
  I am particularly pointing out the dup_x1 and dup_x2 instructions that
duplicate the top variable and insert in INTO the stack (not on top of the
stack). These instructions are generated in the case of compiling i++ with

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.

Post a followup to this message

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