RFR: 8284638: store skip buffers in InputStream Object

[Brian Burkhalter]

On Sat, 9 Oct 2021 19:02:17 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>>> in extream situation, when doing this.skipBuffer = skipBuffer in Thread B, it might make this.skipBuffer to a byte[6] in thread A, and thus cause a IndexOutofBoundException in Thread A.
>> 
>> No, it won't. The later `skipBuffer` references are made to the local variable; so even though the `new byte[6]` may replace the cached `new byte[10]` skip buffer in instance field, in thread A, it is still using the old `new byte[10]` which is stored in the local variable/stack, and everything just proceeds fine (only shortcoming is that the 10-length skip buffer is wasted and recycled)
>
>> > in extream situation, when doing this.skipBuffer = skipBuffer in Thread B, it might make this.skipBuffer to a byte[6] in thread A, and thus cause a IndexOutofBoundException in Thread A.
>> 
>> No, it won't. The later `skipBuffer` references are made to the local variable; so even though the `new byte[6]` may replace the cached `new byte[10]` skip buffer in instance field, in thread A, it is still using the old `new byte[10]` which is stored in the local variable/stack, and everything just proceeds fine (only shortcoming is that the 10-length skip buffer is wasted and recycled)
> 
> you are correct. I forgot you use same name local variable hiding the field variable, so the later skipBuffer passed to read() is local variable.
> 
> (sigh) I feel like super stupid when facing multithread programming.

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.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872