Look for right caller method when handling OSR in context of inliner #4177
Conversation
|
I have marked this pull request as a work in progress as it interacts with OpenJ9 pull request #6626, which makes the same change in OSR-related inliner code in OpenJ9. Andrew Craik @andrewcraik , who advised me on this fix, indicated that the way the calling method is found should be kept consistent. So, I'm wondering whether I should protect the change in OMR under some OpenJ9-specific macro, and mark the OpenJ9 pull request dependent on this OMR pull request, so that the change in OMR is only enabled when the change in OpenJ9 is available and enabled. Once both pull requests were merged, I would then submit new pull requests so that the changes would no longer be protected by a macro. |
|
The 'correct' answer would be to protect the condition change and make J9 cause that macro to be defined. If there is an easy way to do this then that would simplify the merge. Otherwise we will have to sequence the delivery with the corresponding OpenJ9 change to avoid the problematic intermediate state. |
|
looks like the right change - I'll approve once we know the delivery plan |
In many places, OSR-related code in the inliner is calling getOwningMethodSymbol() on a symbol reference in order to access information about the calling method. However, the owning method for a symbol reference is not necessarily the calling method. Instead, code should call getInlinedResolvedMethodSymbol() on the TR::Compilation object for the bytecode's caller index or, if the caller index is -1, call getMethodSymbol(). These changes are guarded by #if defined(INLINER_OSR_CALLING_METHOD) so that they can enabled together with corresponding changes in downstream components. Once the downstream components have changed, a definition of INLINER_OSR_CALLING_METHOD will be added, and then the guards subsequently removed. Signed-off-by: Henry Zongaro <zongaro@ca.ibm.com>
hzongaro
force-pushed
the
inliner-osr-calling-method
branch
from
a679075
to
b41fbae
Compare
|
I've put the changes under I will submit subsequent pull requests to enable the change and then to make them unconditional |
hzongaro
changed the title
|
@genie-omr build all |
In many places, OSR-related code in the inliner is calling
getOwningMethodSymbol()on a symbol reference in order to access information about the calling method. However, the owning method for a symbol reference is not necessarily the calling method.Instead, code should call
getInlinedResolvedMethodSymbol()on theTR::Compilationobject for the bytecode's caller index or, if the caller index is -1, callgetMethodSymbol().Signed-off-by: Henry Zongaro zongaro@ca.ibm.com