RFR(xs): 8146905 - cleanup ostream, staticBufferStream
Thomas Stüfe
thomas.stuefe at gmail.com
Wed Jan 20 07:54:16 UTC 2016
May I please have a review for this? Thanks!
On Wed, Jan 13, 2016 at 3:00 PM, Thomas Stüfe <thomas.stuefe at gmail.com>
wrote:
> Dear all,
>
> please take a look at this small cleanup of ostream.
>
> bug report: https://bugs.openjdk.java.net/browse/JDK-8146905
> webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8146905-get-rid-of-staticBufferStream/webrev.00/webrev/
>
> Basically, it gets rid of the staticBufferStream class by moving its one
> feature up to the parent outputStream class:
>
> When printing the error log in vmError.cpp, we want to use as little stack
> space as possible. outputStream class uses on-stack buffers to assemble
> snprintf functions. So, staticBufferStream was introduced as a child of
> outputStream which overwrites the print functions and makes them use a
> caller provided buffer. It then delegates the real writing to a connected
> stream object.
>
> The problem with that approach is that this is not a good fit for a child
> class.Not all operations possible with outputStream are cleanly delegated
> to the connected stream class, so a staticBufferStream behaves sometimes
> differently from all other streams (see e.g. JDK-8145410, which will be
> automatically fixed with this change too).
>
> Another problem is that this delegation model leads to some code
> duplication, because all print() methods of outputStream are practically
> duplicated in staticBufferStream.
>
> Another cosmetic note is that all other child classes of outputStream
> (bufferedStream, stringStream, fileStream...) are specializations in term
> of log destination, not internal behaviour.
>
> Note that I implemented this in a very simple way without using templates,
> because I wanted to keep the changes as small as possible.
>
> Kind Regards, Thomas
>
More information about the hotspot-runtime-dev
mailing list