Disassembling Java Classes

2003-02-14 The Java Specialists' Newsletter [Issue 064] - Disassembling Java Classes

Author: Dr. Heinz M. Kabutz

If you are reading this, and have not subscribed, please consider doing it now by going to our subscribe page. You can subscribe either via email or RSS.

Welcome to the 64th edition of The Java(tm) Specialists' Newsletter sent to 5869 Java Specialists in 94 countries.

I stepped off the plane last Tuesday, having come via London from Estonia, and was hit in the face by 31 degree Celsius heat. I was still wearing my warm clothes that were necessary in the -17 degree Celsius in Estonia (travel report to follow), but very quickly, I adapted again to shorts and T-shirt.

While I was in London, I had the opportunity to meet Jack Shirazi, the author of the best Java performance tuning website. Basically, when I don't know or understand something about Java performance, I go look at the website. Still coming is a review of Jack's book.

Disassembling Java Classes

A few months ago, on our local Java User Group discussion forum, I casually asked the question what was faster: i++, ++i or i+=1. I also mentioned that the answer might surprise them. Wanting to encourage thinking, I never gave the answer ;-)

Yesterday, one of my readers, a bright young student at the Cape Town Technical University, sent me an answer based on a thorough investigation through microbenchmarks. His conclusion was correct, but the approach to getting to the conclusion led to a lot of effort being spent on his part.

The easiest way to decide which is fastest is actually to disassemble the Java Class. Note that I am saying disassemble, not decompile. Let's look at the following class:

public class Increment {
  public int preIncrement() {
    int i = 0;
    ++i;
    return i;
  }
  public int postIncrement() {
    int i = 0;
    i++;
    return i;
  }
  public int negative() {
    int i = 0;
    i-=-1;
    return i;
  }
  public int plusEquals() {
    int i = 0;
    i += 1;
    return i;
  }
}

I may ask you: which method is the fastest, which is the slowest? C programmers would probably say that the fastest are i++ and ++i. When you try running these methods many times, you will notice slight differences between them, based on which you run first, how soon the hotspot kicks in, whether you use client or server hotspot, whether you are busy playing an MP3 on your machine while running the test and the phase of the moon.

Instead of measuring the performance, why not investigate what the Java compiler did? You can disassemble a class with the standard javap tool available in your JAVA_HOME\bin directory:

javap -c Increment

Note that the class must already be compiled. The result is the following:

Compiled from Increment.java
public class Increment extends java.lang.Object {
    public Increment();
    public int preIncrement();
    public int postIncrement();
    public int negative();
    public int plusEquals();
}

Method Increment()
   0 aload_0
   1 invokespecial #9 <Method java.lang.Object()>
   4 return

Method int preIncrement()
   0 iconst_0
   1 istore_1
   2 iinc 1 1
   5 iload_1
   6 ireturn

Method int postIncrement()
   0 iconst_0
   1 istore_1
   2 iinc 1 1
   5 iload_1
   6 ireturn

Method int negative()
   0 iconst_0
   1 istore_1
   2 iinc 1 1
   5 iload_1
   6 ireturn

Method int plusEquals()
   0 iconst_0
   1 istore_1
   2 iinc 1 1
   5 iload_1
   6 ireturn

Now when we look at the different methods of incrementing the local variable, we can see that they are actually identical!

Next time you are thinking of measuring performance using System.currentTimeMillis(), think of also looking at the generated byte code. It might save you a lot of time.

I want to thank Daniël Maree for inspiring me to write this newsletter through his thorough research as to which increment method was faster.

Kind regards

Heinz

P.S. I hope you all enjoy Valentine's day. Remember to leave work early today - i.e. before 8pm ;-)

This material from The Java(tm) Specialists' Newsletter by Maximum Solutions (South Africa). Please contact Maximum Solutions for more information.