Hi, Thanks for all the feedback.
Here is a new webrev: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-ioobe-check-index-range/webrev/ Changes: - Move check methods to IndexOutOfBoundsException - Use BiFunction, rather than a specific exception mapping function. - Add check methods that do not accept an exception mapping function and throw IndexOutOfBoundsException. - Add 2 argument constructors to Array/String/IndexOutOfBoundsException, thus allowing support for method refs. Remi, i left the generic signatures as is, i am presuming there is an advantage to naming T, rather than using a wildcard e.g. IDEs could use that information (although IntelliJ does not appear to do so at the moment). Paul. On 21 Sep 2015, at 15:42, Paul Sandoz <paul.san...@oracle.com> 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
