Hi Paul,
It seems that all that is needed for performance is to intrinsify static
methods Integer.compareUnsigned(int, int) and Long.compareUnsigned(long,
long). Or would that not be enough? Then perhaps explicit compare
operations would suffice:
public class Integer {
...
public static boolean unsignedLess(int a, int b);
public static boolean unsignedLessOrEqual(int a, int b);
You could still have Arrays.checkIndex methods, but they could be pure
bytecode methods with standard exception types / messages. And if one
needs special exception types / messages, (s)he can use the intrinsified
comparison methods directly and imperative code to throw the exception.
What do you think?
Regards, Peter
On 09/21/2015 03:42 PM, Paul Sandoz wrote:
Hi,
Please review the following which adds methods to Arrays to check indexes and
ranges:
https://bugs.openjdk.java.net/browse/JDK-8135248
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-array-check-index-range/webrev/
The original motivation was an intrinsic method, Arrays.checkIndex, to check if
an index is within bounds. Such an intrinsic guides HotSpot towards better
optimisations for bounds checks using one unsigned comparison instead of two
signed comparisons, and better eliding of integer to long conversions when an
index is used to create an offset for Unsafe access. The end result is more
efficient array access especially so from within unrolled loops. The VarHandles
work will use Arrays.checkIndex for array access.
A follow up issue [1] will track the intrinsification of Arrays.checkIndex.
We thought it would be opportunistic to support two further common use-cases
for sub-range checks, Arrays.checkFromToIndex and Arrays.
checkFromIndexSize. There is no current plan to intrinsify these methods.
Bounds checking is not difficult but it can be easy to make trivial mistakes.
Thus it is advantageous to consolidate such checks not just from an
optimization perspective but from a correctness and security/integrity
perspective.
There are many areas in the JDK where such checks are performed. A follow up
issue [2] will track updates to use the new methods.
The main challenge for these new methods is to design in such a way that
1) existing use-cases can still report the same set of exceptions with the same
messages;
2) method byte code size is not unduly increased, thus perturbing inlining; and
3) there is a reasonable path for any future support of long indexes.
Paul.
[1] https://bugs.openjdk.java.net/browse/JDK-8042997
[2] https://bugs.openjdk.java.net/browse/JDK-8135250
