Sometimes constraints are questionable

Martin Buchholz martinrb at google.com
Sat May 30 23:33:56 UTC 2020


On Sat, May 30, 2020 at 11:11 AM Florian Weimer <fw at deneb.enyo.de> wrote:
>
> * Martin Buchholz:
>
> > I wrote an earlier version of this grow logic, and then it was
> > transplanted into other classes.
> >
> > We strongly suspect that the VM will throw OOME when we try to
> > allocate an array beyond MAX_ARRAY_SIZE, so are reluctant to do so,
> > but we also consider the VM behavior a bug that may eventually get
> > fixed (or is already a non-issue with a different VM).  We are trying
> > for good behavior with both sorts of VM.
>
> I still don't think this explains the present code.

It's very easy for nano-bugs in code like this to creep in, because of
the difficulty of testing.

>  However, I
> wouldn't be surprised if there have been early bugs where the VM would
> produce a corrupt array instead of failing the allocation.  But these
> bugs will have been fixed by now.

IIRC I invented MAX_ARRAY_SIZE and there was no thought of such VM
bugs.  VM engineers are expected to fix any such bugs quickly.

> C++ has a subclass of std::bad_alloc for certain allocations that
> exceed implementation limits (std::bad_array_new_length).  Since
> memory is rarely tight when this happens, it allows providing better
> diagnostics.

And hotspot itself includes a meaningful detail when it throws an
exception from new Object[Integer.MAX_VALUE].
But that behavior is unspecified.
We could have introduced a new subclass of Throwable that was
specified to be thrown when implementation limits were exceeded.
As usual, probably too late now.


More information about the core-libs-dev mailing list