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