-
Notifications
You must be signed in to change notification settings - Fork 6.1k
8314249: Refactor handling of invokedynamic in JVMCI ConstantPool #15297
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
8314249: Refactor handling of invokedynamic in JVMCI ConstantPool #15297
Conversation
|
👋 Welcome back iklam! A progress list of the required criteria for merging this PR into |
…this PR already have test cases
Webrevs
|
| * {@code constantPool}. | ||
| * Gets the appendix object (if any) associated with the entry identified by {@code which}. | ||
| * | ||
| * @param which if negative, is treated as an encoded indy index for INVONEDYNAMIC; |
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.
INVONEDYNAMIC -> INVOKEDYNAMIC
| * <li>which - May be either a {@code rawIndex} or a {@code cpci}.</li> | ||
| * </ul> | ||
| * | ||
| * Note that {@code cpci} and {@code which} are used only in the HotSpot-specific implementation. They are not used by the public iterface in jdk.vm.ci.meta.*. |
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.
iterface -> iterface
| * {@code cpi} was not decoded from an instruction stream | ||
| * @return the bootstrap method invocation details or {@code null} if the entry at {@code cpi} | ||
| * @param index if {@code opcode} is -1, {@code index} is a constant pool index. Otherwise {@code opcode} | ||
| * must be ${code Bytecodes.INVOKEDYNAMIC}, and {@code index} must be the operand of that |
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.
${code Bytecodes.INVOKEDYNAMIC} -> {@code INVOKEDYNAMIC} (in numerous places)
|
Thanks a lot for this cleanup and adding the extra tests. |
|
@iklam This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be: You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 22 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
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 makes sense. Do we run this test with hotspot testing?
| public BootstrapMethodInvocation lookupBootstrapMethodInvocation(int rawCpi, int opcode) { | ||
| int cpi = opcode == -1 ? rawCpi : rawIndexToConstantPoolIndex(rawCpi, opcode); | ||
| public BootstrapMethodInvocation lookupBootstrapMethodInvocation(int index, int opcode) { | ||
| int cpi = opcode == -1 ? index : indyIndexConstantPoolIndex(index, opcode); |
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.
Why would opcode be -1 here?
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.
So that tests such as TestDynamicConstant.java can iterate through the constant pool, looking for invokedynamic related entries.
Yes, tests under |
|
Going to push as commit 0299364.
Your commit was automatically rebased without conflicts. |
| final int index = rawIndexToConstantPoolCacheIndex(cpi, opcode); | ||
| final HotSpotResolvedJavaMethod method = compilerToVM().lookupMethodInPool(this, index, (byte) opcode, (HotSpotResolvedJavaMethodImpl) caller); | ||
| public JavaMethod lookupMethod(int rawIndex, int opcode, ResolvedJavaMethod caller) { | ||
| final int cpci = rawIndexToConstantPoolCacheIndex(rawIndex, opcode); |
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.
@iklam we need to support opcode == INVOKEDYNAMIC here. After this change, we are seeing:
Caused by: java.lang.InternalError: java.lang.IllegalArgumentException: unexpected opcode 186
at jdk.internal.vm.compiler/org.graalvm.compiler.serviceprovider.GraalServices.lookupMethodWithCaller(GraalServices.java:464)
at jdk.internal.vm.compiler/org.graalvm.compiler.java.BytecodeParser.lookupMethodInPool(BytecodeParser.java:4274)
at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.phases.SharedGraphBuilderPhase$SharedBytecodeParser.lookupMethodInPool(SharedGraphBuilderPhase.java:209)
at jdk.internal.vm.compiler/org.graalvm.compiler.java.BytecodeParser.lookupMethod(BytecodeParser.java:4266)
at jdk.internal.vm.compiler/org.graalvm.compiler.java.BytecodeParser.genInvokeDynamic(BytecodeParser.java:1725)
at jdk.internal.vm.compiler/org.graalvm.compiler.java.BytecodeParser.processBytecode(BytecodeParser.java:5363)
at jdk.internal.vm.compiler/org.graalvm.compiler.java.BytecodeParser.iterateBytecodesForBlock(BytecodeParser.java:3431)
... 116 more
Caused by: java.lang.IllegalArgumentException: unexpected opcode 186
at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotConstantPool.rawIndexToConstantPoolCacheIndex(HotSpotConstantPool.java:275)
at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotConstantPool.lookupMethod(HotSpotConstantPool.java:722)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
at jdk.internal.vm.compiler/org.graalvm.compiler.serviceprovider.GraalServices.lookupMethodWithCaller(GraalServices.java:457)
... 122 more
when building libgraal. The following patch seems to fix it:
diff --git a/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotConstantPool.java b/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotConstantPool.java
index d4bb97f03c4..1d32211f1a0 100644
--- a/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotConstantPool.java
+++ b/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotConstantPool.java
@@ -719,7 +719,15 @@ private static JavaType getJavaType(final Object type) {
@Override
public JavaMethod lookupMethod(int rawIndex, int opcode, ResolvedJavaMethod caller) {
- final int cpci = rawIndexToConstantPoolCacheIndex(rawIndex, opcode);
+ final int cpci;
+ if (opcode == jdk.vm.ci.hotspot.HotSpotConstantPool.Bytecodes.INVOKEDYNAMIC) {
+ if (!isInvokedynamicIndex(rawIndex)) {
+ throw new IllegalArgumentException("expected a raw index for INVOKEDYNAMIC but got " + rawIndex);
+ }
+ cpci = rawIndex;
+ } else {
+ cpci = rawIndexToConstantPoolCacheIndex(rawIndex, opcode);
+ }
final HotSpotResolvedJavaMethod method = compilerToVM().lookupMethodInPool(this, cpci, (byte) opcode, (HotSpotResolvedJavaMethodImpl) caller);
if (method != null) {
return method;
This PR is part of the clean up JVMCI to track JDK-8301993, where the constant pool cache is being removed (as of now, only method references use the CpCache).
rawIndexToConstantPoolIndex()is used only for theinvokedynamicbytecode. It should be renamed toindyIndexConstantPoolIndex()rawIndexToConstantPoolCacheIndex()should not be called for theinvokedynamicbytecode, which doesn't use cpCache entries after JDK-8301995.Some
cpiparameters should be renamed torawIndexorwhichAdded a test case for
ConstantPool.lookupAppendix(), which was not tested in the JDK repo.I added comments about the 4 types of indices used in HotSpotConstantPool.java:
cpi,rawIndex,cpciandwhich. The latter two types will be removed after JDK-8301993 is complete.Note that there are still some incorrect use of
cpiin the implementation and test cases. Those will be cleaned up in JDK-8314172Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/15297/head:pull/15297$ git checkout pull/15297Update a local copy of the PR:
$ git checkout pull/15297$ git pull https://git.openjdk.org/jdk.git pull/15297/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 15297View PR using the GUI difftool:
$ git pr show -t 15297Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/15297.diff
Webrev
Link to Webrev Comment