Fix underestimation of array length in constrainAload

[dylanjtuttle]

To this point, VP has constrained the length of an array in constrainAload to be between 0 and TR::getMaxSigned<TR::Int32>() / elementSize elements long. This was likely a due to a historical limitation. Since arrays can be longer than TR::getMaxSigned<TR::Int32>() bytes, if such an array were copied, it would fail the ArrayCopyBNDCHK, causing erroneous removal of trees that would prevent the copy from being performed. I discussed my findings during my investigation of this issue in a series of comments in openj9 #19247.

This PR increases the high bound of the constraint on the length of an array in constrainAload by using J9::ObjectModel::maxArraySizeInElements() instead, which produces a better upper bound based on the size of the heap. We already use this method in other parts of VP, like constrainArraylength.

Fixes: openj9 #19247, openj9 #19403, openj9 #15500 (most likely)

[dylanjtuttle]

@hzongaro Could I get a review on this when you get back?

[dylanjtuttle]

Since this is for 0.48, maybe I should get a quicker review. @0xdaryl @vijaysun-omr would one of you be able to review this when you get a chance?

[vijaysun-omr]

Can you please elaborate on the actual problem ? i.e. what was the array info constraint saying originally and how does the fix address it ? Maybe the problem is that TR::getMaxSigned<TR::Int32>()/elementSize underestimates the number of elements because we can have arrays that are more than TR::getMaxSigned<TR::Int32>() bytes long.

[vijaysun-omr]

jenkins build all

[dylanjtuttle]

Maybe the problem is that TR::getMaxSigned<TR::Int32>()/elementSize underestimates the number of elements because we can have arrays that are more than TR::getMaxSigned<TR::Int32>() bytes long.

That's correct. I've updated the description with a more in depth explanation of the problem and how this PR will fix it.

[dylanjtuttle]

@vijaysun-omr Does this need to be double delivered for 0.48? This is the first time I've been in a situation where that might be necessary, so I'm not sure what that entails.

[hzongaro]

@pshipton, is it too late for us to get this into the OpenJ9 0.48 release?

[hzongaro]

Does this need to be double delivered for 0.48? This is the first time I've been in a situation where that might be necessary, so I'm not sure what that entails.

It would entail opening a pull request for this change against the OpenJ9-OMR 0.48 release branch.

[pshipton]

is it too late for us to get this into the OpenJ9 0.48 release?

No, everything is delayed.