Improving the performance of OpenJDK

[Edward Nevill]

> Gary Benson wrote:
> > Gary Benson wrote:
> > ...
> > > > > > Edward Nevill wrote:
> > > > > > > get_native_u2() and get_Java_u2() ... This seems to be a
> > > > > > > misguided attempt of the original authors to optimised
> > > > > > > reading of halfwords (judging by the comment immediate
> > > > > > > preceding the code).
> > ...
> > > So I did a quick SPECjvm98 run of this change on amd64.  A couple
> > > of the times are improved, by 3-10%, but one of the times is
> > > *slower* by 11%.  See attached.  I'm not sure what to make of
> > > that...
> > 
> > I'm wondering if rewriting get_Java_u2() to read directly rather
> > than read and swap is speeding it up, but removing the optimization
> > from get_native_u2() is slowing it down.  I'm going to try this with
> > the original get_native_u2() and with get_Java_u2() just a copy of
> > the big-endian get_native_u2().
> 
> So this way around it's a little more encouraging; two of the times
> are 8-10% faster, one is 5% faster.  Some of the times are still
> slower though, though not by as much, maybe 1-2%.  It's still
> disturbingly ambiguous though... thoughts?

I can believe on some architectures that get_native_u2() is faster.

However, x86 supports unaligned accesses, so the code should do something
like.

#ifdef TARGET_SUPPORTS_UNALIGNED_ACCESSES
	return *p;
#else
/* Do current crud, or something better */
#endif

The main killer is the get_Java_u2(). The stupid unsigned hw load, followed
by the sign extension, followed by a full word bytesex reversal.

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.

Regards,
Ed.