RFR(s): 8220394: bufferedStream does not honor size limit

[David Holmes]

Hi Thomas,

On 11/03/2019 4:19 am, Thomas Stüfe wrote:
> Hi all,
> 
> may I have please reviews for this fix:
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8220394
> cr:
> http://cr.openjdk.java.net/~stuefe/webrevs/8220394--bufferedstream-does-not-honor-size-limit/webrev.00/webrev/index.html
> 
> When playing around with a new jcmd addition, I found that bufferedStream -
> which is used quite a bit in the VM - in its dynamic, self-allocating form
> does not honor the buffer size limit. So faulty or just plain verbose
> printing code can cause high memory usage.
> 
> First I wanted to keep the change minimal but I found a number of things
> wrong with bufferedStream, mainly the fact that "bufmax" was actually
> used/misused as a flush threshold, for the use of the child class
> "networkStream". So I decided to separate the two - buffer size max and
> flush threshold - cleanly.

Hmmm my take on this was that bufferedStream was erroneously not 
implementing a flush that actually flushes and resets the buffer. It 
seems somewhat bizarre to have bufferedStream provide bufmax only for 
its subclass. Not sure we need separate flush and size thresholds - 
especially given that flush has been a no-op (we obviously don't care 
about when to flush).

There would still be a bug with regard to the resizing strategy and 
"bufmax" due to re-doubling for small values, but that seems easily fixed.

> I also renamed the members to be conform with modern hotpsot code and
> changed ctors to use initializer lists.
> 
> Note that when examining the streams, I found that they do not seem to
> explicitly zero-terminate. I was surprised by that, is that intentional?

I'm confused - why would a (non-string)stream zero-terminate?

Cheers,
David

> 
> Cheers, Thomas
>