I continue to think JDK library code should avoid exposing VM
implementation limits to users, i.e. exception detail messages should
not include MAX_ARRAY_SIZE
I think our grow code has been drifting to being inconsistent and
incoherent over the years.
In the code below, the detail message looks wrong; this exception is
thrown when minCapacity wraps around, not when between SAFE_BOUND and
UNSAFE_BOUND.
int SAFE_BOUND = MAX_ARRAY_SIZE >> coder;
int UNSAFE_BOUND = Integer.MAX_VALUE >> coder;
if (UNSAFE_BOUND - minCapacity < 0) { // overflow
- throw new OutOfMemoryError();
+ throw new
+ OutOfMemoryError("StringBuilder buffer exceeds maximum size: " +
+ MAX_ARRAY_SIZE);
On Mon, Jun 1, 2020 at 12:19 PM Jim Laskey <james.las...@oracle.com> wrote:
>
> To be honest I should (will) file another bug against the use of math exact
> here. I don't think the tests actually catch what they think they test. Looks
> good in theory but more often than not, the pos array above that code will
> blow up before you get there.
>
>
>
>
> > On Jun 1, 2020, at 4:09 PM, Paul Sandoz <paul.san...@oracle.com> wrote:
> >
> > +1
> >
> > I quibble about the “ignored” variable name for the caught
> > ArithmeticException.
> >
> > Paul.
> >
> >> On Jun 1, 2020, at 5:48 AM, Jim Laskey <james.las...@oracle.com> wrote:
> >>
> >> Cleans up every case of OutOfMemoryError without a message. Some logic
> >> changes in String::repeat and ByteArrayChannel:: hugeCapacity.
> >>
> >> Thank you.
> >>
> >> Cheers,
> >>
> >> -- Jim
> >>
> >> webrev: http://cr.openjdk.java.net/~jlaskey/8230744/webrev-00/index.html
> >> <http://cr.openjdk.java.net/~jlaskey/8230744/webrev-00/index.html>
> >> jbs: https://bugs.openjdk.java.net/browse/JDK-8230744
> >> <https://bugs.openjdk.java.net/browse/JDK-8230744>
> >>
> >>
> >
>
