Paolo, Look at this bug evaluation http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6219959 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 :-( Regards, Jesús > 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
