RFR: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary
ivan.gerasimov at oracle.com
Tue Mar 1 20:58:10 UTC 2016
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.
> 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:
>> 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,
>> 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
>>>> 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
>>>> 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!
More information about the core-libs-dev