On Mon, 8 Apr 2024 13:46:03 GMT, Roger Riggs <rri...@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
