A simple optimization proposal

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed Feb 12 14:00:19 PST 2014


Looks reasonable. Kris, you need also look for other patterns listed in 
JDK-8003585.

Thanks,
Vladimir

On 2/12/14 12:39 PM, Krystal Mok wrote:
> Hi Martin and John,
>
> I did a quick-and-dirty patch and it seems to work:
> https://gist.github.com/rednaxelafx/8964030
> If it looks right then I'll refactor that code a little bit and send it
> in for official review.
>
> - Kris
>
>
> On Wed, Feb 12, 2014 at 11:17 AM, John Rose <john.r.rose at oracle.com
> <mailto:john.r.rose at oracle.com>> wrote:
>
>     It's totally reasonable, and is already filed as an RFE (please
>     comment on it!):
>
>     https://bugs.openjdk.java.net/browse/JDK-8003585
>
>     — John
>
>     On Feb 12, 2014, at 9:40 AM, Martin Grajcar <maaartinus at gmail.com
>     <mailto:maaartinus at gmail.com>> wrote:
>
>>     Most hash tables are power-of-two sized so that they can use
>>     masking for the access. It looks like the bounds check doesn't get
>>     eliminated, although it could be.
>>
>>     Based on the equivalence |a[x & (a.length - 1)]| throws if and
>>     only if |a.length == 0|, I'm proposing this simple algorithm:
>>
>>       * For each array access, check if the index has been computed
>>         via a bitwise and.
>>       * If so, check if either of the operands was computed as length
>>         minus one.
>>       * If so, replace the bounds check by a zero-length check.
>>
>>     This zero-length check can then be easily moved out of the loop by
>>     the existing optimizations.
>>
>>     I hope I'm not talking non-sense. For more details see
>>     http://stackoverflow.com/questions/21702939/why-the-bounds-check-doesnt-get-eliminated
>>
>>     Regards,
>>     Martin.
>
>


More information about the hotspot-compiler-dev mailing list