stringStream objects are used as temporary string buffers a lot in hotspot. When investigating JDK-8259710, I found that 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).