On Sat, May 30, 2020 at 11:11 AM Florian Weimer <f...@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.
