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

[Ivan Gerasimov]

Thank you Martin!

On 01.03.2016 21:54, Martin Buchholz wrote:
> Thanks, Ivan.
>
>   135     /**
>   136      * This method has the same contract as ensureCapacity, but is
>   137      * never synchronized.
>   138      */
I'll update this comment to reflect the real behavior of that method.

Sincerely yours,
Ivan


> 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!
>>>