2

I have read that some of the JVMs out there can optimize code execution by removing bounds checking. What I am trying to figure out is what coding technique will work better.

In method example1 below would the JVM ever figure it out and eliminate the bounds checking of the source[index] reference?

Is example2 the better code practice? It would seem so, but in some algorithms inside a loop the index being out of bounds is a normal condition. So you don't want to be generating tons of Exception objects inside that loop.

public void example1(int [] source, int index) {
    if (index >= 0 && index < source.length)
        System.out.println("Value is " + source[index]);
    else 
        System.out.println("Out of range: " + index);
}

public void example2(int [] source, int index) {
    try {        
        System.out.println("Value is " + source[index]);        
    } catch (IndexOutOfBoundsException exp) {
        System.out.println("Out of range: " + index);
    }
}

These code fragments are only representational. I am aware that in these examples the bounds-checking will hardly matter to performance. However I am working on an embedded protocol application where the redundant bounds checking will add up.

leventov
  • 14,760
  • 11
  • 69
  • 98
AlanObject
  • 9,613
  • 19
  • 86
  • 142
  • [This](http://www.ssw.uni-linz.ac.at/Research/Papers/Wuerthinger07/Wuerthinger07.pdf) paper from some colleagues here should be interesting for you. I think those changes were incorporated in hotspot, but not sure. Anyways the 2nd example surely is worse from a performance and coding practice point of view. – Voo Jul 03 '11 at 16:08
  • @AlanObject, A bounds check is many orders of magnitude, smaller than an a call to the output. In most cases it will make no difference. – Peter Lawrey Jul 03 '11 at 16:40

2 Answers2

5

To your first question, in example1 the bounds check can theoretically be eliminated. I'd expect the best modern JIT compilers to do this (e.g. perhaps via common sub-expression elimination in the bounds check when source[index] is expanded). As usual this will be implementation dependent so you can't rely on it. OTOH even if the bounds check isn't eliminated the difference will be trivial - you're hitting the already cached memory location for source.length and doing a couple of integer compares so the overhead is tiny.

example2 is not good practice - you are hitting an exception but then catching it and continuing as if nothing happened. Unless you are watching stdout closely you might completely miss the fact that there is a bug in your code.

There are basically two common "good" possibilities depending on what you consider to be a valid input for "index":

  1. An out-of-bounds index value is expected and is considered valid input. In which case you should test and handle it explicitly as in example1. You shouldn't need to throw any sort of exception in this case.

  2. An out-of-bounds index is unexpected (and is therefore a bug in the calling code). Your code should raise an exception here. If you like you can catch and re-throw the exception with your own message but you could also just let the IndexOutOfBounds exception propagate. Don't worry about the performance impact of this exception handling - you have just discovered a bug and therefore you want the program to fail as quickly and "loudly" as it can.....

mikera
  • 105,238
  • 25
  • 256
  • 415
  • 1
    Good answer. But I think the printing to stdout was just to demonstrate different use cases. – Dunes Jul 03 '11 at 17:13
1

I don't see how the index being out of bounds could ever be a normal condition. Either your algorithm has a bug, or you don't validate input correctly. And validating input, in this case, consists in checking that the index is in the bounds. Checking it with an if (as in your first snippet) is obviously much more readable, clean and efficient than catching an exception.

JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
  • When you are decoding a network packet, the index for an array is often computed from data within the packet itself, which may be corrupt. The code needs to deal with badly formed packets gracefully. Failure to do so in C code is usually the basis for many security exploits. – AlanObject Jul 03 '11 at 18:50
  • Yes. That's what I call "validating input". The input here is the index computed from the data. If you have to handle corrupted packets gracefully, then check that the index is in bounds, and act accordingly. But the check should be implemented using an if statement, and not by catching an IndexOutOfBoundsException. – JB Nizet Jul 03 '11 at 18:57