RFR: 8281467: Allow larger OptoLoopAlignment and CodeEntryAlignment

[Aleksey Shipilev]

On Tue, 8 Feb 2022 18:39:07 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> I am following up on the performance issue where the culprit seems to be the too low `OptoLoopAlignment`. To perform better experiments, I suggest allowing larger alignments.
>> 
>> Note that we cannot make `OptoLoopAlignment` larger than `CodeEntryAlignment`, because nmethod copy would break it, see assert in `MacroAssembler::align`. See [JDK-8273459](https://bugs.openjdk.java.net/browse/JDK-8273459) for latest discussion about it. So `CodeEntryAlignment` needs to be configurable as well.
>> 
>> The default values for options are different per platform, so tests are x86_64 specific.
>> 
>> No default value is changed, this only unblocks experiments.
>> 
>> Additional testing:
>>  - [x] New tests on Linux x86_64 fastdebug
>>  - [x] New tests on Linux x86_64 release
>
> src/hotspot/share/runtime/globals.hpp line 1539:
> 
>> 1537:           range(1, 128)                                                     \
>> 1538:           constraint(OptoLoopAlignmentConstraintFunc, AfterErgo)            \
>> 1539:                                                                             \
> 
> Should OptoLoopAlignment be an int, instead of an intx, since its range is small?

Dunno, maybe? I see the lot of other "small" options are `intx`, and the change like that would proliferate to all architectures that set `OptoLoopAlignment` as their `product_pd`. It also raises the question if `CodeEntryAlignment` should also be `int`? I'd rather keep this patch small, to be honest.

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

PR: https://git.openjdk.java.net/jdk/pull/7388