The changes for JDK-8310929 uses ByteArrayLittleEndian, which in turn initializes a slew of VarHandles. This adds up to a ~1.5ms regression on a classpath-based Hello World program.

We could either back out the use of ByteArrayLittleEndian - this would only partially revert the performance improvement from JDK-8310929 - or we could resolve some of the start-up regression by refactoring ByteArrayLittleEndian to create VHs lazily.

While the VH initialization doesn't currently happen very early, having a dependency on the VarHandle machinery from Integer.toString is risky and may surprisingly prohibit its use from code executed during very early bootstrap. The safest option might thus be to revert the use of ByteArrayLittleEndian introduced by JDK-8310929