-
Notifications
You must be signed in to change notification settings - Fork 720
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consolidate AOT Relocation Records #10916
Consolidate AOT Relocation Records #10916
Conversation
@mstoodle could you please revew? |
reloRecord->setSize(reloTarget, relocation->getSizeOfRelocationData()); | ||
reloRecord->setType(reloTarget, kind); | ||
|
||
uint8_t wideOffsets = relocation->needsWideOffsets() ? RELOCATION_TYPE_WIDE_OFFSET : 0; | ||
reloRecord->setFlag(reloTarget, wideOffsets); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason for this is because of an ordering issue, namely:
- Do platform specific way of gathering data for the relocation header, if it exists
- Otherwse, do common way of gathering data for the relocation header
If a relo type has both a platform specific implementation and a common implementation, the platform specific implementation must be done. This means that even though this deleted code is common regardless of the relotype, we cannot move it into the code that does the common way of gathering data, because we might not call into it. Therefore, this code is moved into each of the platform specific versions of initializeAOTRelocationHeader
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not a huge fan of spraying code like that. Did you consider defining a "common" initialization routine that must be called for all platforms followed/preceded by a call to either the platform or "default" initialization code? You'd still have the flexibility to move stuff from the "common" initialization routine to all the platform routines if needed, but if you could share it, it can go into that common routine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, this code was technically redundant because the the TR_RelocationRecordBinaryTemplate
fields were being initialized in each of the various implementations via the raw pointer manipulation, before executing this code, so I definitely didn't increase the code duplication, I just didn't decrease it heh :).
However, adding a common pre-initialization routine is definitely a good idea; I will add it in the misc clean up PR that I'll open after this. Given how big this PR is I don't want to complicate it further or introduce some stupid bug.
TR::LabelSymbol *table; | ||
uint8_t *codeLocation; | ||
// Zero-initialize header | ||
memset(cursor, 0, sizeOfReloData); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is extremely necessary. Prior to this change, the flags were written in via a pointer. Now, it is written in using the setFlag
API, which masks it in. Therefore, we need to make sure that buffer does not contain random data or it could result in that random data being interpreted as valid bits in the flag field.
// This has to be created after the kind has been written into the header | ||
TR_RelocationRecord storage; | ||
TR_RelocationRecord *reloRecord = TR_RelocationRecord::create(&storage, reloRuntime, reloTarget, reinterpret_cast<TR_RelocationRecordBinaryTemplate *>(relocation->getRelocationData())); | ||
cursor += sizeof(TR_RelocationRecordBinaryTemplate); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Temporary in this commit, this is removed in the last commit in this PR. It was needed because the yet to be consolidated relocation records assume the position of the cursor is past the TR_RelocationRecordBinaryTemplate
portion of the header.
TR_RelocationRecord *reloRecord = TR_RelocationRecord::create(&storage, reloRuntime, targetKind, reinterpret_cast<TR_RelocationRecordBinaryTemplate *>(cursor)); | ||
|
||
uint8_t wideOffsets = relocation->needsWideOffsets() ? RELOCATION_TYPE_WIDE_OFFSET : 0; | ||
uint32_t *wordAfterHeader = &reinterpret_cast<TR_RelocationRecordPicTrampolineBinaryTemplate *>(cursor)->_numTrampolines; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Temporary, this is removed by the end of the PR. Consequence of the hacky
#if defined(TR_HOST_64BIT)
uint32_t _extra;
#endif
field in TR_RelocationRecordBinaryTemplate
@mstoodle review reminder :) |
@mstoodle friendly review reminder. |
@mstoodle friendly review reminder |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would you please change title to "Add new TR_RelocationRecord::create API" and add a few words to explain why you're adding this new API?
moRecord->setConstantPool(reloTarget, reinterpret_cast<uintptr_t>(symRef->getOwningMethod(comp)->constantPool())); | ||
moRecord->setReloFlags(reloTarget, flags); | ||
|
||
cursor = relocation->getRelocationData() + TR_RelocationRecord::getSizeOfAOTRelocationHeader(static_cast<TR_RelocationRecordType>(targetKind)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the fact that this relocation is implemented differently for this platform should probably be fixed at some point. Would you please create an issue for someone to bring these two implementations in line?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Opened #11201
uintptr_t inlinedSiteIndex = self()->findCorrectInlinedSiteIndex(tempSR->getOwningMethod(comp)->constantPool(), recordInfo->data2); | ||
TR::SymbolReference *symRef = reinterpret_cast<TR::SymbolReference *>(recordInfo->data1); | ||
uintptr_t inlinedSiteIndex = reinterpret_cast<uintptr_t>(recordInfo->data2); | ||
uint8_t flags = static_cast<uint8_t>(recordInfo->data3); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
similar comment here for the ARM and P implementations, which only seem to differ in the requirement for flags? Seems like it could be folded into the common implementation. Another issue or maybe combine into one issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks really good @dsouzai ! Was a lot to get through in one gulp, but virtually all of it is good to go. I got tired of pointing out the places (that I know you already know about) where we should do some post PR cleanup to try to avoid having e.g. ARM and POWER require very slightly different steps (due to flags setting and use of different information passing mechanisms to configure the relocation records) to construct the relocations themselves.
self()->traceRelocationOffsets(cursor, offsetSize, endOfCurrentRecord, orderedPair); | ||
if (isVerbose) | ||
{ | ||
traceMsg(self()->comp(), "\nTR_DataAddress: InlinedCallSite index = %d, Constant pool = %x, cpIndex = %d, offset = %x", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't the flags also be printed by this code? Same comment for the MethodObject and ClassAddress relocations, I think.
jenkins test sanity all jdk8,jdk11 |
Add a new API that does not require the relocation record binary template header to already exist in order to determine the kind of the relocation record when creating it. This is necessary because the TR_RelocationRecord and subclasses are an API class that are used to both read and write data to and from, respectively, the binary template header. Signed-off-by: Irwin D'Souza <dsouzai.gh@gmail.com>
Signed-off-by: Irwin D'Souza <dsouzai.gh@gmail.com>
Remove the duplicated code that writes the TR_DiscontiguousSymbolFromManager relocation header information, and consolidate it in one canonical location. Signed-off-by: Irwin D'Souza <dsouzai.gh@gmail.com>
Remove the duplicated code that writes the TR_MethodObject relocation header information, and consolidate it in one canonical location. Note: TR_MethodObject is not used anywhere on P; in fact that code that wrote out the header data was incorrect as it wrote in the fields in the wrong order. Signed-off-by: Irwin D'Souza <dsouzai.gh@gmail.com>
Remove the duplicated code that writes the TR_ClassAddress relocation header information, and consolidate it in one canonical location. Signed-off-by: Irwin D'Souza <dsouzai.gh@gmail.com>
Remove the duplicated code that writes the TR_DataAddress relocation header information, and consolidate it in one canonical location. Signed-off-by: Irwin D'Souza <dsouzai.gh@gmail.com>
Remove the duplicated code that writes the TR_AbsoluteMethodAddressOrderedPair relocation header information, and consolidate it in one canonical location. Signed-off-by: Irwin D'Souza <dsouzai.gh@gmail.com>
Remove the duplicated code that writes the TR_FixedSequenceAddress relocation header information, and consolidate it in one canonical location. Signed-off-by: Irwin D'Souza <dsouzai.gh@gmail.com>
Remove the duplicated code that writes the TR_FixedSequenceAddress2 relocation header information, and consolidate it in one canonical location. Signed-off-by: Irwin D'Souza <dsouzai.gh@gmail.com>
Remove the duplicated code that writes the TR_ArrayCopyToc & TR_ArrayCopyHelper relocation header information, and consolidate it in one canonical location. Signed-off-by: Irwin D'Souza <dsouzai.gh@gmail.com>
Remove the duplicated code that writes the TR_BodyInfoAddressLoad relocation header information, and consolidate it in one canonical location. Signed-off-by: Irwin D'Souza <dsouzai.gh@gmail.com>
Signed-off-by: Irwin D'Souza <dsouzai.gh@gmail.com>
Remove the duplicated code that writes the TR_RamMethodSequence relocation header information, and consolidate it in one canonical location. Also, delete the unused TR_RamMethodSequenceReg relocation. Signed-off-by: Irwin D'Souza <dsouzai.gh@gmail.com>
Remove the duplicated code that writes the TR_ArbitraryClassAddress relocation header information, and consolidate it in one canonical location. Signed-off-by: Irwin D'Souza <dsouzai.gh@gmail.com>
Remove the duplicated code that writes the TR_GlobalValue relocation header information, and consolidate it in one canonical location. Signed-off-by: Irwin D'Souza <dsouzai.gh@gmail.com>
Remove the duplicated code that writes the TR_HCR relocation header information, and consolidate it in one canonical location. Signed-off-by: Irwin D'Souza <dsouzai.gh@gmail.com>
Remove the duplicated code that writes the TR_EmitClass relocation header information, and consolidate it in one canonical location. Signed-off-by: Irwin D'Souza <dsouzai.gh@gmail.com>
Remove the duplicated code that writes the TR_PicTrampolines relocation header information, and consolidate it in one canonical location. Signed-off-by: Irwin D'Souza <dsouzai.gh@gmail.com>
This relocation type is added in needsInvokeExactJ2IThunk. However, invokeExact isn't supported in AOT. Additionally, the code to actually do the relocation is missing, meaning this relo type is essentially dead code. Signed-off-by: Irwin D'Souza <dsouzai.gh@gmail.com>
Remove the duplicated code that writes the TR_DebugCounter relocation header information, and consolidate it in one canonical location. Signed-off-by: Irwin D'Souza <dsouzai.gh@gmail.com>
Signed-off-by: Irwin D'Souza <dsouzai.gh@gmail.com>
jenkins test sanity win32 jdk8 |
@mstoodle I'm gonna push the requested review changes (once I've verified they build), so it might not be worth running any more tests until then since it'll kind of get swept under the rug. |
ok thanks @dsouzai ....it was only one build that was resubmitted anyway because win32 cratered last time. |
All tests passed; will push new changes up. |
9d64e26
to
dd619b5
Compare
@mstoodle review changes made. |
Jenkins test sanity all jdk8 |
Builds failed because of a whole bunch of jenkins exceptions |
Jenkins test sanity plinux,plinuxxl,xlinux,xlinuxxl,osx jdk8 |
Looks like more jenkins failures.. |
Jenkins test sanity plinux,plinuxxl,xlinux,xlinuxxl jdk8 |
Finally success! |
#4803
This one seems relatively big compared to the previous such PRs. However,