RFR: 8247373: ArraysSupport.newLength doc, test, and exception message

[Roger Riggs]

On Fri, 4 Dec 2020 17:49:25 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 640:
>> 
>>> 638:         int prefLength = oldLength + Math.max(minGrowth, prefGrowth); // might overflow
>>> 639:         if (0 < prefLength && prefLength <= SOFT_MAX_ARRAY_LENGTH) {
>>> 640:             return prefLength;
>> 
>> In spite of the assert `minGrowth > 0`, that is unchecked, I would suggest prefLength == 0 to return prefLength.
>>     ```if (0 <= prefLength && prefLength <= SOFT_MAX_ARRAY_LENGTH) {
>>             return prefLength;```
>> Otherwise, it falls into hughLength(...) which will return the SOFT_MAX_ARRAY_LENGTH.
>> 
>> It would be more robust if the algorithm was well defined if either min or pref were zero.
>
> The preconditions aren't checked, because this is an internal method, and the code size is minimized in order to help inlining. That's also why `hugeLength` is a separate method. (I guess I could add comments to this effect.) With this in mind it's hard to reason about robustness. If prefLength is zero, this can only be because some precondition was violated (e.g., oldLength is negative). If this were to occur there doesn't seem to be any advantage choosing one undefined behavior over another.

Is there a reason the code would not naturally work when either min or preferred is zero?
Why are their preconditions?  What do they allow?
These methods are used in enough places that a slip in any of the clients would be trouble and hard to track down.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1617