Enable peeking ILGen for methods with invokedynamic/invokehandle #22227
Conversation
| @@ -982,6 +982,8 @@ TR_J9EstimateCodeSize::processBytecodeAndGenerateCFG(TR_CallTarget *calltarget, | |||
| break; | |||
| case J9BCinvokedynamic: | |||
| case J9BCinvokehandle: | |||
| nph.setNeedsPeekingToTrue(); | |||
| heuristicTrace(tracer(), "Depth %d: Enabled peeking ILGen for method %s due to invokedynamic/invokehandle bytecode at at bc index %d.", _recursionDepth, callerName, i); | |||
There was a problem hiding this comment.
Is the fall-thru deliberate here? Maybe add comment to that effect.
There was a problem hiding this comment.
Yes, it is deliberate. I will add a comment to indicate that.
nbhuiyan
force-pushed
the
nph-invokehandle
branch
from
d075828 to
fa59738
Compare
Enabling peeking ILGen for non-root methods that contain invokedynamic or invokehandle bytecodes. This will ensure that final field folding necessary for obtaining the target method is possible, and paves the way for more inlining opportunities along MethodHandle operations. Signed-off-by: Nazim Bhuiyan <[email protected]>
nbhuiyan
force-pushed
the
nph-invokehandle
branch
from
fa59738 to
61a59f0
Compare
|
Simple enough, but also asking @jdmpapin for a review |
|
Jenkins test sanity all |
|
Jenkins test sanity.openjdk xlinux jdk21 I think we should test at least one platform against a wider set of tests. |
|
Jenkins test sanity all jdk21 Re-starting Vijay's tests specifying a JDK level. |
|
Z sanity OpenJDK failure appears to be #21619 |
|
Windows failure is in cmdLineTester_GCCheck_3 while analyzing the core file produced. This is unlikely to be caused by the change in this PR. |
Seems that it was. It's the same type of failure that is now occurring with frequency and set as a blocker. |
|
I think if we can't fix the problem in the next day or two, we should revert this. Or first try some builds with this reverted to ensure it is the right change to revert. |
Enabling peeking ILGen for non-root methods that contain invokedynamic or invokehandle bytecodes. This will ensure that final field folding necessary for obtaining the target method is possible, and paves the way for more inlining opportunities along MethodHandle operations.