Re: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209)
On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote:
> Please review this small patch to enable the OSX build using Xcode 12.0.
>
> Thanks,
> Paul
No, don't do this. In the original, double is used to obtain the desired
alignmnent. Changing the element type to short reduces the alignment
requirement for the variable. initialize_shared_locs will then adjust the
alignment, potentially shrinking the effective array size. So this is a
real change that I think shouldn't be made.
I think changing the declaration for locs_buf to any of the following gives
equivalent behavior to the current code. I don't know whether any of them
will trigger the new clang warning though. I don't have access to that
version right now, and the documentation for the warning is useless (like so
much of clang's warning options documentation).
(1) alignas(double) char locs_buf[20 * sizeof(double)];
(but alignas is not yet in the "permitted features" list in the Style Guide:
https://bugs.openjdk.java.net/browse/JDK-8252584)
(2) union { char locs_buf[20 * sizeof(double)]; double align; };
(3) std::aligned_storage_t<20 * sizeof(double)> locs_buf;
and change (relocInfo*)locs_buf => (relocInfo*)_buf
and #include
This has the benefit of being explicit that we're just stack allocating a
block of storage.
I'll make a wild guess that (1) and (2) will still warn, though char arrays
are somewhat special in the language so maybe they won't. I'm pretty sure
(3) should do the trick.
-
Changes requested by kbarrett (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/348
Integrated: 8235710: Remove the legacy elliptic curves
On Mon, 21 Sep 2020 21:10:58 GMT, Anthony Scarpino wrote: > This change removes the native elliptic curves library code; as well as, and > calls to that code, tests, and files > associated with those libraries. The makefiles have been changed to remove > from all source builds of the ec code. The > SunEC system property is removed and java.security configurations changed to > reflect the removed curves. This will > remove the following elliptic curves from SunEC: secp112r1, secp112r2, > secp128r1, secp128r2, secp160k1, secp160r1, > secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, > sect113r2, sect131r1, sect131r2, > sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, > sect239k1, sect283k1, sect283r1, > sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 > c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, > X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 > prime192v2, X9.62 prime192v3, X9.62 > prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 > brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 This pull request has now been integrated. Changeset: 0b83fc01 Author:Anthony Scarpino URL: https://git.openjdk.java.net/jdk/commit/0b83fc01 Stats: 20155 lines in 77 files changed: 28 ins; 20048 del; 79 mod 8235710: Remove the legacy elliptic curves Reviewed-by: xuelei, erikj - PR: https://git.openjdk.java.net/jdk/pull/289
Re: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209)
On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote:
> Please review this small patch to enable the OSX build using Xcode 12.0.
>
> Thanks,
> Paul
Changes requested by dholmes (Reviewer).
src/hotspot/share/runtime/sharedRuntime.cpp line 2851:
> 2849: if (buf != NULL) {
> 2850: CodeBuffer buffer(buf);
> 2851: short locs_buf[80];
This code is just weird. Why is the buf array not declared to be the desired
type? If the compiler rejects double
because it isn't relocInfo* then why does it accept short? And if it accepts
short will it accept int or long long or
int64_t? Using int64_t would be a clearer change. Though semantically this code
is awful. :( Should it be intptr_t ?
-
PR: https://git.openjdk.java.net/jdk/pull/348
Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6]
Hi Chris, Monica, On 25/09/2020 1:47 am, Chris Plummer wrote: As for the copyright in the new SA files, I believe it is incorrect and needs to include Oracle. There are a number of other non-SA files that are new and also have the same copyright issue. If a file was created completely from scratch then it should just have the Microsoft copyright notice. However, if it was copied from an existing file and modified, then the existing file's copyright should be included and a Microsoft one added if the changes are significant. But IANAL. :) Cheers, David I also looked at src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java. It looks fine except it needs a copyright date update. - Changes requested by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/212
Integrated: 8253615: Change to Visual Studio 2019 16.7.2 for building on Windows at Oracle
On Thu, 24 Sep 2020 20:25:27 GMT, Erik Joelsson wrote: > Oracle is changing the minor version of Visual Studio used for building the > JDK on Windows. This patch updates the jib > profiles configuration to point to the new devkit. This pull request has now been integrated. Changeset: 24a42489 Author:Erik Joelsson URL: https://git.openjdk.java.net/jdk/commit/24a42489 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod 8253615: Change to Visual Studio 2019 16.7.2 for building on Windows at Oracle Reviewed-by: mikael - PR: https://git.openjdk.java.net/jdk/pull/346
Re: RFR: 8253616: Change to GCC 10.2 for building on Linux at Oracle
On Thu, 24 Sep 2020 21:31:49 GMT, Mikael Vidstedt wrote: > Please review this change which updates the defaults in the linux devkit > creator, the doc/building.md file, and the JIB > (Oracle) configuration to gcc 10.2. Marked as reviewed by erikj (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/349
Re: RFR: 8253615: Change to Visual Studio 2019 16.7.2 for building on Windows at Oracle [v2]
On Thu, 24 Sep 2020 22:20:47 GMT, Erik Joelsson wrote: >> Oracle is changing the minor version of Visual Studio used for building the >> JDK on Windows. This patch updates the jib >> profiles configuration to point to the new devkit. > > Erik Joelsson has updated the pull request incrementally with one additional > commit since the last revision: > > Update build docs Marked as reviewed by mikael (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/346
Re: RFR: 8253615: Change to Visual Studio 2019 16.7.2 for building on Windows at Oracle [v2]
> Oracle is changing the minor version of Visual Studio used for building the > JDK on Windows. This patch updates the jib > profiles configuration to point to the new devkit. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Update build docs - Changes: - all: https://git.openjdk.java.net/jdk/pull/346/files - new: https://git.openjdk.java.net/jdk/pull/346/files/e77d322b..759c8070 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=346=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=346=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/346.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/346/head:pull/346 PR: https://git.openjdk.java.net/jdk/pull/346
Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6]
On Thu, 24 Sep 2020 15:43:10 GMT, Chris Plummer wrote: >> Monica Beckwith has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev >> excludes the unrelated changes brought in by the merge/rebase. The pull >> request contains 17 additional commits since >> the last revision: >> - cleanup for 8253539: Remove unused JavaThread functions for >> set_last_Java_fp/pc >> - cleanup for 8253457: Remove unimplemented register stack functions >> - Merge remote-tracking branch 'upstream/master' into jdk-windows >> - Update orderAccess_windows_aarch64.hpp >> >>changing from Acq-reL to Sequential Consistency to avoid compiler >> reordering when no ordering hints are provided >> - 8248787: G1: Workaround MSVC bug >>Reviewed-by: >>Contributed-by: mbeckwit, luhenry, burban >> - 8248670: Windows: Exception handling support on AArch64 >>Reviewed-by: >>Contributed-by: mbeckwit, luhenry, burban >> - 8248660: AArch64: Make _clear_cache and _nop portable >>Summary: __builtin___clear_cache, etc. >>Contributed-by: mbeckwit, luhenry, burban >> - 8248659: AArch64: Extend CPU Feature detection >>Reviewed-by: >>Contributed-by: mbeckwit, luhenry, burban >> - 8248656: Add Windows AArch64 platform support code >>Reviewed-by: >>Contributed-by: mbeckwit, luhenry, burban >> - 8248498: Add build system support for Windows AArch64 >>Reviewed-by: >>Contributed-by: mbeckwit, luhenry, burban >> - ... and 7 more: >> https://git.openjdk.java.net/jdk/compare/6fea1339...2b662010 > > I looked at changes to existing SA files. These changes look fine. > > I did not look at the new aarch64 SA files other than the copyright section. > I assume they are clones of the x64 > versions with some symbolic renaming. If there is any more than that and > you'd like me to have a look, let me know. > As for the copyright in the new SA files, I believe it is incorrect and needs > to include Oracle. There are a number of > other non-SA files that are new and also have the same copyright issue. > I also looked at > src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java. It > looks fine except it needs > a copyright date update. @dholmes-ora, makes sense. I will do the needful. Thanks. > @mo-beck This PR should not be associated with any JBS issues which are > targeted at repo-aarch64-port. All such issues > should have been closed by now when the associated code was pushed to > aarch64-port repo. That was the whole point of > creating separate issues so that they could be tracked in the porting repo. > Now that all of that work should be > complete the only issue that should remain open in relation to the > Windows-Aarch64 port is JDK-8248238. Thanks. - PR: https://git.openjdk.java.net/jdk/pull/212
Re: RFR: 8235710: Remove the legacy elliptic curves [v3]
On Thu, 24 Sep 2020 21:37:14 GMT, Weijun Wang wrote: >> jdk.disabled.namedCurves is commented out and I don't think it's good for >> every operation disabled algorithms call to >> check an empty property. The description for the disabledAlgorithm >> properties say you have to use "include", so I >> don't think it is necessary to we keep it active.. > > I just think this is an unnecessary behavior change. After all, the purpose > of `jdk.disabled.namedCurves` is to be > included in other disabledAlgorithms properties. > No strong opinion on this. Please decide yourself. I understand what you are saying. The property only existed because there were so many curves that would have overwhelmed the disabledAlgorithms. I also don't like making this a permanent addition to the disabledAlgorithm properties. It's possible we may remove the property in the future as it's likely unnecessary going forward. - PR: https://git.openjdk.java.net/jdk/pull/289
Re: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209)
On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > Please review this small patch to enable the OSX build using Xcode 12.0. > > Thanks, > Paul The awt change looks fine although it would be nice if you could paste the compiler error message into the bug report, since I'd like to see the compiler's reason why this is ambiguous today and not before - assuming that is the issue. - Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/348
Re: RFR: 8235710: Remove the legacy elliptic curves [v3]
On Thu, 24 Sep 2020 21:15:34 GMT, Anthony Scarpino wrote: >> src/java.base/share/conf/security/java.security line 636: >> >>> 634: # >>> 635: jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage >>> TLSServer, \ >>> 636: RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224 >> >> `jdk.disabled.namedCurves` still exists. If someone decides to add a curve >> there, shouldn't it be also disabled here? > > jdk.disabled.namedCurves is commented out and I don't think it's good for > every operation disabled algorithms call to > check an empty property. The description for the disabledAlgorithm > properties say you have to use "include", so I > don't think it is necessary to we keep it active.. I just think this is an unnecessary behavior change. After all, the purpose of `jdk.disabled.namedCurves` is to be included in other disabledAlgorithms properties. No strong opinion on this. Please decide yourself. - PR: https://git.openjdk.java.net/jdk/pull/289
RFR: 8253616: Change to GCC 10.2 for building on Linux at Oracle
Please review this change which updates the defaults in the linux devkit creator, the doc/building.md file, and the JIB (Oracle) configuration to gcc 10.2. - Commit messages: - 8253616: Change to GCC 10.2 for building on Linux at Oracle Changes: https://git.openjdk.java.net/jdk/pull/349/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=349=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253616 Stats: 33 lines in 4 files changed: 20 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/349.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/349/head:pull/349 PR: https://git.openjdk.java.net/jdk/pull/349
RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209)
Please review this small patch to enable the OSX build using Xcode 12.0. Thanks, Paul - Commit messages: - JDK-8253375 Changes: https://git.openjdk.java.net/jdk/pull/348/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=348=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253375 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/348.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/348/head:pull/348 PR: https://git.openjdk.java.net/jdk/pull/348
Re: RFR: 8253615: Change to Visual Studio 2019 16.7.2 for building on Windows at Oracle
On Thu, 24 Sep 2020 20:25:27 GMT, Erik Joelsson wrote:
> Oracle is changing the minor version of Visual Studio used for building the
> JDK on Windows. This patch updates the jib
> profiles configuration to point to the new devkit.
Do you want to update doc/building.{md,html} to reflect the change at Oracle as
well?
-
PR: https://git.openjdk.java.net/jdk/pull/346
Re: RFR: 8235710: Remove the legacy elliptic curves [v3]
On Thu, 24 Sep 2020 19:48:45 GMT, Weijun Wang wrote: >> Anthony Scarpino has updated the pull request incrementally with one >> additional commit since the last revision: >> >> change exception for ec keyagreement >> fix supportedcurves in SunEC > > src/java.base/share/conf/security/java.security line 636: > >> 634: # >> 635: jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, >> \ >> 636: RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224 > > `jdk.disabled.namedCurves` still exists. If someone decides to add a curve > there, shouldn't it be also disabled here? jdk.disabled.namedCurves is commented out and I don't think it's good for every operation disabled algorithms call to check an empty property. The description for the disabledAlgorithm properties say you have to use "include", so I don't think it is necessary to we keep it active.. - PR: https://git.openjdk.java.net/jdk/pull/289
Re: RFR: 8235710: Remove the legacy elliptic curves [v3]
On Wed, 23 Sep 2020 23:38:03 GMT, Anthony Scarpino wrote: >> This change removes the native elliptic curves library code; as well as, and >> calls to that code, tests, and files >> associated with those libraries. The makefiles have been changed to remove >> from all source builds of the ec code. The >> SunEC system property is removed and java.security configurations changed to >> reflect the removed curves. This will >> remove the following elliptic curves from SunEC: secp112r1, secp112r2, >> secp128r1, secp128r2, secp160k1, secp160r1, >> secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, >> sect113r2, sect131r1, sect131r2, >> sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, >> sect239k1, sect283k1, sect283r1, >> sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 >> c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, >> X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, >> X9.62 prime192v2, X9.62 prime192v3, X9.62 >> prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 >> brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 > > Anthony Scarpino has updated the pull request incrementally with one > additional commit since the last revision: > > change exception for ec keyagreement > fix supportedcurves in SunEC src/java.base/share/conf/security/java.security line 636: > 634: # > 635: jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \ > 636: RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224 `jdk.disabled.namedCurves` still exists. If someone decides to add a curve there, shouldn't it be also disabled here? - PR: https://git.openjdk.java.net/jdk/pull/289
RFR: 8253615: Change to Visual Studio 2019 16.7.2 for building on Windows at Oracle
Oracle is changing the minor version of Visual Studio used for building the JDK on Windows. This patch updates the jib profiles configuration to point to the new devkit. - Commit messages: - Bump VS version in jib-profiles Changes: https://git.openjdk.java.net/jdk/pull/346/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=346=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253615 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/346.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/346/head:pull/346 PR: https://git.openjdk.java.net/jdk/pull/346
Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6]
On Thu, 24 Sep 2020 14:04:22 GMT, Monica Beckwith wrote: >> This is a continuation of >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >> * The define-guards around R18 have been changed to `R18_RESERVED`. This >> will be enabled for Windows only for now but >> will be required for the upcoming macOS+Aarch64 [2] port as well. >> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov >> in our PR for now and built the >> Windows-specific CPU feature detection on top of it. >> >> [1] >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html >> [2] https://openjdk.java.net/jeps/8251280 > > Monica Beckwith has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull > request contains 17 additional commits since > the last revision: > - cleanup for 8253539: Remove unused JavaThread functions for > set_last_Java_fp/pc > - cleanup for 8253457: Remove unimplemented register stack functions > - Merge remote-tracking branch 'upstream/master' into jdk-windows > - Update orderAccess_windows_aarch64.hpp > >changing from Acq-reL to Sequential Consistency to avoid compiler > reordering when no ordering hints are provided > - 8248787: G1: Workaround MSVC bug >Reviewed-by: >Contributed-by: mbeckwit, luhenry, burban > - 8248670: Windows: Exception handling support on AArch64 >Reviewed-by: >Contributed-by: mbeckwit, luhenry, burban > - 8248660: AArch64: Make _clear_cache and _nop portable >Summary: __builtin___clear_cache, etc. >Contributed-by: mbeckwit, luhenry, burban > - 8248659: AArch64: Extend CPU Feature detection >Reviewed-by: >Contributed-by: mbeckwit, luhenry, burban > - 8248656: Add Windows AArch64 platform support code >Reviewed-by: >Contributed-by: mbeckwit, luhenry, burban > - 8248498: Add build system support for Windows AArch64 >Reviewed-by: >Contributed-by: mbeckwit, luhenry, burban > - ... and 7 more: > https://git.openjdk.java.net/jdk/compare/ddd43bee...2b662010 I looked at changes to existing SA files. These changes look fine. I did not look at the new aarch64 SA files other than the copyright section. I assume they are clones of the x64 versions with some symbolic renaming. If there is any more than that and you'd like me to have a look, let me know. As for the copyright in the new SA files, I believe it is incorrect and needs to include Oracle. There are a number of other non-SA files that are new and also have the same copyright issue. I also looked at src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java. It looks fine except it needs a copyright date update. - Changes requested by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/212
Integrated: 8253500: [REDO] JDK-8253208 Move CDS related code to a separate class
On Wed, 23 Sep 2020 23:05:59 GMT, Yumin Qi wrote: > This patch is a REDO for JDK-8253208 which was backed out since it caused > runtime/cds/DeterministicDump.java failed, > see JDK-8253495. Since the failure is another issue and only triggered by > this patch, the test case now is put on > ProblemList.txt. The real root cause for the failure is detailed in > JDK-8253495. When JDK-8253208 was backed out, > CDS.java remained without removed from that patch (see JDK-8253495 subtask), > so this patch does not include CDS.java > (this is why you will see CDS.c without CDS.java in this patch). Tests > tier1-4 passed. This pull request has now been integrated. Changeset: 89c5e49b Author:Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/89c5e49b Stats: 156 lines in 22 files changed: 57 ins; 53 del; 46 mod 8253500: [REDO] JDK-8253208 Move CDS related code to a separate class Reviewed-by: mchung, iklam - PR: https://git.openjdk.java.net/jdk/pull/327
Re: RFR: 8253500: [REDO] JDK-8253208 Move CDS related code to a separate class
On Wed, 23 Sep 2020 23:05:59 GMT, Yumin Qi wrote: > This patch is a REDO for JDK-8253208 which was backed out since it caused > runtime/cds/DeterministicDump.java failed, > see JDK-8253495. Since the failure is another issue and only triggered by > this patch, the test case now is put on > ProblemList.txt. The real root cause for the failure is detailed in > JDK-8253495. When JDK-8253208 was backed out, > CDS.java remained without removed from that patch (see JDK-8253495 subtask), > so this patch does not include CDS.java > (this is why you will see CDS.c without CDS.java in this patch). Tests > tier1-4 passed. Build changes ok. - PR: https://git.openjdk.java.net/jdk/pull/327
Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5]
On Thu, 24 Sep 2020 04:52:22 GMT, David Holmes wrote: >> Monica Beckwith has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update orderAccess_windows_aarch64.hpp >> >> changing from Acq-reL to Sequential Consistency to avoid compiler >> reordering when no ordering hints are provided > > src/hotspot/share/runtime/stubRoutines.cpp line 397: > >> 395: // test safefetch routines >> 396: // Not on Windows 32bit until 8074860 is fixed >> 397: #if ! (defined(_WIN32) && defined(_M_IX86)) && !defined(_M_ARM64) > > The comment needs updating to refer to Aarch64. This is actually not needed anymore, as it does work just fine on Windows+Aarch64. Presumably we have added it in the early days of the port when we haven't figured out exception handling quite yet. Thanks for catching David. - PR: https://git.openjdk.java.net/jdk/pull/212
Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v7]
> This is a continuation of
> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>
> Changes since then:
> * We've improved the write barrier as suggested by Andrew [1]
> * The define-guards around R18 have been changed to `R18_RESERVED`. This will
> be enabled for Windows only for now but
> will be required for the upcoming macOS+Aarch64 [2] port as well.
> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov
> in our PR for now and built the
> Windows-specific CPU feature detection on top of it.
>
> [1]
> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
> [2] https://openjdk.java.net/jeps/8251280
Monica Beckwith has updated the pull request incrementally with two additional
commits since the last revision:
- os_windows: remove duplicated UMA handling
- test_safefetch{32,N} works fine on win+aarch64
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/212/files
- new: https://git.openjdk.java.net/jdk/pull/212/files/2b662010..68f61d60
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk=212=06
- incr: https://webrevs.openjdk.java.net/?repo=jdk=212=05-06
Stats: 22 lines in 2 files changed: 0 ins; 21 del; 1 mod
Patch: https://git.openjdk.java.net/jdk/pull/212.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212
PR: https://git.openjdk.java.net/jdk/pull/212
Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5]
On Thu, 24 Sep 2020 04:45:16 GMT, David Holmes wrote: >> Monica Beckwith has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update orderAccess_windows_aarch64.hpp >> >> changing from Acq-reL to Sequential Consistency to avoid compiler >> reordering when no ordering hints are provided > > src/hotspot/os/windows/os_windows.cpp line 2546: > >> 2544: >> 2545: #ifdef _M_ARM64 >> 2546: // Unsafe memory access > > I'm not at all clear why this unsafe memory access handling is for Aarch64 > only? Hum, this was already part of [JDK-8250810](https://github.com/openjdk/jdk/commit/a4eaf9536c272862b5ec856bf263679be09bddc9) / [JDK-8248817](https://github.com/openjdk/jdk/commit/257809d7440e87ac595d03b6c9a98d8f457f314c) (see a couple lines below in this PR) without the `ifdef` for Aarch64, but I messed up rebasing on top of it. I removed it now, thanks for catching! - PR: https://git.openjdk.java.net/jdk/pull/212
Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6]
> This is a continuation of > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will > be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov > in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 Monica Beckwith has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: - cleanup for 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc - cleanup for 8253457: Remove unimplemented register stack functions - Merge remote-tracking branch 'upstream/master' into jdk-windows - Update orderAccess_windows_aarch64.hpp changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided - 8248787: G1: Workaround MSVC bug Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248670: Windows: Exception handling support on AArch64 Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248660: AArch64: Make _clear_cache and _nop portable Summary: __builtin___clear_cache, etc. Contributed-by: mbeckwit, luhenry, burban - 8248659: AArch64: Extend CPU Feature detection Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248656: Add Windows AArch64 platform support code Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248498: Add build system support for Windows AArch64 Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - ... and 7 more: https://git.openjdk.java.net/jdk/compare/6cee388c...2b662010 - Changes: - all: https://git.openjdk.java.net/jdk/pull/212/files - new: https://git.openjdk.java.net/jdk/pull/212/files/4da7b89e..2b662010 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=212=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk=212=04-05 Stats: 1938 lines in 234 files changed: 652 ins; 841 del; 445 mod Patch: https://git.openjdk.java.net/jdk/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk/pull/212
Re: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions [v4]
> A few days ago I posted an initial version of the necessary configuration > required to run pre-submit build and tests > for JDK main-line contributions using GitHub Actions [2] and the free tier > [3] available to everyone working with open > source repositories. I've incorporated the feedback into an updated version > that I believe is ready to be integrated. > If this is integrated into the `master` branch, future branches created and > updated in personal forks will build and > run the basic tier 1 tests as described in this configuration, on Linux, > Windows and macOS (all on x64). It's of course > possible for any contributor to opt out fully or partially of these automatic > runs in a few different ways. To opt out > completely, a contributor can simply disable GitHub Actions on their personal > fork, and no further jobs will be > executed. Another option is to add a repository secret [4] with the name > `JDK_SUBMIT_FILTER` set to any value. If this > is set, only branches prefixed with `submit/` will be subject to automatic > build and test. This can also be further > refined by adding a repository secret named `JDK_SUBMIT_PLATFORMS` with a > value such as `Linux x64, Windows x64` to > limit automatic build and test to these two platforms. It will still be > possible to run the tests on any branch and/or > platform by manually triggering the workflow. To see what this looks like in > practice, an example run can be found > here: https://github.com/rwestberg/jdk/actions/runs/265131985 (note that > there is currently a failing test on Windows > which is tracked by JDK-8249095, which should probably be resolved before > this change is integrated). Best regards, > Robin [1] > https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2] > https://github.com/features/actions [3] > https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits > [4] > https://docs.github.com/en/actions/reference/encrypted-secrets Robin Westberg has updated the pull request incrementally with one additional commit since the last revision: Update boot JDK to 15 - Changes: - all: https://git.openjdk.java.net/jdk/pull/284/files - new: https://git.openjdk.java.net/jdk/pull/284/files/496d896c..de5074fe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=284=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=284=02-03 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/284.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/284/head:pull/284 PR: https://git.openjdk.java.net/jdk/pull/284
Re: RFR: 8248984: Bump minimum boot jdk to JDK 15
On Wed, 23 Sep 2020 22:47:47 GMT, Erik Joelsson wrote: >> JDK 15 is now GA. The minimum boot JDK version for mainline/JDK 16 should be >> bumped to this version. >> >> Testing: tier1-5 passed with a slightly earlier version of this change. >> Re-running tier1 now for good luck. > > @rwestberg Note that you will need to update your actions patch if this goes > in first. @erikj79 Thanks for the heads-up, I've updated #284 to use 15 now. - PR: https://git.openjdk.java.net/jdk/pull/326
