RFR: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary
martinrb at google.com
Tue Mar 1 18:54:38 UTC 2016
136 * This method has the same contract as ensureCapacity, but is
137 * never synchronized.
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