RFR: 8343933: Add a MemorySegment::fill benchmark with varying sizes [v2]

[Francesco Nigro]

On Mon, 11 Nov 2024 17:23:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Add mixed test
>>  - Merge branch 'master' into ms-fill-bench-sizes
>>  - Use static arrays
>>  - Revert changes from other branch
>>  - Add benchmark
>>  - Add benchmarks
>
> IIUC, this benchmark is designed to test what happens in the case where a bulk operation is executed on a segment whose type is not known e.g. through type profiling (e.g. polluted case). Note that in this case (MIXED) the fact that we can't rely on which segment it is (and hence on whether it has a certain scope or not, and what the base object is) would greatly dominate the cost of branch misprediction, which I saw mentioned here. In extreme cases of profile pollution it is very possible for a method to be optimized under the assumption that e.g. the method is always executed on off-heap segments, and then hit an on-heap segment, which will perform horribly.
> 
> We have test cases such as these in `LoopOverPolluted[Segments/Buffer]`. It makes sense to test something similar for bulk access too.

@mcimadamore I've added a suggestion (at https://github.com/openjdk/jdk/pull/22010#discussion_r1836806492) on how to make sure that the type profile is polluted and shared by all the `fill` invocations (although only perfasm + perfnorm or TypeProfile logging will tell us if it has worked as expected) - sadly I had to rely on DONTINLINE :"( 
Said that, resetting the "inlining budget"  with a not inlined frame is still brittle and should be verified by adding profiling or printinlining inspection (or just perfasm, searching for callq/call, manually)

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

PR Comment: https://git.openjdk.org/jdk/pull/22010#issuecomment-2469936358