On Tue, 28 Feb 2023 09:05:44 GMT, John Hendrikx <jhendr...@openjdk.org> wrote:
>> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1903:
>>
>>> 1901: throw new OutOfMemoryError("Required length exceeds
>>> implementation limit");
>>> 1902: }
>>> 1903: int total = count * length;
>>
>> We may avoid division if we use the long type:
>>
>>
>> long totalLong = ((long) count) * length;
>> if (totalLong > Integer.MAX_VALUE - offset) {
>> throw new OutOfMemoryError("Required length exceeds implementation
>> limit");
>> }
>> int total = (int) totalLong;
>>
>>
>> Should be faster.
>
> I'm a bit surprised this (and the original code) is throwing
> `OutOfMemoryError` when running into the max array size. It is not truly an
> out of memory error, but being an `Error`, it would evade standard catch
> `Exception` blocks. I would think this is more of an `IllegalStateException`
> or perhaps something array specific.
>
> `OutOfMemoryError` is documented pretty specifically that an object
> allocation failed after exhaustive GC, but no allocation or GC happened:
>
>>Thrown when the Java Virtual Machine cannot allocate an object because it is
>>out of memory, and no more memory could be made available by the garbage
>>collector.
>
> ... which is not happening here at all. This leads me to believe the error is
> not used correctly here.
>
> Other reasons I find it surprising: `StringBuilder` is not documented to
> throw this anywhere, it seems to just leak through from various methods
> implemented by `AbstractStringBuilder`.
OOME is used for a number of not-strictly out of memory conditions, for example
off-heap allocation and allocations that can't succeed because they exceed
implementation limits.
-------------
PR: https://git.openjdk.org/jdk/pull/12728
