The Java Specialists' Newsletter
Issue 1732009-05-28 Category: Performance Java version: Java 1.0 - 6.0

Welcome to the 173rd issue of The Java(tm) Specialists' Newsletter, sent to you from Zürich in Switzerland. This is the 12th week I'm away from Crete this year alone, with another 2 weeks away before the middle of June. So out of 26 weeks in the first half of 2009, I will have been away for 14, which is more than 50%. Due to the economic crisis, I fully expected at least half of my engagements to get cancelled, but that did not happen. Our Java Specialist Master Course and Design Patterns Course are just way too popular. HOWEVER, as from the middle of June, I'll be on "holiday" in Crete for a few months, coinciding with my kids 14 week school holiday. This will give me more time to think and produce some nice newsletters. Also, I am talking to a publisher to perhaps put together a book of my most popular newsletters, so you will have something to take to the beach.

Upcoming Java Specialist Master Courses: - please click here to sign up.

As from May 2010, we are also offering this course on the island of Crete. We only accept 6 students per class in Crete, due to the size of our conference room. Please book early to avoid disappointment!

San Jose CA, Mar 16-19 2010, $3500
Ottawa, Canada, Mar 22-25 2010, $3500
Oslo, Norway, Apr 13-16 2010, Kr 24500
Montreal, Canada, Apr 20-23 2010, $3500
Toronto, Canada, May 17-20 2010, $3500
Chania, Crete, May 25-28, Jun 29-Jul 2 or Aug 24-27 2010, €2500

In-house courses if these dates or locations do not suit you - click here for more information.

Java Memory Puzzle

Instead of telling you some mystery of Java memory, it is time for you to put on your thinking caps. I had a discussion a few weeks ago with one of my subscribers of whether you should null your local variables, to make things easier for the garbage collector. His understanding was that the local variables will be stored on the stack and thus popped off at the end of the method call anyway, so nulling them was a waste of time. In almost all situations, he is right. However, he had a class that did something most peculiar, something like this:

public class JavaMemoryPuzzle {
  private final int dataSize =
      (int) (Runtime.getRuntime().maxMemory() * 0.6);

  public void f() {
    {
      byte[] data = new byte[dataSize];
    }

    byte[] data2 = new byte[dataSize];
  }

  public static void main(String[] args) {
    JavaMemoryPuzzle jmp = new JavaMemoryPuzzle();
    jmp.f();
  }
}
  

When you run this you will always get an OutOfMemoryError, even though the local variable data is no longer visible outside of the code block.

So here comes the puzzle, that I'd like you to ponder about a bit. If you very politely ask the VM to release memory, then you don't get an OutOfMemoryError:

public class JavaMemoryPuzzlePolite {
  private final int dataSize =
      (int) (Runtime.getRuntime().maxMemory() * 0.6);

  public void f() {
    {
      byte[] data = new byte[dataSize];
    }

    for(int i=0; i<10; i++) {
      System.out.println("Please be so kind and release memory");
    }
    byte[] data2 = new byte[dataSize];
  }

  public static void main(String[] args) {
    JavaMemoryPuzzlePolite jmp = new JavaMemoryPuzzlePolite();
    jmp.f();
    System.out.println("No OutOfMemoryError");
  }
}
  

Why does this work? In my original newsletter, I asked my readers to send an answer. 400 emails later, I'd now prefer you to look at the next newsletter for the answer. Please contact me via my website if you have something new to add to the puzzle.

Heinz

Performance Articles Related Java Course