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>