Intialize dataAddr field only for non-zero length array #20869
Conversation
VermaSh
force-pushed
the
inline_array_allocation_z
branch
from
ff0ba22 to
5938046
Compare
|
Off-heap personal build, upstream personal build. My off-heap personal build is looking good so far, only 1 unrelated failure. I'll remove the WIP tag once both builds have passed without off-heap related failures. cc: @r30shah / @zl-wang / @dmitripivkine |
VermaSh
changed the title
VermaSh
force-pushed
the
inline_array_allocation_z
branch
from
5938046 to
54bf0a5
Compare
|
Launched new non-off-heap personal build to verify PR changes |
VermaSh
force-pushed
the
inline_array_allocation_z
branch
2 times, most recently
from
da4a877 to
9b31e29
Compare
VermaSh
force-pushed
the
inline_array_allocation_z
branch
8 times, most recently
from
1317bac to
c3c566c
Compare
|
Relaunched non off-heap build |
VermaSh
force-pushed
the
inline_array_allocation_z
branch
2 times, most recently
from
f3b4840 to
7994eb1
Compare
Update array inline allocation sequence to initialize dataAddr field only for non-zero size arrays. Field should be left blank for zero size arrays. Signed-off-by: Shubham Verma <[email protected]>
VermaSh
force-pushed
the
inline_array_allocation_z
branch
3 times, most recently
from
648f364 to
068425c
Compare
|
I have verified the sequence for x and z through a unit test. Need to do the same for power and aarch64 before removing WIP tag. |
VermaSh
force-pushed
the
inline_array_allocation_z
branch
from
068425c to
6d13fde
Compare
|
Launched personal non off-heap build for power. |
VermaSh
force-pushed
the
inline_array_allocation_z
branch
3 times, most recently
from
71bbabb to
8f03946
Compare
VermaSh
changed the title
|
Kept only z here as it is ready for review, other platforms require more testing. @r30shah Can I please get a review? |
| if (isOffHeapAllocationEnabled) | ||
| { | ||
| TR_ASSERT_FATAL_WITH_NODE(node, | ||
| TR::InstOpCode::LGF == loadDimLenOpCode, |
There was a problem hiding this comment.
Can you explain why we have this assert (Checking loadDimLenOpCode to LGF). That variable is initialized to LGF at line 4891 and I do not see it ever updated.
There was a problem hiding this comment.
dataAddr field should be 0 for 0 size arrays. Since size will already be 0, I figured we can use that to 0-out dataAddr field. The issue is that size is 4 bytes wide whereas dataAddr is 8 bytes wide, in order to use the same register I need to clear top 4 bytes of firstDimLenReg. I added the assert to ensure that size is sign extended to 64 bits when being loaded to firstDimLenReg. Same logic for second LGF assert.
There was a problem hiding this comment.
I do get the reason behind using the LGF instruction. Do you mean to say the logic for the assert is safeguarding someone accidentally changing the code to use other instruction to load firstDimLenReg ? If so instead of putting this assert which I feel is not needed, we should put the comment where you are loading firstDimLenReg on why using LGF instead of LG and warn about the potential functional issue.
| } | ||
| if (isOffHeapAllocationEnabled) | ||
| { | ||
| TR_ASSERT_FATAL_WITH_NODE(node, |
Update array inline allocation sequence to initialize dataAddr field only for non-zero length arrays. Field should be left blank for zero length arrays. Additionally this also clears padding field after the size field.