A simple optimization proposal

Krystal Mok rednaxelafx at gmail.com
Fri Feb 14 10:54:56 PST 2014


Hi Paul,

I checked ArrayDeque, the methods that use the pattern array[x &
(array.length - 1)] do get matched by this patch, but there aren't
dominating tests before them to totally eliminate the range check, so I
wouldn't be expecting that much of a performance gain here.

e.g.

      220     /**
      221      * Inserts the specified element at the front of this deque.
      222      *
      223      * @param e the element to add
      224      * @throws NullPointerException if the specified element is
null
      225      */
      226     public void addFirst(E e) {
      227         if (e == null)
      228             throw new NullPointerException();
      229         elements[head = (head - 1) & (elements.length - 1)] = e;
      230         if (head == tail)
      231             doubleCapacity();
      232     }

There's no dominating check on elements.length, so a range check will still
have to be generated in this case. Simplifying the check to
(elements.length != 0) or (elements.length u> 0) doesn't really buy much,
because the final index is calculated and put into a register already
anyway, doing the normal (index u< elements.length) check before this patch
should be just as fast.

Thanks,
Kris


On Thu, Feb 13, 2014 at 1:50 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> On Feb 13, 2014, at 9:32 PM, John Rose <john.r.rose at oracle.com> wrote:
> > You might want to look at the code for HashMap.getNode, which (I think)
> optimizes with your existing logic.
> >
>
> See also code in ArrayDeque.
>
> Paul.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140214/b98fdca7/attachment.html 


More information about the hotspot-compiler-dev mailing list