RFR (M): 8143925: Enhancing CounterMode.crypt() for AES

[Vitaly Davidovich]

I don't think there's a need to write out 20 different ways to do a range
check -- I think nobody would expect all 20 to be covered by the
optimizer.  Some of those variations may not map cleanly to
Object::checkIndex either, nor is there any guarantee that people will
update all their existing range checks (or even know about) to use
Object::checkIndex -- some code will be left unoptimized no matter what.

But my point is the same as Andrew's, I think; instead of making checkIndex
an intrinsic, simply add a pattern match against that exact bytecode shape
(perhaps with basic canonicalization) and then still encourage people to
use Object::checkIndex.  This is better than intrinsic (modulo profile
pollution) since any other code that happens to use same pattern will match
as well, and not require an update to use checkIndex.  Then, if someone
comes to this list with an unoptimized example with a different bytecode
shape and has a convincing argument that the code shape is "common", you
guys can consider pattern matching that as well.

On Wed, Jan 6, 2016 at 2:50 PM, John Rose <john.r.rose at oracle.com> wrote:

>
> > On Jan 6, 2016, at 9:56 AM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> >
> > better canonicalization
>
> That's our first and most important tactic.  (Actually inlining is.)
>
> But the various idioms for checkIndex do not canonicalize easily. In this
> case the correct trade-off is not to invest more time and research and code
> into stronger canonicalization.
>
> We do have canonicalization of if-expressions. It's just that in this case
> strengthening it to cover range checks reliably is harder than the
> reasonable alternative.
>
> – John
>
> PS.  I am tempted to write out a list of 20 different ways to code a range
> check but will leave that as a exercise.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160106/911daf5c/attachment-0001.html>