RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks (original) (raw)

Alan Bateman Alan.Bateman at oracle.com
Tue May 14 11:03:36 UTC 2013

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

More information about the core-libs-dev mailing list