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

Krystal Mok rednaxelafx at gmail.com
Mon May 5 19:10:33 UTC 2014


Hi Paul,

Oops, my bad. I've been busy with my day work and hadn't got around to
write a test case for this patch, that's what caused the delay. I can try
to come up with a test case later this week if you can wait.

Best regards,
Kris


On Mon, May 5, 2014 at 8:02 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi Nils,
>
> Any update on this?
>
> I have been looking at this area in the context of array access for JEP
> 193: Enhanced Volatiles (i will send another email on that later today).
> But I was wanted to share some initial perf results with this patch.
>
> Here are the relevant snippets of benchmark code:
>
>     private static final int N = 1 << Integer.getInteger("N", 8);
>     private static final int START = (N >> 1);
>     private static final int END = (N >> 1) + N;
> ...
>
>     private Value value;
>
>     private Value[] receiver;
>
>     @Setup
>     public void setUp() throws Exception {
>         value = new ExtendedValue(1);
>         receiver = new ExtendedValue[N];
>         for (int i = 0; i < receiver.length; i++) {
>             receiver[i] = value;
>         }
>     }
> ...
>     @GenerateMicroBenchmark
>     public int relaxed_r_aa() {
>         Value[] _receiver = receiver;
>         int sum = 0;
>         for (int i = START; i < END; i++) {
>             int j = i & (_receiver.length - 1);
>             sum += _receiver[j].i;
>         }
>         return sum;
>     }
>
>     @GenerateMicroBenchmark
>     public Value[] relaxed_w_aa() {
>         Value[] _receiver = receiver;
>         for (int i = START; i < END; i++) {
>             int j = i & (_receiver.length - 1);
>             _receiver[j] = value;
>         }
>         return _receiver;
>     }
>
>     @GenerateMicroBenchmark
>     public int relaxed_r_unsafe() {
>         Value[] _receiver = receiver;
>         int sum = 0;
>         for (int i = START; i < END; i++) {
>             int j = i & (_receiver.length - 1);
>             Value v = (Value) UNSAFE.getObject(
>                     _receiver,
>                     (((long) j) << UNSAFE_ARRAY_SHIFT_V) +
> UNSAFE_ARRAY_OFFSET_V);
>             sum += v.i;
>         }
>         return sum;
>     }
>
>     @GenerateMicroBenchmark
>     public Value[] relaxed_w_unsafe() {
>         Value[] _receiver = receiver;
>         for (int i = START; i < END; i++) {
>             int j = i & (_receiver.length - 1);
>             UNSAFE.putObject(_receiver,
>                              (((long) j) << UNSAFE_ARRAY_SHIFT_V) +
> UNSAFE_ARRAY_OFFSET_V,
>                              value);
>         }
>         return _receiver;
>     }
>
> Here are some results on OpenJDK 9 without the patch (times are in ns/op
> for N=1,8,64,512, for one thread, measured on a Dell laptop with an Intel
> Core i5-2520 CPU @ 2.50GHz):
>
>     Benchmark                             1        8        64        512
>     relaxed_r_aa                        1.304    9.128    48.599    372.214
>     relaxed_r_unsafe                    1.152    6.615    44.456    348.989
>
>     relaxed_w_aa                        3.256   16.105    76.896    599.830
>     relaxed_w_unsafe                    2.888   11.553    56.037    532.179
>
> Here are the results with the patch applied to hotspot (in the dev repo):
>
>     Benchmark                             1        8        64        512
>     relaxed_r_aa                        1.291    6.664    37.604    285.830
>     relaxed_r_unsafe                    1.151    6.621    44.483    348.249
>
>     relaxed_w_aa                        3.279   12.646    66.324    481.281
>     relaxed_w_unsafe                    2.888   11.549    56.028    531.589
>
>
> One has to be a little careful interpreting the results since compilation
> of the JMH loop measurement method can monkey around with 'em (I think from
> OSR'ed to complete, which might be affecting how loops are unrolled, but i
> would need to dive into the machine code of the compiled methods to
> verify). However, even so this patch looks promising.
>
> Paul.
>
> On Feb 17, 2014, at 2:07 PM, Nils Eliasson <nils.eliasson at oracle.com>
> wrote:
>
> Current change passes JPRT. Running bigapps and nightly code policy as
> well.
>
> Will wait for tests and reviewer go-ahead before pushing.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140505/a47552c8/attachment.html>


More information about the hotspot-compiler-dev mailing list