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

[John Rose]

On Jan 6, 2016, at 2:41 AM, Andrew Haley <aph at redhat.com> wrote:
> 
>> 
>> 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.

Sure, and we do this as much as possible.  But there are too many
degrees of freedom in user-coded range check expressions.  So
we give the users a clearer target to aim at if they want best perf.
on range checks.

You could say (as Vitaly pointed out for Integer.compareTo), that
we don't need an intrinsic as long as the bytecoded body of
Objects.checkIndex has the Best Possible Formulation (tm)
of a range check, which naturally will always be maximally
optimized by the JIT.  The specific problem with range checking
is that (as I said before) the JVM inserts its own range checks
into bytecode semantics (iaload etc.), and we need to make
the user-written ones fold up with the JVM-inserted ones.
That is a hard coupling between the JDK and JVM, much
harder than just "yes, we are all using the same math".
An intrinsic properly expresses and enforces this coupling.
Using a similar expression does not.

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

Yes, come to think of it, one "super power" of an intrinsic is that
the inlining heuristics apply to it more favorably.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160106/d7fbc92a/attachment.html>