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

[Roland Westrelin]

> As a general comment, would it make sense to assume exceptional paths are not taken in most Java code? That is, for code optimization purposes it's probably a reasonable assumption.  It seems like having an exceptional path is already a hint that it's not expected to fail; most Java devs know not to use exceptions for expected control flow.

That sounds reasonable. There’s a BailoutToInterpreterForThrows command line argument that does that (off by default, not available in product builds). I don’t know what the history behind it is.

> Could bytecode shape just like checkIndex be treated as same hint? Are there cases where something looks like checkIndex but really isn't? 

That sounds like a good suggestion. We would trade:
2 comparisons: i < 0 || i >= length
for
2 comparisons: length < 0 || i >=u length 

so even if it doesn't result in further improvements, we wouldn’t lose anything.

Roland.


> 
> Roland.
> 
> >
> > On Wednesday, January 6, 2016, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> > Note, we already have range check pattern matching code in C2 (thanks to Roland):
> >
> > https://bugs.openjdk.java.net/browse/JDK-8137168
> >
> > Vladimir
> >
> > On 1/6/16 12:39 PM, Vitaly Davidovich wrote:
> > 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
> > <mailto:john.r.rose at oracle.com>> wrote:
> >
> >
> >      > On Jan 6, 2016, at 9:56 AM, Vitaly Davidovich <vitalyd at gmail.com
> >     <mailto: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.
> >
> >
> >
> >
> > --
> > Sent from my phone
> 
> 
> 
> -- 
> Sent from my phone