On Wed, 13 Apr 2022 15:03:22 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> This change may be problematic for servers with a large number connections >> and an input stream for each connection. It could add up to 2k to the >> footprint of each connection when skip is used. > >> @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. ------------- PR: https://git.openjdk.java.net/jdk/pull/5872
