RFR: JDK-8260030: Improve stringStream buffer handling [v2]

[Kim Barrett]

On Thu, 21 Jan 2021 18:45:35 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> stringStream objects are used as temporary string buffers a lot in hotspot. When investigating JDK-8259710, I found that a large majority of the stringStreams created never use the backing buffer fully; about 70% of all streams write less than 32 characters.
>> 
>> stringStream creates an backing buffer, C-heap allocated, with a default size of 256 characters. Some things could be improved:
>> 
>> - add a small in-object buffer for the first n characters to be written. This would avoid or at least delay allocation of the backing buffer from C-heap, at the expense of slightly increased object size and one memcpy when switching over to C-heap. Note that if the backing buffer is smaller than what now is the default size, the total footprint will go down despite the increased object size.
>> 
>> - Delaying allocation of the backing buffer would be good for the many cases where stringStream objects are created as temporary objects without being actually used, see eg. compile.hpp `class PrintInliningBuffer`
>> 
>> - Besides all that, the code could benefit from a little grooming (using modern style syntax etc).
>> 
>> ----
>> 
>> This patch:
>> 
>> - renames members of stringStream to conform to common syntax (eg leading underscores) and to be clearer
>> - Uses initialization lists
>> - Factors out buffer growth code from stringStream::write() to a new function stringStream::grow()
>> - Introduces a new object-internal mini buffer, `stringStream::_small_buffer`, sized 32 bytes, which is initially used for all writes
>> 
>> This patch drastically reduces the number of malloc calls done from this class. The internal buffer size of 32byte seems a good cut-off. Running some unrelated test program (no tracing active), I see a reduction in the number of malloc calls from stringStream from ~211K malloc calls down to 53K (debug VM). In a release VM, it drops from ~85K down to about 1K. The reason is that `stringStream` is used in a ton of places as a temporary stack allocated object, to write very minimal text snippets to.
>> 
>> I also tweaked the associated gtest to test more thoroughly.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Kim Feedback

Other than the minor nit about use of `_is_fixed` in the destructor, looks good.

src/hotspot/share/utilities/ostream.cpp line 414:

> 412: 
> 413: stringStream::~stringStream() {
> 414:   if (_is_fixed == false && _buffer != _small_buffer) {

Still using `_is_fixed == false` rather than `!_is_fixed`.

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

Marked as reviewed by kbarrett (Reviewer).

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