Request for Reviews (S): JDK-8003585 strength reduce or eliminate range checks for power-of-two sized arrays

Krystal Mok rednaxelafx at
Wed Sep 30 22:38:03 UTC 2015

Hi Roland,

Thanks for picking it up! It mostly looks good to me. (Not a Reviewer)

What I really needed with my earlier webrev was some instructions as to
what test to write -- since the Java corelibs can come across this
optimization a lot (e.g. HashMap), I didn't have a good idea of what kind
of test really needs to be written.

A couple of issues with this webrev:

1. In subnode.cpp, line 1346:

1344     } else if (_test._test == BoolTest::lt &&
1345                cmp2->Opcode() == Op_AddI &&
1346                cmp2->in(2)->find_int_con(1)) {
1347       bound = cmp2->in(1);
1348     }

I think it should be
  cmp2->in(2)->find_int_con(0) == 1
instead, because the value passed into this function is actually for a
"fallback when no int constant is found". Passing the expected value (1) to
it defeats the purpose.

  jint find_int_con(jint value_if_unknown) const {
    const TypeInt* t = find_int_type();
    return (t != NULL && t->is_con()) ? t->get_con() : value_if_unknown;

2. Formattign nitpick: could you please trim the spaces before the new's on
lines 1368, 1369 and 1387

Kris (OpenJDK username: krismo)

On Wed, Sep 30, 2015 at 1:34 AM, Roland Westrelin <
roland.westrelin at> wrote:

> I’m picking that one up. Here is a new webrev:
> The only change to c2 compared to the previous webrev is that ((x & m) u<
> m+1) is optimized the same way ((x & m) u<= m) is. Actually, I don’t think
> that C2 currently produces the ((x & m) u<= m) shape. The
> IfNode::fold_compares() logic produces the ((x & m) u< m+1) variant. I also
> added a test case to check the validity of the transformations and ran
> usual testing on the change.
> Roland.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the hotspot-compiler-dev mailing list