Improving the performance of OpenJDK

[Andrew Haley]

Edward Nevill wrote:
> 
> Question: Why is the class data in the wrong endianness in the first place?
> The data affected is the data embeded in the Java bytecode and the data
> in the constant pool. Why does the classfile loader not just correct
> the endianness on load. It has to do verification anyway so it has to
> trawl through the classfile? It might as well correct the endianness.

No I don't understand this either.  However, there are other places than
the interpreter that read the bytecode, so it's not just a matter of
fixing it there.

All accesses to the constant pool seem to read the operand in native byte
order, and then constantPoolOopDesc::field_or_method_at() does:

  // Takes either a constant pool cache index in possibly byte-swapped
  // byte order (which comes from the bytecodes after rewriting) or,
  // if "uncached" is true, a vanilla constant pool index
  jint field_or_method_at(int which, bool uncached) {
    int i = -1;
    if (uncached || cache() == NULL) {
      i = which;
    } else {
      // change byte-ordering and go via cache
      i = cache()->entry_at(Bytes::swap_u2(which))->constant_pool_index();
    }
    assert(tag_at(i).is_field_or_method(), "Corrupted constant pool");
    return *int_at_addr(i);
  }

In other words: the operands are rewritten but left in Java byte order.

Andrew.