Adding a fixate method to StringBuilder and StringBuffer.

Jesús Viñuales serverperformance at
Thu Apr 16 08:26:21 UTC 2009


Look at this bug evaluation to get further
information about what Tom told you yesterday.

I'm afraid that there is nothing to do here... because an optimization based
on buffer-sharing + copy-on-write has several problems (although I'm sure
that with the "new" memory model, a redesign based on a volatile flag would
solve the concurrency problems) and *surprisingly* seems not to give any
performance gain at all!! (surely because of the overload for the GC).

Last autumn I tried (for fun) several solutions (even tried a completely
internal redesign of StringBuilder based on appending in a String list
instead of arraycopying to a char buffer) but had no luck.

It would be great that some brilliant brain would be able to optimize, it
but seems difficult/impossible or at least I think that this has no priority


> Tom Hawtin wrote:
> Paulo Levi wrote:
> > Since CharSequence is obviously flawed in that it doesn't allow
> > efficient read-only views because of a missing method, there are
> various
> > methods in the jdk where a stringbuilder/buffer is built, populated
> and
> > then toString()-ed and left to be garbage collected. I'm seeing
> places,
> > especially in the Document classes, where this originates a
> OutOfMemory
> > exception, because the second buffers can't be created concurrently.
> > I'm asking for a
> > public final String fixate()
> > method for both stringbuffer and builder that reuses the internal
> char
> > array on a private String constructor (that takes the array), and
> sets a
> > flag to never allow the buffer to be modified again.
> >
> > But what i would really like is that the CharSequence interface would
> > altered. CharSequence2.
> This is the way StringBuffer worked prior to 1.5. That produced so many
> problems. It is widely known that 1.4 still suffers from unsafe
> publication issues (not that 1.4 *spec* has a sensible memory model at
> all). Obviously for StringBuilder, without synchronisation, it is way
> out.
> Swing text classes, used reasonably, should not result in
> OutOfMemoryErrors. If you require to have lots of Strings sharing the
> same backing buffer, in Sun's current implementation you can use
> toString once followed by many String.substrings. Other
> performance-optimised implementations have different behaviour. If
> exact
> behaviour is important to you, then you will need to use your own
> immutable char[] wrapper class.
> Tom Hawtin

More information about the core-libs-dev mailing list