RFR (XS) 8076759: AbstractStringBuilder.append(...) should ensure enough capacity for the upcoming "trivial" append calls

[Ulf Zibis]

May be:
..., then a new internal array becomes allocated and refilled with greater capacity.

... to give a hint, that this action may be expensive.

-Ulf

Am 05.05.2015 um 19:47 schrieb Aleksey Shipilev:
> Hi again,
>
> Here is a new webrev:
>    http://cr.openjdk.java.net/~shade/8076759/webrev.01/
>
> Pruned the implementation details from expandCapacity Javadoc, and about
> to submit a CCC for it.
>
> Thanks,
> -Aleksey.
>
> On 05.05.2015 16:33, Roger Riggs wrote:
>> Hi Aleksey,
>>
>> Thanks for checking the rounding alternative.
>>
>> As for the CCC, since the implementation details are in the javadoc
>> then it will be needed either to remove the details or to update them.
>> I'd be inclined to try to remove them since they are there primarily for
>> performance.
>>
>> Thanks, Roger
>>
>>
>>
>> On 5/5/2015 4:31 AM, Aleksey Shipilev wrote:
>>> Hi Roger,
>>>
>>> On 05/01/2015 08:19 PM, Roger Riggs wrote:
>>>> Is there any additional benefit by rounding up the next multiple of 4
>>>> or 8.
>>>> That would avoid a few wasted bytes at the end of the buffer modulo the
>>>> allocation size.
>>> It does not seem to help any further. Tried "plus32-round8", as in:
>>>     http://cr.openjdk.java.net/~shade/8076759/patches.txt
>>>
>>> ...and it performs similar to "plus32":
>>>     http://cr.openjdk.java.net/~shade/8076759/data-foot.png
>>>     http://cr.openjdk.java.net/~shade/8076759/data-perf.png
>>>
>>>> Otherwise, looks fine to me also.
>>> I actually wonder if my change in ensureCapacity Javadoc requires a CCC?
>>> On that topic, I also tempted to remove the implementation details from
>>> the Javadoc there, since it does not play well with "describe what you
>>> will do, not how would you do it".
>>>
>>> Thanks,
>>> -Aleksey.
>>>
>
>