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

[Vitaly Davidovich]

I agree with Andrew.

We had a similarly themed discussion a few months back when someone wanted
to make Integer/Long::compareTo an intrinsic; the sentiment there was that
there's nothing "special" about compareTo, and instead the JIT can be
taught to pick up the pattern used in the bytecode for those methods.
Objects::checkIndex seems no different in that regard.

I realize that there may always be a user-specified shape that the JIT
doesn't understand, but straightforward cases should hopefully Just
Work(tm) as those patterns can be picked up elsewhere in code and
performance improves without changing a line of code.

On Wednesday, January 6, 2016, Andrew Haley <aph at redhat.com> wrote:

> On 05/01/16 22:11, John Rose wrote:
>
> > Dropping the intrinsic would prevent them from expressing their
> > intention, forcing them to fall back on Java's expression operators.
>
> I don't really understand that point: Objects.checkIndex would still
> exist, and hopefully people would use it, but it wouldn't need
> special-case handling in C2.
>
> > Also, it's not just a matter of micro-optimizing a single expression
> > to use unsigned arithmetic (though that is surprisingly tricky).
>
> I accept that point.
>
> > Range checks are interesting to block-level loop transformations
> > (iteration range reorganization).  Do you really want your loop
> > optimizations to be gated on "sufficient smarts" in the JIT's
> > expression pattern matcher?
>
> Please forgive me for pushing this: I'm not arguing for the sake of it,
> I'm trying to understand your reasoning.
>
> As it stands we recognize a call to Objects.checkIndex and transform
> it into a certain pattern.  I'm assuming that it's not impossible to
> recognize the logic inside Objects.checkIndex and transform it into
> the same form that the intrinsic generates.  And that would have a
> payoff in all the places that the same logic is used in existing
> programs, both inside and outside the JDK.
>
> I suppose one downside of this approach is that C2 might decide
> not to inline Objects.checkIndex, so it would be called instead
> and the optimization would not be done.
>
> Andrew.
>


-- 
Sent from my phone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160106/b72882cf/attachment-0001.html>