Re: RFR: 8275874: [JVMCI] use volatile accessors for aligned reads in c2v_readFieldValue

On Tue, 26 Oct 2021 05:20:22 GMT, David Holmes wrote: > Isn't the title of this issue expressed incorrectly? Yes - thanks for pointing that out. - PR: https://git.openjdk.java.net/jdk/pull/6109

Re: RFR: 8275874: [JVMCI] use volatile accessors for all unaligned reads in c2v_readFieldValue

On Mon, 25 Oct 2021 14:33:27 GMT, Doug Simon wrote: > [JDK-8275645](https://bugs.openjdk.java.net/browse/JDK-8275645) resulted in > loosing single-copy atomicity for reads in `c2v_readFieldValue`. This PR > fixes that by using `_field_acquire` accessors for all aligned reads > an

RFR: 8275874: [JVMCI] use volatile accessors for all unaligned reads in c2v_readFieldValue

[JDK-8275645](https://bugs.openjdk.java.net/browse/JDK-8275645), resulted in the loose of single-copy atomicity for reads in c2v_readFieldValue. This PR fixes that by using the `_field_acquire` accessors for all aligned reads in c2v_readFieldValue and only using the `_field` accessors for

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

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

On Tue, 27 Apr 2021 19:07:45 GMT, Igor Ignatyev wrote: > > I guess this should really be named `isJVMCICompilerEnabled` now and the > > `vm.graal.enabled` predicate renamed to `vm.jvmcicompiler.enabled` but > > maybe that's too big a change (or can be done later). > > @dougxc, I don't think

Integrated: 8265403: consolidate definition of CPU features

On Sat, 17 Apr 2021 20:18:31 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

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

On Mon, 19 Apr 2021 20:01:46 GMT, Vladimir Kozlov wrote: >> Doug Simon has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - updated date in copyright >> - added blank lines after macros > > You need re

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

ith a single macro that is > used to generate enum declarations as well as vmstructs entries. > > In addition, the JVMCI API is updated to exposes the new CPU feature > constants and now has a check that ensure these constants are in sync with > the underlying macro definiti

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

On Mon, 19 Apr 2021 19:00:09 GMT, Vladimir Kozlov wrote: >> Doug Simon 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. The pull request co

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

On Mon, 19 Apr 2021 18:58:46 GMT, Vladimir Kozlov wrote: >> Doug Simon 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. The pull request co

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

On Mon, 19 Apr 2021 18:57:37 GMT, Vladimir Kozlov wrote: >> Doug Simon 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. The pull request co

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

On Sun, 18 Apr 2021 07:32:07 GMT, Alan Bateman 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. > > Are you sure it make sense to have this dev config in the

Integrated: 8252600: [JVMCI] remove mx configuration

On Sat, 17 Apr 2021 20:37:08 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. This pull request has now been integrated. Changeset: 54cb38

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

ith a single macro that is > used to generate enum declarations as well as vmstructs entries. > > In addition, the JVMCI API is updated to exposes the new CPU feature > constants and now has a check that ensure these constants are in sync with > the underlying macro definition

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

ith a single macro that is > used to generate enum declarations as well as vmstructs entries. > > In addition, the JVMCI API is updated to exposes the new CPU feature > constants and now has a check that ensure these constants are in sync with > the underlying macro definiti

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 conte

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

> This PR updates the configuration files used to develop the JVMCI Java and > C++ sources with mx and Eclipse. Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous c

RFR: 8265403: consolidate definition of CPU features

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 updates x86 and AArch64 to define CPU features with a single macro

Re: RFR: 8265403: consolidate definition of CPU features

On Sat, 17 Apr 2021 20:18:31 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

Re: RFR: 8252600: [JVMCI] update JVMCI code style and mx configuration

On Sat, 17 Apr 2021 20:37:08 GMT, Doug Simon wrote: > This PR updates the configuration files used to develop the JVMCI Java and > C++ sources with mx and Eclipse. Until we have downstream repos for JDK 17, it's very handy to have this config in the JDK. I've tried to keep it only in

RFR: 8252600: [JVMCI] update JVMCI code style and mx configuration

This PR updates the configuration files used to develop the JVMCI Java and C++ sources with mx and Eclipse. - Commit messages: - 8252600: [JVMCI] update JVMCI code style and mx configuration Changes: https://git.openjdk.java.net/jdk/pull/3559/files Webrev:

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

On Mon, 12 Apr 2021 22:10:06 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` — Graal's

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 Sat, 10 Apr 2021 17:41:05 GMT, Vladimir Kozlov wrote: >> Marked as reviewed by iignatyev (Reviewer). > > Thank you, Igor. I filed https://bugs.openjdk.java.net/browse/JDK-8265032 We would definitely like to be able to continue testing of GraalVM with the JDK set of jtreg tests. So keeping

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. This pull request has now been integrated. Changeset: 29c72631 Author:

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

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. - Commit messages: - 8252709: Enable JVMCI when building linux-aarch64 at Oracle Changes:

Re: RFR: 8254827: JVMCI: Enable it for Windows+AArch64

On Thu, 15 Oct 2020 15:00:47 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

Re: RFR(XS): 8244061: Disable jvmci/graal/aot when building linux-aarch64 at Oracle

Ok, thanks for the clarification. I wasn’t sure if external parties had managed to set up a jib server but it sounds like that’s not so easy in practice. -Doug > On 29 Apr 2020, at 11:02, Magnus Ihse Bursie > wrote: > > On 2020-04-29 10:45, Doug Simon wrote: >> If I un

Re: RFR(XS): 8244061: Disable jvmci/graal/aot when building linux-aarch64 at Oracle

If I understand correctly, this disables building jvmci/graal/aot in *any* linux-aarch64 jib based build, not just those done at Oracle. Wouldn’t this be better done on the jib command line? -Doug > On 29 Apr 2020, at 06:12, Mikael Vidstedt wrote: > > > Please review this small change which

Re: RFR(S) 8205078: [Graal] org.graalvm.compiler.core.test.VerifyDebugUsageTest fails with "Expected exception: VerificationError"

> On 7 Aug 2018, at 08:07, Ekaterina Pavlova > wrote: > > Vladimir, thanks for prompt review. > > I can revert the changes and add -XDstringConcat=inline to JAVAC flags for > all tests. > I did it only for org/graalvm/compiler/core/test/VerifyDebugUsageTest.java > because > Doug was not

Re: RFR(M): 8205207: Port Graal unit tests under jtreg

> On 22 Jun 2018, at 23:29, Doug Simon wrote: > > > >> On 22 Jun 2018, at 23:16, Ekaterina Pavlova >> wrote: >> >> Erik, Doug, >> >> thank you a lot for your reviews and advises. >> I fixed everything what Erik has pointed out,

Re: RFR(M): 8205207: Port Graal unit tests under jtreg

> On 22 Jun 2018, at 23:16, Ekaterina Pavlova > wrote: > > Erik, Doug, > > thank you a lot for your reviews and advises. > I fixed everything what Erik has pointed out, please see my answers inlined. > As about moving more staff in 'updategraalinopenjdk' can we consider this as > next

Re: RFR(M): 8205207: Port Graal unit tests under jtreg

> On 19 Jun 2018, at 23:00, Erik Joelsson wrote: > > Hello, > > Please always include build-dev when reviewing build changes. > > In general this looks pretty good but there are some details that need fixing. > > (Aside from this particular review, I must state my reservation against all

Re: (10) (M) RFR: 8174231: Factor out and share PlatformEvent and Parker code for POSIX systems

> On 19 May 2017, at 11:15, Magnus Ihse Bursie > wrote: > > > On 2017-05-19 09:15, David Holmes wrote: >> Hi Magnus, >> >> On 18/05/2017 8:06 PM, Magnus Ihse Bursie wrote: >>> >>> >>> On 2017-05-18 09:35, David Holmes wrote: On 18/05/2017 5:32 PM, Magnus

Re: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci

sion of Graal will no longer benefit from the qualified exports of JVMCI to jdk.vm.compiler. -Doug > On 2/16/17 2:01 AM, Doug Simon wrote: >> Just to note here, this means an external version of Graal will now have to >> use --add-exports VM options to access JVMCI. Which is ok s

Re: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci

Just to note here, this means an external version of Graal will now have to use --add-exports VM options to access JVMCI. Which is ok since additional VM options are required anyway to put an external Graal on the module path. -Doug > On 16 Feb 2017, at 08:54, Magnus Ihse Bursie

Re: RFR: JDK-8172548 unpack200 fails linking with new update of SS12u4

> On 2 Feb 2017, at 13:07, Magnus Ihse Bursie > wrote: > > When building with Solaris Studio 12u4, linking of unpack200 fails. The fix > is to include "environ" in the mapfile. > > This patch is contributed by Douglas Simon. For full disclosure, the original

Re: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT compiler

> On 9 Dec 2016, at 08:07, Vladimir Kozlov wrote: > > Thank you, Mandy > > On 12/8/16 7:46 PM, Mandy Chung wrote: >> >>> On Dec 7, 2016, at 2:10 PM, Vladimir Kozlov >>> wrote: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8166417

Re: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT compiler

> On 8 Dec 2016, at 13:50, Magnus Ihse Bursie > wrote: > > On 2016-12-07 23:10, Vladimir Kozlov wrote: >> https://bugs.openjdk.java.net/browse/JDK-8166417 >> >> It is part of JEP 295: Ahead-of-Time Compilation >> https://bugs.openjdk.java.net/browse/JDK-8166089

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

> On 27 Oct 2016, at 20:12, Vladimir Kozlov wrote: > > On 10/27/16 10:55 AM, Christian Thalinger wrote: >> >>> On Oct 27, 2016, at 2:40 AM, Erik Joelsson wrote: >>> >>> >>> >>> On 2016-10-27 02:45, Vladimir Kozlov wrote: AOT JEP:

Re: [9] RFR (xs) 8168317: [JVMCI] use reflection instead of jdk 9 Module API in Services.java

> On 24 Oct 2016, at 23:24, Christian Thalinger wrote: > > >> On Oct 24, 2016, at 3:48 AM, Erik Joelsson wrote: >> >> Adding build-dev, which should be included when discussing build issues. For >> any new readers, please see [1] for the

Re: Setting/overriding HOTSPOT_VERSION_STRING

th-version-security Set version 'SECURITY' field (third number) [current > --with-version-patchSet version 'PATCH' field (fourth number) [not > > Regards, > Volker > > PS: the correct list for build related questions is build-dev. > build-infra-dev was for the devel

Re: code review round 0 for minor FDS makefile fix (8033714)

wrote: This code review request is going to three different aliases. Don't use Thunderbird's reply to list option since it will pick just _one_ of the _three_ lists. Greetings, Doug Simon and Tom Rodriguez have sent a Full Debug Symbols (FDS) makefile fix our way. Here are the bug