> 172:          * lookupConstant(int index, boolean resolve) {

This example should focus on resolving the static arguments:

List args = cp.getStaticArguments();
List resolvedArgs = new ArrayList<>(args.size());
for (JavaConstant c : args) {
    JavaConstant r = c;
    if (c instanceof PrimitiveConstant pc) {
        r = ...
    }
    resolvedArgs.append(rc);
}

It should also use real Java code to remove all ambiguity.

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

PR Comment: https://git.openjdk.org/jdk/pull/15588#issuecomment-1718890016
PR Review Comment: https://git.openjdk.org/jdk/pull/15588#discussion_r1325465891

From duke at openjdk.org  Thu Sep 14 12:48:13 2023
From: duke at openjdk.org (Sacha Coppey)
Date: Thu, 14 Sep 2023 12:48:13 GMT
Subject: RFR: 8315771: [JVMCI] Resolution of bootstrap methods with int[]
 static arguments [v9]
In-Reply-To: 
References: 
Message-ID: 

> Currently, `jdk.vm.ci.meta.ConstantPool.lookupBootstrapMethodInvocation` does not support static arguments of type `int[]`.
> 
> Supporting those static arguments allows to correctly lookup the `BootstrapMethodInvocation` of some `InvokeDynamic` and `DynamicConstant`.
> 
> To lookup the constant at the index in the static arguments index list, a new class is introduced, allowing to lazily resolve the constant or obtain the constant pool index of the arguments:
> 
> 
>     static class CachedBSMArgs extends AbstractList {
>         private final JavaConstant[] cache;
>         private final HotSpotConstantPool cp;
>         private final int bssIndex;
> 
>         CachedBSMArgs(HotSpotConstantPool cp, int bssIndex, int size) {
>             this.cp = cp;
>             this.bssIndex = bssIndex;
>             this.cache = new JavaConstant[size];
>         }
> 
>         @Override
>         public JavaConstant get(int index) {
>             JavaConstant res = cache[index];
>             if (res == null) {
>                 int argCpi = compilerToVM().bootstrapArgumentIndexAt(cp, bssIndex, index);
>                 res = compilerToVM().lookupConstantInPool(cp, argCpi, false);
>                 if (res == null) {
>                     res = JavaConstant.forInt(argCpi);
>                 }
>                 cache[index] = res;
>             }
>             return res;
>         }
> 
>         @Override
>         public int size() {
>             return cache.length;
>         }
>     }

Sacha Coppey has updated the pull request incrementally with one additional commit since the last revision:

  Update getStaticArguments documentation example and update TestDynamicConstant to test the new functionality

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15588/files
  - new: https://git.openjdk.org/jdk/pull/15588/files/d75e0926..f4377fc9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15588&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15588&range=07-08

  Stats: 73 lines in 2 files changed: 54 ins; 9 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/15588.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15588/head:pull/15588

PR: https://git.openjdk.org/jdk/pull/15588

From dnsimon at openjdk.org  Fri Sep 15 14:01:21 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 15 Sep 2023 14:01:21 GMT
Subject: RFR: 8315954: getArgumentValues002.java fails on Graal [v2]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 15 Sep 2023 13:56:00 GMT, Doug Simon  wrote:

>> This PR adds `HotSpotResolvedJavaMethod.getOopMapAt` to get the oop map for a method at a given BCI. This is required to do correct clearing of oops at OSR entry points.
>> 
>> As part of this addition, I needed to be able to detect requests for oop maps at invalid BCIs. For this, I added `InterpreterOopMap::has_valid_mask()`. When an oop map computation is requested for an invalid BCI, this method returns false.
>
> Doug Simon has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - generalized getLiveObjectLocalsAt to getOopMapAt
>  - need to zero oop_map_buf
>  - simplified getLiveObjectLocalsAt and moved it from ResolvedJavaMethod to HotSpotResolvedJavaMethod

src/hotspot/share/interpreter/oopMapCache.cpp line 616:

> 614:   tmp->fill(method, bci);
> 615:   if (tmp->has_valid_mask()) {
> 616:     entry->resource_copy(tmp);

If `tmp` is invalid (e.g. oop map was requested for invalid BCI), then `resource_copy` crashes the VM in strange ways since it blindly trusts the mask size to be valid.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15705#discussion_r1325828568

From dnsimon at openjdk.org  Fri Sep 15 14:01:23 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 15 Sep 2023 14:01:23 GMT
Subject: RFR: 8315954: getArgumentValues002.java fails on Graal [v2]
In-Reply-To: 
References: 

 <8aJO9BMxnzPYrMKaB73gsH2ra5Htz07Qo9c1yz-j-pk=.ca761ecd-81d8-47b7-b25b-673b2834d536@github.com>

Message-ID: 

On Thu, 14 Sep 2023 17:46:15 GMT, Tom Rodriguez  wrote:

>> We only look up the mask for locals and so ignore stack indexes in the mask altogether. I'm assuming therefore that `mask.is_oop(i)` can never hit any problems.
>> Note that this API should be safe when called for *any* valid BCI, not just those for an OSR entry point. Even if called for a BCI with a non-empty stack, the current implementation simply ignores that part of the mask.
>
> Yes that's implied by the name of the method. It would make me happy if there was a comment pointing out that we're explicitly ignoring whether the stack is non-empty and contains oops.

Instead, I generalized `getLiveObjectLocalsAt` to `getOopMapAt` since the VM computation is for both locals and operand stack anyway.
When called for OSR entry points, the result will be the same since (currently) HotSpot requires the stack to be empty.

>> In the common case we can avoid the overhead of allocating a long array and initializing each of it elements with a JNI upcall.
>
> It's premature optimization.  This is called once per OSR compile and the call itself is doing a dataflow over the bytecodes which seems more expensive then a couple JNI calls.  The array can be filled in using `copy_bytes_to` from HotSpot, which is a pair of JNI calls.  You already have 2 JNI calls because of the unsafe allocation.  I can maybe accept that returning a long from the JVM to avoid an allocation for the < 64 case isn't a terrible idea but I can't see any universe where we care about that.
> 
> This method should be returning a BitSet not a long.  Having the caller do that fixup is super ugly.

Ok, I'm convinced.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15705#discussion_r1327321803
PR Review Comment: https://git.openjdk.org/jdk/pull/15705#discussion_r1324933851

From dnsimon at openjdk.org  Fri Sep 15 14:01:21 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 15 Sep 2023 14:01:21 GMT
Subject: RFR: 8315954: getArgumentValues002.java fails on Graal [v2]
In-Reply-To: <8aJO9BMxnzPYrMKaB73gsH2ra5Htz07Qo9c1yz-j-pk=.ca761ecd-81d8-47b7-b25b-673b2834d536@github.com>
References: 

 <8aJO9BMxnzPYrMKaB73gsH2ra5Htz07Qo9c1yz-j-pk=.ca761ecd-81d8-47b7-b25b-673b2834d536@github.com>
Message-ID: 

On Thu, 14 Sep 2023 17:27:35 GMT, Tom Rodriguez  wrote:

>> Doug Simon has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - generalized getLiveObjectLocalsAt to getOopMapAt
>>  - need to zero oop_map_buf
>>  - simplified getLiveObjectLocalsAt and moved it from ResolvedJavaMethod to HotSpotResolvedJavaMethod
>
> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 3099:
> 
>> 3097:   JVMCIPrimitiveArray oop_map = JVMCIENV->wrap(oop_map_handle);
>> 3098:   int oop_map_len = JVMCIENV->get_length(oop_map);
>> 3099:   if (nwords > oop_map_len) {
> 
> Should we sanity check against `mask.number_of_entries()`?  One wrinkle here is that `compute_one_oop_map` also computes information about the stack so the mask it computes can be larger than just max_locals.  For the purposes of OSR this doesn't matter as none of the JITs support OSR with a non-empty stack, so we would never call it for a bci with a non-empty stack.  So should we disallow calling it with a non-empty stack or just properly handle it by passing in an array long enough to contain `max_locals + max_stack`?

We only look up the mask for locals and so ignore stack indexes in the mask altogether. I'm assuming therefore that `mask.is_oop(i)` can never hit any problems.
Note that this API should be safe when called for *any* valid BCI, not just those for an OSR entry point. Even if called for a BCI with a non-empty stack, the current implementation simply ignores that part of the mask.

> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java line 788:
> 
>> 786: 
>> 787:     @Override
>> 788:     public long getLiveObjectLocalsAt(int bci, BitSet bigOopMap) {
> 
> This seems overly complicated to me.  Why isn't it simply:
> 
>    public BitSet getLiveObjectLocalsAt(int bci) {
>         int locals = getMaxLocals();
>         int nwords = ((locals - 1) / 64) + 1;
>         long liveness[] = new long[nwords];
>         compilerToVM().getLiveObjectLocalsAt(this, bci, liveness);
>         return new BitSet(liveness);
>     }

In the common case we can avoid the overhead of allocating a long array and initializing each of it elements with a JNI upcall.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15705#discussion_r1326318835
PR Review Comment: https://git.openjdk.org/jdk/pull/15705#discussion_r1324860652

From never at openjdk.org  Fri Sep 15 14:01:22 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Fri, 15 Sep 2023 14:01:22 GMT
Subject: RFR: 8315954: getArgumentValues002.java fails on Graal [v2]
In-Reply-To: 
References: 

 <8aJO9BMxnzPYrMKaB73gsH2ra5Htz07Qo9c1yz-j-pk=.ca761ecd-81d8-47b7-b25b-673b2834d536@github.com>

Message-ID: 

On Thu, 14 Sep 2023 17:40:56 GMT, Doug Simon  wrote:

>> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 3099:
>> 
>>> 3097:   JVMCIPrimitiveArray oop_map = JVMCIENV->wrap(oop_map_handle);
>>> 3098:   int oop_map_len = JVMCIENV->get_length(oop_map);
>>> 3099:   if (nwords > oop_map_len) {
>> 
>> Should we sanity check against `mask.number_of_entries()`?  One wrinkle here is that `compute_one_oop_map` also computes information about the stack so the mask it computes can be larger than just max_locals.  For the purposes of OSR this doesn't matter as none of the JITs support OSR with a non-empty stack, so we would never call it for a bci with a non-empty stack.  So should we disallow calling it with a non-empty stack or just properly handle it by passing in an array long enough to contain `max_locals + max_stack`?
>
> We only look up the mask for locals and so ignore stack indexes in the mask altogether. I'm assuming therefore that `mask.is_oop(i)` can never hit any problems.
> Note that this API should be safe when called for *any* valid BCI, not just those for an OSR entry point. Even if called for a BCI with a non-empty stack, the current implementation simply ignores that part of the mask.

Yes that's implied by the name of the method. It would make me happy if there was a comment pointing out that we're explicitly ignoring whether the stack is non-empty and contains oops.

>> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java line 788:
>> 
>>> 786: 
>>> 787:     @Override
>>> 788:     public long getLiveObjectLocalsAt(int bci, BitSet bigOopMap) {
>> 
>> This seems overly complicated to me.  Why isn't it simply:
>> 
>>    public BitSet getLiveObjectLocalsAt(int bci) {
>>         int locals = getMaxLocals();
>>         int nwords = ((locals - 1) / 64) + 1;
>>         long liveness[] = new long[nwords];
>>         compilerToVM().getLiveObjectLocalsAt(this, bci, liveness);
>>         return new BitSet(liveness);
>>     }
>
> In the common case we can avoid the overhead of allocating a long array and initializing each of it elements with a JNI upcall.

It's premature optimization.  This is called once per OSR compile and the call itself is doing a dataflow over the bytecodes which seems more expensive then a couple JNI calls.  The array can be filled in using `copy_bytes_to` from HotSpot, which is a pair of JNI calls.  You already have 2 JNI calls because of the unsafe allocation.  I can maybe accept that returning a long from the JVM to avoid an allocation for the < 64 case isn't a terrible idea but I can't see any universe where we care about that.

This method should be returning a BitSet not a long.  Having the caller do that fixup is super ugly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15705#discussion_r1326324383
PR Review Comment: https://git.openjdk.org/jdk/pull/15705#discussion_r1324912621

From never at openjdk.org  Fri Sep 15 14:01:18 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Fri, 15 Sep 2023 14:01:18 GMT
Subject: RFR: 8315954: getArgumentValues002.java fails on Graal [v2]
In-Reply-To: 
References: 

Message-ID: <8aJO9BMxnzPYrMKaB73gsH2ra5Htz07Qo9c1yz-j-pk=.ca761ecd-81d8-47b7-b25b-673b2834d536@github.com>

On Fri, 15 Sep 2023 13:56:00 GMT, Doug Simon  wrote:

>> This PR adds `HotSpotResolvedJavaMethod.getOopMapAt` to get the oop map for a method at a given BCI. This is required to do correct clearing of oops at OSR entry points.
>> 
>> As part of this addition, I needed to be able to detect requests for oop maps at invalid BCIs. For this, I added `InterpreterOopMap::has_valid_mask()`. When an oop map computation is requested for an invalid BCI, this method returns false.
>
> Doug Simon has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - generalized getLiveObjectLocalsAt to getOopMapAt
>  - need to zero oop_map_buf
>  - simplified getLiveObjectLocalsAt and moved it from ResolvedJavaMethod to HotSpotResolvedJavaMethod

This looks good now.

src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 3099:

> 3097:   JVMCIPrimitiveArray oop_map = JVMCIENV->wrap(oop_map_handle);
> 3098:   int oop_map_len = JVMCIENV->get_length(oop_map);
> 3099:   if (nwords > oop_map_len) {

Should we sanity check against `mask.number_of_entries()`?  One wrinkle here is that `compute_one_oop_map` also computes information about the stack so the mask it computes can be larger than just max_locals.  For the purposes of OSR this doesn't matter as none of the JITs support OSR with a non-empty stack, so we would never call it for a bci with a non-empty stack.  So should we disallow calling it with a non-empty stack or just properly handle it by passing in an array long enough to contain `max_locals + max_stack`?

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod.java line 136:

> 134:      * Computes which local variables contain live object values
> 135:      * at the instruction denoted by {@code bci}. This is the "oop map" used
> 136:      * by the garbage collector.

`by the garbage collector for interpreter frames.`

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java line 788:

> 786: 
> 787:     @Override
> 788:     public long getLiveObjectLocalsAt(int bci, BitSet bigOopMap) {

This seems overly complicated to me.  Why isn't it simply:

   public BitSet getLiveObjectLocalsAt(int bci) {
        int locals = getMaxLocals();
        int nwords = ((locals - 1) / 64) + 1;
        long liveness[] = new long[nwords];
        compilerToVM().getLiveObjectLocalsAt(this, bci, liveness);
        return new BitSet(liveness);
    }

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/ResolvedJavaMethod.java line 494:

> 492:      *         by the current JVMCI runtime
> 493:      */
> 494:     default long getLiveObjectLocalsAt(int bci, BitSet bigOopMap) {

I think this should be in HotSpotResolvedJavaMethod since there's no apparent need for it in SVM.

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

Marked as reviewed by never (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15705#pullrequestreview-1627408725
PR Review Comment: https://git.openjdk.org/jdk/pull/15705#discussion_r1326305491
PR Review Comment: https://git.openjdk.org/jdk/pull/15705#discussion_r1326294532
PR Review Comment: https://git.openjdk.org/jdk/pull/15705#discussion_r1324808658
PR Review Comment: https://git.openjdk.org/jdk/pull/15705#discussion_r1324809645

From never at openjdk.org  Fri Sep 15 14:01:18 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Fri, 15 Sep 2023 14:01:18 GMT
Subject: RFR: 8315954: getArgumentValues002.java fails on Graal [v2]
In-Reply-To: 
References: 

Message-ID: <04EdBkR5FxVRvYdChK8g3nWNu93Iht65AgYEQv_ef6U=.bc20196c-9cab-4212-bb1a-85ce46a46b72@github.com>

On Wed, 13 Sep 2023 09:47:48 GMT, Doug Simon  wrote:

>> Doug Simon has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - generalized getLiveObjectLocalsAt to getOopMapAt
>>  - need to zero oop_map_buf
>>  - simplified getLiveObjectLocalsAt and moved it from ResolvedJavaMethod to HotSpotResolvedJavaMethod
>
> src/hotspot/share/interpreter/oopMapCache.cpp line 204:
> 
>> 202: void InterpreterOopMap::initialize() {
>> 203:   _method    = nullptr;
>> 204:   _mask_size = INT_MAX;  // This value should cause a failure quickly
> 
> Unless I'm mistaken, `USHRT_MAX` is a legal (but unlikely) value (i.e. `max_locals` in a class file can be 65635) so I changed this to use `INT_MAX` instead.

It's actually not legal since _mask_size is always a multiple of `bits_per_entry` which is 2 so any odd value would work.  I would be leery of touching this unless you really need to.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15705#discussion_r1324817483

From dnsimon at openjdk.org  Fri Sep 15 14:01:13 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 15 Sep 2023 14:01:13 GMT
Subject: RFR: 8315954: getArgumentValues002.java fails on Graal [v2]
In-Reply-To: 
References: 
Message-ID: 

> This PR adds `HotSpotResolvedJavaMethod.getOopMapAt` to get the oop map for a method at a given BCI. This is required to do correct clearing of oops at OSR entry points.
> 
> As part of this addition, I needed to be able to detect requests for oop maps at invalid BCIs. For this, I added `InterpreterOopMap::has_valid_mask()`. When an oop map computation is requested for an invalid BCI, this method returns false.

Doug Simon has updated the pull request incrementally with three additional commits since the last revision:

 - generalized getLiveObjectLocalsAt to getOopMapAt
 - need to zero oop_map_buf
 - simplified getLiveObjectLocalsAt and moved it from ResolvedJavaMethod to HotSpotResolvedJavaMethod

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15705/files
  - new: https://git.openjdk.org/jdk/pull/15705/files/23b94e35..c6c6c0d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15705&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15705&range=00-01

  Stats: 251 lines in 8 files changed: 65 ins; 120 del; 66 mod
  Patch: https://git.openjdk.org/jdk/pull/15705.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15705/head:pull/15705

PR: https://git.openjdk.org/jdk/pull/15705

From dnsimon at openjdk.org  Fri Sep 15 14:01:19 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 15 Sep 2023 14:01:19 GMT
Subject: RFR: 8315954: getArgumentValues002.java fails on Graal [v2]
In-Reply-To: <04EdBkR5FxVRvYdChK8g3nWNu93Iht65AgYEQv_ef6U=.bc20196c-9cab-4212-bb1a-85ce46a46b72@github.com>
References: 

 <04EdBkR5FxVRvYdChK8g3nWNu93Iht65AgYEQv_ef6U=.bc20196c-9cab-4212-bb1a-85ce46a46b72@github.com>
Message-ID: 

On Wed, 13 Sep 2023 17:06:23 GMT, Tom Rodriguez  wrote:

>> src/hotspot/share/interpreter/oopMapCache.cpp line 204:
>> 
>>> 202: void InterpreterOopMap::initialize() {
>>> 203:   _method    = nullptr;
>>> 204:   _mask_size = INT_MAX;  // This value should cause a failure quickly
>> 
>> Unless I'm mistaken, `USHRT_MAX` is a legal (but unlikely) value (i.e. `max_locals` in a class file can be 65635) so I changed this to use `INT_MAX` instead.
>
> It's actually not legal since _mask_size is always a multiple of `bits_per_entry` which is 2 so any odd value would work.  I would be leery of touching this unless you really need to.

Ok, I'll revert it to `USHRT_MAX`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15705#discussion_r1324862209

From psandoz at openjdk.org  Fri Sep 15 19:46:47 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 15 Sep 2023 19:46:47 GMT
Subject: RFR: 8315771: [JVMCI] Resolution of bootstrap methods with int[]
 static arguments [v9]
In-Reply-To: 
References: 

Message-ID: <4246ZOubrNeUr6OnRWcgzJyHItBmM-FqFp8ED9pgMMI=.36ca4df6-1208-4a10-92d2-2f868029a245@github.com>

On Thu, 14 Sep 2023 12:48:13 GMT, Sacha Coppey  wrote:

>> Currently, `jdk.vm.ci.meta.ConstantPool.lookupBootstrapMethodInvocation` does not support static arguments of type `int[]`.
>> 
>> Supporting those static arguments allows to correctly lookup the `BootstrapMethodInvocation` of some `InvokeDynamic` and `DynamicConstant`.
>> 
>> To lookup the constant at the index in the static arguments index list, a new class is introduced, allowing to lazily resolve the constant or obtain the constant pool index of the arguments:
>> 
>> 
>>     static class CachedBSMArgs extends AbstractList {
>>         private final JavaConstant[] cache;
>>         private final HotSpotConstantPool cp;
>>         private final int bssIndex;
>> 
>>         CachedBSMArgs(HotSpotConstantPool cp, int bssIndex, int size) {
>>             this.cp = cp;
>>             this.bssIndex = bssIndex;
>>             this.cache = new JavaConstant[size];
>>         }
>> 
>>         @Override
>>         public JavaConstant get(int index) {
>>             JavaConstant res = cache[index];
>>             if (res == null) {
>>                 int argCpi = compilerToVM().bootstrapArgumentIndexAt(cp, bssIndex, index);
>>                 res = compilerToVM().lookupConstantInPool(cp, argCpi, false);
>>                 if (res == null) {
>>                     res = JavaConstant.forInt(argCpi);
>>                 }
>>                 cache[index] = res;
>>             }
>>             return res;
>>         }
>> 
>>         @Override
>>         public int size() {
>>             return cache.length;
>>         }
>>     }
>
> Sacha Coppey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update getStaticArguments documentation example and update TestDynamicConstant to test the new functionality

Some general comments:

- Consider also running `TestDynamicConstant` with the `-XX:UseBootstrapCallInfo=3`. This will stress test the lazy resolution, so it is always lazy. See https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/bootstrapInfo.cpp#L130 for more details.

- In the default case, lazy resolution of bootstrap args will only occur when a condy refers to another condy, it is not specific to primitive constants. This is to avoid an edge case of infinite recursion in HotSpot (see test https://github.com/openjdk/jdk/blob/master/test/jdk/java/lang/invoke/condy/CondyNestedTest.java)

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

PR Comment: https://git.openjdk.org/jdk/pull/15588#issuecomment-1721757452

From never at openjdk.org  Mon Sep 18 18:40:41 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 18 Sep 2023 18:40:41 GMT
Subject: RFR: 8315954: getArgumentValues002.java fails on Graal [v2]
In-Reply-To: 
References: 

Message-ID: <-vcjV1PPar4XngNmn___A2whUTbQIK46aaq_fgtHJlI=.237223b6-d854-46e6-847f-b9e608f7ae06@github.com>

On Fri, 15 Sep 2023 14:01:13 GMT, Doug Simon  wrote:

>> This PR adds `HotSpotResolvedJavaMethod.getOopMapAt` to get the oop map for a method at a given BCI. This is required to do correct clearing of oops at OSR entry points.
>> 
>> As part of this addition, I needed to be able to detect requests for oop maps at invalid BCIs. For this, I added `InterpreterOopMap::has_valid_mask()`. When an oop map computation is requested for an invalid BCI, this method returns false.
>
> Doug Simon has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - generalized getLiveObjectLocalsAt to getOopMapAt
>  - need to zero oop_map_buf
>  - simplified getLiveObjectLocalsAt and moved it from ResolvedJavaMethod to HotSpotResolvedJavaMethod

New version looks good.

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

Marked as reviewed by never (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15705#pullrequestreview-1631741044

From duke at openjdk.org  Tue Sep 19 11:26:39 2023
From: duke at openjdk.org (Sacha Coppey)
Date: Tue, 19 Sep 2023 11:26:39 GMT
Subject: RFR: 8315771: [JVMCI] Resolution of bootstrap methods with int[]
 static arguments [v10]
In-Reply-To: 
References: 
Message-ID: 

> Currently, `jdk.vm.ci.meta.ConstantPool.lookupBootstrapMethodInvocation` does not support static arguments of type `int[]`.
> 
> Supporting those static arguments allows to correctly lookup the `BootstrapMethodInvocation` of some `InvokeDynamic` and `DynamicConstant`.
> 
> To lookup the constant at the index in the static arguments index list, a new class is introduced, allowing to lazily resolve the constant or obtain the constant pool index of the arguments:
> 
> 
>     static class CachedBSMArgs extends AbstractList {
>         private final JavaConstant[] cache;
>         private final HotSpotConstantPool cp;
>         private final int bssIndex;
> 
>         CachedBSMArgs(HotSpotConstantPool cp, int bssIndex, int size) {
>             this.cp = cp;
>             this.bssIndex = bssIndex;
>             this.cache = new JavaConstant[size];
>         }
> 
>         @Override
>         public JavaConstant get(int index) {
>             JavaConstant res = cache[index];
>             if (res == null) {
>                 int argCpi = compilerToVM().bootstrapArgumentIndexAt(cp, bssIndex, index);
>                 res = compilerToVM().lookupConstantInPool(cp, argCpi, false);
>                 if (res == null) {
>                     res = JavaConstant.forInt(argCpi);
>                 }
>                 cache[index] = res;
>             }
>             return res;
>         }
> 
>         @Override
>         public int size() {
>             return cache.length;
>         }
>     }

Sacha Coppey has updated the pull request incrementally with one additional commit since the last revision:

  Add -XX:UseBootstrapCallInfo=3 to TestDynamicConstant

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15588/files
  - new: https://git.openjdk.org/jdk/pull/15588/files/f4377fc9..9e0627a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15588&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15588&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15588.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15588/head:pull/15588

PR: https://git.openjdk.org/jdk/pull/15588

From duke at openjdk.org  Tue Sep 19 11:37:09 2023
From: duke at openjdk.org (Sacha Coppey)
Date: Tue, 19 Sep 2023 11:37:09 GMT
Subject: RFR: 8315771: [JVMCI] Resolution of bootstrap methods with int[]
 static arguments [v11]
In-Reply-To: 
References: 
Message-ID: 

> Currently, `jdk.vm.ci.meta.ConstantPool.lookupBootstrapMethodInvocation` does not support static arguments of type `int[]`.
> 
> Supporting those static arguments allows to correctly lookup the `BootstrapMethodInvocation` of some `InvokeDynamic` and `DynamicConstant`.
> 
> To lookup the constant at the index in the static arguments index list, a new class is introduced, allowing to lazily resolve the constant or obtain the constant pool index of the arguments:
> 
> 
>     static class CachedBSMArgs extends AbstractList {
>         private final JavaConstant[] cache;
>         private final HotSpotConstantPool cp;
>         private final int bssIndex;
> 
>         CachedBSMArgs(HotSpotConstantPool cp, int bssIndex, int size) {
>             this.cp = cp;
>             this.bssIndex = bssIndex;
>             this.cache = new JavaConstant[size];
>         }
> 
>         @Override
>         public JavaConstant get(int index) {
>             JavaConstant res = cache[index];
>             if (res == null) {
>                 int argCpi = compilerToVM().bootstrapArgumentIndexAt(cp, bssIndex, index);
>                 res = compilerToVM().lookupConstantInPool(cp, argCpi, false);
>                 if (res == null) {
>                     res = JavaConstant.forInt(argCpi);
>                 }
>                 cache[index] = res;
>             }
>             return res;
>         }
> 
>         @Override
>         public int size() {
>             return cache.length;
>         }
>     }

Sacha Coppey has updated the pull request incrementally with one additional commit since the last revision:

  Add an extra run configuration for TestDynamicConstant instead of replacing it

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15588/files
  - new: https://git.openjdk.org/jdk/pull/15588/files/9e0627a3..ea4aa983

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15588&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15588&range=09-10

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15588.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15588/head:pull/15588

PR: https://git.openjdk.org/jdk/pull/15588

From dnsimon at openjdk.org  Tue Sep 19 16:57:48 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 19 Sep 2023 16:57:48 GMT
Subject: RFR: 8315771: [JVMCI] Resolution of bootstrap methods with int[]
 static arguments [v11]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 19 Sep 2023 11:37:09 GMT, Sacha Coppey  wrote:

>> Currently, `jdk.vm.ci.meta.ConstantPool.lookupBootstrapMethodInvocation` does not support static arguments of type `int[]`.
>> 
>> Supporting those static arguments allows to correctly lookup the `BootstrapMethodInvocation` of some `InvokeDynamic` and `DynamicConstant`.
>> 
>> To lookup the constant at the index in the static arguments index list, a new class is introduced, allowing to lazily resolve the constant or obtain the constant pool index of the arguments:
>> 
>> 
>>     static class CachedBSMArgs extends AbstractList {
>>         private final JavaConstant[] cache;
>>         private final HotSpotConstantPool cp;
>>         private final int bssIndex;
>> 
>>         CachedBSMArgs(HotSpotConstantPool cp, int bssIndex, int size) {
>>             this.cp = cp;
>>             this.bssIndex = bssIndex;
>>             this.cache = new JavaConstant[size];
>>         }
>> 
>>         @Override
>>         public JavaConstant get(int index) {
>>             JavaConstant res = cache[index];
>>             if (res == null) {
>>                 int argCpi = compilerToVM().bootstrapArgumentIndexAt(cp, bssIndex, index);
>>                 res = compilerToVM().lookupConstantInPool(cp, argCpi, false);
>>                 if (res == null) {
>>                     res = JavaConstant.forInt(argCpi);
>>                 }
>>                 cache[index] = res;
>>             }
>>             return res;
>>         }
>> 
>>         @Override
>>         public int size() {
>>             return cache.length;
>>         }
>>     }
>
> Sacha Coppey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add an extra run configuration for TestDynamicConstant instead of replacing it

Looks good to me now.

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

Marked as reviewed by dnsimon (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15588#pullrequestreview-1633775202

From dnsimon at openjdk.org  Tue Sep 19 20:12:42 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 19 Sep 2023 20:12:42 GMT
Subject: RFR: 8315771: [JVMCI] Resolution of bootstrap methods with int[]
 static arguments [v11]
In-Reply-To: 
References: 

Message-ID: <3oSqhsQiqNt4yLaAjFdmKgXt0972_qwYptt7HrfVIUA=.f122e196-2cd8-47f9-875d-974f0888a64b@github.com>

On Tue, 19 Sep 2023 11:37:09 GMT, Sacha Coppey  wrote:

>> Currently, `jdk.vm.ci.meta.ConstantPool.lookupBootstrapMethodInvocation` does not support static arguments of type `int[]`.
>> 
>> Supporting those static arguments allows to correctly lookup the `BootstrapMethodInvocation` of some `InvokeDynamic` and `DynamicConstant`.
>> 
>> To lookup the constant at the index in the static arguments index list, a new class is introduced, allowing to lazily resolve the constant or obtain the constant pool index of the arguments:
>> 
>> 
>>     static class CachedBSMArgs extends AbstractList {
>>         private final JavaConstant[] cache;
>>         private final HotSpotConstantPool cp;
>>         private final int bssIndex;
>> 
>>         CachedBSMArgs(HotSpotConstantPool cp, int bssIndex, int size) {
>>             this.cp = cp;
>>             this.bssIndex = bssIndex;
>>             this.cache = new JavaConstant[size];
>>         }
>> 
>>         @Override
>>         public JavaConstant get(int index) {
>>             JavaConstant res = cache[index];
>>             if (res == null) {
>>                 int argCpi = compilerToVM().bootstrapArgumentIndexAt(cp, bssIndex, index);
>>                 res = compilerToVM().lookupConstantInPool(cp, argCpi, false);
>>                 if (res == null) {
>>                     res = JavaConstant.forInt(argCpi);
>>                 }
>>                 cache[index] = res;
>>             }
>>             return res;
>>         }
>> 
>>         @Override
>>         public int size() {
>>             return cache.length;
>>         }
>>     }
>
> Sacha Coppey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add an extra run configuration for TestDynamicConstant instead of replacing it

This PR still needs another review given that it's not trivial. Maybe @TobiHartmann or @tkrodriguez can help out.

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

PR Comment: https://git.openjdk.org/jdk/pull/15588#issuecomment-1726401315

From psandoz at openjdk.org  Tue Sep 19 23:55:43 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 19 Sep 2023 23:55:43 GMT
Subject: RFR: 8315771: [JVMCI] Resolution of bootstrap methods with int[]
 static arguments [v11]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 19 Sep 2023 11:37:09 GMT, Sacha Coppey  wrote:

>> Currently, `jdk.vm.ci.meta.ConstantPool.lookupBootstrapMethodInvocation` does not support static arguments of type `int[]`.
>> 
>> Supporting those static arguments allows to correctly lookup the `BootstrapMethodInvocation` of some `InvokeDynamic` and `DynamicConstant`.
>> 
>> To lookup the constant at the index in the static arguments index list, a new class is introduced, allowing to lazily resolve the constant or obtain the constant pool index of the arguments:
>> 
>> 
>>     static class CachedBSMArgs extends AbstractList {
>>         private final JavaConstant[] cache;
>>         private final HotSpotConstantPool cp;
>>         private final int bssIndex;
>> 
>>         CachedBSMArgs(HotSpotConstantPool cp, int bssIndex, int size) {
>>             this.cp = cp;
>>             this.bssIndex = bssIndex;
>>             this.cache = new JavaConstant[size];
>>         }
>> 
>>         @Override
>>         public JavaConstant get(int index) {
>>             JavaConstant res = cache[index];
>>             if (res == null) {
>>                 int argCpi = compilerToVM().bootstrapArgumentIndexAt(cp, bssIndex, index);
>>                 res = compilerToVM().lookupConstantInPool(cp, argCpi, false);
>>                 if (res == null) {
>>                     res = JavaConstant.forInt(argCpi);
>>                 }
>>                 cache[index] = res;
>>             }
>>             return res;
>>         }
>> 
>>         @Override
>>         public int size() {
>>             return cache.length;
>>         }
>>     }
>
> Sacha Coppey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add an extra run configuration for TestDynamicConstant instead of replacing it

This generally looks good to me. I was initially confused about the reuse (or overload?) of `PrimitiveConstant` for a static argument that is the constant pool index to a `CONSTANT_Dynamic_info` entry, from which it can be resolved or it's `BootstrapMethodInvocation` obtained.

It's very subtle, and I wondering if using a new type would be better and more clearly distinguish between a primitive constant and an index in the constant pool. However, i am not an expert in JVMCI so do not know what repercussions that might have. It's as if you want to expose a lazily resolved constant.

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

PR Comment: https://git.openjdk.org/jdk/pull/15588#issuecomment-1726691490

From dnsimon at openjdk.org  Wed Sep 20 09:51:44 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 20 Sep 2023 09:51:44 GMT
Subject: RFR: 8315771: [JVMCI] Resolution of bootstrap methods with int[]
 static arguments [v11]
In-Reply-To: 
References: 

Message-ID: <4KfhN9x5iswyBhS7NHHDk3QPRZrQgzyH2P62RK0u88U=.85e08a5c-ecf8-4290-b854-7ab82d643977@github.com>

On Tue, 19 Sep 2023 11:37:09 GMT, Sacha Coppey  wrote:

>> Currently, `jdk.vm.ci.meta.ConstantPool.lookupBootstrapMethodInvocation` does not support static arguments of type `int[]`.
>> 
>> Supporting those static arguments allows to correctly lookup the `BootstrapMethodInvocation` of some `InvokeDynamic` and `DynamicConstant`.
>> 
>> To lookup the constant at the index in the static arguments index list, a new class is introduced, allowing to lazily resolve the constant or obtain the constant pool index of the arguments:
>> 
>> 
>>     static class CachedBSMArgs extends AbstractList {
>>         private final JavaConstant[] cache;
>>         private final HotSpotConstantPool cp;
>>         private final int bssIndex;
>> 
>>         CachedBSMArgs(HotSpotConstantPool cp, int bssIndex, int size) {
>>             this.cp = cp;
>>             this.bssIndex = bssIndex;
>>             this.cache = new JavaConstant[size];
>>         }
>> 
>>         @Override
>>         public JavaConstant get(int index) {
>>             JavaConstant res = cache[index];
>>             if (res == null) {
>>                 int argCpi = compilerToVM().bootstrapArgumentIndexAt(cp, bssIndex, index);
>>                 res = compilerToVM().lookupConstantInPool(cp, argCpi, false);
>>                 if (res == null) {
>>                     res = JavaConstant.forInt(argCpi);
>>                 }
>>                 cache[index] = res;
>>             }
>>             return res;
>>         }
>> 
>>         @Override
>>         public int size() {
>>             return cache.length;
>>         }
>>     }
>
> Sacha Coppey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add an extra run configuration for TestDynamicConstant instead of replacing it

While it's tempting to introduce a new type to distinguish between a primitive constant and an index in the constant pool, it would involve changing API that is already used in Graal.
What's more, we're (ab)using the fact that `java.lang.invoke.ConstantGroup.get(int index)` always returns a boxed value. Boxed Java values in JVMCI are always represented by a `JavaConstant` for which `c.getJavaKind() == JavaKind.Object`. So we can use `PrimitiveConstant` here as a side channel to represent a constant pool index.

@Zeavee can you please update the javadoc of `BootstrapMethodInvocation.getStaticArguments()` one more time to make this crystal clear:

        /**
         * Gets the static arguments with which the bootstrap method will be invoked.
         *
         * The {@linkplain JavaConstant#getJavaKind kind} of each argument will be
         * {@link JavaKind#Object} or {@link JavaKind#Int}. The latter represents an
         * unresolved {@code CONSTANT_Dynamic_info} entry. To resolve this entry, the
         * corresponding bootstrap method has to be called first:
         *
         *          * List args = bmi.getStaticArguments();
         * List resolvedArgs = new ArrayList<>(args.size());
         * for (JavaConstant c : args) {
         *     JavaConstant r = c;
         *     if (c.getJavaKind() == JavaKind.Int) {
         *         // If needed, access corresponding BootstrapMethodInvocation using
         *         // cp.lookupBootstrapMethodInvocation(pc.asInt(), -1)
         *         r = cp.lookupConstant(c.asInt(), true);
         *     } else {
         *         assert c.getJavaKind() == JavaKind.Object;
         *     }
         *     resolvedArgs.append(r);
         * }
         * 

No need to re-run testing after this change as it's only a doc change.

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

PR Comment: https://git.openjdk.org/jdk/pull/15588#issuecomment-1727370299

From duke at openjdk.org  Wed Sep 20 10:27:45 2023
From: duke at openjdk.org (Sacha Coppey)
Date: Wed, 20 Sep 2023 10:27:45 GMT
Subject: RFR: 8315771: [JVMCI] Resolution of bootstrap methods with int[]
 static arguments [v12]
In-Reply-To: 
References: 
Message-ID: 

> Currently, `jdk.vm.ci.meta.ConstantPool.lookupBootstrapMethodInvocation` does not support static arguments of type `int[]`.
> 
> Supporting those static arguments allows to correctly lookup the `BootstrapMethodInvocation` of some `InvokeDynamic` and `DynamicConstant`.
> 
> To lookup the constant at the index in the static arguments index list, a new class is introduced, allowing to lazily resolve the constant or obtain the constant pool index of the arguments:
> 
> 
>     static class CachedBSMArgs extends AbstractList {
>         private final JavaConstant[] cache;
>         private final HotSpotConstantPool cp;
>         private final int bssIndex;
> 
>         CachedBSMArgs(HotSpotConstantPool cp, int bssIndex, int size) {
>             this.cp = cp;
>             this.bssIndex = bssIndex;
>             this.cache = new JavaConstant[size];
>         }
> 
>         @Override
>         public JavaConstant get(int index) {
>             JavaConstant res = cache[index];
>             if (res == null) {
>                 int argCpi = compilerToVM().bootstrapArgumentIndexAt(cp, bssIndex, index);
>                 res = compilerToVM().lookupConstantInPool(cp, argCpi, false);
>                 if (res == null) {
>                     res = JavaConstant.forInt(argCpi);
>                 }
>                 cache[index] = res;
>             }
>             return res;
>         }
> 
>         @Override
>         public int size() {
>             return cache.length;
>         }
>     }

Sacha Coppey has updated the pull request incrementally with one additional commit since the last revision:

  Update BootstrapMethodInvocation.getStaticArguments documentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15588/files
  - new: https://git.openjdk.org/jdk/pull/15588/files/ea4aa983..7c274812

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15588&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15588&range=10-11

  Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15588.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15588/head:pull/15588

PR: https://git.openjdk.org/jdk/pull/15588

From dnsimon at openjdk.org  Wed Sep 20 10:36:41 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 20 Sep 2023 10:36:41 GMT
Subject: RFR: 8315771: [JVMCI] Resolution of bootstrap methods with int[]
 static arguments [v12]
In-Reply-To: 
References: 

Message-ID: <44MH5AZzw872CQtGHdhNjE86bn9E_P4ZrnF2jKAJ3lg=.06789c7f-b6bc-4783-bc34-98d3f48501d5@github.com>

On Wed, 20 Sep 2023 10:27:45 GMT, Sacha Coppey  wrote:

>> Currently, `jdk.vm.ci.meta.ConstantPool.lookupBootstrapMethodInvocation` does not support static arguments of type `int[]`.
>> 
>> Supporting those static arguments allows to correctly lookup the `BootstrapMethodInvocation` of some `InvokeDynamic` and `DynamicConstant`.
>> 
>> To lookup the constant at the index in the static arguments index list, a new class is introduced, allowing to lazily resolve the constant or obtain the constant pool index of the arguments:
>> 
>> 
>>     static class CachedBSMArgs extends AbstractList {
>>         private final JavaConstant[] cache;
>>         private final HotSpotConstantPool cp;
>>         private final int bssIndex;
>> 
>>         CachedBSMArgs(HotSpotConstantPool cp, int bssIndex, int size) {
>>             this.cp = cp;
>>             this.bssIndex = bssIndex;
>>             this.cache = new JavaConstant[size];
>>         }
>> 
>>         @Override
>>         public JavaConstant get(int index) {
>>             JavaConstant res = cache[index];
>>             if (res == null) {
>>                 int argCpi = compilerToVM().bootstrapArgumentIndexAt(cp, bssIndex, index);
>>                 res = compilerToVM().lookupConstantInPool(cp, argCpi, false);
>>                 if (res == null) {
>>                     res = JavaConstant.forInt(argCpi);
>>                 }
>>                 cache[index] = res;
>>             }
>>             return res;
>>         }
>> 
>>         @Override
>>         public int size() {
>>             return cache.length;
>>         }
>>     }
>
> Sacha Coppey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update BootstrapMethodInvocation.getStaticArguments documentation

Still looks good to me.

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

Marked as reviewed by dnsimon (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15588#pullrequestreview-1635311502

From psandoz at openjdk.org  Wed Sep 20 19:49:44 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 20 Sep 2023 19:49:44 GMT
Subject: RFR: 8315771: [JVMCI] Resolution of bootstrap methods with int[]
 static arguments [v12]
In-Reply-To: 
References: 

Message-ID: <5BlQD4TmyezKE8QyV3C5snm8-hrfShEkapy7gtgQKkk=.5436e771-d72b-441d-ab26-89b8ef4cbe23@github.com>

On Wed, 20 Sep 2023 10:27:45 GMT, Sacha Coppey  wrote:

>> Currently, `jdk.vm.ci.meta.ConstantPool.lookupBootstrapMethodInvocation` does not support static arguments of type `int[]`.
>> 
>> Supporting those static arguments allows to correctly lookup the `BootstrapMethodInvocation` of some `InvokeDynamic` and `DynamicConstant`.
>> 
>> To lookup the constant at the index in the static arguments index list, a new class is introduced, allowing to lazily resolve the constant or obtain the constant pool index of the arguments:
>> 
>> 
>>     static class CachedBSMArgs extends AbstractList {
>>         private final JavaConstant[] cache;
>>         private final HotSpotConstantPool cp;
>>         private final int bssIndex;
>> 
>>         CachedBSMArgs(HotSpotConstantPool cp, int bssIndex, int size) {
>>             this.cp = cp;
>>             this.bssIndex = bssIndex;
>>             this.cache = new JavaConstant[size];
>>         }
>> 
>>         @Override
>>         public JavaConstant get(int index) {
>>             JavaConstant res = cache[index];
>>             if (res == null) {
>>                 int argCpi = compilerToVM().bootstrapArgumentIndexAt(cp, bssIndex, index);
>>                 res = compilerToVM().lookupConstantInPool(cp, argCpi, false);
>>                 if (res == null) {
>>                     res = JavaConstant.forInt(argCpi);
>>                 }
>>                 cache[index] = res;
>>             }
>>             return res;
>>         }
>> 
>>         @Override
>>         public int size() {
>>             return cache.length;
>>         }
>>     }
>
> Sacha Coppey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update BootstrapMethodInvocation.getStaticArguments documentation

Looks good. I suppose you could generalize the test a little more to iterate over the static arguments, independent of the condyType. That exercises the code a little more esp. when running under the `-XX:UseBootstrapCallInfo=3` argument. Up to you.

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

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15588#pullrequestreview-1636380714

From duke at openjdk.org  Thu Sep 21 11:36:14 2023
From: duke at openjdk.org (Sacha Coppey)
Date: Thu, 21 Sep 2023 11:36:14 GMT
Subject: RFR: 8315771: [JVMCI] Resolution of bootstrap methods with int[]
 static arguments [v13]
In-Reply-To: 
References: 
Message-ID: <70iXh9oqq7zBEDlH6UOYG4RUGndIAFcQqDNndxzcaTo=.9841ab79-51a3-4db0-aaaa-6367f30002b8@github.com>

> Currently, `jdk.vm.ci.meta.ConstantPool.lookupBootstrapMethodInvocation` does not support static arguments of type `int[]`.
> 
> Supporting those static arguments allows to correctly lookup the `BootstrapMethodInvocation` of some `InvokeDynamic` and `DynamicConstant`.
> 
> To lookup the constant at the index in the static arguments index list, a new class is introduced, allowing to lazily resolve the constant or obtain the constant pool index of the arguments:
> 
> 
>     static class CachedBSMArgs extends AbstractList {
>         private final JavaConstant[] cache;
>         private final HotSpotConstantPool cp;
>         private final int bssIndex;
> 
>         CachedBSMArgs(HotSpotConstantPool cp, int bssIndex, int size) {
>             this.cp = cp;
>             this.bssIndex = bssIndex;
>             this.cache = new JavaConstant[size];
>         }
> 
>         @Override
>         public JavaConstant get(int index) {
>             JavaConstant res = cache[index];
>             if (res == null) {
>                 int argCpi = compilerToVM().bootstrapArgumentIndexAt(cp, bssIndex, index);
>                 res = compilerToVM().lookupConstantInPool(cp, argCpi, false);
>                 if (res == null) {
>                     res = JavaConstant.forInt(argCpi);
>                 }
>                 cache[index] = res;
>             }
>             return res;
>         }
> 
>         @Override
>         public int size() {
>             return cache.length;
>         }
>     }

Sacha Coppey has updated the pull request incrementally with one additional commit since the last revision:

  Iterate over all static arguments in TestDynamicConstant

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15588/files
  - new: https://git.openjdk.org/jdk/pull/15588/files/7c274812..7a8d9f2e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15588&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15588&range=11-12

  Stats: 30 lines in 1 file changed: 18 ins; 2 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/15588.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15588/head:pull/15588

PR: https://git.openjdk.org/jdk/pull/15588

From dnsimon at openjdk.org  Thu Sep 21 12:39:45 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 21 Sep 2023 12:39:45 GMT
Subject: RFR: 8315771: [JVMCI] Resolution of bootstrap methods with int[]
 static arguments [v13]
In-Reply-To: <70iXh9oqq7zBEDlH6UOYG4RUGndIAFcQqDNndxzcaTo=.9841ab79-51a3-4db0-aaaa-6367f30002b8@github.com>
References: 
 <70iXh9oqq7zBEDlH6UOYG4RUGndIAFcQqDNndxzcaTo=.9841ab79-51a3-4db0-aaaa-6367f30002b8@github.com>
Message-ID: 

On Thu, 21 Sep 2023 11:36:14 GMT, Sacha Coppey  wrote:

>> Currently, `jdk.vm.ci.meta.ConstantPool.lookupBootstrapMethodInvocation` does not support static arguments of type `int[]`.
>> 
>> Supporting those static arguments allows to correctly lookup the `BootstrapMethodInvocation` of some `InvokeDynamic` and `DynamicConstant`.
>> 
>> To lookup the constant at the index in the static arguments index list, a new class is introduced, allowing to lazily resolve the constant or obtain the constant pool index of the arguments:
>> 
>> 
>>     static class CachedBSMArgs extends AbstractList {
>>         private final JavaConstant[] cache;
>>         private final HotSpotConstantPool cp;
>>         private final int bssIndex;
>> 
>>         CachedBSMArgs(HotSpotConstantPool cp, int bssIndex, int size) {
>>             this.cp = cp;
>>             this.bssIndex = bssIndex;
>>             this.cache = new JavaConstant[size];
>>         }
>> 
>>         @Override
>>         public JavaConstant get(int index) {
>>             JavaConstant res = cache[index];
>>             if (res == null) {
>>                 int argCpi = compilerToVM().bootstrapArgumentIndexAt(cp, bssIndex, index);
>>                 res = compilerToVM().lookupConstantInPool(cp, argCpi, false);
>>                 if (res == null) {
>>                     res = JavaConstant.forInt(argCpi);
>>                 }
>>                 cache[index] = res;
>>             }
>>             return res;
>>         }
>> 
>>         @Override
>>         public int size() {
>>             return cache.length;
>>         }
>>     }
>
> Sacha Coppey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Iterate over all static arguments in TestDynamicConstant

Marked as reviewed by dnsimon (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15588#pullrequestreview-1637714807

From fparain at openjdk.org  Thu Sep 21 13:21:44 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 21 Sep 2023 13:21:44 GMT
Subject: RFR: 8315954: getArgumentValues002.java fails on Graal [v2]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 14 Sep 2023 11:47:30 GMT, Doug Simon  wrote:

>> Doug Simon has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - generalized getLiveObjectLocalsAt to getOopMapAt
>>  - need to zero oop_map_buf
>>  - simplified getLiveObjectLocalsAt and moved it from ResolvedJavaMethod to HotSpotResolvedJavaMethod
>
> src/hotspot/share/interpreter/oopMapCache.cpp line 616:
> 
>> 614:   tmp->fill(method, bci);
>> 615:   if (tmp->has_valid_mask()) {
>> 616:     entry->resource_copy(tmp);
> 
> If `tmp` is invalid (e.g. oop map was requested for invalid BCI), then `resource_copy` crashes the VM in strange ways since it blindly trusts the mask size to be valid.

This is not the only place where `resource_copy()` is called, could you add an assert in `resource_copy()` itself to check that it is never called with an invalid bci/mask_size.
Thank you.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15705#discussion_r1333043061

From dnsimon at openjdk.org  Thu Sep 21 14:41:15 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 21 Sep 2023 14:41:15 GMT
Subject: RFR: 8315954: getArgumentValues002.java fails on Graal [v3]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 21 Sep 2023 13:18:31 GMT, Frederic Parain  wrote:

>> src/hotspot/share/interpreter/oopMapCache.cpp line 616:
>> 
>>> 614:   tmp->fill(method, bci);
>>> 615:   if (tmp->has_valid_mask()) {
>>> 616:     entry->resource_copy(tmp);
>> 
>> If `tmp` is invalid (e.g. oop map was requested for invalid BCI), then `resource_copy` crashes the VM in strange ways since it blindly trusts the mask size to be valid.
>
> This is not the only place where `resource_copy()` is called, could you add an assert in `resource_copy()` itself to check that it is never called with an invalid bci/mask_size.
> Thank you.

Ok, I've added that assertion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15705#discussion_r1333169517

From dnsimon at openjdk.org  Thu Sep 21 14:41:14 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 21 Sep 2023 14:41:14 GMT
Subject: RFR: 8315954: getArgumentValues002.java fails on Graal [v3]
In-Reply-To: 
References: 
Message-ID: 

> This PR adds `HotSpotResolvedJavaMethod.getOopMapAt` to get the oop map for a method at a given BCI. This is required to do correct clearing of oops at OSR entry points.
> 
> As part of this addition, I needed to be able to detect requests for oop maps at invalid BCIs. For this, I added `InterpreterOopMap::has_valid_mask()`. When an oop map computation is requested for an invalid BCI, this method returns false.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  add assertion to InterpreterOopMap::resource_copy

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15705/files
  - new: https://git.openjdk.org/jdk/pull/15705/files/c6c6c0d8..3c903ec0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15705&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15705&range=01-02

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15705.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15705/head:pull/15705

PR: https://git.openjdk.org/jdk/pull/15705

From fparain at openjdk.org  Thu Sep 21 15:02:45 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 21 Sep 2023 15:02:45 GMT
Subject: RFR: 8315954: getArgumentValues002.java fails on Graal [v3]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 21 Sep 2023 14:41:14 GMT, Doug Simon  wrote:

>> This PR adds `HotSpotResolvedJavaMethod.getOopMapAt` to get the oop map for a method at a given BCI. This is required to do correct clearing of oops at OSR entry points.
>> 
>> As part of this addition, I needed to be able to detect requests for oop maps at invalid BCIs. For this, I added `InterpreterOopMap::has_valid_mask()`. When an oop map computation is requested for an invalid BCI, this method returns false.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add assertion to InterpreterOopMap::resource_copy

Runtime changes look good to me. Thank you for the additional assert.

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

Marked as reviewed by fparain (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15705#pullrequestreview-1638080188

From psandoz at openjdk.org  Thu Sep 21 16:03:47 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 21 Sep 2023 16:03:47 GMT
Subject: RFR: 8315771: [JVMCI] Resolution of bootstrap methods with int[]
 static arguments [v13]
In-Reply-To: <70iXh9oqq7zBEDlH6UOYG4RUGndIAFcQqDNndxzcaTo=.9841ab79-51a3-4db0-aaaa-6367f30002b8@github.com>
References: 
 <70iXh9oqq7zBEDlH6UOYG4RUGndIAFcQqDNndxzcaTo=.9841ab79-51a3-4db0-aaaa-6367f30002b8@github.com>
Message-ID: 

On Thu, 21 Sep 2023 11:36:14 GMT, Sacha Coppey  wrote:

>> Currently, `jdk.vm.ci.meta.ConstantPool.lookupBootstrapMethodInvocation` does not support static arguments of type `int[]`.
>> 
>> Supporting those static arguments allows to correctly lookup the `BootstrapMethodInvocation` of some `InvokeDynamic` and `DynamicConstant`.
>> 
>> To lookup the constant at the index in the static arguments index list, a new class is introduced, allowing to lazily resolve the constant or obtain the constant pool index of the arguments:
>> 
>> 
>>     static class CachedBSMArgs extends AbstractList {
>>         private final JavaConstant[] cache;
>>         private final HotSpotConstantPool cp;
>>         private final int bssIndex;
>> 
>>         CachedBSMArgs(HotSpotConstantPool cp, int bssIndex, int size) {
>>             this.cp = cp;
>>             this.bssIndex = bssIndex;
>>             this.cache = new JavaConstant[size];
>>         }
>> 
>>         @Override
>>         public JavaConstant get(int index) {
>>             JavaConstant res = cache[index];
>>             if (res == null) {
>>                 int argCpi = compilerToVM().bootstrapArgumentIndexAt(cp, bssIndex, index);
>>                 res = compilerToVM().lookupConstantInPool(cp, argCpi, false);
>>                 if (res == null) {
>>                     res = JavaConstant.forInt(argCpi);
>>                 }
>>                 cache[index] = res;
>>             }
>>             return res;
>>         }
>> 
>>         @Override
>>         public int size() {
>>             return cache.length;
>>         }
>>     }
>
> Sacha Coppey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Iterate over all static arguments in TestDynamicConstant

Marked as reviewed by psandoz (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15588#pullrequestreview-1638223402

From dnsimon at openjdk.org  Thu Sep 21 16:31:51 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 21 Sep 2023 16:31:51 GMT
Subject: RFR: 8315954: getArgumentValues002.java fails on Graal [v3]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 21 Sep 2023 14:41:14 GMT, Doug Simon  wrote:

>> This PR adds `HotSpotResolvedJavaMethod.getOopMapAt` to get the oop map for a method at a given BCI. This is required to do correct clearing of oops at OSR entry points.
>> 
>> As part of this addition, I needed to be able to detect requests for oop maps at invalid BCIs. For this, I added `InterpreterOopMap::has_valid_mask()`. When an oop map computation is requested for an invalid BCI, this method returns false.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add assertion to InterpreterOopMap::resource_copy

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/15705#issuecomment-1729911323

From dnsimon at openjdk.org  Thu Sep 21 16:31:52 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 21 Sep 2023 16:31:52 GMT
Subject: Integrated: 8315954: getArgumentValues002.java fails on Graal
In-Reply-To: 
References: 
Message-ID: 

On Wed, 13 Sep 2023 09:46:01 GMT, Doug Simon  wrote:

> This PR adds `HotSpotResolvedJavaMethod.getOopMapAt` to get the oop map for a method at a given BCI. This is required to do correct clearing of oops at OSR entry points.
> 
> As part of this addition, I needed to be able to detect requests for oop maps at invalid BCIs. For this, I added `InterpreterOopMap::has_valid_mask()`. When an oop map computation is requested for an invalid BCI, this method returns false.

This pull request has now been integrated.

Changeset: 542b3000
Author:    Doug Simon 
URL:       https://git.openjdk.org/jdk/commit/542b3000f0cd1136466066cb4046257220ac2827
Stats:     278 lines in 8 files changed: 256 ins; 0 del; 22 mod

8315954: getArgumentValues002.java fails on Graal

Reviewed-by: never, fparain

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

PR: https://git.openjdk.org/jdk/pull/15705

From duke at openjdk.org  Thu Sep 21 17:03:53 2023
From: duke at openjdk.org (Sacha Coppey)
Date: Thu, 21 Sep 2023 17:03:53 GMT
Subject: Integrated: 8315771: [JVMCI] Resolution of bootstrap methods with
 int[] static arguments
In-Reply-To: 
References: 
Message-ID: 

On Wed, 6 Sep 2023 11:24:10 GMT, Sacha Coppey  wrote:

> Currently, `jdk.vm.ci.meta.ConstantPool.lookupBootstrapMethodInvocation` does not support static arguments of type `int[]`.
> 
> Supporting those static arguments allows to correctly lookup the `BootstrapMethodInvocation` of some `InvokeDynamic` and `DynamicConstant`.
> 
> To lookup the constant at the index in the static arguments index list, a new class is introduced, allowing to lazily resolve the constant or obtain the constant pool index of the arguments:
> 
> 
>     static class CachedBSMArgs extends AbstractList {
>         private final JavaConstant[] cache;
>         private final HotSpotConstantPool cp;
>         private final int bssIndex;
> 
>         CachedBSMArgs(HotSpotConstantPool cp, int bssIndex, int size) {
>             this.cp = cp;
>             this.bssIndex = bssIndex;
>             this.cache = new JavaConstant[size];
>         }
> 
>         @Override
>         public JavaConstant get(int index) {
>             JavaConstant res = cache[index];
>             if (res == null) {
>                 int argCpi = compilerToVM().bootstrapArgumentIndexAt(cp, bssIndex, index);
>                 res = compilerToVM().lookupConstantInPool(cp, argCpi, false);
>                 if (res == null) {
>                     res = JavaConstant.forInt(argCpi);
>                 }
>                 cache[index] = res;
>             }
>             return res;
>         }
> 
>         @Override
>         public int size() {
>             return cache.length;
>         }
>     }

This pull request has now been integrated.

Changeset: 015f6f5d
Author:    Sacha Coppey 
Committer: Doug Simon 
URL:       https://git.openjdk.org/jdk/commit/015f6f5d9497b8cef9ba2e789799a28bcd454341
Stats:     202 lines in 5 files changed: 184 ins; 8 del; 10 mod

8315771: [JVMCI] Resolution of bootstrap methods with int[] static arguments

Reviewed-by: dnsimon, psandoz

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

PR: https://git.openjdk.org/jdk/pull/15588

From dholmes at openjdk.org  Fri Sep 22 01:05:36 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 22 Sep 2023 01:05:36 GMT
Subject: RFR: 8315771: [JVMCI] Resolution of bootstrap methods with int[]
 static arguments [v13]
In-Reply-To: <70iXh9oqq7zBEDlH6UOYG4RUGndIAFcQqDNndxzcaTo=.9841ab79-51a3-4db0-aaaa-6367f30002b8@github.com>
References: 
 <70iXh9oqq7zBEDlH6UOYG4RUGndIAFcQqDNndxzcaTo=.9841ab79-51a3-4db0-aaaa-6367f30002b8@github.com>
Message-ID: 

On Thu, 21 Sep 2023 11:36:14 GMT, Sacha Coppey  wrote:

>> Currently, `jdk.vm.ci.meta.ConstantPool.lookupBootstrapMethodInvocation` does not support static arguments of type `int[]`.
>> 
>> Supporting those static arguments allows to correctly lookup the `BootstrapMethodInvocation` of some `InvokeDynamic` and `DynamicConstant`.
>> 
>> To lookup the constant at the index in the static arguments index list, a new class is introduced, allowing to lazily resolve the constant or obtain the constant pool index of the arguments:
>> 
>> 
>>     static class CachedBSMArgs extends AbstractList {
>>         private final JavaConstant[] cache;
>>         private final HotSpotConstantPool cp;
>>         private final int bssIndex;
>> 
>>         CachedBSMArgs(HotSpotConstantPool cp, int bssIndex, int size) {
>>             this.cp = cp;
>>             this.bssIndex = bssIndex;
>>             this.cache = new JavaConstant[size];
>>         }
>> 
>>         @Override
>>         public JavaConstant get(int index) {
>>             JavaConstant res = cache[index];
>>             if (res == null) {
>>                 int argCpi = compilerToVM().bootstrapArgumentIndexAt(cp, bssIndex, index);
>>                 res = compilerToVM().lookupConstantInPool(cp, argCpi, false);
>>                 if (res == null) {
>>                     res = JavaConstant.forInt(argCpi);
>>                 }
>>                 cache[index] = res;
>>             }
>>             return res;
>>         }
>> 
>>         @Override
>>         public int size() {
>>             return cache.length;
>>         }
>>     }
>
> Sacha Coppey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Iterate over all static arguments in TestDynamicConstant

test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/TestDynamicConstant.java line 36:

> 34:  *      jdk.vm.ci.hotspot.test.TestDynamicConstant
> 35:  * @run testng/othervm
> 36:  *      -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:-UseJVMCICompiler -XX:UseBootstrapCallInfo=3

Error: VM option 'UseBootstrapCallInfo' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions.

New bug being filed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15588#discussion_r1333758461

From azafari at openjdk.org  Tue Sep 26 11:53:41 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 26 Sep 2023 11:53:41 GMT
Subject: RFR: 8198918: jio_snprintf and friends are not checked by -Wformat
Message-ID: 

- The `ATTRIBUTE_PRINTF` usage in cpp files is useless. They are removed.
-  There are cases where `jio_xxprintf` functions use `char *` arguments for format string, rather than a literal like `"%s..."`. These cases are not compiled when `ATTRIBUTE_PRINTF` is used for them. So, I use the attribute and got the corresponding compile errors. Then I fixed the issues and remove the attribute when all fixed.
-
### Test
The changes are tested on all platforms tiers 1-4.

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

Commit messages:
 - 8198918: jio_snprintf and friends are not checked by -Wformat

Changes: https://git.openjdk.org/jdk/pull/15918/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15918&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8198918
  Stats: 13 lines in 5 files changed: 0 ins; 5 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/15918.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15918/head:pull/15918

PR: https://git.openjdk.org/jdk/pull/15918

From dnsimon at openjdk.org  Thu Sep 28 07:27:45 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 28 Sep 2023 07:27:45 GMT
Subject: RFR: 8317139: [JVMCI] oop handles clearing message pollutes event log
Message-ID: 

The message for the event of clearing oop handles after each libjvmci compilation should only be logged at level 2 (i.e. `-XX:JVMCIEventLogLevel=2` or `-XX:JVMCITraceLevel=2`). Otherwise, it crowds out more useful events in hs-err crash logs. For example:

JVMCI Events (20 events):
Event: 0.853 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 94 to 68
Event: 0.853 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 102 to 63
Event: 0.855 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 70 to 69
Event: 0.856 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 71 to 70
Event: 0.861 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 78 to 77
Event: 0.866 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 82 to 81
Event: 0.870 Thread 0x00007fded01824f0 compacted oop handles in JVMCI runtime 0 from 88 to 85
Event: 0.875 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 91 to 90
Event: 0.876 Thread 0x00007fded01824f0 compacted oop handles in JVMCI runtime 0 from 86 to 52
Event: 0.878 Thread 0x00007fde0002d2f0 compacted oop handles in JVMCI runtime 1 from 69 to 65
Event: 0.897 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 101 to 99
Event: 0.897 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 100 to 70
Event: 0.897 Thread 0x00007fdde00037f0 compacted oop handles in JVMCI runtime 3 from 99 to 66
Event: 0.902 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 71 to 70
Event: 0.916 Thread 0x00007fde0002d2f0 compacted oop handles in JVMCI runtime 1 from 78 to 62
Event: 0.916 Thread 0x00007fdde00037f0 compacted oop handles in JVMCI runtime 3 from 81 to 79
Event: 0.919 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 100 to 80
Event: 0.922 Thread 0x00007fde0002d2f0 compacted oop handles in JVMCI runtime 1 from 70 to 69
Event: 0.923 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 85 to 84
Event: 0.926 Thread 0x00007fded01824f0 compacted oop handles in JVMCI runtime 0 from 77 to 74

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

Commit messages:
 - change log level of "compacted oop handles" JVMCI message to 2

Changes: https://git.openjdk.org/jdk/pull/15956/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15956&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317139
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15956/head:pull/15956

PR: https://git.openjdk.org/jdk/pull/15956

From never at openjdk.org  Thu Sep 28 17:41:28 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Thu, 28 Sep 2023 17:41:28 GMT
Subject: RFR: 8317139: [JVMCI] oop handles clearing message pollutes event
 log
In-Reply-To: 
References: 
Message-ID: 

On Thu, 28 Sep 2023 07:20:52 GMT, Doug Simon  wrote:

> The message for the event of clearing oop handles after each libjvmci compilation should only be logged at level 2 (i.e. `-XX:JVMCIEventLogLevel=2` or `-XX:JVMCITraceLevel=2`). Otherwise, it crowds out more useful events in hs-err crash logs. For example:
> 
> JVMCI Events (20 events):
> Event: 0.853 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 94 to 68
> Event: 0.853 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 102 to 63
> Event: 0.855 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 70 to 69
> Event: 0.856 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 71 to 70
> Event: 0.861 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 78 to 77
> Event: 0.866 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 82 to 81
> Event: 0.870 Thread 0x00007fded01824f0 compacted oop handles in JVMCI runtime 0 from 88 to 85
> Event: 0.875 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 91 to 90
> Event: 0.876 Thread 0x00007fded01824f0 compacted oop handles in JVMCI runtime 0 from 86 to 52
> Event: 0.878 Thread 0x00007fde0002d2f0 compacted oop handles in JVMCI runtime 1 from 69 to 65
> Event: 0.897 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 101 to 99
> Event: 0.897 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 100 to 70
> Event: 0.897 Thread 0x00007fdde00037f0 compacted oop handles in JVMCI runtime 3 from 99 to 66
> Event: 0.902 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 71 to 70
> Event: 0.916 Thread 0x00007fde0002d2f0 compacted oop handles in JVMCI runtime 1 from 78 to 62
> Event: 0.916 Thread 0x00007fdde00037f0 compacted oop handles in JVMCI runtime 3 from 81 to 79
> Event: 0.919 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 100 to 80
> Event: 0.922 Thread 0x00007fde0002d2f0 compacted oop handles in JVMCI runtime 1 from 70 to 69
> Event: 0.923 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 85 to 84
> Event: 0.926 Thread 0x00007fded01824f0 compacted oop handles in JVMCI runtime 0 from 77 to 74

Marked as reviewed by never (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15956#pullrequestreview-1649398337

From dnsimon at openjdk.org  Thu Sep 28 20:46:42 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 28 Sep 2023 20:46:42 GMT
Subject: RFR: 8317273: compiler/codecache/OverflowCodeCacheTest.java fails
 transiently on Graal
Message-ID: <0WoMZ-vkfE6bHGRGHa9x_EPguba5P6F4wIvJsAYYt1E=.1e751aa4-0466-45b7-be9a-5542497c9800@github.com>

This PR changes JVMCI to throw a `BailoutException` instead of causing a VM fatal error when a JVMCI RuntimeStub cannot be allocated in the CodeCache.

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

Commit messages:
 - bailout when a JVMCI RuntimeStub cannot be allocated in the CodeCache

Changes: https://git.openjdk.org/jdk/pull/15970/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15970&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317273
  Stats: 106 lines in 5 files changed: 89 ins; 12 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/15970.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15970/head:pull/15970

PR: https://git.openjdk.org/jdk/pull/15970

From never at openjdk.org  Thu Sep 28 21:00:26 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Thu, 28 Sep 2023 21:00:26 GMT
Subject: RFR: 8317273: compiler/codecache/OverflowCodeCacheTest.java fails
 transiently on Graal
In-Reply-To: <0WoMZ-vkfE6bHGRGHa9x_EPguba5P6F4wIvJsAYYt1E=.1e751aa4-0466-45b7-be9a-5542497c9800@github.com>
References: <0WoMZ-vkfE6bHGRGHa9x_EPguba5P6F4wIvJsAYYt1E=.1e751aa4-0466-45b7-be9a-5542497c9800@github.com>
Message-ID: 

On Thu, 28 Sep 2023 20:34:14 GMT, Doug Simon  wrote:

> This PR changes JVMCI to throw a `BailoutException` instead of causing a VM fatal error when a JVMCI RuntimeStub cannot be allocated in the CodeCache.

looks good.

src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 663:

> 661:   }
> 662: 
> 663:   name = os::strdup(name); // Note: this leaks. See JDK-8289632

JDK-8289632 was closed as not an issue since RuntimeStubs are never freed in normal execution so maybe drop this comment.

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

Marked as reviewed by never (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15970#pullrequestreview-1649700178
PR Review Comment: https://git.openjdk.org/jdk/pull/15970#discussion_r1340661454

From dnsimon at openjdk.org  Thu Sep 28 21:31:36 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 28 Sep 2023 21:31:36 GMT
Subject: RFR: 8317273: compiler/codecache/OverflowCodeCacheTest.java fails
 transiently on Graal [v2]
In-Reply-To: <0WoMZ-vkfE6bHGRGHa9x_EPguba5P6F4wIvJsAYYt1E=.1e751aa4-0466-45b7-be9a-5542497c9800@github.com>
References: <0WoMZ-vkfE6bHGRGHa9x_EPguba5P6F4wIvJsAYYt1E=.1e751aa4-0466-45b7-be9a-5542497c9800@github.com>
Message-ID: 

> This PR changes JVMCI to throw a `BailoutException` instead of causing a VM fatal error when a JVMCI RuntimeStub cannot be allocated in the CodeCache.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  removed obsolete comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15970/files
  - new: https://git.openjdk.org/jdk/pull/15970/files/6ca0cc1a..fa625f1a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15970&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15970&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15970.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15970/head:pull/15970

PR: https://git.openjdk.org/jdk/pull/15970

From thartmann at openjdk.org  Fri Sep 29 11:11:07 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 29 Sep 2023 11:11:07 GMT
Subject: RFR: 8317139: [JVMCI] oop handles clearing message pollutes event
 log
In-Reply-To: 
References: 
Message-ID: 

On Thu, 28 Sep 2023 07:20:52 GMT, Doug Simon  wrote:

> The message for the event of clearing oop handles after each libjvmci compilation should only be logged at level 2 (i.e. `-XX:JVMCIEventLogLevel=2` or `-XX:JVMCITraceLevel=2`). Otherwise, it crowds out more useful events in hs-err crash logs. For example:
> 
> JVMCI Events (20 events):
> Event: 0.853 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 94 to 68
> Event: 0.853 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 102 to 63
> Event: 0.855 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 70 to 69
> Event: 0.856 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 71 to 70
> Event: 0.861 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 78 to 77
> Event: 0.866 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 82 to 81
> Event: 0.870 Thread 0x00007fded01824f0 compacted oop handles in JVMCI runtime 0 from 88 to 85
> Event: 0.875 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 91 to 90
> Event: 0.876 Thread 0x00007fded01824f0 compacted oop handles in JVMCI runtime 0 from 86 to 52
> Event: 0.878 Thread 0x00007fde0002d2f0 compacted oop handles in JVMCI runtime 1 from 69 to 65
> Event: 0.897 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 101 to 99
> Event: 0.897 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 100 to 70
> Event: 0.897 Thread 0x00007fdde00037f0 compacted oop handles in JVMCI runtime 3 from 99 to 66
> Event: 0.902 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 71 to 70
> Event: 0.916 Thread 0x00007fde0002d2f0 compacted oop handles in JVMCI runtime 1 from 78 to 62
> Event: 0.916 Thread 0x00007fdde00037f0 compacted oop handles in JVMCI runtime 3 from 81 to 79
> Event: 0.919 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 100 to 80
> Event: 0.922 Thread 0x00007fde0002d2f0 compacted oop handles in JVMCI runtime 1 from 70 to 69
> Event: 0.923 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 85 to 84
> Event: 0.926 Thread 0x00007fded01824f0 compacted oop handles in JVMCI runtime 0 from 77 to 74

Looks good to me too.

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15956#pullrequestreview-1650569031

From dnsimon at openjdk.org  Fri Sep 29 15:41:31 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 29 Sep 2023 15:41:31 GMT
Subject: RFR: 8317139: [JVMCI] oop handles clearing message pollutes event
 log
In-Reply-To: 
References: 
Message-ID: <50GBQwFnEig-Xi2AzWjviuz94bezyuQfV6nsH4O1LVQ=.bdd9f890-e35a-4466-b71e-3cf930919eb9@github.com>

On Thu, 28 Sep 2023 07:20:52 GMT, Doug Simon  wrote:

> The message for the event of clearing oop handles after each libjvmci compilation should only be logged at level 2 (i.e. `-XX:JVMCIEventLogLevel=2` or `-XX:JVMCITraceLevel=2`). Otherwise, it crowds out more useful events in hs-err crash logs. For example:
> 
> JVMCI Events (20 events):
> Event: 0.853 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 94 to 68
> Event: 0.853 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 102 to 63
> Event: 0.855 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 70 to 69
> Event: 0.856 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 71 to 70
> Event: 0.861 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 78 to 77
> Event: 0.866 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 82 to 81
> Event: 0.870 Thread 0x00007fded01824f0 compacted oop handles in JVMCI runtime 0 from 88 to 85
> Event: 0.875 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 91 to 90
> Event: 0.876 Thread 0x00007fded01824f0 compacted oop handles in JVMCI runtime 0 from 86 to 52
> Event: 0.878 Thread 0x00007fde0002d2f0 compacted oop handles in JVMCI runtime 1 from 69 to 65
> Event: 0.897 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 101 to 99
> Event: 0.897 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 100 to 70
> Event: 0.897 Thread 0x00007fdde00037f0 compacted oop handles in JVMCI runtime 3 from 99 to 66
> Event: 0.902 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 71 to 70
> Event: 0.916 Thread 0x00007fde0002d2f0 compacted oop handles in JVMCI runtime 1 from 78 to 62
> Event: 0.916 Thread 0x00007fdde00037f0 compacted oop handles in JVMCI runtime 3 from 81 to 79
> Event: 0.919 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 100 to 80
> Event: 0.922 Thread 0x00007fde0002d2f0 compacted oop handles in JVMCI runtime 1 from 70 to 69
> Event: 0.923 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 85 to 84
> Event: 0.926 Thread 0x00007fded01824f0 compacted oop handles in JVMCI runtime 0 from 77 to 74

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/15956#issuecomment-1741026243

From dnsimon at openjdk.org  Fri Sep 29 15:43:06 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 29 Sep 2023 15:43:06 GMT
Subject: Integrated: 8317139: [JVMCI] oop handles clearing message pollutes
 event log
In-Reply-To: 
References: 
Message-ID: 

On Thu, 28 Sep 2023 07:20:52 GMT, Doug Simon  wrote:

> The message for the event of clearing oop handles after each libjvmci compilation should only be logged at level 2 (i.e. `-XX:JVMCIEventLogLevel=2` or `-XX:JVMCITraceLevel=2`). Otherwise, it crowds out more useful events in hs-err crash logs. For example:
> 
> JVMCI Events (20 events):
> Event: 0.853 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 94 to 68
> Event: 0.853 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 102 to 63
> Event: 0.855 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 70 to 69
> Event: 0.856 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 71 to 70
> Event: 0.861 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 78 to 77
> Event: 0.866 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 82 to 81
> Event: 0.870 Thread 0x00007fded01824f0 compacted oop handles in JVMCI runtime 0 from 88 to 85
> Event: 0.875 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 91 to 90
> Event: 0.876 Thread 0x00007fded01824f0 compacted oop handles in JVMCI runtime 0 from 86 to 52
> Event: 0.878 Thread 0x00007fde0002d2f0 compacted oop handles in JVMCI runtime 1 from 69 to 65
> Event: 0.897 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 101 to 99
> Event: 0.897 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 100 to 70
> Event: 0.897 Thread 0x00007fdde00037f0 compacted oop handles in JVMCI runtime 3 from 99 to 66
> Event: 0.902 Thread 0x00007fde0002e6d0 compacted oop handles in JVMCI runtime 2 from 71 to 70
> Event: 0.916 Thread 0x00007fde0002d2f0 compacted oop handles in JVMCI runtime 1 from 78 to 62
> Event: 0.916 Thread 0x00007fdde00037f0 compacted oop handles in JVMCI runtime 3 from 81 to 79
> Event: 0.919 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 100 to 80
> Event: 0.922 Thread 0x00007fde0002d2f0 compacted oop handles in JVMCI runtime 1 from 70 to 69
> Event: 0.923 Thread 0x00007fdde0002470 compacted oop handles in JVMCI runtime 4 from 85 to 84
> Event: 0.926 Thread 0x00007fded01824f0 compacted oop handles in JVMCI runtime 0 from 77 to 74

This pull request has now been integrated.

Changeset: a185be03
Author:    Doug Simon 
URL:       https://git.openjdk.org/jdk/commit/a185be0346be2aba4de531ee6cce9b99f08aa223
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8317139: [JVMCI] oop handles clearing message pollutes event log

Reviewed-by: never, thartmann

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

PR: https://git.openjdk.org/jdk/pull/15956