I'm the author of most of the MAX_ARRAY_SIZE code in the jdk.
We should be as consistent as we can given the history. It all looks
pretty similar.
---
+ if (minCapacity < 0) // overflow
+ throw new OutOfMemoryError("Memory capacity overflow: "
+ + minCapacity);
+
I deliberately tried to push this cold code into hugeCapacity. (yeah, not
worth much ...)
---
I deliberately tried to avoid a hard limit within the grow code itself,
instead letting the VM fail with its OOME. Perhaps the VM will surprise us
by allowing the creation of the array of size Integer.MAX_VALUE, as I think
it should.
+ * @implNote
+ * The maximum size permitted by this implementation is
+ * {@code Integer.MAX_VALUE - 8}.
---
So unsurprisingly I prefer the status quo. We don't know for sure that """
ByteArrayOutputStream hugeCapacity method can return invalid capacity"""
On Mon, Jul 23, 2018 at 2:49 PM, Brian Burkhalter <
brian.burkhal...@oracle.com> wrote:
> Hi Roger,
>
> Updated version: http://cr.openjdk.java.net/~bpb/8206403/webrev.01/
>
> On Jul 23, 2018, at 2:10 PM, Roger Riggs <roger.ri...@oracle.com> wrote:
>
> > You might want to add an @requires of 8Gb or whatever so the test only
> runs on a system it can succeed on.
>
> Re-tested and changed to @requires 2g and dropped the @ignore.
>
> > I don't see the @randomness in the test. (Other than perhaps available
> heap).
>
> That was vestigial from copying the header from elsewhere.
>
> > ByteArrayOutputStream:121: A message indicating the nature of the error
> would be useful.
>
> There was no message in the original file but I concur that one is better
> so I added one.
>
> > In the test, I don't think you need to fill the array, writing 0 is just
> as good as 0xff.
>
> Changed.
>
> Thanks for the review.
>
> Brian
