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" <fo...@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" <vita...@gmail.com> > > À: "Paul Sandoz" <paul.san...@oracle.com> > > Cc: "core-libs-dev" <core-libs-dev@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.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 > > > > > >
