If you consider doing benchmarks in detail maybe consider a static buffer, too? (Especially if it can be used in multiple implementations?)
Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev <core-libs-dev-r...@openjdk.java.net> im Auftrag von XenoAmess <d...@openjdk.java.net> Gesendet: Wednesday, April 13, 2022 11:58:06 PM An: core-libs-dev@openjdk.java.net <core-libs-dev@openjdk.java.net> Betreff: Re: RFR: 8284638: store skip buffers in InputStream Object [v2] On Wed, 13 Apr 2022 16:02:10 GMT, Alan Bateman <al...@openjdk.org> wrote: >>> @AlanBateman You are correct about this. But I wonder if this be a problem, >>> why Reader class can afford store a skip buffer for each Reader. >>> >>> Is there anything different in the situations about skipBuffer in Reader >>> and InputStream? >> >> Maybe the skip buffer in Reader should be looked at too, esp. as it >> couldpotentially grow to 16k bytes. The concern with changing >> InputStream.skip is that there may be a lot more input streams than readers >> in use, esp. if there is an input stream for every socket connection. > >> @AlanBateman Is the concern about holding more memory sufficient to retain >> the buffer using a SoftReference so it can be freed eagerly? >> These buffers are never read from, so are quite a waste, but at least they >> are only used when >> the underlying stream overrides skip. > > Maybe but I think it needs some benchmarks to know if caching a byte[] will > help or just bloat memory. If the InputStream is to a file or socket then > maybe skip is dominated by the I/O rather than the array allocation and > zero'ing. @AlanBateman jmh test added ------------- PR: https://git.openjdk.java.net/jdk/pull/5872
