On Mon, 11 Nov 2024 17:23:56 GMT, Maurizio Cimadamore <mcimadam...@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
