RFR: 8357660: [JVMCI] Add Support for Retrieving All Indy BootstrapMethodInvocations directly from the ConstantPool

Tom Shull duke at openjdk.org
Fri May 30 15:06:30 UTC 2025


On Tue, 27 May 2025 15:03:02 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Changed to return a list.
>> 
>>> Why not make this return all BootstrapMethodInvocations
>> 1. Within HotSpot it is very easy to pick off all indy BootstrapMethodInvocations via [the ConstantPoolCache](https://github.com/openjdk/jdk/blob/72a3022dc6a1521d8e3f08fe5d592f760fc462d2/src/hotspot/share/oops/cpCache.hpp#L74)
>> 2. Each invokedynamic bytecode location has a unique BootstrapMethodInvocation instance, but they may share the same constant pool entry, so it's not trivial to find all BootstrapMethodInvocations. One would have to iterate both all method bytecodes and constant pool slots, and do some additional filtering.
>
> How about `List<BootstrapMethodInvocation> lookupBootstrapMethodInvocations(boolean indy)`? That is, it either gets the indy *or* the condy BSM invocations. I can imagine SVM wanting the latter at some point right?
> 
> BTW, I noticed that the javadoc for `ConstantPool.lookupBootstrapMethodInvocation` is somewhat incorrect. Please check and apply these corrections in this PR:
> 
> diff --git a/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/ConstantPool.java b/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/ConstantPool.java
> index 2273b256f03..3519af4bcbb 100644
> --- a/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/ConstantPool.java
> +++ b/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/ConstantPool.java
> @@ -199,12 +199,12 @@ interface BootstrapMethodInvocation {
>       * in the constant pool.
>       *
>       * @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
> -     *              opcode in the bytecode stream (i.e., a {@code rawIndex}).
> -     * @param opcode must be {@code Bytecodes.INVOKEDYNAMIC}, or -1 if
> +     *              must be {@code Bytecodes.INVOKEDYNAMIC} or {@code CONSTANT_Dynamic_info}, and {@code index}
> +     *              must be the operand of that opcode in the bytecode stream (i.e., a {@code rawIndex}).
> +     * @param opcode must be {@code Bytecodes.INVOKEDYNAMIC}, {@code CONSTANT_Dynamic_info}, or -1 if
>       *            {@code index} was not decoded from a bytecode stream
>       * @return the bootstrap method invocation details or {@code null} if the entry specified by {@code index}
> -     *         is not a {@code CONSTANT_Dynamic_info} or @{code CONSTANT_InvokeDynamic_info}
> +     *         is not a {@code CONSTANT_Dynamic_info} or {@code CONSTANT_InvokeDynamic_info}
>       * @jvms 4.7.23 The {@code BootstrapMethods} Attribute
>       */
>      default BootstrapMethodInvocation lookupBootstrapMethodInvocation(int index, int opcode) {

I prototyped the option `List<BootstrapMethodInvocation> lookupBootstrapMethodInvocations(boolean indy)` here: https://github.com/openjdk/jdk/compare/master...teshull:jdk:jvmci_bootstrap_alternative

As part of this I also prototyped generic BSM resolution / lookup logic

>From the SVM perspective, retrieving condys via this new support isn't a big win. It's easy enough already to walk the ConstantPool. However, for symmetry purposes, it is reasonable to have this method (along with the resolve / lookup). What's your preference: this new version or the original?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25420#discussion_r2110104069


More information about the graal-dev mailing list