The reason for keeping HugeCapacity separate was that they require extra
memory to be available, and they are skipped otherwise.
And we want all "regular" Capacity tests to run always on all systems.
With kind regards,
Ivan
On 2/4/19 1:39 PM, Roger Riggs wrote:
Hi Ivan,
Can we put the new StringBuffer tests into the existing
StringBuffer.Capacity.java test?
It can help keep functional test pieces to together and not create n+1
files.
Looking back I would have preferred the same for the
StringBuilder.Huge tests.
There is a Capacity.java test there too. But the tests have diverged.
Thanks, Roger
On 02/04/2019 04:25 PM, Ivan Gerasimov wrote:
Thank you Roger for reviewing!
On 2/4/19 11:32 AM, Roger Riggs wrote:
Hi Ivan,
A good boundary condition to clean up.
Should tests for StringBuffer be added too?
Yes, let's add them.
Please find the updated webrev here:
http://cr.openjdk.java.net/~igerasim/8218227/01/webrev/
With kind regards,
Ivan
Maxing out the length at MAX_VALUE must always result in an OOM.
If such an allocation were to succeed, it would violate the
specified initial capacity requirement.
Thanks, Roger
On 02/02/2019 02:28 AM, Ivan Gerasimov wrote:
Hello!
The spec of the constructors
StringBuilder(String)/StringBuilder(CharSequence) states that the
initial capacity of the builder will be set to the length of the
argument plus 16.
This causes them to throw confusing NegativeArraySizeException when
the argument's length is close to Integer.MAX_VALUE.
Let the arguments length be (Integer.MAX_VALUE - DELTA), like in
the code below:
String str = "Z".repeat(Integer.MAX_VALUE - DELTA);
StringBuilder sb = new StringBuilder(str);
Currently the behavior is as following:
0 <= DELTA <= 2 - unable to construct str,
2 <= DELTA <= 15 - NegativeArraySizeException is thrown,
16 <= DELTA <= 17 - OutOfMemoryError is thrown,
DELTA >= 18 - works fine.
With the fix, OOM will be thrown for all DELTA <= 17.
Also the fix will make constructing a StringBuilder from UTF16
coded String slightly more efficient.
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8218227
WEBREV: http://cr.openjdk.java.net/~igerasim/8218227/00/webrev/
Would you please help review the fix?
--
With kind regards,
Ivan Gerasimov
