RFR (M): 8143925: Enhancing CounterMode.crypt() for AES
roland.westrelin at oracle.com
Mon Jan 11 15:54:35 UTC 2016
> 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
2 comparisons: length < 0 || i >=u length
so even if it doesn't result in further improvements, we wouldn’t lose anything.
> > 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
More information about the hotspot-compiler-dev