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

[John Rose]

On Jan 6, 2016, at 2:05 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> Can you give me a pointer to an example of such duplicated
> pre-intrinsic code?
> 

It's another case of belt-and-suspenders.

The internal bytecodes of a non-replaced intrinsic candidate perform
hardwired range checks as part of iaload, etc.  So the JVM defends
itself against out-of-range access, as usual.  Meanwhile, at a higher
level, the intrinsic candidate (whether replaced or not) is dominated
by a call to explicit range check logic.

  if (rangeCheckFail(array, indexes))  goto L_throw_1;
  /* non-replaced intrinsic, logic gets inlined as follows: */
  for (index in indexes…) {
     if (rangeCheckFail(array, index))  goto L_throw_2;
     tem = iaload(array, index);
     … }

In the case of a replaced intrinsic, there is not guaranteed to
be a full range check of the array access, so:

  if (rangeCheckFail(array, indexes))  goto L_throw_1;
  /* replaced intrinsic */
  …some vectorized assembly code works with array and indexes…

In the first case, if the first "rangeCheckFail" logic is similar enough
to the second "rangeCheckFail" logic, the JIT can elide the second one.
But they are likely *not* to match if the programmer has written something
elegant and/or clever for the first set of checks.

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