If you allocate a "new byte[1]", then on 64-bit platform you will get this layout:

[B object internals:
 OFFSET SIZE TYPE DESCRIPTION
      0 4 (object header)
      4 4 (object header)
      8 4 (object header)
     12 4 int [B.length
     16 1 byte [B.<elements>
     17 7 (loss due to the next object alignment)
Instance size: 24 bytes (reported by Instrumentation API)
Space losses: 0 bytes internal + 7 bytes external = 7 bytes total

Everything is as expected: the elements start at offset 16, there is one element, and 7-byte external alignment shadow. However, the same test with -XX:-UseCompressedClassPointers:

[B object internals:
 OFFSET SIZE TYPE DESCRIPTION
      0 4 (object header)
      4 4 (object header)
      8 4 (object header)
     12 4 (object header)
     16 4 int [B.length
     20 4 (alignment/padding gap)
     24 1 byte [B.<elements>
     25 7 (loss due to the next object alignment)
Instance size: 32 bytes (reported by Instrumentation API)
Space losses: 4 bytes internal + 7 bytes external = 11 bytes total

Now, the elements are starting from offset 24! And there is a 4-byte gap between length field and elements. It seems to be because the starting offset for all arrays is granular to HeapWordSize:

arrayOop.hpp:

  // Returns the offset of the first element.
  static int base_offset_in_bytes(BasicType type) {
    return header_size(type) * HeapWordSize;
  }

But it seems to be little sense in aligning at least byte[] arrays by HeapWord? We can save quite some space on small arrays (when CCPs are disabled either explicitly, or implicitly due to large heap), if that gap is closed.

This is referenced in JOL Sample:
  http://hg.openjdk.java.net/code-tools/jol/file/c851de7dd320/jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_25_ArrayAlignment.java