RFR(s): 8220394: bufferedStream does not honor size limit
david.holmes at oracle.com
Mon Mar 11 07:56:08 UTC 2019
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
> 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, Thomas
More information about the hotspot-runtime-dev