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

[Vitaly Davidovich]

>
> Where we differ is this:  I am skeptical that there is a well-defined set
> of "straightforward cases", which all reasonable coders, who expect
> optimization, will use.


I'm not sure we differ here.  A "straightforward case" of bytecode like
Object::checkIndex is a good start.

It is better to point out one case for favorable treatment, and say "if you
> really expect best optimization, use this name".  Followed by, "if you
> don't choose to use that name, we'll still try to optimize all the
> straightforward cases, but don't expect us to prioritize them as highly as
> the best practice we suggested".


For new code or code being modified, using a known method to guarantee
optimization is great; unfortunately that doesn't work for existing code.
And of course existing profile pollution problem makes using common entry
points a bit unpleasant if there's risk the profile doesn't match your
particular call.

More generally, I'd expect you guys would also prefer to keep # of
intrinsics down and rely on better canonicalization and pattern matching?
This has, as mentioned, the added side benefit that it will match existing
code shapes without requiring any changes.  Over time, provided people
report missed optimizations, hopefully the set of patterns that get matched
increases and the # of "clever" cases that fail to optimize goes down.

On Wed, Jan 6, 2016 at 12:42 PM, John Rose <john.r.rose at oracle.com> wrote:

> On Jan 6, 2016, at 4:20 AM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
>
> 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.
>
>
> Where we differ is this:  I am skeptical that there is a well-defined set
> of "straightforward cases", which all reasonable coders, who expect
> optimization, will use.
>
> It is better to point out one case for favorable treatment, and say "if
> you really expect best optimization, use this name".  Followed by, "if you
> don't choose to use that name, we'll still try to optimize all the
> straightforward cases, but don't expect us to prioritize them as highly as
> the best practice we suggested".
>
> — John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160106/03d31543/attachment.html>