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

[Vitaly Davidovich]

>
> 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.


I'm surprised that's not the default behavior (i.e. statically treating
control flow ending with exception as uncommon).  Exceptional paths should
not be optimization barriers, IMHO.  It would also be good to not count
bytecodes in those paths for inlining purposes, but that's a separate topic
I suppose.

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.


Yes, that's my thinking as well.  You won't lose anything, but may gain
something by picking up similarly-shaped user-code checks elsewhere in
existing code.  Personally, I think intrinsics should be reserved for
constructs/intentions impossible (or very difficult) to express in plain
bytecode and for platform/CPU specific things; all else would be pattern
matched to cast a wider net.


On Mon, Jan 11, 2016 at 10:54 AM, Roland Westrelin <
roland.westrelin at oracle.com> wrote:

> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160111/faf15918/attachment.html>