On 1/06/2020 9:52 am, Martin Buchholz wrote:
On Sun, May 31, 2020 at 4:35 PM David Holmes <david.hol...@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
