RFR: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

[Martin Buchholz]

Thanks, Ivan.

 135     /**
 136      * This method has the same contract as ensureCapacity, but is
 137      * never synchronized.
 138      */

This comment should be updated, since treatment of negative argument
is completely different.

Otherwise looks good.


On Tue, Mar 1, 2016 at 9:33 AM, Ivan Gerasimov
<ivan.gerasimov at oracle.com> wrote:
> Hello!
>
> I added another regtest to perform some basic sanity checks wrt
> StringBuilder's capacity.
> In this test I we only operate on relatively small sizes.
> A situation when capacity grows large is checked in a separate test, which
> is ignored by default.
>
> Do you think this fix is good to go?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8149330
> WEBREV: http://cr.openjdk.java.net/~igerasim/8149330/03/webrev/
>
> Comments, suggestions are very welcome.
>
> Sincerely yours,
> Ivan
>
>
>
> On 23.02.2016 20:29, Martin Buchholz wrote:
>>
>> On Tue, Feb 23, 2016 at 7:20 AM, Ivan Gerasimov
>> <ivan.gerasimov at oracle.com> wrote:
>>>
>>> While writing this, I just noticed that I actually made a mistake when
>>> did
>>> newCapacity < 0 check.
>>> This wouldn't catch the overflow when the oldCapacity happens to be
>>> Integer.MAX_VALUE (which is not possible with the current hotspot, but
>>> may
>>> become an issue one day).
>>
>> Well done!
>>
>> One interesting way that capacity may end up being Integer.MAX_VALUE
>> is if we switch to char[] for storage.  Then in LATIN1 mode you could
>> store Integer.MAX_VALUE elements even without help from hotspot!
>>
>