On Fri, 4 Dec 2020 17:49:25 GMT, Stuart Marks <sma...@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
