On Thu, 17 Jul 2025 22:18:44 GMT, Ioi Lam wrote:
> When `-XX:+AOTClassLinking` is enabled when dumping CDS archives with `java
> -Xshare:dump`, we have more stringent restriction of what Java code can be
> executed -- if arbitrary Java code is executed, it may produce side effects
> that canno
On Fri, 20 Jun 2025 15:05:03 GMT, Coleen Phillimore wrote:
>> This uses names for frame types for stackmaps in the verifier and
>> redefinition.
>> Tested with tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with one
> additional commit since the last revision:
>
>
On Wed, 18 Jun 2025 12:13:38 GMT, Coleen Phillimore wrote:
> This uses names for frame types for stackmaps in the verifier and
> redefinition.
> Tested with tier1-7.
LGTM, thanks!
-
Marked as reviewed by matsaave (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/25870#pullr
On Mon, 9 Jun 2025 13:58:09 GMT, Johan Sjölen wrote:
>> Hi,
>>
>> The constant pool currently has a lot of methods specific to extracting
>> parts of the operands array. What this array actually is, is a sequence of
>> bootstrap method attribute entries, where each entry has the following
>>
On Fri, 16 May 2025 04:38:47 GMT, Ioi Lam wrote:
>> This is an alternative (and opposite) approach to
>> https://github.com/openjdk/jdk/pull/24895. We basically convert most `[cds]`
>> logs to `[aot]` logs. However, for the few logs that might be needed by
>> existing user scripts, we use macr
On Fri, 17 Jan 2025 12:18:52 GMT, Coleen Phillimore wrote:
>> Please review this change to replace SIZE_FORMAT with %zu in the runtime
>> code. The second and third commits are hand editing for fixing up formats
>> of the code, not the output. After this, there'll be a separate change to
>>
On Tue, 7 Jan 2025 12:51:33 GMT, Coleen Phillimore wrote:
>> There are a lot of format modifiers that are noisy and unnecessary in the
>> code. This change removes the INTX variants. It's not that disruptive even
>> for backporting because %z modifier has been available for a long time so
>>
On Tue, 7 Jan 2025 12:51:33 GMT, Coleen Phillimore wrote:
>> There are a lot of format modifiers that are noisy and unnecessary in the
>> code. This change removes the INTX variants. It's not that disruptive even
>> for backporting because %z modifier has been available for a long time so
>>
On Thu, 22 Aug 2024 20:08:43 GMT, Roman Kennke wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes)
>> #20603 and #20605, plus the Tiny Class-Pointers parts that have been
>> prev
On Thu, 19 Sep 2024 12:08:46 GMT, Roman Kennke wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes)
>> #20603 and #20605, plus the Tiny Class-Pointers parts that have been
>> prev
On Thu, 5 Sep 2024 18:56:19 GMT, Matias Saavedra Silva
wrote:
> This patch cleans up the use of `get_new_method()` so callers don't have to
> worry about throwing `NoSuchMethodError`. The method is refactored to throw
> the error and avoid ever returning nullptr. Verified with
On Wed, 11 Sep 2024 21:02:41 GMT, Matias Saavedra Silva
wrote:
>> This patch cleans up the use of `get_new_method()` so callers don't have to
>> worry about throwing `NoSuchMethodError`. The method is refactored to throw
>> the error and avoid ever returning nullptr
On Sat, 14 Sep 2024 08:09:04 GMT, David Holmes wrote:
> A refactoring should not change behaviour. Maybe this only looked like an
> opportunity for refactoring but in reality is not?
The change of behavior here is there will no longer be any potential crashes
resulting from `get_new_method()` r
> This patch cleans up the use of `get_new_method()` so callers don't have to
> worry about throwing `NoSuchMethodError`. The method is refactored to throw
> the error and avoid ever returning nullptr. Verified with tier1-5 tests.
Matias Saavedra Silva has updated the pull request
On Tue, 3 Sep 2024 12:33:47 GMT, Coleen Phillimore wrote:
>> Move JVM implementation access flags that are not specified by the classfile
>> format into Klass so we can shrink AccessFlags to u2 in a future change.
>>
>> Tested with tier1-7.
>>
>> NOTE: there are arm, ppc and s390 changes to th
On Fri, 30 Aug 2024 14:00:44 GMT, Coleen Phillimore wrote:
>> Move JVM implementation access flags that are not specified by the classfile
>> format into Klass so we can shrink AccessFlags to u2 in a future change.
>>
>> Tested with tier1-7.
>>
>> NOTE: there are arm, ppc and s390 changes to t
On Thu, 29 Aug 2024 18:50:42 GMT, Coleen Phillimore wrote:
>> Move JVM implementation access flags that are not specified by the classfile
>> format into Klass so we can shrink AccessFlags to u2 in a future change.
>>
>> Tested with tier1-7.
>>
>> NOTE: there are arm, ppc and s390 changes to t
On Mon, 6 May 2024 17:05:47 GMT, Matias Saavedra Silva
wrote:
> The beginning of the RW region contains pointers to c++ vtables which are
> always located at a fixed offset from the shared base address at runtime.
> This offset can be calculated at dumptime and stored with the
On Tue, 7 May 2024 21:39:04 GMT, Chris Plummer wrote:
>> Matias Saavedra Silva has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Chris comments and cleanup
>
> SA changes look good. Thanks for taking care of
ovement, all the
> pointers to RO tables are replaced with offsets as well.
>
> These changes will reduce the number of pointers in the RW and RO regions and
> will allow for the relocation bitmap size optimizations to be more effective.
> Verified with tier 1-5 tests.
Matias Saa
ovement, all the
> pointers to RO tables are replaced with offsets as well.
>
> These changes will reduce the number of pointers in the RW and RO regions and
> will allow for the relocation bitmap size optimizations to be more effective.
> Verified with tier 1-5 tests.
Matias Saa
ovement, all the
> pointers to RO tables are replaced with offsets as well.
>
> These changes will reduce the number of pointers in the RW and RO regions and
> will allow for the relocation bitmap size optimizations to be more effective.
> Verified with tier 1-5 tests.
Matias Saa
On Mon, 6 May 2024 22:32:12 GMT, Chris Plummer wrote:
>> The beginning of the RW region contains pointers to c++ vtables which are
>> always located at a fixed offset from the shared base address at runtime.
>> This offset can be calculated at dumptime and stored with the read-only
>> tables a
The beginning of the RW region contains pointers to c++ vtables which are
always located at a fixed offset from the shared base address at runtime. This
offset can be calculated at dumptime and stored with the read-only tables at
the top of the RO region. As a further improvement, all the pointe
On Wed, 17 Apr 2024 15:26:52 GMT, Matias Saavedra Silva
wrote:
> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190),
> [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and
> [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic
> ope
On Wed, 17 Apr 2024 22:48:16 GMT, Dean Long wrote:
>> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190),
>> [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and
>> [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic
>> operands needed to be rewr
On Wed, 17 Apr 2024 22:41:08 GMT, Dean Long wrote:
>> Matias Saavedra Silva has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Dean and Gilles comments
>
> src/hotspot/share/ci/ciEnv.cpp line 1513:
>
g to access errors if there is no matching decode call. These
> calls are removed with some methods adjusted to distinguish between indices
> with the bytecode. Verified with tier 1-5 tests.
Matias Saavedra Silva has updated the pull request incrementally with one
additional commit since t
On Wed, 17 Apr 2024 22:48:16 GMT, Dean Long wrote:
> Did you consider minimizing changes by leaving
> decode_invokedynamic_index/encode_invokedynamic_index calls in place, but
> having the implementations not change the value?
The intention from the start was to remove the encode/decode method
On Wed, 17 Apr 2024 22:43:38 GMT, Dean Long wrote:
>> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190),
>> [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and
>> [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic
>> operands needed to be rewr
Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190),
[JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and
[JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic
operands needed to be rewritten to encoded values to better distinguish indy
entries from
On Sat, 2 Dec 2023 00:38:58 GMT, Ioi Lam wrote:
>> This is a simple clean up that moves the code for initializing the CDS
>> config states from arguments.cpp to cdsConfig.cpp
>>
>> I renamed a few functions, but otherwise the code is unchanged.
>>
>> - `get_default_shared_archive_path()` -> `d
On Tue, 28 Nov 2023 23:24:53 GMT, Ioi Lam wrote:
> This is a simple clean up that moves the code for initializing the CDS config
> states from arguments.cpp to cdsConfig.cpp
>
> I renamed a few functions, but otherwise the code is unchanged.
>
> - `get_default_shared_archive_path()` -> `defaul
On Thu, 13 Jul 2023 03:25:38 GMT, Daohan Qu wrote:
>> This patch should fix the wrong CP index for `invokedynamic` instruction
>> generated by SA's `ClassWriter`. The buggy code in
>> `sun.jvm.hotspot.tools.jcore.ByteCodeRewriter` should have been up-to-date
>> with the following code snippet
On Thu, 29 Jun 2023 17:29:50 GMT, Coleen Phillimore wrote:
>> Please review change for mostly fixing return types in the constant pool and
>> metadata to fix -Wconversion warnings in JVMTI code. The order of
>> preference for changes are: 1. change the types to more distinct types
>> (fields
On Mon, 12 Jun 2023 19:52:36 GMT, Ioi Lam wrote:
> resolvedIndyEntry.hpp was added in
> [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995) and is included in
> the popular cpCache.hpp. As a result, resolvedIndyEntry.hpp is included in
> 807 out of about 1160 hotspot .o files.
>
> The
On Fri, 9 Jun 2023 14:56:21 GMT, Coleen Phillimore wrote:
>> Matias Saavedra Silva has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Removed unnecessary assignment
>
> Looks good.
Thank you for the reviews
On Thu, 8 Jun 2023 21:42:24 GMT, Matias Saavedra Silva
wrote:
> The accessor methods in constantpool.cpp were previously cleaned up to allow
> for different types of indices to be used, distinguishing them by the
> bytecode. This patch adds the same changes to the hotspot servi
> The accessor methods in constantpool.cpp were previously cleaned up to allow
> for different types of indices to be used, distinguishing them by the
> bytecode. This patch adds the same changes to the hotspot serviceability
> agent code. Verified with tier 1-5 tests.
Matias Sa
The accessor methods in constantpool.cpp were previously cleaned up to allow
for different types of indices to be used, distinguishing them by the bytecode.
This patch adds the same changes to the hotspot serviceability code. Verified
with tier 1-5 tests.
-
Commit messages:
- 8309
On Wed, 24 May 2023 18:19:33 GMT, Coleen Phillimore wrote:
>> This change uses a number of ways to eliminate -Wconversion warnings in the
>> metadata files in the oops directory.
>>
>> 1. narrow return types to u2 if the accessor is for a field or value that's
>> u2 (u2 is most common for con
On Fri, 28 Apr 2023 15:42:58 GMT, Coleen Phillimore wrote:
>> This change moves the flags from AccessFlags to either ConstMethodFlags or
>> MethodFlags, depending on whether they are set at class file parse time,
>> which makes them essentially const, or at runtime, which makes them needing
>>
On Thu, 27 Apr 2023 14:21:23 GMT, Coleen Phillimore wrote:
>> This change moves the flags from AccessFlags to either ConstMethodFlags or
>> MethodFlags, depending on whether they are set at class file parse time,
>> which makes them essentially const, or at runtime, which makes them needing
>>
On Thu, 20 Apr 2023 00:35:06 GMT, Coleen Phillimore wrote:
> Please review this small change to remove Method AccessFlags that are unused.
> These flags were moved to ConstMethod a long time ago.
> Tested with tier1-4, SA tests locally
Nice cleanup, LGTM!
-
Marked as reviewed by
On Wed, 12 Apr 2023 17:59:23 GMT, Ioi Lam wrote:
>> This PR combines the "open" and "closed" regions of the CDS archive heap
>> into a single region. This significantly simplifies the implementation,
>> making it more compatible with non-G1 collectors. There's a net removal of
>> ~1000 lines i
On Mon, 3 Apr 2023 03:32:27 GMT, Ioi Lam wrote:
> This PR combines the "open" and "closed" regions of the CDS archive heap into
> a single region. This significantly simplifies the implementation, making it
> more compatible with non-G1 collectors. There's a net removal of ~1000 lines
> in src
On Mon, 3 Apr 2023 03:32:27 GMT, Ioi Lam wrote:
> This PR combines the "open" and "closed" regions of the CDS archive heap into
> a single region. This significantly simplifies the implementation, making it
> more compatible with non-G1 collectors. There's a net removal of ~1000 lines
> in src
On Tue, 28 Mar 2023 19:50:36 GMT, Matias Saavedra Silva
wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold info
erified with tier1-9 tests.
>
> The PPC port was provided by @reinrich, RISCV was provided by @DingliZhang
> and @zifeihan, and S390x by @offamitkumar.
>
> This change supports the following platforms: x86, aarch64, PPC, RISCV, and
> S390x
Matias Saavedra Silva has updated the p
On Mon, 27 Feb 2023 21:37:34 GMT, Matias Saavedra Silva
wrote:
> The current structure used to store the resolution information for
> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
> ambigious fields f1 and f2. This structure can hold information f
On Tue, 28 Mar 2023 15:00:14 GMT, Matias Saavedra Silva
wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold info
Verified with tier1-9 tests.
>
> The PPC was provided by @reinrich and the RISCV port was provided by
> @DingliZhang and @zifeihan.
>
> This change supports the following platforms: x86, aarch64, PPC, and RISCV
Matias Saavedra Silva has updated the pull request incrementally with on
Verified with tier1-9 tests.
>
> The PPC was provided by @reinrich and the RISCV port was provided by
> @DingliZhang and @zifeihan.
>
> This change supports the following platforms: x86, aarch64, PPC, and RISCV
Matias Saavedra Silva has updated the pull request incrementally with on
Verified with tier1-9 tests.
>
> The PPC was provided by @reinrich and the RISCV port was provided by
> @DingliZhang and @zifeihan.
>
> This change supports the following platforms: x86, aarch64, PPC, and RISCV
Matias Saavedra Silva has updated the pull request incrementally with
Verified with tier1-9 tests.
>
> The PPC was provided by @reinrich and the RISCV port was provided by
> @DingliZhang and @zifeihan.
>
> This change supports the following platforms: x86, aarch64, PPC, and RISCV
Matias Saavedra Silva has updated the pull request incrementally wi
On Wed, 22 Mar 2023 17:42:35 GMT, Matias Saavedra Silva
wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold info
Verified with tier1-9 tests.
>
> The PPC was provided by @reinrich and the RISCV port was provided by
> @DingliZhang and @zifeihan.
>
> This change supports the following platforms: x86, aarch64, PPC, and RISCV
Matias Saavedra Silva has updated the pull request incrementally with
Verified with tier1-9 tests.
>
> The PPC was provided by @reinrich and the RISCV port was provided by
> @DingliZhang and @zifeihan.
>
> This change supports the following platforms: x86, aarch64, PPC, and RISCV
Matias Saavedra Silva has updated the pull request incrementally with o
On Tue, 21 Mar 2023 10:51:08 GMT, Andrew Haley wrote:
>> Matias Saavedra Silva has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix riscv interpreter mistake and acquire semantics
>
> src/hotspot/cpu/aar
Verified with tier1-9 tests.
>
> The PPC was provided by @reinrich and the RISCV port was provided by
> @DingliZhang and @zifeihan.
>
> This change supports the following platforms: x86, aarch64, PPC, and RISCV
Matias Saavedra Silva has updated the pull request incrementally with
Verified with tier1-9 tests.
>
> The PPC was provided by @reinrich and the RISCV port was provided by
> @DingliZhang and @zifeihan.
>
> This change supports the following platforms: x86, aarch64, PPC, and RISCV
Matias Saavedra Silva has updated the pull request incrementally w
Verified with tier1-9 tests.
>
> The PPC was provided by @reinrich and the RISCV port was provided by
> @DingliZhang and @zifeihan.
>
> This change supports the following platforms: x86, aarch64, PPC, and RISCV
Matias Saavedra Silva has updated the pull request incrementally wit
On Thu, 16 Mar 2023 16:11:57 GMT, Richard Reingruber wrote:
>> Matias Saavedra Silva has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fixed aarch64 interpreter mistake
>
> src/hotspot/cpu/aarch64/templ
Verified with tier1-9 tests.
>
> The PPC was provided by @reinrich and the RISCV port was provided by
> @DingliZhang and @zifeihan.
>
> This change supports the following platforms: x86, aarch64, PPC, and RISCV
Matias Saavedra Silva has updated the pull request incrementally w
Verified with tier1-9 tests.
>
> The PPC was provided by @reinrich and the RISCV port was provided by
> @DingliZhang and @zifeihan.
>
> This change supports the following platforms: x86, aarch64, PPC, and RISCV
Matias Saavedra Silva has updated the pull request incrementally w
On Tue, 14 Mar 2023 15:39:39 GMT, Gui Cao wrote:
>> Matias Saavedra Silva has updated the pull request with a new target base
>> due to a merge or a rebase. The incremental webrev excludes the unrelated
>> changes brought in by the merge/rebase. The pull request contains f
On Tue, 14 Mar 2023 23:29:17 GMT, Calvin Cheung wrote:
>> Matias Saavedra Silva has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> RISCV port update
>
> src/hotspot/share/interpreter/bootstrapInfo.cpp line 234
Verified with tier1-9 tests.
>
> The PPC was provided by @reinrich and the RISCV port was provided by
> @DingliZhang and @zifeihan.
>
> This change supports the following platforms: x86, aarch64, PPC, and RISCV
Matias Saavedra Silva has updated the pull request incrementally with o
On Tue, 14 Mar 2023 09:20:54 GMT, Richard Reingruber wrote:
> @matias9927 can I ask you to merge master? There seem to be conflicts (at
> least I see a message "This branch has conflicts that must be resolved"). I'd
> like to give the change a spin in our CI testing. This requires that it can
Verified with tier1-9 tests.
>
> The PPC was provided by @reinrich and the RISCV port was provided by
> @DingliZhang and @zifeihan.
>
> This change supports the following platforms: x86, aarch64, PPC, and RISCV
Matias Saavedra Silva has updated the pull request with a new tar
On Mon, 13 Mar 2023 21:04:22 GMT, Coleen Phillimore wrote:
>> Matias Saavedra Silva has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Interpreter optimization and comments
>
> src/hotspot/cpu/x86/interp_masm
Verified with tier1-9 tests.
>
> The PPC was provided by @reinrich and the RISCV port was provided by
> @DingliZhang and @zifeihan.
>
> This change supports the following platforms: x86, aarch64, PPC, and RISCV
Matias Saavedra Silva has updated the pull request incrementally with on
On Tue, 7 Mar 2023 14:00:19 GMT, Coleen Phillimore wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold information for fields,
>> metho
On Tue, 7 Mar 2023 13:39:50 GMT, Coleen Phillimore wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold information for fields,
>> metho
On Tue, 7 Mar 2023 13:35:18 GMT, Coleen Phillimore wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold information for fields,
>> metho
On Tue, 7 Mar 2023 14:10:33 GMT, Coleen Phillimore wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold information for fields,
>> metho
The current structure used to store the resolution information for
invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
ambigious fields f1 and f2. This structure can hold information for fields,
methods, and invokedynamics and each of its fields can hold different types o
77 matches
Mail list logo
