On 09/21/2015 05:22 PM, Peter Levart wrote:
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
Or,
...have intrinsified method(s) in the form of:
public class Arrays {
...
public static boolean isIndexValid(int i, int length);
public static boolean isFromToIndexValid(int from, int to, int length);
...
... and pure bytecode checkXXXIndex methods implemented in terms of
above but just for standard exceptions. Code throwing customized
exceptions would use isXXXIndexValid methods and imperative code to
construct and throw exception.
The question is whether boolean return from intrinsic method coupled
with if statement in bytecode optimizes equally well as if the branch
was in the intrinsified method itself.
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
