Re: RFR: 8300979: Lazily initialize (byte, char)arr in java.io.DataInputStream [v3]

2023-03-29 Thread Per Minborg
On Tue, 28 Mar 2023 18:15:57 GMT, Eirik Bjorsnos wrote: > > @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 re

Re: RFR: 8300979: Lazily initialize (byte, char)arr in java.io.DataInputStream [v3]

2023-03-28 Thread Eirik Bjorsnos
On Thu, 23 Mar 2023 14:00:40 GMT, Eirik Bjorsnos 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

Re: RFR: 8300979: Lazily initialize (byte, char)arr in java.io.DataInputStream [v3]

2023-03-28 Thread Per Minborg
On Thu, 23 Mar 2023 14:00:40 GMT, Eirik Bjorsnos 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

Re: RFR: 8300979: Lazily initialize (byte, char)arr in java.io.DataInputStream [v3]

2023-03-23 Thread altrisi
On Wed, 22 Mar 2023 10:12:26 GMT, Per Minborg wrote: >> This PR proposed to lazily initialize the scratch arrays only if/when needed. > > 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

Re: RFR: 8300979: Lazily initialize (byte, char)arr in java.io.DataInputStream [v3]

2023-03-23 Thread Eirik Bjorsnos
On Thu, 23 Mar 2023 13:51:35 GMT, Eirik Bjorsnos wrote: > 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 op

Re: RFR: 8300979: Lazily initialize (byte, char)arr in java.io.DataInputStream [v3]

2023-03-23 Thread Eirik Bjorsnos
On Wed, 22 Mar 2023 10:12:26 GMT, Per Minborg wrote: >> This PR proposed to lazily initialize the scratch arrays only if/when needed. > > 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

Re: RFR: 8300979: Lazily initialize (byte, char)arr in java.io.DataInputStream [v3]

2023-03-22 Thread Alan Bateman
On Wed, 22 Mar 2023 10:12:26 GMT, Per Minborg wrote: >> This PR proposed to lazily initialize the scratch arrays only if/when needed. > > 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

Re: RFR: 8300979: Lazily initialize (byte, char)arr in java.io.DataInputStream [v3]

2023-03-22 Thread Alan Bateman
On Wed, 22 Mar 2023 10:07:57 GMT, Per Minborg wrote: >> src/java.base/share/classes/java/io/DataInputStream.java line 64: >> >>> 62: * working arrays initialized on demand by readUTF >>> 63: */ >>> 64: private byte[] bytearr; >> >> Could the `bytearr` and `chararr` instance variab

Re: RFR: 8300979: Lazily initialize (byte, char)arr in java.io.DataInputStream [v3]

2023-03-22 Thread Per Minborg
> This PR proposed to lazily initialize the scratch arrays only if/when needed. 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 five additio

Re: RFR: 8300979: Lazily initialize (byte, char)arr in java.io.DataInputStream [v3]

2023-03-22 Thread Per Minborg
On Tue, 21 Mar 2023 16:17:35 GMT, Brian Burkhalter 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 five additional >> comm