RFR: 8329623: NegativeArraySizeException encoding large String to UTF-8

[Raffaello Giulietti]

On Mon, 8 Apr 2024 13:46:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Indeed, different OOMEs are thrown in the two cases triggered by different limits, min +2 is due to integer overflow, while min +1  is due a VM limit on the size of byte[Integer.MAX_VALUE]. Different VM implementations may have different limits on the max size of a byte array.
>
> There might be some merit in lowering the threshold at which an exact size computation is triggered.
> The oversized allocation "wastes" quite a bit of memory and causes extra GC work and usually triggers a second copy of the final size.
> However, some guess or heuristic would be needed to choose the threshold at which extra cpu work is needed to compute the exact size vs some metric as to the "cost" of wasted memory (and saving on the copy).
> Most guesses would be somewhat arbitrary; bigger than 1Mb, 1GB, etc....? 
> Choosing that number would be out of scope for the issue raised by this bug.

What I mean is that the VM limit might change and suddenly accept `MAX_VALUE` as an allowed array size (very unlikely, I guess). The test would then fail on `min + 1` because it expects a OOME which will not be thrown.

But that is very remote.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18663#discussion_r1555944305