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
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
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
On Tue, 18 Jan 2022 23:09:12 GMT, Liam Miller-Cushon wrote:
> Update links to the chromium style guide in the HotSpot Style Guide.
I agree that for small changes like this the process should be simplified.
-
PR: https://git.openjdk.java.net/jdk/pull/7138
On Thu, 4 Nov 2021 18:15:08 GMT, Sandhya Viswanathan
wrote:
>> Looks good. I will run tests.
>
> Thanks a lot @vnkozlov.
@sviswa7 testing passed you can integrate.
-
PR: https://git.openjdk.java.net/jdk/pull/6265
On Thu, 4 Nov 2021 19:49:08 GMT, Sandhya Viswanathan
wrote:
>> This patch removes conflicts with libsvml.so distributed with Intel's MKL
>> library:
>> Renames exported symbols from __svml to __jsvml.
>> Renames library from libsvml.so to libjsvml.so.
>> Updates the
On Thu, 4 Nov 2021 19:49:08 GMT, Sandhya Viswanathan
wrote:
>> This patch removes conflicts with libsvml.so distributed with Intel's MKL
>> library:
>> Renames exported symbols from __svml to __jsvml.
>> Renames library from libsvml.so to libjsvml.so.
>> Updates the
On Thu, 4 Nov 2021 17:48:56 GMT, Sandhya Viswanathan
wrote:
> This patch removes conflicts with libsvml.so distributed with Intel's MKL
> library:
> Renames exported symbols from __svml to __jsvml.
> Renames library from libsvml.so to libjsvml.so.
> Updates the stubGenerator_x86_64.cpp
On Thu, 4 Nov 2021 17:48:56 GMT, Sandhya Viswanathan
wrote:
> This patch removes conflicts with libsvml.so distributed with Intel's MKL
> library:
> Renames exported symbols from __svml to __jsvml.
> Renames library from libsvml.so to libjsvml.so.
> Updates the stubGenerator_x86_64.cpp
On Wed, 6 Oct 2021 05:17:28 GMT, Jie Fu wrote:
>> Hi all,
>>
>> I tried to build OpenJDK on Cygwin (Windows 2016 + VS2019).
>> However, I failed with C4474 and C4778 warnings as below:
>>
>> Compiling 100 properties into resource bundles for java.desktop
>> Compiling 3038 files for java.base
On Wed, 6 Oct 2021 05:17:28 GMT, Jie Fu wrote:
>> Hi all,
>>
>> I tried to build OpenJDK on Cygwin (Windows 2016 + VS2019).
>> However, I failed with C4474 and C4778 warnings as below:
>>
>> Compiling 100 properties into resource bundles for java.desktop
>> Compiling 3038 files for java.base
On Sun, 26 Sep 2021 09:55:00 GMT, Jie Fu wrote:
> Hi all,
>
> I tried to build OpenJDK on Cygwin (Windows 2016 + VS2019).
> However, I failed with C4474 and C4778 warnings as below:
>
> Compiling 100 properties into resource bundles for java.desktop
> Compiling 3038 files for java.base
>
On Sun, 26 Sep 2021 09:55:00 GMT, Jie Fu wrote:
> Hi all,
>
> I tried to build OpenJDK on Cygwin (Windows 2016 + VS2019).
> However, I failed with C4474 and C4778 warnings as below:
>
> Compiling 100 properties into resource bundles for java.desktop
> Compiling 3038 files for java.base
>
On Tue, 28 Sep 2021 17:31:24 GMT, Scott Gibbons
wrote:
>> Change the default code entry alignment to 64 bytes from 32 bytes. This
>> allows for maintaining proper 64-byte alignment of data within a code
>> segment, which is required by several AVX-512 instructions.
>>
>> I ran into this
On Tue, 28 Sep 2021 17:31:24 GMT, Scott Gibbons
wrote:
>> Change the default code entry alignment to 64 bytes from 32 bytes. This
>> allows for maintaining proper 64-byte alignment of data within a code
>> segment, which is required by several AVX-512 instructions.
>>
>> I ran into this
On Tue, 28 Sep 2021 01:10:53 GMT, Scott Gibbons
wrote:
>> Change the default code entry alignment to 64 bytes from 32 bytes. This
>> allows for maintaining proper 64-byte alignment of data within a code
>> segment, which is required by several AVX-512 instructions.
>>
>> I ran into this
On Tue, 28 Sep 2021 01:15:30 GMT, Scott Gibbons
wrote:
>> Change the default code entry alignment to 64 bytes from 32 bytes. This
>> allows for maintaining proper 64-byte alignment of data within a code
>> segment, which is required by several AVX-512 instructions.
>>
>> I ran into this
On Thu, 16 Sep 2021 16:08:22 GMT, Erik Joelsson wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Revert alignment of 64-bytes; Add align64()
>
> .gitignore line 19:
>
>> 17: **/JTwork/**
>> 18:
On Thu, 16 Sep 2021 13:52:24 GMT, Scott Gibbons
wrote:
> Change the default code entry alignment to 64 bytes from 32 bytes. This
> allows for maintaining proper 64-byte alignment of data within a code
> segment, which is required by several AVX-512 instructions.
>
> I ran into this while
On Thu, 16 Sep 2021 13:52:24 GMT, Scott Gibbons
wrote:
> Change the default code entry alignment to 64 bytes from 32 bytes. This
> allows for maintaining proper 64-byte alignment of data within a code
> segment, which is required by several AVX-512 instructions.
>
> I ran into this while
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 Fri, 4 Jun 2021 17:40:48 GMT, Vladimir Kozlov wrote:
> JDK-8264806 removed Graal sources from JDK and INCLUDE_GRAAL is not defined
> anymore. We can now remove code added by JDK-8264874:
> https://github.com/openjdk/jdk/commit/951f277a
>
> Tested Tier1.
This pull reque
JDK-8264806 removed Graal sources from JDK and INCLUDE_GRAAL is not defined
anymore. We can now remove code added by JDK-8264874:
https://github.com/openjdk/jdk/commit/951f277a
Tested Tier1.
-
Commit messages:
- 8268272: Remove JDK-8264874 changes because Graal was removed.
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
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
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
On Thu, 13 May 2021 16:37:38 GMT, Vladimir Kozlov wrote:
> [JDK-8264806](https://bugs.openjdk.java.net/browse/JDK-8264806) changes
> removed sources and also removed JVMCI compiler from list of upgradable
> modules. JVMCI compiler modules should be upgradable in JDK to work with
On Thu, 13 May 2021 16:37:38 GMT, Vladimir Kozlov wrote:
> [JDK-8264806](https://bugs.openjdk.java.net/browse/JDK-8264806) changes
> removed sources and also removed JVMCI compiler from list of upgradable
> modules. JVMCI compiler modules should be upgradable in JDK to work with
On Thu, 13 May 2021 16:37:38 GMT, Vladimir Kozlov wrote:
> [JDK-8264806](https://bugs.openjdk.java.net/browse/JDK-8264806) changes
> removed sources and also removed JVMCI compiler from list of upgradable
> modules. JVMCI compiler modules should be upgradable in JDK to work with
On Thu, 13 May 2021 16:37:38 GMT, Vladimir Kozlov wrote:
> [JDK-8264806](https://bugs.openjdk.java.net/browse/JDK-8264806) changes
> removed sources and also removed JVMCI compiler from list of upgradable
> modules. JVMCI compiler modules should be upgradable in JDK to work with
[JDK-8264806](https://bugs.openjdk.java.net/browse/JDK-8264806) changes removed
sources and also removed JVMCI compiler from list of upgradable modules. JVMCI
compiler modules should be upgradable in JDK to work with GraalVM.
Make these modules upgradable again and empty by leaving only
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-t
/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-t
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 Mon, 19 Apr 2021 19:38:52 GMT, Doug Simon wrote:
>> src/hotspot/cpu/x86/vmStructs_x86.hpp line 45:
>>
>>> 43:
>>> 44: #define DECLARE_LONG_CPU_FEATURE_CONSTANT(id, name, bit)
>>> GENERATE_VM_LONG_CONSTANT_ENTRY(VM_Version::CPU_##id)
>>> 45: #define VM_LONG_CPU_FEATURE_CONSTANTS
>>>
On Mon, 19 Apr 2021 19:56:45 GMT, Doug Simon wrote:
>> While porting
>> [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I
>> noticed that new CPU features were defined for x86 and AArch64 without being
>> exposed via JVMCI. To avoid this problem in future, this PR
On Mon, 19 Apr 2021 09:46:17 GMT, Doug Simon wrote:
>> While porting
>> [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I
>> noticed that new CPU features were defined for x86 and AArch64 without being
>> exposed via JVMCI. To avoid this problem in future, this PR
On Sun, 18 Apr 2021 20:17:14 GMT, Doug Simon wrote:
>> This PR removes the mx configuration files in the JDK as they do not really
>> belong here. Instead, I've updated and moved them to
>> https://github.com/dougxc/mx_jdk.
>
> Doug Simon has refreshed the contents of this pull request, and
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
/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-tier
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` —
al.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-tier1-4
Vladi
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 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 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 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
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 cha
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
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 del
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,
On Wed, 7 Apr 2021 22:37:28 GMT, Ioi Lam wrote:
> Many HotSpot developers make only the `hotspot` target, and copy the
> resulting `libjvm.so` into an already-build JDK image.
>
> HotSpot requires `interim-langtools` only when Graal is enabled. When Graal
> is disabled, we can avoid building
On Mon, 22 Feb 2021 20:15:33 GMT, Doug Simon wrote:
> To allow for better testing of JVMCI support on AArch64 in aid of producing a
> reliable GraalVM release on this platform, it should be included by default.
I would wait results of testing before approval. You may need to make
additional
On Mon, 11 Jan 2021 02:14:17 GMT, Hao Sun
wrote:
>> 1. '-Wdeprecated-copy'
>> As specified in C++11 [1], "the generation of the implicitly-defined
>> copy constructor is deprecated if T has a user-defined destructor or
>> user-defined copy assignment operator". The rationale behind is the
>>
On Wed, 6 Jan 2021 06:14:11 GMT, Hao Sun
wrote:
>> 1. '-Wdeprecated-copy'
>> As specified in C++11 [1], "the generation of the implicitly-defined
>> copy constructor is deprecated if T has a user-defined destructor or
>> user-defined copy assignment operator". The rationale behind is the
>>
On Wed, 6 Jan 2021 13:24:22 GMT, Hao Sun
wrote:
>> @vnkozlov I was wondering if you could take a look at this? We're not sure
>> whether 'operator=' is problematic or not. Thanks.
>
> I manually checked the usages of assignment operators for class DUIterator,
> DUIterator_Fast and
On Tue, 5 Jan 2021 03:44:10 GMT, Hao Sun
wrote:
>> 1. '-Wdeprecated-copy'
>> As specified in C++11 [1], "the generation of the implicitly-defined
>> copy constructor is deprecated if T has a user-defined destructor or
>> user-defined copy assignment operator". The rationale behind is the
>>
On Wed, 23 Dec 2020 10:09:08 GMT, Hao Sun
wrote:
>> The declaration sites for JVM flags were changed by JDK-8243205 and the
>> subsequent JDK-8258074. As a result, undeclared identifier errors
>> occurred while building VM without compiler1 or compiler2 feature.
>>
>> Making the corresponding
On Tue, 17 Nov 2020 00:31:24 GMT, Igor Ignatyev wrote:
> Hi all,
>
>
> [8256414](https://bugs.openjdk.java.net/browse/JDK-8256414) / #1233 added
> similar profile to submit workflow, this patch defines `linux-x64-optimized`
> profile in jib-profile so it can be used by mach5 and added to
On Mon, 16 Nov 2020 18:26:18 GMT, Igor Ignatyev wrote:
> Hi all,
>
> Could you please review this small and trivial patch which adds
> `linux-x64-optimized` build to submit workflow so breakages of this build
> flavor would be easier to spot?
>
> Thanks,
> -- Igor
Marked as reviewed by kvn
On Thu, 5 Nov 2020 22:13:54 GMT, Eric Caspole wrote:
> While profiling an issue I added this sort by code size to LogCompilation,
> using -z
>
> $ java -ea -jar target/LogCompilation-1.0-SNAPSHOT.jar -z 2000-2.log | head
>
> 879 4 com.fee.fi.fo.Fum::foobar (3076 bytes)(code size: 57344)
>
On Tue, 20 Oct 2020 15:46:36 GMT, Bernhard Urban-Forster
wrote:
>> Use r18 as allocatable register on Linux only.
>>
>> A bootstrap works now (it has been crashing before due to r18 being
>> allocated):
>> $ ./windows-aarch64-server-fastdebug/bin/java.exe
>> -XX:+UnlockExperimentalVMOptions
On Mon, 2 Nov 2020 20:05:10 GMT, Bernhard Urban-Forster
wrote:
>> make/autoconf/jvm-features.m4 line 309:
>>
>>> 307: if test "x$OPENJDK_TARGET_CPU" = "xx86_64"; then
>>> 308: AC_MSG_RESULT([yes])
>>> 309: elif test "x$OPENJDK_TARGET_CPU" = "xaarch64"; then
>>
>> You are missing
On Tue, 20 Oct 2020 15:46:36 GMT, Bernhard Urban-Forster
wrote:
>> Use r18 as allocatable register on Linux only.
>>
>> A bootstrap works now (it has been crashing before due to r18 being
>> allocated):
>> $ ./windows-aarch64-server-fastdebug/bin/java.exe
>> -XX:+UnlockExperimentalVMOptions
On Fri, 30 Oct 2020 17:40:51 GMT, Vladimir Kozlov wrote:
> We shipped Ahead-of-Time compilation (the jaotc tool) in JDK 9, as an
> experimental feature. We shipped Graal as an experimental JIT compiler in JDK
> 10. We haven't seen much use of these features, and the effort
On Sun, 1 Nov 2020 20:15:01 GMT, Igor Veresov wrote:
>> We shipped Ahead-of-Time compilation (the jaotc tool) in JDK 9, as an
>> experimental feature. We shipped Graal as an experimental JIT compiler in
>> JDK 10. We haven't seen much use of these features, and the effort required
>> to
We shipped Ahead-of-Time compilation (the jaotc tool) in JDK 9, as an
experimental feature. We shipped Graal as an experimental JIT compiler in JDK
10. We haven't seen much use of these features, and the effort required to
support and enhance them is significant. We therefore intend to disable
On Fri, 25 Sep 2020 20:14:29 GMT, Paul Sandoz wrote:
> This pull request is for integration of the Vector API. It was previously
> reviewed under conditions when mercurial was
> used for the source code control system. Review threads can be found here
> (searching for issue number 8223347 in
On Mon, 28 Sep 2020 19:08:04 GMT, Philippe Marschall
wrote:
>> @marschall I will sponsor it after you integrate the latest update.
>
> @vnkozlov done, I hope I now made it correctly with a merge commit for the
> latest merge conflict
hs-tier1, hs-tier3-graal testing passed
-
On Wed, 23 Sep 2020 20:02:45 GMT, Erik Gahlin wrote:
>> Philippe Marschall has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now
>> contains one commit:
>> 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate
>
> Marked as reviewed
On Wed, 23 Sep 2020 18:41:06 GMT, Philippe Marschall
wrote:
>> Hello, newbie here
>>
>> I picked JDK-8138732 to work on because it has a "starter" label and I
>> believe I understand what to do.
>>
>> - I tried to update the copyright year to 2020 in every file.
>> - I decided to change
On Wed, 9 Sep 2020 09:49:44 GMT, Philippe Marschall
wrote:
>> Hello, newbie here
>>
>> I picked JDK-8138732 to work on because it has a "starter" label and I
>> believe I understand what to do.
>>
>> - I tried to update the copyright year to 2020 in every file.
>> - I decided to change
On Fri, 11 Sep 2020 21:53:12 GMT, Vladimir Kozlov wrote:
>> Marked as reviewed by psandoz (Reviewer).
>
> You should consider upstreaming Graal changes (jdk.internal.vm.compiler) into
> https://github.com/oracle/graal
> Otherwise next time we do "Update Graal" in
On Thu, 10 Sep 2020 17:59:54 GMT, Paul Sandoz wrote:
>> Philippe Marschall has refreshed the contents of this pull request, and
>> previous commits have been removed. The
>> incremental views will show differences compared to the previous content of
>> the PR.
>
> Marked as reviewed by psandoz
Good.
Thanks,
Vladimir
On 4/28/20 9:12 PM, Mikael Vidstedt wrote:
Please review this small change which disables JVMCI, Graal, and AOT when
building linux-aarch64 at Oracle, for now.
JBS: https://bugs.openjdk.java.net/browse/JDK-8244061
webrev:
+1
Thanks
Vladimir
> On Oct 22, 2019, at 3:42 PM, Bob Vandette wrote:
>
> Hotspot changes look good to me.
>
> Bob.
>
>
>> On Oct 22, 2019, at 6:36 PM, mark.reinh...@oracle.com wrote:
>>
>> 2019/10/22 12:43:42 -0700, bob.vande...@oracle.com:
> On Oct 22, 2019, at 3:22 PM,
HotSpot changes seem fine to me.
Thanks,
Vladimir
On 10/21/19 8:22 PM, mark.reinh...@oracle.com wrote:
RFE: https://bugs.openjdk.java.net/browse/JDK-8232080
CSR: https://bugs.openjdk.java.net/browse/JDK-8232753
Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/
This change implements jlink
Good.
Thanks
Vladimir
> On Oct 4, 2019, at 12:29 PM, dean.l...@oracle.com wrote:
>
> https://bugs.openjdk.java.net/browse/JDK-8231902
> http://cr.openjdk.java.net/~dlong/8231902/webrev/
>
> A recent upstream Graal change causes the META-INF/providers directory to
> contain only a single file,
Good (C2 part).
Thanks,
Vladimir
On 4/3/19 10:13 AM, Roman Kennke wrote:
I don't think it should be part of this cleanup.
Fair enough.
I have run several tests today, and removing the is_Phi() call doesn't seem to
negatively impact Shenandoah.
Updated webrevs:
Incremental:
I don't think it should be part of this cleanup.
Please, file separate RFE to push this change with separate review and testing.
Thanks,
Vladimir
On 4/3/19 4:18 AM, Roland Westrelin wrote:
Hi Vladimir,
opto/loopnode.cpp new is_Phi check was added. Please, explain.
When we expand
This is nice cleanup :)
4294 lines changed: 977 ins; 2841 del; 476 mod
First is general question. I don't understand why you need (diagnostic) ShenandoahLoadRefBarrier flag if it is new
behavior and you can't use old one because you removed it. I am definitely missing something here.
Thank
1 - 100 of 237 matches
Mail list logo
