re. 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 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
re. 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
re. 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 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
re. 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 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
re. 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
re. 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
re. 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 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
re. 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
re. 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
re. 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 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,
>>
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,
>>
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,
>>
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,
>>
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
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
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 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
re. 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 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
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 t
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
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
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
re. 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, 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
re. 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
re. 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 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
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, 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 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
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:
-
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
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
> 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
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 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()` ->
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()` ->
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 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
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
tive, leading 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: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:
>
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
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
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
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
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
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
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
60 matches
Mail list logo
