On Fri, 10 Jun 2022 13:23:51 GMT, David Holmes wrote:
> Expired Flags in 20:
>
> - FilterSpuriousWakeups
> - MinInliningThreshold
> - PrefetchFieldsAhead
>
> No remaining usages in code or tests.
>
> - UseHeavyMonitors (expired in PRODUCT ONLY)
>
> As this flag now only exists for debug buil
On Wed, 8 Jun 2022 09:39:23 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This patch implements intrinsics for `Integer/Long::compareUnsigned` using
>> the same approach as the JVM does for long and floating-point comparisons.
>> This allows efficient and reliable usage of unsigned comparison in Java,
On Wed, 8 Jun 2022 09:39:23 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This patch implements intrinsics for `Integer/Long::compareUnsigned` using
>> the same approach as the JVM does for long and floating-point comparisons.
>> This allows efficient and reliable usage of unsigned comparison in Java,
On Tue, 7 Jun 2022 17:14:18 GMT, Quan Anh Mai wrote:
> Hi,
>
> This patch implements intrinsics for `Integer/Long::compareUnsigned` using
> the same approach as the JVM does for long and floating-point comparisons.
> This allows efficient and reliable usage of unsigned comparison in Java,
> w
On Thu, 26 May 2022 06:19:40 GMT, Jatin Bhateja wrote:
>> Yes.
>
>> @jatin-bhateja something wrong with merge. `vpadd()` is removed. It was
>> added by #8778 and still is used in `x86.ad`.
>
> Hi @vnkozlov , after integration of PR 8778 there were there were two copies
> of vpadd with same sig
On Wed, 25 May 2022 06:29:23 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> Patch adds the planned support for new vector operations and APIs targeted
>> for [JEP 426: Vector API (Fourth
>> Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
>>
>> Following is the brief summary of chan
On Wed, 25 May 2022 06:29:06 GMT, Jatin Bhateja wrote:
>> Jatin Bhateja has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8284960: Review comments resolved.
>
> Hi @vnkozlov , Your comments have been addressed.
@jatin-bhateja something wr
On Fri, 20 May 2022 09:51:24 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> Patch adds the planned support for new vector operations and APIs targeted
>> for [JEP 426: Vector API (Fourth
>> Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
>>
>> Following is the brief summary of chan
On Sat, 21 May 2022 15:30:29 GMT, Vladimir Kozlov wrote:
> I started our testing. Please, wait results.
Testing passed clean.
-
PR: https://git.openjdk.java.net/jdk/pull/8525
On Sat, 21 May 2022 10:31:25 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This patch optimises the matching rules for floating-point comparison with
>> respects to eq/ne on x86-64
>>
>> 1, When the inputs of a comparison is the same (i.e `isNaN` patterns), `ZF`
>> is always set, so we don't need `cm
On Fri, 20 May 2022 22:22:43 GMT, Sandhya Viswanathan
wrote:
>> I see that you swapped `src, dst` in `match()` but `format` is sill
>> incorrect and the code is confusing.
>
> I agree with @vnkozlov that this needs explanation. Could you please add
> comments here with IR and example code gene
On Wed, 4 May 2022 22:27:48 GMT, Paul Sandoz wrote:
> The changes to `Float` and `Double` look good. I don't think we need
> additional tests, see test/jdk/java/lang/Math/IeeeRecommendedTests.java.
Thank you, Paul for pointing the test. It means we need to run tier4 (which
runs these tests wit
On Wed, 4 May 2022 19:32:41 GMT, Vladimir Kozlov wrote:
>> Hi,
>>
>> This patch optimises the matching rules for floating-point comparison with
>> respects to eq/ne on x86-64
>>
>> 1, When the inputs of a comparison is the same (i.e `isNaN` patterns), `ZF`
On Wed, 4 May 2022 01:59:17 GMT, Quan Anh Mai wrote:
> Hi,
>
> This patch optimises the matching rules for floating-point comparison with
> respects to eq/ne on x86-64
>
> 1, When the inputs of a comparison is the same (i.e `isNaN` patterns), `ZF`
> is always set, so we don't need `cmpOpUCF2`
On Fri, 8 Apr 2022 22:17:23 GMT, Srinivas Vamsi Parasa
wrote:
>> Optimizes the divideUnsigned() and remainderUnsigned() methods in
>> java.lang.Integer and java.lang.Long classes using x86 intrinsics. This
>> change shows 3x improvement for Integer methods and upto 25% improvement for
>> Long
On Fri, 8 Apr 2022 22:17:23 GMT, Srinivas Vamsi Parasa
wrote:
>> Optimizes the divideUnsigned() and remainderUnsigned() methods in
>> java.lang.Integer and java.lang.Long classes using x86 intrinsics. This
>> change shows 3x improvement for Integer methods and upto 25% improvement for
>> Long
On Fri, 8 Apr 2022 18:32:06 GMT, Sandhya Viswanathan
wrote:
> My suggestion is to keep the -ve path assembly optimization in this patch.
> When the optimization in IR is introduced, the assembly could then be
> simplified as suggested by @merykitty.
Okay. Lets do that as part of JDK-8282365.
On Fri, 8 Apr 2022 01:05:33 GMT, Srinivas Vamsi Parasa
wrote:
>> Optimizes the divideUnsigned() and remainderUnsigned() methods in
>> java.lang.Integer and java.lang.Long classes using x86 intrinsics. This
>> change shows 3x improvement for Integer methods and upto 25% improvement for
>> Long
On Fri, 8 Apr 2022 00:55:50 GMT, Srinivas Vamsi Parasa
wrote:
>> I have few comments.
>
> Hi Vladimir (@vnkozlov),
>
> Incorporated all the suggestions you made in the previous review and pushed a
> new commit.
> Please let me know if anything else is needed.
>
> Thanks,
> Vamsi
@vamsi-paras
On Fri, 8 Apr 2022 01:59:10 GMT, Quan Anh Mai wrote:
> Personally, I think the optimisation for `div < 0` should be handled by the
> mid-end optimiser, which will not only give us the advantages of dead code
> elimination, but also global code motion. I would suggest the backend only
> doing `
On Fri, 8 Apr 2022 01:05:33 GMT, Srinivas Vamsi Parasa
wrote:
>> Optimizes the divideUnsigned() and remainderUnsigned() methods in
>> java.lang.Integer and java.lang.Long classes using x86 intrinsics. This
>> change shows 3x improvement for Integer methods and upto 25% improvement for
>> Long
On Tue, 5 Apr 2022 20:26:18 GMT, Vamsi Parasa wrote:
>> Optimizes the divideUnsigned() and remainderUnsigned() methods in
>> java.lang.Integer and java.lang.Long classes using x86 intrinsics. This
>> change shows 3x improvement for Integer methods and upto 25% improvement for
>> Long. This cha
On Thu, 24 Feb 2022 19:04:37 GMT, Vamsi Parasa wrote:
>> src/hotspot/share/opto/divnode.cpp line 881:
>>
>>> 879: return (phase->type( in(2) )->higher_equal(TypeLong::ONE)) ? in(1) :
>>> this;
>>> 880: }
>>> 881:
>>> //--Value--
On Wed, 23 Mar 2022 02:03:26 GMT, Fei Yang wrote:
>> This PR implements JEP 422: Linux/RISC-V Port [1].
>> The PR starts as a squashed merge of the
>> https://openjdk.java.net/projects/riscv-port branch.
>>
>> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive
>> Unmatched bo
On Tue, 22 Mar 2022 11:50:13 GMT, Fei Yang wrote:
>> This PR implements JEP 422: Linux/RISC-V Port [1].
>> The PR starts as a squashed merge of the
>> https://openjdk.java.net/projects/riscv-port branch.
>>
>> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive
>> Unmatched bo
On Tue, 22 Mar 2022 11:50:13 GMT, Fei Yang wrote:
>> This PR implements JEP 422: Linux/RISC-V Port [1].
>> The PR starts as a squashed merge of the
>> https://openjdk.java.net/projects/riscv-port branch.
>>
>> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive
>> Unmatched bo
On Wed, 23 Feb 2022 14:19:20 GMT, Claes Redestad wrote:
>> I'm requesting comments and, hopefully, some help with this patch to replace
>> `StringCoding.hasNegatives` with `countPositives`. The new method does a
>> very similar pass, but alters the intrinsic to return the number of leading
>>
On Mon, 14 Feb 2022 10:30:09 GMT, Tobias Hartmann wrote:
> We observed several failures on macosx aarch64 after integration of
> [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448). I could
> reliably reproduce
> [JDK-8281512](https://bugs.openjdk.java.net/browse/JDK-8281512) with
On Wed, 5 Jan 2022 08:59:00 GMT, Jatin Bhateja wrote:
>> Patch extends existing macrologic inferencing algorithm to handle masked
>> logic operations.
>>
>> Existing algorithm:
>>
>> 1. Identify logic cone roots.
>> 2. Packs parent and logic child nodes into a MacroLogic node in bottom up
>>
On Tue, 4 Jan 2022 15:11:47 GMT, Jatin Bhateja wrote:
>> Patch extends existing macrologic inferencing algorithm to handle masked
>> logic operations.
>>
>> Existing algorithm:
>>
>> 1. Identify logic cone roots.
>> 2. Packs parent and logic child nodes into a MacroLogic node in bottom up
>>
On Tue, 4 Jan 2022 15:11:47 GMT, Jatin Bhateja wrote:
>> Patch extends existing macrologic inferencing algorithm to handle masked
>> logic operations.
>>
>> Existing algorithm:
>>
>> 1. Identify logic cone roots.
>> 2. Packs parent and logic child nodes into a MacroLogic node in bottom up
>>
On Tue, 4 Jan 2022 15:01:22 GMT, Jatin Bhateja wrote:
>> src/hotspot/cpu/x86/x86.ad line 1900:
>>
>>> 1898:
>>> 1899: case Op_MacroLogicV:
>>> 1900: if(bt != T_INT && bt != T_LONG) {
>>
>> Missing `VM_Version::supports_evex()` check?
>
> Hi @vnkozlov, we already have that check (UseA
On Mon, 3 Jan 2022 12:31:50 GMT, Jatin Bhateja wrote:
>> Patch extends existing macrologic inferencing algorithm to handle masked
>> logic operations.
>>
>> Existing algorithm:
>>
>> 1. Identify logic cone roots.
>> 2. Packs parent and logic child nodes into a MacroLogic node in bottom up
>>
On Wed, 15 Dec 2021 05:59:45 GMT, Vladimir Kozlov wrote:
> A proper fix for this is to use the catchException combination. However, that
> introduces significant cold startup performance regression. JDK-8278447
> tracks the work to address the performance regression using catchExcepti
On Wed, 15 Dec 2021 17:56:23 GMT, Vladimir Kozlov wrote:
>> A proper fix for this is to use the catchException combination. However,
>> that introduces significant cold startup performance regression. JDK-8278447
>> tracks the work to address the performance regression us
w regression test. Tested tier1-3.
Vladimir Kozlov has updated the pull request incrementally with one additional
commit since the last revision:
Removed boot classloader check
-
Changes:
- all: https://git.openjdk.java.net/jdk18/pull/27/files
- new: https://git.openjdk.java
On Wed, 15 Dec 2021 17:19:25 GMT, Mandy Chung wrote:
>> @dholmes-ora, thank you for looking on it.
>> I discussed it with Mandy and agreed that we need to narrow down this
>> workaround as much as possible. That is why it is done only for system class
>> loaded by null loader.
>
> David has a g
On Wed, 15 Dec 2021 07:00:17 GMT, David Holmes wrote:
>> A proper fix for this is to use the catchException combination. However,
>> that introduces significant cold startup performance regression. JDK-8278447
>> tracks the work to address the performance regression using catchException
>> and
A proper fix for this is to use the catchException combination. However, that
introduces significant cold startup performance regression. JDK-8278447 tracks
the work to address the performance regression using catchException and
asSpreader combinator. It may require significant work and refactor
On Tue, 2 Nov 2021 06:25:33 GMT, Aleksey Shipilev wrote:
>> This blocks JDK-8276215: `StrictMath` intrinsics are handled peculiarly by
>> giving failing intrinsics a second chance to match against the similar
>> `Math` intrinsics. This has interesting consequence for matchers: we can
>> match
On Mon, 1 Nov 2021 15:35:36 GMT, Aleksey Shipilev wrote:
>> This blocks JDK-8276215: `StrictMath` intrinsics are handled peculiarly by
>> giving failing intrinsics a second chance to match against the similar
>> `Math` intrinsics. This has interesting consequence for matchers: we can
>> match
On Mon, 1 Nov 2021 15:35:36 GMT, Aleksey Shipilev wrote:
>> This blocks JDK-8276215: `StrictMath` intrinsics are handled peculiarly by
>> giving failing intrinsics a second chance to match against the similar
>> `Math` intrinsics. This has interesting consequence for matchers: we can
>> match
On Tue, 19 Oct 2021 20:34:55 GMT, Vamsi Parasa wrote:
>> Optimize the new Math.unsignedMultiplyHigh using the x86 mul instruction.
>> This change show 1.87X improvement on a micro benchmark.
>
> Vamsi Parasa has updated the pull request incrementally with one additional
> commit since the last
On Tue, 19 Oct 2021 20:34:55 GMT, Vamsi Parasa wrote:
>> Optimize the new Math.unsignedMultiplyHigh using the x86 mul instruction.
>> This change show 1.87X improvement on a micro benchmark.
>
> Vamsi Parasa has updated the pull request incrementally with one additional
> commit since the last
On Fri, 15 Oct 2021 19:19:13 GMT, Vamsi Parasa wrote:
> > How you verified correctness of results? I suggest to extend
> > `test/jdk//java/lang/Math/MultiplicationTests.java` test to cover unsigned
> > method.
>
> Tests for unsignedMultiplyHigh were already added in
> test/jdk//java/lang/Math
On Wed, 13 Oct 2021 18:55:10 GMT, Vamsi Parasa wrote:
> Optimize the new Math.unsignedMultiplyHigh using the x86 mul instruction.
> This change show 1.87X improvement on a micro benchmark.
How you verified correctness of results?
I suggest to extend `test/jdk//java/lang/Math/MultiplicationTests
On Fri, 8 Oct 2021 21:25:26 GMT, Paul Sandoz wrote:
> This PR improves the performance of vector operations that accept masks on
> architectures that support masking in hardware, specifically Intel AVX512 and
> ARM SVE.
>
> On architectures that do not support masking in hardware the same tech
On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev wrote:
>> Hi all,
>>
>> could you please review this big tedious and trivial(-ish) patch which moves
>> `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
>>
>> the majority of the patch is the following substitutions:
>>
On Wed, 28 Jul 2021 17:13:49 GMT, Igor Ignatyev wrote:
> Hi all,
>
> could you please review this big tedious and trivial(-ish) patch which moves
> `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
>
> the majority of the patch is the following substitutions:
> - `s~s
On Wed, 28 Jul 2021 05:35:59 GMT, Vladimir Kozlov wrote:
> Backout the following changes due to vector tests failures in tier 2 and
> later:
> [JDK-8266054](https://bugs.openjdk.java.net/browse/JDK-8266054) VectorAPI
> rotate operation optimization
>
> Changes also cause
On Wed, 28 Jul 2021 06:24:20 GMT, Jatin Bhateja wrote:
> * Thanks for reporting it, should it be ok to move those tests to
> ProblemList.txt and let me fix this as a follow up issue instead of a revert ?
@jatin-bhateja We did not test original changes in our testing infra. There
could be other
Backout the following changes due to vector tests failures in tier 2 and later:
[JDK-8266054](https://bugs.openjdk.java.net/browse/JDK-8266054) VectorAPI
rotate operation optimization
Changes also caused copyright header validation failure in Tier1 due to missing
`,` after copyright year in ne
On Tue, 27 Jul 2021 18:31:20 GMT, Sandhya Viswanathan
wrote:
>> Jatin Bhateja has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 19 commits:
>>
>> - 8266054: Re-designing benchmark to remove noise.
>> - Merge branch 'master' of ht
On Thu, 15 Jul 2021 12:44:23 GMT, Jorn Vernee wrote:
>> Thanks.
>>
>> I've been careful here to return a `Thread*` since the result is stored in
>> `r15_thread` and I thought converting between sub and super types could
>> potentially result in different pointers due to the way super types are
On Thu, 24 Jun 2021 17:02:03 GMT, Scott Gibbons
wrote:
>> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration.
>> Also allows for performance improvement for non-AVX-512 enabled platforms.
>> Due to the nature of MIME-encoded inputs, modify the intrinsic signature to
>
On Wed, 23 Jun 2021 00:31:55 GMT, Scott Gibbons
wrote:
>> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration.
>> Also allows for performance improvement for non-AVX-512 enabled platforms.
>> Due to the nature of MIME-encoded inputs, modify the intrinsic signature to
>
On Wed, 23 Jun 2021 00:31:55 GMT, Scott Gibbons
wrote:
>> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration.
>> Also allows for performance improvement for non-AVX-512 enabled platforms.
>> Due to the nature of MIME-encoded inputs, modify the intrinsic signature to
>
On Wed, 23 Jun 2021 00:31:55 GMT, Scott Gibbons
wrote:
>> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration.
>> Also allows for performance improvement for non-AVX-512 enabled platforms.
>> Due to the nature of MIME-encoded inputs, modify the intrinsic signature to
>
On Wed, 19 May 2021 00:58:15 GMT, Sandhya Viswanathan
wrote:
>> This PR contains Short Vector Math Library support related changes for
>> [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414),
>> in preparation for when targeted.
>>
>> Intel Short Vector Math Library (SVM
On Fri, 14 May 2021 23:58:38 GMT, Sandhya Viswanathan
wrote:
> Vector API test operations (IS_DEFAULT, IS_FINITE, IS_INFINITE, IS_NAN and
> IS_NEGATIVE) are computed in three steps:
> 1) reinterpreting the floating point vectors as integral vectors (int/long)
> 2) perform the test in integer do
On Tue, 18 May 2021 23:59:28 GMT, Sandhya Viswanathan
wrote:
>> This PR contains Short Vector Math Library support related changes for
>> [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414),
>> in preparation for when targeted.
>>
>> Intel Short Vector Math Library (SVM
On Sat, 15 May 2021 02:06:29 GMT, Sandhya Viswanathan
wrote:
>> This PR contains Short Vector Math Library support related changes for
>> [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414),
>> in preparation for when targeted.
>>
>> Intel Short Vector Math Library (SVM
On Fri, 9 Apr 2021 17:35:11 GMT, Vladimir Kozlov wrote:
> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to
> Java-based JIT compiler (Graal) from JDK:
>
> - `jdk.internal.vm.compiler` — the Graal compiler
> - `jdk.internal.vm.compiler.management` —
a
> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
>
>
> @AlanBateman suggested that we can avoid it by using Module API to export
> packages at runtime . It requires changes in GraalVM's JVMCI too so I will
> file followup RFE to implement it.
>
&
a
> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
>
>
> @AlanBateman suggested that we can avoid it by using Module API to export
> packages at runtime . It requires changes in GraalVM's JVMCI too so I will
> file followup RFE to implement it.
>
&
On Thu, 8 Apr 2021 15:23:52 GMT, Vladimir Kozlov wrote:
> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to
> Ahead-of-Time Compiler from JDK:
>
> - `jdk.aot` module — the `jaotc` tool
> - `src/hotspot/share/aot` — loads AoT compiled code into V
y `#if INCLUDE_AOT`
>
> Additionally, remove tests as well as code in makefiles related to AoT
> compilation.
>
> Tested hs-tier1-4
Vladimir Kozlov has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains six commits:
- Merge
On Fri, 23 Apr 2021 03:50:54 GMT, Yi Yang wrote:
>> The JDK codebase re-created many variants of checkIndex(`grep -I -r
>> 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which
>> annotated with @IntrinsicCandidate and it only has a corresponding C1
>> intrinsic version.
On Tue, 13 Apr 2021 09:30:23 GMT, Doug Simon wrote:
>> We would definitely like to be able to continue testing of GraalVM with the
>> JDK set of jtreg tests. So keeping `Compiler::isGraalEnabled()` working like
>> it does today is important.
>
>> @dougxc I restored Compiler::isGraalEnabled().
>
On Sun, 11 Apr 2021 10:25:47 GMT, Doug Simon wrote:
>> Vladimir Kozlov 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 contain
a
> src/jdk.internal.vm.compiler.management/share/classes/module-info.java
>
>
> @AlanBateman suggested that we can avoid it by using Module API to export
> packages at runtime . It requires changes in GraalVM's JVMCI too so I will
> file followup RFE to implement it.
>
>
On Mon, 12 Apr 2021 16:18:32 GMT, Erik Joelsson wrote:
>> Vladimir Kozlov 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 contain
On Sat, 10 Apr 2021 16:47:45 GMT, Igor Ignatyev wrote:
>> Vladimir Kozlov 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 contain
On Sat, 10 Apr 2021 15:38:11 GMT, Igor Ignatyev wrote:
>> Vladimir Kozlov 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 contain
On Sat, 10 Apr 2021 15:38:11 GMT, Igor Ignatyev wrote:
> should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and
> update a few of its users accordingly?
> what about `vm.graal.enabled` `@requires` property?
Thank you, @iignatev for looking on changes.
I forgot to mention that
On Fri, 9 Apr 2021 17:35:11 GMT, Vladimir Kozlov wrote:
> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to
> Java-based JIT compiler (Graal) from JDK:
>
> - `jdk.internal.vm.compiler` — the Graal compiler
> - `jdk.internal.vm.compiler.management` —
jdk.internal.vm.compiler.management/share/classes/module-info.java
>
> @AlanBateman suggested that we can avoid it by using Module API to export
> packages at runtime . It requires changes in GraalVM's JVMCI too so I will
> file followup RFE to implement it.
>
> Tested hs
y `#if INCLUDE_AOT`
>
> Additionally, remove tests as well as code in makefiles related to AoT
> compilation.
>
> Tested hs-tier1-4
Vladimir Kozlov has updated the pull request incrementally with one additional
commit since the last revision:
Address review comments
-
On Fri, 9 Apr 2021 16:54:35 GMT, Ioi Lam wrote:
>> Vladimir Kozlov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove exports from Graal module to jdk.aot
>
> src/hotspot/share/oops/methodCounters.
On Fri, 9 Apr 2021 16:34:58 GMT, Igor Veresov wrote:
>> Vladimir Kozlov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove exports from Graal module to jdk.aot
>
> src/hotspot/share/jvmci/jvmciCodeInsta
On Fri, 9 Apr 2021 16:30:41 GMT, Igor Veresov wrote:
>> Vladimir Kozlov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove exports from Graal module to jdk.aot
>
> src/hotspot/share/oops/instanc
On Fri, 9 Apr 2021 08:32:59 GMT, Aleksey Shipilev wrote:
>> Vladimir Kozlov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove exports from Graal module to jdk.aot
>
> src/hotspot/share/code/comp
On Fri, 9 Apr 2021 03:03:33 GMT, David Holmes wrote:
>> Vladimir Kozlov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove exports from Graal module to jdk.aot
>
> src/hotspot/share/memory/heap.h
On Fri, 9 Apr 2021 08:29:21 GMT, Aleksey Shipilev wrote:
>> Vladimir Kozlov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove exports from Graal module to jdk.aot
>
> src/hotspot/cpu/x86/globalDefinit
On Fri, 9 Apr 2021 02:44:23 GMT, David Holmes wrote:
>> Vladimir Kozlov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove exports from Graal module to jdk.aot
>
> src/hotspot/cpu/x86/compiledIC_x86.c
As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to
Java-based JIT compiler (Graal) from JDK:
- `jdk.internal.vm.compiler` — the Graal compiler
- `jdk.internal.vm.compiler.management` — Graal's `MBean`
- `test/hotspot/jtreg/compiler/graalunit` — Graal's unit tests
Remo
On Fri, 9 Apr 2021 17:09:58 GMT, Vladimir Kozlov wrote:
>> Hi Vladimir,
>>
>> This looks good to me - I went through all the files.
>>
>> It was nice to see how nicely compartmentalized the AOT feature was - that
>> made checking the changes qui
On Fri, 9 Apr 2021 04:32:14 GMT, David Holmes wrote:
> Hi Vladimir,
>
> This looks good to me - I went through all the files.
>
> It was nice to see how nicely compartmentalized the AOT feature was - that
> made checking the changes quite simple. The one exception was the
> fingerprinting cod
On Thu, 8 Apr 2021 20:59:59 GMT, Coleen Phillimore wrote:
> There's a comment above
> void VM_RedefineClasses::mark_dependent_code(InstanceKlass* ik) {
> that should be rewritten, so I think we should just file an RFE to remove it
> afterwards.
https://bugs.openjdk.java.net/browse/JDK-8264941
On Thu, 8 Apr 2021 20:00:30 GMT, Vladimir Kozlov wrote:
>> GC changes look good.
>
>> void CodeCache::mark_for_evol_deoptimization(InstanceKlass* dependee) {
>> This function, its caller and the function in jvmtiRedefineClasses.cpp that
>> calls it can be delet
On Thu, 8 Apr 2021 19:58:11 GMT, Stefan Karlsson wrote:
>> Vladimir Kozlov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove exports from Graal module to jdk.aot
>
> GC change
y `#if INCLUDE_AOT`
>
> Additionally, remove tests as well as code in makefiles related to AoT
> compilation.
>
> Tested hs-tier1-4
Vladimir Kozlov has updated the pull request incrementally with one additional
commit since the last revision:
Remove exports from Graal module t
y `#if INCLUDE_AOT`
>
> Additionally, remove tests as well as code in makefiles related to AoT
> compilation.
>
> Tested hs-tier1-4
Vladimir Kozlov has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains three commits:
- Merge
y `#if INCLUDE_AOT`
>
> Additionally, remove tests as well as code in makefiles related to AoT
> compilation.
>
> Tested hs-tier1-4
Vladimir Kozlov has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains two commits:
- Merge
As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to
Ahead-of-Time Compiler from JDK:
- `jdk.aot` module — the `jaotc` tool
- `src/hotspot/share/aot` — loads AoT compiled code into VM for execution
- related HotSpot code guarded by `#if INCLUDE_AOT`
Additionally, rem
/java/lang/Thread.java#L310
https://github.com/openjdk/loom/blob/fibers/src/hotspot/share/prims/jvm.cpp#L3130
It will be much easy to optimize.
On 3/5/21 11:13 AM, Eirik Bjørsnøs wrote:
On Fri, Mar 5, 2021 at 6:41 PM Vladimir Kozlov mailto:vladimir.koz...@oracle.com>> wrote:
Vladimir,
Thanks
Hi Erik,
The implementation of ThreadLocal is based on HashMap:
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/ThreadLocal.java#L76
Currently it is "impossible" for JIT compiler to reliably know that value stored by set() in hash map is the same as
read by get(
On Thu, 26 Nov 2020 13:13:43 GMT, Vladimir Ivanov wrote:
> Introduce sharing of `LambdaForms` for `VarHandle` linkers and invokers.
> It reduces the number of LambdaForms needed at runtime.
>
> Testing: tier1-4
Good.
-
Marked as reviewed by kvn (Reviewer).
PR: https://git.openjdk
On Wed, 25 Nov 2020 03:31:36 GMT, Vladimir Kozlov wrote:
> JDK-8188055 added the function Reference.refersTo. For performance, the
> supporting native methods Reference.refersTo0 and PhantomReference.refersTo0
> should be intrinsified by C2.
>
> Initial patch was pr
ts to test intrinsics.
>
> Ran new test with Shenandoah. Found only one issue. As result I disable
> PhantomReference::refersTo intrinsic for COOP+ Shenandoah combination.
> Someone from Shenandoah team have to test changes if that is enough.
Vladimir Kozlov has updated the pull requ
1 - 100 of 272 matches
Mail list logo
