I'm still not deeply reading the code in java.nio but I see in
AbstractStringBuilder
* Will not return a capacity greater than
* {@code (MAX_ARRAY_SIZE >> coder)} unless the given minimum capacity
* is greater than that.
My intent was that a garden variety grow method would first grow to
MAX_ARRAY_SIZE, then to Integer.MAX_VALUE.
(this doesn't always work, e.g. hash tables want to have a
power-of-two sized backing array)
(these methods have evolved recently without much help from me)
(Library code should know as little about VM implementation
idiosyncrasies as possible)
On Sun, May 31, 2020 at 5:56 PM David Holmes <david.hol...@oracle.com> wrote:
>
> 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
