On Thu, 23 Mar 2023 14:00:40 GMT, Eirik Bjorsnos <d...@openjdk.org> wrote:
>> I cannot explain why, but the changes suggested in this PR seem to introduce >> a small, but significant performance regression on the >> `DataInputStreamTest.readInt` benchmark: >> >> Baseline: >> >> >> Benchmark Mode Cnt Score Error Units >> DataInputStreamTest.readInt avgt 20 5.563 ± 0.037 us/op >> >> >> PR: >> >> >> Benchmark Mode Cnt Score Error Units >> DataInputStreamTest.readInt avgt 20 6.021 ± 0.020 us/op >> >> >> The reason this puzzles me is that the `readInt` benchmark don't involve the >> UTF code paths at all. So why would it become slower, just because two >> fields are no longer initialized with the default arrays? > >> The reason this puzzles me is that the `readInt` benchmark don't involve the >> UTF code paths at all. So why would it become slower, just because two >> fields are no longer initialized with the default arrays? > > Could there be some JIT optimizations not being possible because the fields > are no longer 'never null'? > @eirbjo I've updated the PR so we hold zero-length arrays rather than null > arrays. Please re-run your benchmark to see if there is any change. @minborg I ran the test now after your integration and I no longer observe the regression I did before. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13121#issuecomment-1487396449