RFR: 8020282: Generated code quality: redundant LEAs in the chained dereferences

[Aleksey Shipilev]

On Wed, 4 Jun 2025 09:15:12 GMT, Manuel Hässig <mhaessig at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/vm/compiler/x86/RedundantLeaPeephole.java line 33:
>> 
>>> 31: @Warmup(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS)
>>> 32: @Measurement(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS)
>>> 33: @Fork(value = 3, jvmArgsAppend = {"-Xms1g", "-Xmx1g"})
>> 
>> Ha, what did you need these args for? Could be nice to have a little comment in the code.
>
> This is what I gather to be good practice from @shipilev's [blog post about JMS benchmarks](https://shipilev.net/blog/2016/arrays-wisdom-ancients/#_benchmark). It ensures a consistent heap size across machines and runs because the `StoreN` benchmarks are sensitive to different GC's and heap layouts. But these are my first JMH benchmarks, so I appreciate any input.

Yes, exactly. We often do this for allocation-heavy benchmarks to put GC in more consistent conditions. GC often tries to decide whether to do a GC cycle or expand the heap, and this decision might change with minor externalities. So it sometimes contributes to run-to-run and intra-run variance. This benchmark does allocate pretty hard, so setting a heap size makes sense.

(Additionally, this forces a selection of a particular compressed oops mode, 32-bit in this case, which is also nice for reproducibility.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25471#discussion_r2126122739