Cheapest way to force implicit array bounds check

Question

Let's say I have a method with the following signature:

public int indexOf(byte[] bytes, byte toFind, int offset, int length) {
  ...
}

This method does something simple like look for the byte toFind in the range [offset, offset+length) in bytes. I want to check up-front whether offset and length are valid for bytes. That is, that offset and offset + length fall in bytes.

The explicit check would look something like:

if (offset < 0 || offset > bytes.length - length) {
  throw ...;  // bad santa!
}

It seems that I can perform this more cheaply (in terms of emitted bytecode, and perhaps runtime performance) by performing "dummy" array access instead:

public int indexOf(byte[] bytes, byte toFind, int offset, int length) {
  int dummy = bytes[offset] + bytes[offset + length - 1];
  ...
}

I'd like to get rid of the int dummy and + if I could, or reduce their cost. The compiler doesn't like standalone accesses like bytes[offset];, presumably because an expression like this usually doesn't have side effects and is pointless (but not so in this case). Using the dummy int also causes a compiler warning which must be suppressed.

Any suggestions on how I can make the change with a minimum amount of bytecode (runtime performance is important here too, but I suspect that most solutions are optimized to the same thing as unused portions are dropped).

Answer 1

How about this ?

if ((bytes[offset] | bytes[offset+length-1])==0) { }

Answer 2

The cheapest way in terms of bytecode length, is the way used by several JRE classes, e.g. ByteBuffer or ArrayList: use a dedicated check method.

Starting with Java 9, there is a standard method for this purpose, which is also starting to supersede these internal check methods, to become the central place for these kind of checks, also known by the JVM’s optimizer if it has a way of optimizing this check:
Objects.checkFromIndexSize​(offset, length, bytes.length);

---

In comparison to other approaches:

• Using an array access with a dummy variable:

  public int indexOf1(byte[] bytes, byte toFind, int offset, int length) {
      int dummy = bytes[offset] + bytes[offset + length - 1];
      //...
  }
  

  compiles to

   0: aload_1
   1: iload_3
   2: baload
   3: aload_1
   4: iload_3
   5: iload         4
   7: iadd
   8: iconst_1
   9: isub
  10: baload
  11: iadd
  12: istore        5
  14: ...
  

• Using an array access and a dummy branch instruction

  public int indexOf2(byte[] bytes, byte toFind, int offset, int length) {
      if ((bytes[offset] | bytes[offset+length-1])==0) { }
      //...
  }
  

  compiles to

   0: aload_1
   1: iload_3
   2: baload
   3: aload_1
   4: iload_3
   5: iload         4
   7: iadd
   8: iconst_1
   9: isub
  10: baload
  11: ior
  12: ifne          15
  15: ...
  

• Using a dedicated check method

  public int indexOf3(byte[] bytes, byte toFind, int offset, int length) {
      checkIndex(bytes, offset, length);
      //...
  }
  
  private void checkIndex(byte[] bytes, int offset, int length) {
     //...
  }
  

  compiles to

   0: aload_0
   1: aload_1
   2: iload_3
   3: iload         4
   5: invokespecial #23                 // Method checkIndex:([BII)V
   8: ...
  

So delegating wins when considering the code using it. It also does not introduce local variables on the caller side. The additional space required by the implementation method pays off as soon as more than one method uses it. Such a method is usually private or static, being invoked by an instruction without dynamic dispatch and getting inlined at runtime, so there will be no performance difference. The JVM will usually inline methods that small, regardless of whether they are a hot spot or not.

When comparing the performance of an implicit array bounds check with an explicit comparison, there is no reason why either should be faster than the other. They are basically doing the same and in either case, the JVM can elide them if it can prove that the caller will always pass valid numbers only.

By the way, Buffer.checkBounds guides you to an implementation with only a single conditional:

private void checkIndex(byte[] bytes, int offset, int length) {
    if((offset | length | (offset+length) | (bytes.length-(offset+length))) < 0)
        throw new IndexOutOfBoundsException();
}

Unlike the array access variant, this also handles the case where length is negative (but offset+length would yield a valid index).

Answer 3

I hope that just executing bytes[offset] and bytes[offset + length - 1] is the cheapest way. The shortest way in JVM bytecode would be just to execute these expressions and leave it on the operand stack.

However, you can't do it in Java. You also can't use pop2 instruction (or two pop instructions), because bytes[something] is not a valid Java command. There are three potentially best ways:

1. Use a method call like int java.lang.Math.max(int, int). This adds one 3-byte invokestatic instruction and one 1-byte pop instruction. So, it is a 4-byte overhead. You can save one byte, if you write a static dummy method with two int arguments and void result. An intelligent JVM optimizer would probably reduce this code to one pop2 instruction, since Math.max(...) has no side effect and you discard the result by pop instruction. However, I am not sure if this applies for Hotspot.
2. Assign it to a local variable. One assign means one istore instruction. If you have five parameters (including this, because the method is not static), you use the generic 2-byte istore version instead of 1-byte istore_<n> (for n in {0, 1, 2, 3}). If you had at most three parameters, you would probably save something by reducing scope of the dummy variable.
3. Compare it (=> generate boolean) and use an empty branch, i.e. if ((bytes[offset] == bytes[offset+length-1])) { }. In this case, you don't need any extra method (like max or pop2) or any extra local variable (which enlarges local variable table).

If you don't use any further optimizer and you don't modify the method signature to use less variables, the third way is probably a winner. In my simple test, it requires only 16 bytes for instrutions (some other implementations are equal, but not better) and does not require anything more in local variable table or constant pool. You probably can save several bytes by manual bytecode optimisations or by Proguard. But be careful, Proguard may optimize it too much and remove the array access. (I am not sure, but it claims in documentation that it may remove some NullPointerExceptions.)

See https://gist.github.com/4523924

Answer 4

Not sure about the bytecode length, but how about:

bytes[offset] |= bytes[offset];
bytes[offset + length - 1] |= bytes[offset + length - 1];