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

[Manuel Hässig]

On Wed, 4 Jun 2025 09:22:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> 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.)

Added comment in [67afb3c](https://github.com/openjdk/jdk/pull/25471/commits/67afb3ca570a5d0edc7b157f3403fde9d8829f2f) to explain this.

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

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