RFR 8135248: Add utility methods to check indexes and ranges

[forax at univ-mlv.fr]

An intrinsic replace a method, so the bytecoded method is never executed by the interpreter (it's not fully true in tiers mode), 
so it's not that you can not use the profile info is that there is no profile info. 

In the case of checkIndex, even if c1 compiles the bytecoded version of checkIndex, the profile info will be useless, 
so even if the code that generated the IR nodes can look for the profile info there is no point to do that. 
It's better here to be blind and to always ask to bailout into the interpreter if the index is wrong. 

Rémi 

----- Mail original -----

> De: "Vitaly Davidovich" <vitalyd at gmail.com>
> À: "Rémi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
> <paul.sandoz at oracle.com>
> Envoyé: Lundi 21 Septembre 2015 16:31:18
> Objet: Re: RFR 8135248: Add utility methods to check indexes and ranges

> Interesting - I didn't realize intrinsics cannot use profile info (kind of
> odd - why is that?). Thanks for pointing that out though.

> sent from my phone
> On Sep 21, 2015 10:28 AM, "Remi Forax" < forax at univ-mlv.fr > wrote:

> > Hi Vitaly,
> 
> > checkIndex has not the same issue as requireNonNull if it is intrisified
> > because
> 
> > the code that generate the IR node graph can not use the profiling info of
> > the interpreter
> 
> > thus the assembly code generated will always bail out if the index is
> > wrong.
> 

> > Rémi
> 

> > ----- Mail original -----
> 
> > > De: "Vitaly Davidovich" < vitalyd at gmail.com >
> 
> > > À: "Paul Sandoz" < paul.sandoz at oracle.com >
> 
> > > Cc: "core-libs-dev" < core-libs-dev at openjdk.java.net >
> 
> > > Envoyé: Lundi 21 Septembre 2015 16:01:16
> 
> > > Objet: Re: RFR 8135248: Add utility methods to check indexes and ranges
> 
> > >
> 
> > > So is this saying that enhancing Hotspot JIT to detect range check
> > > patterns
> 
> > > better is too much work? On the surface, it seems odd to need intrinsics,
> > > a
> 
> > > functional interface, and fixed template for getting efficient range
> > > checks.
> 
> > >
> 
> > > Also, this may end up with similar profile pollution problems as things
> 
> > > like Objects.requireNonNull.
> 
> > >
> 
> > > sent from my phone
> 
> > > On Sep 21, 2015 9:42 AM, "Paul Sandoz" < paul.sandoz at 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
> 
> > > >
> 
> > >
>