RFR 8223593 : Refactor code for reallocating storage

[Pavel Rappo]

> On 10 May 2019, at 09:52, Peter Levart <peter.levart at gmail.com> wrote:
> 
> <snip>
> 
> Is there a case where returning > MAX_ARRAY_SIZE will not lead to OOME?
> 
> If this utility method is meant for re-sizing arrays only (currently it is only used for that), then perhaps the method could throw OOME explicitly in this case. You already throw OOME for the overflow case, so currently the method is not uniform in returning exceptional values (i.e. values that lead to exceptions).
> 
> Unless you expect some VMs to tolerate arrays as large as Integer.MAX_VALUE ?

I think the proposed behaviour is equivalent to what there is now. After all,
it's a refactoring effort and as such *should* result in equivalent behaviour.

If understand you correctly, your question can be answered by answering 

    Why there is MAX_ARRAY_SIZE in the first place?

> These lines:
> 
>  607         int newCapacity = oldCapacity + preferredGrowBy;
>  608         if (preferredGrowBy < growAtLeastBy) {
>  609             newCapacity = oldCapacity + growAtLeastBy;
>  610         }
> 
> ...could perhaps be more easily grasped as:
> 
> int newCapacity = oldCapacity + Math.max(preferredGrowBy, growAtLeastBy);

I'm not an expert here, but if I understood Ivan correctly, the purpose was to
avoid branching. Maybe intrinsified Math.max is superior in both readability and
performance. I simply don't know. If you feel strongly about using it, you could
maybe compare those approaches by benchmarking.