RFR 8135248: Add utility methods to check indexes and ranges
Joseph D. Darcy
joe.darcy at oracle.com
Tue Sep 29 00:10:44 UTC 2015
Joining this thread late, I think the range checking methods would have
a happier life where they are more often found and used if the they live
somewhere other than the exception classes.
The class java.util.Objects is not an ideal host for these methods,
since they don't deal directly with objects per se, but the scope of
Objects could be expanded to include these utilities as well.
On 9/22/2015 1:23 AM, Paul Sandoz wrote:
> Hi Jason,
> Not a bad idea, after some I tend to agree.
> I was hesitating for two reasons, one is that they might be harder to find, and the other is not all reported exceptions will be instances of IndexOutOfBoundsException. However, as you point out not all bound checks are related to arrays and i think that is more so the case than exceptions related to IndexOutOfBoundsException.
> On 21 Sep 2015, at 21:17, Jason Mehrens <jason_mehrens at hotmail.com> wrote:
>> Hi Paul,
>> Would it make sense to add these methods to the IndexOutOfBoundsException class itself or is there a compatibility worry? Seems better to use the room in IndexOutOfBoundsException class file and keep these methods out of the Arrays class. It is also odd that in the future the LinkedList would depend on the Arrays class to check bounds.
>> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Paul Sandoz <paul.sandoz at oracle.com>
>> Sent: Monday, September 21, 2015 8:42 AM
>> To: core-libs-dev
>> Subject: RFR 8135248: Add utility methods to check indexes and ranges
>> Please review the following which adds methods to Arrays to check indexes and ranges:
>> 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  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  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.
>>  https://bugs.openjdk.java.net/browse/JDK-8042997
>>  https://bugs.openjdk.java.net/browse/JDK-8135250
More information about the core-libs-dev