RFR (M): 8143925: Enhancing CounterMode.crypt() for AES
aph at redhat.com
Wed Jan 6 10:41:31 UTC 2016
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.
More information about the hotspot-compiler-dev