On Mon, 11 Nov 2024 14:50:57 GMT, Per Minborg <pminb...@openjdk.org> wrote:
>> This PR proposes to add a new `MemorySegment::fill" benchmark where the byte >> size of the segments varies. > > 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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22010#issuecomment-2468683925
