NULL initialize dataAddr field for 0 size arrays #20892
Conversation
|
@hzongaro Can I please get a review? |
There was a problem hiding this comment.
I have some questions about whether the padding field always exists.
Also, I wonder whether it would be worthwhile having methods that will return the offset of the padding field instead of calculating it here, and perhaps a method that will indicate whether the padding field even exists, if it might not exist.
| @@ -1554,37 +1553,18 @@ static TR::Register * generateMultianewArrayWithInlineAllocators(TR::Node *node, | |||
| // Init size and mustBeZero ('0') fields to 0 | |||
| generateMemImmInstruction(TR::InstOpCode::S4MemImm4, node, generateX86MemoryReference(targetReg, fej9->getOffsetOfContiguousArraySizeField(), cg), 0, cg); | |||
| generateMemImmInstruction(TR::InstOpCode::S4MemImm4, node, generateX86MemoryReference(targetReg, fej9->getOffsetOfDiscontiguousArraySizeField(), cg), 0, cg); | |||
| if (TR::Compiler->om.compressObjectReferences()) | |||
| { // Clear padding in contiguous array header layout. +4 because size field is 4 bytes wide. | |||
| generateMemImmInstruction(TR::InstOpCode::S4MemImm4, node, generateX86MemoryReference(targetReg, fej9->getOffsetOfDiscontiguousArraySizeField() + 4, cg), 0, cg); | |||
There was a problem hiding this comment.
Do you know why this padding wasn’t previously being cleared? What problems will failing to clear it cause?
There was a problem hiding this comment.
I believe it just slipped through the cracks. It hasn't caused any failures as of now, I don't think we read the padding. I am clearing it mostly because of the implicit expectation that all non used "fields" in an array header should be NULL.
There was a problem hiding this comment.
I believe it is already being done for VM allocated arrays. @tajila Can you please confirm if this is true?
There was a problem hiding this comment.
GC always zeroes header of the object before initialization (including possible padding) if it has not been zeroed before as part of pre-zeroed TLH. So, yes, padding in the header is zeroed always.
There was a problem hiding this comment.
My concern about changes like this is logic connected with Indexable header shapes happen to be used now. Any change in this area would require to fix (and find first!) all places like this. I understand any generalization can impact JIT performance, but we should think about it. Also if we want to clear padding using 32-bit instruction (is it right?) why do J9IndexableObjectDiscontiguousCompressed->size offset + 4 bytes, why not to use J9IndexableObjectDiscontiguousCompressed->padding directly?
| @@ -1633,6 +1613,28 @@ static TR::Register * generateMultianewArrayWithInlineAllocators(TR::Node *node, | |||
| generateMemRegInstruction(TR::InstOpCode::SMemReg(use64BitClasses), node, generateX86MemoryReference(targetReg, TR::Compiler->om.offsetOfObjectVftField(), cg), classReg, cg); | |||
| // Init 1st dim array size field | |||
| generateMemRegInstruction(TR::InstOpCode::S4MemReg, node, generateX86MemoryReference(targetReg, fej9->getOffsetOfContiguousArraySizeField(), cg), firstDimLenReg, cg); | |||
| if (!TR::Compiler->om.compressObjectReferences()) | |||
| { // Clear padding in contiguous array header layout. +4 because size field is 4 bytes wide. | |||
| generateMemImmInstruction(TR::InstOpCode::S4MemImm4, node, generateX86MemoryReference(targetReg, fej9->getOffsetOfContiguousArraySizeField() + 4, cg), 0, cg); | |||
There was a problem hiding this comment.
Does the padding field exist for contiguous array header in 32-bit mode? Looking at j9nonbuilder.h, I don't think it does. Sorry if I'm misreading it!
|
That's a good suggestions. I'll open a separate PR with APIs to indicate whether padding field exists and get it's offset. I'll use this PR just for dataAddr changes since it must be cleared for off-heap but we can get away by not clearing padding field. |
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 <shubhamv.sv@gmail.com>
VermaSh
force-pushed
the
inline_array_allocation_x
branch
from
01b6a39 to
5196431
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. Additionally this also clears padding field after the size field.