RFR: 8284638: store skip buffers in InputStream Object
Roger Riggs
rriggs at openjdk.java.net
Mon Apr 11 23:01:34 UTC 2022
On Mon, 11 Apr 2022 22:40:31 GMT, liach <duke at openjdk.java.net> wrote:
>> Isn't it the case that the length of the global `skipBuffer` is non-decreasing? Thus skipping 6 bytes after skipping 10 will not result in a new buffer allocation.
>>
>> Even so, it does appear that prior buffer allocations could be "lost" due to concurrent use of `skip` resulting in a "minor" memory leak in the heap.
>
>> Even so, it does appear that prior buffer allocations could be "lost" due to concurrent use of skip resulting in a "minor" memory leak in the heap.
>
> The minor leak, though maybe somewhat wasteful, is the necessary cost for thread safety as opposed to locking or synchronizing to reliably retrieve a previously allocated array from another thread.
>
> Another concern about this change is that now the skip buffer is no longer immediately GC'd when exiting the scope but will live on till the input stream is no longer reachable. For instance, if an input stream is skipped and then kept for long, this may be a performance regression instead for the increased memory use.
Is this change proposed as the result of some experience with particular apps and streams or just observation of the implementation?
Is there any information about what kind of underlying streams do not support skip directly
and what is the distribution of sizes expected to be 'skipped'?
GIven the object instance overhead of an array, I'd be inclined to suggest a minimum size that would
cover all of the 'small' skipping that could occur. And if that's not big enough, jump to the MAX_SKIP_BUFFER_SIZE. To keep the code simple, I'd start at 128bytes and jump to the max if that's not big enough. There is precious little actual information available to fine tune.
-------------
PR: https://git.openjdk.java.net/jdk/pull/5872
More information about the core-libs-dev
mailing list