RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks

[Alan Bateman]

On 14/05/2013 06:10, David Holmes wrote:
> :
>
>> I'm not sure what to say about the copy-on-change-after-toString
>> approach. As the offset/count fields have been removed from String then
>> it could only be the count == value.length case. It would clearly be a
>> win in some cases but no help in others.
>
> Right - I was still using a offset/count based mental model for String 
> but that doesn't apply any more so we can't share directly except in 
> one case. And from past experiences with StringBuffer issues it seems 
> that accurately sizing the SB based on the expected final size is 
> quite a rarity so the copy-on-write optimization is not worth pursuing 
> (even if it were implementable in a reasonable way - thanks Peter for 
> the additional investigation here!)
>
> So here is hopefully final webrev:
>
> http://cr.openjdk.java.net/~dholmes/8013395/webrev.v5/
>
> It is the same approach as v3, but as Florian pointed out the cache 
> should be cleared before the mutating action - just in case there is 
> an exception.
I think we should go with this version, it looks good.

-Alan