Re: Request for Review: Make the Queens test ("test in build") an option that can be disabled

http://cr.openjdk.java.net/~ihse/make-test-in-build-an-option/webrev.01. This second webrev was reviewed and accepted by David Holmes, Dmitry Samersoff, Coleen Phillimore and Vladimir Kozlov. However, Kelly O'Hair expressed concern that it would not work on Windows due to changes in make/defs.

Re: RFR (S): 7172922: export_ makefile targets do not work unless all supported variants are built

Looks good to me. Vladimir On 4/12/13 11:58 AM, Christian Thalinger wrote: http://cr.openjdk.java.net/~twisti/7172922 7172922: export_ makefile targets do not work unless all supported variants are built Reviewed-by: GEN_DIR can be overwritten by other configurations if multiple JVM_VARIANT_

Re: RFR (M): 8008772: remove gamma launcher

Nils, I don't see attached patch or webrev link. thanks, Vladimir On 5/1/13 1:41 PM, Nils Eliasson wrote: Hi, Here is a patch that fixes so that it still works to create vcprojs, and also sets defaults for the debugger commands. I have verified with creating vcprojs and debugging hotspot in

Re: RFR (M): 8008772: remove gamma launcher

:) Thanks, Vladimir Thanks, Christian -Original Message- From: [email protected] [mailto:[email protected]] On Behalf Of Vladimir Kozlov Sent: den 1 maj 2013 17:22 To: Nils Eliasson Cc: [email protected]; hotspot-dev developers; Christian

Re: RFR (M): 8008772: remove gamma launcher

Did you use 'hg rename' to move hotspot.script? We need to preserve history. Thanks, Vladimir On 5/6/13 9:35 AM, Christian Thalinger wrote: Last warning! If nobody speaks up today I'm going to push this later: http://cr.openjdk.java.net/~twisti/8008772/ -- Chris On May 2, 2013, at 5:28 PM,

Re: RFR (M): 8008772: remove gamma launcher

I see, you also modified it. Okay I agree with changes. Thanks Vladimir On 5/6/13 10:20 AM, Christian Thalinger wrote: On May 6, 2013, at 9:50 AM, Vladimir Kozlov wrote: Did you use 'hg rename' to move hotspot.script? We need to preserve history. hg move, yes. An hg diff on

Re: RFR: 8258856: VM build without C1/C2 fails after JDK-8243205 [v3]

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 h

Re: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion [v3]

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 >> well

Re: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy [v2]

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 DUIterator_L

Re: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy [v4]

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 >> well

Re: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy [v5]

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 >> wel

Re: Integrated: 8252709: Enable JVMCI when building linux-aarch64 at Oracle

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 ch

Re: RFR: 8264874: Build interim-langtools for HotSpot only if Graal is enabled

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 `

RFR: 8264805: Remove the experimental Ahead-of-Time Compiler

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

Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v2]

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

Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v3]

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

Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]

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

Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]

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

Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]

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

Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]

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

Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]

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

Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]

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

RFR: 8264806: Remove the experimental JIT compiler

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

Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]

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

Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]

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

Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]

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

Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]

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

Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]

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

Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]

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

Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]

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.

Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v5]

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 -

Re: RFR: 8264806: Remove the experimental JIT compiler [v2]

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

Re: RFR: 8264806: Remove the experimental JIT compiler

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` —

Re: RFR: 8264806: Remove the experimental JIT compiler [v2]

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

Re: RFR: 8264806: Remove the experimental JIT compiler [v2]

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

Re: RFR: 8264806: Remove the experimental JIT compiler [v2]

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

Re: RFR: 8264806: Remove the experimental JIT compiler [v2]

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

Re: RFR: 8264806: Remove the experimental JIT compiler [v3]

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. > >

Re: RFR: 8264806: Remove the experimental JIT compiler [v2]

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

Re: RFR: 8264806: Remove the experimental JIT compiler [v2]

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(). >

Re: RFR: 8252600: remove mx configuration [v2]

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 pre

Re: RFR: 8265403: consolidate definition of CPU features [v3]

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 upd

Re: RFR: 8265403: consolidate definition of CPU features [v3]

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 >>> CPU_FEA

Re: RFR: 8265403: consolidate definition of CPU features [v4]

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 upd

Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v6]

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

Integrated: 8264805: Remove the experimental Ahead-of-Time Compiler

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

Re: RFR: 8264806: Remove the experimental JIT compiler [v4]

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. > &

Re: RFR: 8264806: Remove the experimental JIT compiler [v5]

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. > &

Integrated: 8264806: Remove the experimental JIT compiler

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` —

RFR: 8267112: JVMCI compiler modules should be kept upgradable

[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 referen

Re: RFR: 8267112: JVMCI compiler modules should be kept upgradable

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

Re: RFR: 8267112: JVMCI compiler modules should be kept upgradable

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

Re: RFR: 8267112: JVMCI compiler modules should be kept upgradable

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

Integrated: 8267112: JVMCI compiler modules should be kept upgradable

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

Re: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v4]

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

Re: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v7]

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

Re: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v8]

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

RFR: 8268272: Remove JDK-8264874 changes because Graal was removed.

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. Chang

Integrated: 8268272: Remove JDK-8264874 changes because Graal was removed.

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

Re: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 [v7]

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 >

Re: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 [v7]

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 >

Re: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 [v7]

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 >

Re: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 [v8]

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 >

Re: RFR: 8273459: Update code segment alignment to 64 bytes

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 imp

Re: RFR: 8273459: Update code segment alignment to 64 bytes

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 imp

Re: RFR: 8273459: Update code segment alignment to 64 bytes [v2]

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 whil

Re: RFR: 8273459: Update code segment alignment to 64 bytes [v2]

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: /src/utils/LogCompi

Re: RFR: 8273459: Update code segment alignment to 64 bytes

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 whil

Re: RFR: 8273459: Update code segment alignment to 64 bytes [v4]

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 whil

Re: RFR: 8273459: Update code segment alignment to 64 bytes [v4]

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 whil

Re: RFR: 8274329: Fix non-portable HotSpot code in MethodMatcher::parse_method_pattern

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 > e:\jie

Re: RFR: 8274329: Fix non-portable HotSpot code in MethodMatcher::parse_method_pattern

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 > e:\jie

Re: RFR: 8274329: Fix non-portable HotSpot code in MethodMatcher::parse_method_pattern [v3]

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 >>

Re: RFR: 8274329: Fix non-portable HotSpot code in MethodMatcher::parse_method_pattern [v3]

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 >>

Re: RFR: 8276025: Hotspot's libsvml.so may conflict with user dependency

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 a

Re: RFR: 8276025: Hotspot's libsvml.so may conflict with user dependency

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 a

Re: RFR: 8276025: Hotspot's libsvml.so may conflict with user dependency [v2]

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 stubGenerator_x86_64.c

Re: RFR: 8276025: Hotspot's libsvml.so may conflict with user dependency [v2]

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 stubGenerator_x86_64.c

Re: RFR: 8276025: Hotspot's libsvml.so may conflict with user dependency [v2]

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

Re: RFR: 8280182: HotSpot Style Guide has stale link to chromium style guide

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

Re: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v3]

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

Re: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v3]

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

Re: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v4]

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

Re: RFR: 8171853: Remove Shark compiler

+1 Thanks, Vladimir On 10/15/17 3:08 PM, David Holmes wrote: Looks good. Thanks, David On 16/10/2017 8:00 AM, Roman Kennke wrote: Ok, I fixed all the comments you mentioned. Differential (against webrev.01): http://cr.openjdk.java.net/~rkennke/8171853/webrev.03.diff/

Re: RFR(XXXS): 8193407: jdk/hs fails Solaris slowdebug test-image build

Reviewed. Looks good. Thanks, Vladimir On 12/12/17 6:16 PM, David Holmes wrote: Hi Dan, On 13/12/2017 12:13 PM, Daniel D. Daugherty wrote: Greetings, I have a 1-liner fix to solve a Solaris slowdebug test-image build problem: JDK-8193407 jdk/hs fails Solaris slowdebug test-image build

Re: RFR: JDK-8187676: Disable uninitialized warnings for two files until proper fix available

Good. Thanks, Vladimir K On 2/9/18 8:37 AM, Erik Joelsson wrote: Hello, In preparation for upgrading the toolchains used at Oracle, we need the build to be clean with the new compiler versions. On Linux, we are currently aiming at GCC 7.3. In hotspot, two files generate warnings when using th

[11] RFR(M) 8197235: src/hotspot/share/jvmci/jvmciCompilerToVM.cpp takes 4 minutes to compile on windows

http://cr.openjdk.java.net/~kvn/8197235/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8197235 To avoid long compilation time of jvmciCompilerToVM.cpp I moved most expensive methods to new file jvmciCompilerToVMInit.cpp and switch off C++ compiler optimization for it on Windows and Solaris

Re: [11] RFR(M) 8197235: src/hotspot/share/jvmci/jvmciCompilerToVM.cpp takes 4 minutes to compile on windows

Thank you, Eric Vladimir K On 3/7/18 3:58 PM, Erik Joelsson wrote: Looks good to me. Thanks for fixing this! /Erik On 2018-03-07 15:23, Vladimir Kozlov wrote: http://cr.openjdk.java.net/~kvn/8197235/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8197235 To avoid long compilation time

Re: [11] RFR(XS) 8199896: [Graal] build Graal on all x86 platforms

Forgot to CC to build-dev. Note, this change does not have effect unless you disable AOT build. We are already building Graal on all x64 platforms as part of AOT build currently. Vladimir On 3/20/18 6:15 PM, Vladimir Kozlov wrote: https://bugs.openjdk.java.net/browse/JDK-8199896 Extend

Re: [11] RFR(XS) 8199896: [Graal] build Graal on all x86 platforms

Thank you, Erik Vladimir On 3/22/18 7:07 AM, Erik Joelsson wrote: Looks good. /Erik On 2018-03-21 18:04, Vladimir Kozlov wrote: Forgot to CC to build-dev. Note, this change does not have effect unless you disable AOT build. We are already building Graal on all x64 platforms as part of

[11] RFR(S) 8200383: Can't build on SPARC Hotspot with code which use math functions

http://cr.openjdk.java.net/~kvn/8200383/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8200383 Changes for JDK-8200303 added calls to log2f() math function and it hit problem building Hotspot on SPARC - it can't find this function. For Hotspot build on Solaris we had hack to support old S

Re: [11] RFR(S) 8200383: Can't build on SPARC Hotspot with code which use math functions

Thank you, Erik Vladimir On 3/28/18 2:10 PM, Erik Joelsson wrote: Looks good. /Erik On 2018-03-28 14:01, Vladimir Kozlov wrote: http://cr.openjdk.java.net/~kvn/8200383/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8200383 Changes for JDK-8200303 added calls to log2f() math function

Re: [11] RFR(S) 8200383: Can't build on SPARC Hotspot with code which use math functions

On 3/28/18 2:51 PM, Magnus Ihse Bursie wrote: On 2018-03-28 23:01, Vladimir Kozlov wrote: http://cr.openjdk.java.net/~kvn/8200383/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8200383 Changes for JDK-8200303 added calls to log2f() math function and it hit problem building Hotspot on

Re: [11] RFR(S) 8200383: Can't build on SPARC Hotspot with code which use math functions

Thank you. I will use second version and do testing again before push. Vladimir On 3/28/18 3:50 PM, Magnus Ihse Bursie wrote: On 2018-03-29 00:48, Erik Joelsson wrote: On 2018-03-28 15:35, Vladimir Kozlov wrote: Based on history it was done for 6307603 in 2010 and reason is the same

Re: RFR(XL): 8199712: Flight Recorder

-lkstat was also used to determine SPARC CPU features as I remember. Vladimir On 4/26/18 9:03 AM, Erik Joelsson wrote: Should linking to the -lkstat library be conditional on jfr feature being set, or perhaps it doesn't matter that much. In that case, adding the library could be done in JvmFea

Re: RFR(L) : 8199375 : [TESTBUG] Open source vm testbase monitoring tests

Igor, Why you need to list each test in TEST.groups and not just directory as we do in other cases? Thanks, Vladimir On 5/1/18 7:10 PM, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html 41276 lines changed: 41274 ins; 1 del; 1 mod; Hi all, could you

Re: RFR(L) : 8199375 : [TESTBUG] Open source vm testbase monitoring tests

all tests from the directory. We use this group in some of our test configurations, and :vmTestbase_nsk_monitoring in others. vmTestbase_nsk_monitoring is defined by the directory as other groups. Thanks, — Igor On May 1, 2018, at 7:54 PM, Vladimir Kozlov wrote: Igor, Why you need to list

Re: RFR(L) : 8199375 : [TESTBUG] Open source vm testbase monitoring tests

open sourced as it might create unneeded complications w/ test execution. I'll file an RFE to not forget about it. Yes, this sounds good. Reviewed. Thanks, Vladimir Thanks, -- Igor On May 2, 2018, at 10:59 AM, Vladimir Kozlov wrote: I wish we have ability to include other files wi

[11] RFR(S) 8202552: [AOT][JVMCI] Incorrect usage of INCLUDE_JVMCI and INCLUDE_AOT

http://cr.openjdk.java.net/~kvn/8202552/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8202552 Stefan K. found several places where #ifdef instead of #if is used for INCLUDE_JVMCI. I also found places where we can use COMPILER2_OR_JVMCI. An other problem surprised me that we don't set INC

Re: [11] RFR(S) 8202552: [AOT][JVMCI] Incorrect usage of INCLUDE_JVMCI and INCLUDE_AOT

Thank you, Stefan Vladimir K On 5/3/18 12:20 AM, Stefan Karlsson wrote: Looks good to me. Thanks for fixing. StefanK On 2018-05-03 00:13, Vladimir Kozlov wrote: http://cr.openjdk.java.net/~kvn/8202552/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8202552 Stefan K. found several

  1   2   3   >