Set dummy resolved method flag in findOrCreateHandleMethodSymbol() - #20231
Conversation
...instead of in the caller. This method is also called from stashArgumentsForOSR(), which neglected to set the flag. Because the flag wasn't set, the symbol reference was available for reuse, and it would be reused even if the invokehandle instruction became resolved before genInvokeHandle(). In that case, genInvokeHandle() would see isUnresolved=false, so it would push only the appendix (if non-null), but then it would get the dummy linkToStatic symbol reference, which expects more arguments. This flag is now set in findOrCreateHandleMethodSymbol(). There's no reason to allow a caller to forget to set the flag.
|
@0xdaryl, could you please review? |
|
Jenkins test sanity all jdk21 |
|
The AArch64 Linux sanity.functional failure is #20233 |
|
Two of the four Windows timeouts appear to be OSR decompilation tests. Can you check if these are real failures? |
|
Looks like #19678, which has also popped up in another PR recently. That issue doesn't mention decomp002-OSRFV, but that seems to just be a variant of decomp002 |
|
I should mention that this change shouldn't affect any actual OSR transitions (though the bug was only in compilations that have OSR enabled)
|
2 participants
...instead of in the caller.
This method is also called from
stashArgumentsForOSR(), which neglected to set the flag. Because the flag wasn't set, the symbol reference was available for reuse, and it would be reused even if theinvokehandleinstruction became resolved beforegenInvokeHandle(). In that case,genInvokeHandle()would seeisUnresolved=false, so it would push only the appendix (if non-null), but then it would get the dummylinkToStaticsymbol reference, which expects more arguments.This flag is now set in
findOrCreateHandleMethodSymbol(). There's no reason to allow a caller to forget to set the flag.