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

Alan Bateman Alan.Bateman at oracle.com
Mon May 13 19:05:54 UTC 2013

On 13/05/2013 08:12, David Holmes wrote:

Thanks for all the feedback and discussion. I've rewritten the patch to use Peter's suggestion of caching the char[] instead of the actual String:

http://cr.openjdk.java.net/~dholmes/8013395/webrev.v3/ I too am concerned that any form of caching that avoids the array-copy (which is the crux of the issue) is going to incur a 2x space penalty. I can imagine old but well-behaved code that uses StringBuffer rather than StringBuilder where very long buffers are created and toString() only called once - and they may get immediate or subsequent OOME due to the extra char[]; or excessive GC activity might be induced if a lot of StringBuffers are used. Assuming the well-behaved case is where the StringBuffer is discarded after calling toString then I wouldn't expect it to too different to today. That is, you have the 2x penalty when toString is called now. Clearly there are other usages which could be problematic.

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.

-Alan.

More information about the core-libs-dev mailing list