Looks good to me. minor nitpick, neither checkFromToIndex() nor checkFromIndexSize() are instrinsic (now !) but i think they also should be annotated with @ForceInline in j.u.Objects to avoid the code to be asymmetric or weird if one of these methods is intrinsinfied later.
Rémi ----- Mail original ----- > De: "Paul Sandoz" <paul.san...@oracle.com> > À: "Core-Libs-Dev" <core-libs-dev@openjdk.java.net>, "hotspot-dev developers" > <hotspot-...@openjdk.java.net> > Envoyé: Mardi 3 Mai 2016 00:37:36 > Objet: RFR 8155794 Move Objects.checkIndex BiFunction accepting methods to > an internal package > > Hi, > > Please review: > > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-jdk/webrev/ > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-hotspot/webrev/ > > This patch is based on that for 8155258 (VarHandle impl improvements) [1] > sent previously. > > The hotspot changes are really small. Likewise for the 8155258 changes is > there is precedent in such cases to push through jdk9-dev rather than hs? > > CCC reviewers strongly indicated for the advanced methods that can customise > the exceptions: "You aren't gonna need it”. > > For expediency I propose to move such methods to an internal class > jdk.internal.util.Preconditions. I would still like to sweep through > java.base and leverage these methods while preserving exception reporting > where possible. > > The hotspot changes are just for renaming of the intrinsic method signatures. > Since the intrinsic method is now internal i have added an @ForceInline on > the corresponding public method, given the potential for this to be used in > performance sensitive code. > > > JPRT core and hotspot tests pass. > > Paul. > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040740.html > <http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040740.html> >
