Sometimes constraints are questionable
David Holmes
david.holmes at oracle.com
Mon Jun 1 00:54:37 UTC 2020
On 1/06/2020 9:52 am, Martin Buchholz wrote:
> On Sun, May 31, 2020 at 4:35 PM David Holmes <david.holmes at oracle.com> wrote:
>
>> Not sure how we could have minCapacity < 0 at this point. It should have
>> been checked before the call to grow, and grow will not make it negative.
>
> At least some of the grow methods were designed so that callers did
> not have to do the checking, and grow would interpret negative values
> as int overflow
>
>>> It just seems that it's pushing the inevitable off to Arrays.copyOf. Shouldn't it be:
>>>
>>> private static int hugeCapacity(int minCapacity) {
>>> if (minCapacity < 0 || minCapacity > MAX_ARRAY_SIZE) {
>>> throw
>>> new OutOfMemoryError("ByteArrayChannel exceeds maximum size: " +
>>> MAX_ARRAY_SIZE);
>>> }
>>>
>>> return MAX_ARRAY_SIZE;
>>> }
>>
>> That seems more appropriate to me - modulo the question mark over
>> minCapacity being negative.
>
> Again, the original design was to allow a capacity with MAX_ARRAY_SIZE
> < capacity <= Integer.MAX_VALUE if and when the VM also allowed it.
The only way to know that is to try and create the array, catch the OOME
and then adjust the value used. None of the code does that so I can't
see how your claim here can be correct. My understanding, having been on
the VM side, was that Hotspot's internal limits were reflected on the
Java side so that the Java code could avoid the VM exception.
David
More information about the core-libs-dev
mailing list