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