Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5]
On Thu, 24 Sep 2020 04:57:39 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 > > I've mainly looked at the non-Aarch64 specific changes. A couple of minor > comments below. @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: 8248984: Bump minimum boot jdk to JDK 15
On Wed, 23 Sep 2020 22:32:37 GMT, Mikael Vidstedt 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. Marked as reviewed by dholmes (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/326
Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5]
On Wed, 23 Sep 2020 13:23:43 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 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 I've mainly looked at the non-Aarch64 specific changes. A couple of minor comments below. 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? 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. - Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/212
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. Marked as reviewed by iklam (Reviewer). - 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. Marked as reviewed by mchung (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/327
Re: RFR: 8235710: Remove the legacy elliptic curves [v3]
> 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 - Changes: - all: https://git.openjdk.java.net/jdk/pull/289/files - new: https://git.openjdk.java.net/jdk/pull/289/files/8a04ce7a..1f9820ab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=289=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=289=01-02 Stats: 20 lines in 3 files changed: 4 ins; 10 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/289.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/289/head:pull/289 PR: https://git.openjdk.java.net/jdk/pull/289
RFR: 8253500: [REDO] JDK-8253208 Move CDS related code to a separate class
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. - Commit messages: - 8253500: [REDO] JDK-8253208 Move CDS related code to a separate class Changes: https://git.openjdk.java.net/jdk/pull/327/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=327=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253500 Stats: 156 lines in 22 files changed: 57 ins; 53 del; 46 mod Patch: https://git.openjdk.java.net/jdk/pull/327.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/327/head:pull/327 PR: https://git.openjdk.java.net/jdk/pull/327
Re: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v5]
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 by egahlin (Reviewer). @marschall I will sponsor it after you integrate the latest update. - PR: https://git.openjdk.java.net/jdk/pull/45
Re: RFR: 8248984: Bump minimum boot jdk to JDK 15
On Wed, 23 Sep 2020 22:32:37 GMT, Mikael Vidstedt 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. - Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/326
Re: RFR: 8248984: Bump minimum boot jdk to JDK 15
On Wed, 23 Sep 2020 22:32:37 GMT, Mikael Vidstedt 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. Marked as reviewed by darcy (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/326
RFR: 8248984: Bump minimum boot jdk to JDK 15
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. - Commit messages: - 8248984: Bump minimum boot jdk to JDK 15 Changes: https://git.openjdk.java.net/jdk/pull/326/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=326=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248984 Stats: 18 lines in 2 files changed: 0 ins; 13 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/326.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/326/head:pull/326 PR: https://git.openjdk.java.net/jdk/pull/326
Re: RFR: 8235710: Remove the legacy elliptic curves [v2]
On Wed, 23 Sep 2020 17:07:21 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with one >> additional commit since the last revision: >> >> remove JDKOPT_DETECT_INTREE_EC from configure.ac > > src/jdk.crypto.ec/share/classes/sun/security/ec/SunEC.java line 219: > >> 217: >> 218: Collection supportedCurves; >> 219: supportedCurves = CurveDB.getSupportedCurves(); > > Shouldn't the supportedCurves be the hardcoded 3 curves? Ah yes. Thanks for seeing that. - PR: https://git.openjdk.java.net/jdk/pull/289
Re: RFR: 8235710: Remove the legacy elliptic curves [v2]
On Tue, 22 Sep 2020 13:53:12 GMT, Sean Mullan wrote: >> Anthony Scarpino has updated the pull request incrementally with one >> additional commit since the last revision: >> >> remove JDKOPT_DETECT_INTREE_EC from configure.ac > > src/jdk.crypto.ec/share/classes/sun/security/ec/ECDHKeyAgreement.java line > 180: > >> 178: ((privNC != null) ? privNC.toString() : " >> unknown") + >> 179: ", PublicKey:" + >> 180: ((pubNC != null) ? pubNC.toString() : " >> unknown"))); > > Spacing issues: "PublicKey:" should be "PublicKey: " and " unknown" should be > "unknown". After considering the keys closer, I don't need to specify the key anymore. PrivateKey and PublicKey were removed - PR: https://git.openjdk.java.net/jdk/pull/289
Re: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v5]
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 `@since` from 9 to 16 since it is a new annotation >> name in a new package. >> - I tried to keep code changes to a minimum, eg not change to imports if >> fully qualified class names are used instead of >> imports. In some cases I did minor reordering of imports to keep them >> sorted alphabetically. >> - All tier1 tests pass. >> - One jpackage/jlink tier2 test fails but I don't believe it is related. >> - Some tier3 Swing tests fail but I don't think they are related. > > 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 by egahlin (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/45
Re: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive
On Wed, 16 Sep 2020 19:01:18 GMT, Ioi Lam wrote:
>> This patch is reorganized after 8252725, which is separated from this patch
>> to refactor jlink glugin code. The previous
>> webrev with hg can be found at:
>> http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725
>> integrated, the
>> regeneration of holder classes is simply to call the new added
>> GenerateJLIClassesHelper.cdsGenerateHolderClasses
>> function. Tests: tier1-4
>
> src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java
> line 67:
>
>> 65: if (VM.isDumpLoadedClassListSetAndOpen) {
>> 66: VM.cdsTraceResolve(traceLF);
>> 67: }
>
> GenerateJLIClassesHelper shouldn't need to know why the trace is needed.
> Also, "cdsTraceResolve" is too generic.
>
> I think it's better to have
> if (TRACE_RESOLVE || VM.CDS_TRACE_JLINV_RESOLVE) {
> ...
> VM.cdsTraceJLINVResolve(traceLF);
>
> The acronym JLINV is used in
> [methodHandles.cpp](https://github.com/openjdk/jdk/blob/ce93cbce77e1f4baa52676826c8ae27d474360b6/src/hotspot/share/prims/methodHandles.cpp#L1524)
With CDS related code moved to CDS.java, I think we should keep TRACE_RESOLVE
here. A new name like suggested by Mandy,
logTraceResolve in CDS.java
> src/java.base/share/classes/jdk/internal/misc/VM.java line 490:
>
>> 488: */
>> 489: public static boolean isDumpLoadedClassListSetAndOpen;
>> 490: private static native boolean isDumpLoadedClassListSetAndOpen0();
>
> I would suggest to rename to `isDumpingLoadedClassList`
Will change.
-
PR: https://git.openjdk.java.net/jdk/pull/193
Re: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v5]
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 `@since` from 9 to 16 since it is a new annotation >> name in a new package. >> - I tried to keep code changes to a minimum, eg not change to imports if >> fully qualified class names are used instead of >> imports. In some cases I did minor reordering of imports to keep them >> sorted alphabetically. >> - All tier1 tests pass. >> - One jpackage/jlink tier2 test fails but I don't believe it is related. >> - Some tier3 Swing tests fail but I don't think they are related. > > 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 Update seems fine. Thanks for JFR testing and fixing. - Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/45
Re: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v5]
> 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 `@since` from 9 to 16 since it is a new annotation name > in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if > fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them > sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. 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 - Changes: https://git.openjdk.java.net/jdk/pull/45/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=45=04 Stats: 749 lines in 65 files changed: 149 ins; 149 del; 451 mod Patch: https://git.openjdk.java.net/jdk/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/45/head:pull/45 PR: https://git.openjdk.java.net/jdk/pull/45
Re: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions
On Wed, 23 Sep 2020 17:24:39 GMT, Erik Joelsson wrote: >> I added `make/conf/test-dependencies` with version numbers specified on the >> format that `jib-profiles.js` would expect. >> Actually using them from that file as well could perhaps be a separate task >> though. :) > > The version-numbers file (which is also a shared properties style file) is > not using quotes for values, which is fine > as long as there are no spaces. I believe if you read it as a properties > file, you need to strip the quotes if you have > them. I prefer if version-numbers and test-dependencies using the same > format. Otherwise this looks good to me! Sounds reasonable, didn't notice that discrepancy! Fixed in the latest commit. - PR: https://git.openjdk.java.net/jdk/pull/284
Re: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions [v3]
> 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: Remove unnecessary quoting from the test-dependencies file - Changes: - all: https://git.openjdk.java.net/jdk/pull/284/files - new: https://git.openjdk.java.net/jdk/pull/284/files/7f260ede..496d896c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=284=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=284=01-02 Stats: 13 lines in 1 file changed: 0 ins; 0 del; 13 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: 8216497: javadoc should auto-link to platform classes [v3]
On Wed, 23 Sep 2020 14:20:12 GMT, Hannes Wallnöfer wrote: >> This pull request is identical with the RFR previously sent for the >> Mercurial repository: >> >> https://mail.openjdk.java.net/pipermail/javadoc-dev/2020-August/001796.html >> >> I'm copy-pasting the comments from the original RFR below. >> >> Most of the new code is added to the Extern class where it fits in quite >> nicely and can use the existing supporting >> code for setting up external links. >> The default behaviour is to generate links to docs.oracle.com for released >> versions and download.java.net for >> prereleases. Platform documentation URLs can be configured using the new >> --link-platform-properties option to >> provide a properties file with URLs pointing to to alternative locations. >> See the CSR linked above for more details on >> the new options. The feature can be disabled using the --no-platform-link >> option, generating the same output as >> previously. One problem I had to solve was how to handle the transition >> from prerelease versions to final releases, >> since the location of the documentation changes in this transition. For >> obvious reasons we don’t want to make that >> switch via code change at a time shortly before release. The way it is done >> is that we determine if the current >> javadoc instance is a prerelease version as indicated by the Version >> returned by BaseConfiguration#getDocletVersion(), >> and then check whether the release/source version of the current javadoc >> execution uses the same (latest) version. This >> means that that only the latest version will ever generate prerelease links >> (e.g. running current javadoc 16 with >> source version 15 will generate links to the final release documentation) >> but I think this is acceptable. Another >> issue I spent some time getting right was tests. New releases require a new >> element-list resource*), so tests have to >> pick up new releases. On the other hand, we don’t want hundreds of tests to >> fail when a new release is added, ideally >> there should be one test with a clear message. Because of this, when a >> release is encountered for which no >> element-list is available a warning is generated instead of an error, and >> the documentation is generated without >> platform links as if running with --no-platform-link option. This allows >> most existing tests to pass and just the new >> test to fail with a relatively clear message of what is wrong. >> *) I also thought about generating the element-list for the current release >> at build time. It’s quite involved, and we >> still need to maintain element-lists for older versions, so I’m not sure >> it’s worth it. >> >> For existing tests that check output affected by the new option I added the >> --no-platform-link option to disable the >> feature. Otherwise we’d have to update those tests with each new release (or >> else freeze the tests to use some static >> release or source version, which we don’t want either). I updated the CSR >> to the new code. It also needs to be >> reviewed: https://bugs.openjdk.java.net/browse/JDK-8251181 >> >> Thanks, >> Hannes > > Hannes Wallnöfer has updated the pull request incrementally with one > additional commit since the last revision: > > Rename --no-platform-link option plus minor cleanup I agree with the judgement call to _not_ introduce default javadoc options. It was just a suggestion to consider, and I agree it would make the calls less intuitively obvious, for the short term gain of editing fewer tests here. It also helped to realize that the support default platform links does _not_ involve any network access. FWIW, the precedent in JavadocTester that I was referrng to is `setAutomaticCheckLinks`, `setAutomaticCheckAccessibility`, but those are about default actions after javadoc has been run, and not about default methods. - Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/171
Re: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions
On Wed, 23 Sep 2020 13:46:50 GMT, Robin Westberg wrote: >> The other primary consumer of this is make/conf/jib-profiles.js. The >> make/conf dir would make sense to me. >> >> The challenge here is creating a set of variables that are suitable enough >> for both config files to consume. For >> BootJDK, we never bothered with bumping the version for updates, and I very >> much doubt we will do that in the future >> for github actions, so a plain major version 14, and soon 15, would be >> preferred from my point of view. This is however >> not enough for jib-profiles.js (yet) so we can't really share bootjdk config >> for now anyway. For jtreg, we specify 5.1 >> and b01 as two separate metadata values. For gtest we specify the version as >> 1.8.1. > > I added `make/conf/test-dependencies` with version numbers specified on the > format that `jib-profiles.js` would expect. > Actually using them from that file as well could perhaps be a separate task > though. :) The version-numbers file (which is also a shared properties style file) is not using quotes for values, which is fine as long as there are no spaces. I believe if you read it as a properties file, you need to strip the quotes if you have them. I prefer if version-numbers and test-dependencies using the same format. Otherwise this looks good to me! - PR: https://git.openjdk.java.net/jdk/pull/284
Re: RFR: 8235710: Remove the legacy elliptic curves [v2]
On Tue, 22 Sep 2020 00:18:07 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: > > remove JDKOPT_DETECT_INTREE_EC from configure.ac src/jdk.crypto.ec/share/classes/sun/security/ec/SunEC.java line 219: > 217: > 218: Collection supportedCurves; > 219: supportedCurves = CurveDB.getSupportedCurves(); Shouldn't the supportedCurves be the hardcoded 3 curves? - PR: https://git.openjdk.java.net/jdk/pull/289
Re: RFR: 8216497: javadoc should auto-link to platform classes [v3]
> This pull request is identical with the RFR previously sent for the Mercurial > repository: > > https://mail.openjdk.java.net/pipermail/javadoc-dev/2020-August/001796.html > > I'm copy-pasting the comments from the original RFR below. > > Most of the new code is added to the Extern class where it fits in quite > nicely and can use the existing supporting > code for setting up external links. > The default behaviour is to generate links to docs.oracle.com for released > versions and download.java.net for > prereleases. Platform documentation URLs can be configured using the new > --link-platform-properties option to > provide a properties file with URLs pointing to to alternative locations. See > the CSR linked above for more details on > the new options. The feature can be disabled using the --no-platform-link > option, generating the same output as > previously. One problem I had to solve was how to handle the transition > from prerelease versions to final releases, > since the location of the documentation changes in this transition. For > obvious reasons we don’t want to make that > switch via code change at a time shortly before release. The way it is done > is that we determine if the current > javadoc instance is a prerelease version as indicated by the Version returned > by BaseConfiguration#getDocletVersion(), > and then check whether the release/source version of the current javadoc > execution uses the same (latest) version. This > means that that only the latest version will ever generate prerelease links > (e.g. running current javadoc 16 with > source version 15 will generate links to the final release documentation) but > I think this is acceptable. Another > issue I spent some time getting right was tests. New releases require a new > element-list resource*), so tests have to > pick up new releases. On the other hand, we don’t want hundreds of tests to > fail when a new release is added, ideally > there should be one test with a clear message. Because of this, when a > release is encountered for which no > element-list is available a warning is generated instead of an error, and the > documentation is generated without > platform links as if running with --no-platform-link option. This allows most > existing tests to pass and just the new > test to fail with a relatively clear message of what is wrong. > *) I also thought about generating the element-list for the current release > at build time. It’s quite involved, and we > still need to maintain element-lists for older versions, so I’m not sure > it’s worth it. > > For existing tests that check output affected by the new option I added the > --no-platform-link option to disable the > feature. Otherwise we’d have to update those tests with each new release (or > else freeze the tests to use some static > release or source version, which we don’t want either). I updated the CSR to > the new code. It also needs to be > reviewed: https://bugs.openjdk.java.net/browse/JDK-8251181 > > Thanks, > Hannes Hannes Wallnöfer has updated the pull request incrementally with one additional commit since the last revision: Rename --no-platform-link option plus minor cleanup - Changes: - all: https://git.openjdk.java.net/jdk/pull/171/files - new: https://git.openjdk.java.net/jdk/pull/171/files/6d659ae3..6009dd70 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=171=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=171=01-02 Stats: 73 lines in 38 files changed: 0 ins; 0 del; 73 mod Patch: https://git.openjdk.java.net/jdk/pull/171.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/171/head:pull/171 PR: https://git.openjdk.java.net/jdk/pull/171
Re: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions [v2]
> 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: Extract all hardcoded versions to a separate configuration file - Changes: - all: https://git.openjdk.java.net/jdk/pull/284/files - new: https://git.openjdk.java.net/jdk/pull/284/files/4074e334..7f260ede Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=284=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=284=00-01 Stats: 170 lines in 2 files changed: 102 ins; 5 del; 63 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: 8253424: Add support for running pre-submit testing using GitHub Actions
On Tue, 22 Sep 2020 14:05:42 GMT, Erik Joelsson wrote:
>> Sure, should not be that hard to parse something similar. The GitHub actions
>> will probably need it in JSON format at
>> some point, but nothing a little `sed -e '1i {' -e 's/#.*//g' -e 's/"//g' -e
>> 's/(.*)=(.*)/"\1": "\2",/g' -e
>> '$s/,\s{0,}$/}/'` won't solve. Any suggestion for the location and name of
>> such a file? I'm thinking it would contain
>> entries like this: BOOT_JDK_VERSION="14.0.2" JTREG_VERSION="jtreg5.1-b01"
>> GTEST_VERSION="release-1.8.1"
>> LINUX_X64_BOOT_JDK_FILENAME="openjdk-14.0.2_linux-x64_bin.tar.gz"
>> LINUX_X64_BOOT_JDK_URL="https://download.java.net/java/GA/jdk14.0.2/205943a0976c4ed48cb16f1043c5c647/12/GPL/openjdk-14.0.2_linux-x64_bin.tar.gz;
>> LINUX_X64_BOOT_JDK_SHA256="91310200f072045dc6cef2c8c23e7e6387b37c46e9de49623ce0fa461a24623d"
>
> The other primary consumer of this is make/conf/jib-profiles.js. The
> make/conf dir would make sense to me.
>
> The challenge here is creating a set of variables that are suitable enough
> for both config files to consume. For
> BootJDK, we never bothered with bumping the version for updates, and I very
> much doubt we will do that in the future
> for github actions, so a plain major version 14, and soon 15, would be
> preferred from my point of view. This is however
> not enough for jib-profiles.js (yet) so we can't really share bootjdk config
> for now anyway. For jtreg, we specify 5.1
> and b01 as two separate metadata values. For gtest we specify the version as
> 1.8.1.
I added `make/conf/test-dependencies` with version numbers specified on the
format that `jib-profiles.js` would expect.
Actually using them from that file as well could perhaps be a separate task
though. :)
-
PR: https://git.openjdk.java.net/jdk/pull/284
Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5]
> 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 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 - Changes: - all: https://git.openjdk.java.net/jdk/pull/212/files - new: https://git.openjdk.java.net/jdk/pull/212/files/50ab8edf..4da7b89e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=212=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk=212=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 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 Mon, 21 Sep 2020 14:47:15 GMT, Bernhard Urban-Forster
wrote:
>>> _Mailing list message from [Andrew Haley](mailto:a...@redhat.com) on
>>> [build-dev](mailto:build-dev@openjdk.java.net):_
>>>
>>> On 18/09/2020 11:14, Monica Beckwith wrote:
>>>
>>> > This is a continuation of
>>> > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>>>
>>> The diffs in assembler_aarch64.cpp are mostly spurious. Please try this.
>>
>>
>> Thank you Andrew. Is the goal to reduce the patch diff in
>> `assembler_aarch64.cpp`? If so, we need to get rid of the
>> retry in your patch to avoid additional calls to `random`, e.g. something
>> like this (the diff for the generated part
>> would look indeed nicer with that:
>> https://gist.github.com/lewurm/2e7b0e00447696c75e00febb83034ba1 ):
>> --- a/src/hotspot/cpu/aarch64/aarch64-asmtest.py
>> +++ b/src/hotspot/cpu/aarch64/aarch64-asmtest.py
>> @@ -13,6 +13,8 @@ class Register(Operand):
>>
>> def generate(self):
>> self.number = random.randint(0, 30)
>> +if self.number == 18:
>> +self.number = 17
>> return self
>>
>> def astr(self, prefix):
>> @@ -37,6 +39,8 @@ class GeneralRegisterOrZr(Register):
>>
>> def generate(self):
>> self.number = random.randint(0, 31)
>> +if self.number == 18:
>> +self.number = 16
>> return self
>>
>> def astr(self, prefix = ""):
>> @@ -54,6 +58,8 @@ class GeneralRegisterOrZr(Register):
>> class GeneralRegisterOrSp(Register):
>> def generate(self):
>> self.number = random.randint(0, 31)
>> +if self.number == 18:
>> +self.number = 15
>> return self
>>
>> def astr(self, prefix = ""):
>> @@ -1331,7 +1337,7 @@ generate(SpecialCases, [["ccmn", "__ ccmn(zr, zr,
>> 3u, Assembler::LE);",
>> ["st1w", "__ sve_st1w(z0, __ S, p1, Address(r0,
>> 7));", "st1w\t{z0.s}, p1, [x0, #7, MUL VL]"],
>> ["st1b", "__ sve_st1b(z0, __ B, p2, Address(sp,
>> r1));","st1b\t{z0.b}, p2, [sp, x1]"],
>> ["st1h", "__ sve_st1h(z0, __ H, p3, Address(sp,
>> r8));","st1h\t{z0.h}, p3, [sp, x8, LSL #1]"],
>> -["st1d", "__ sve_st1d(z0, __ D, p4, Address(r0,
>> r18));", "st1d\t{z0.d}, p4, [x0, x18, LSL #3]"],
>> +["st1d", "__ sve_st1d(z0, __ D, p4, Address(r0,
>> r17));", "st1d\t{z0.d}, p4, [x0, x17,
>> LSL #3]"],
>> ["ldr","__ sve_ldr(z0, Address(sp));",
>> "ldr\tz0, [sp]"],
>> ["ldr","__ sve_ldr(z31, Address(sp, -256));",
>> "ldr\tz31, [sp, #-256, MUL VL]"],
>> ["str","__ sve_str(z8, Address(r8, 255));",
>> "str\tz8, [x8, #255, MUL VL]"],
>
>> _Mailing list message from [Andrew Haley](mailto:a...@redhat.com) on
>> [build-dev](mailto:build-dev@openjdk.java.net):_
>>
>> On 21/09/2020 09:18, Bernhard Urban-Forster wrote:
>>
>> > Thank you Andrew. Is the goal to reduce the patch diff in
>> > `assembler_aarch64.cpp`? If so, we need to get rid of the
>> > retry in your patch to avoid additional calls to `random`, e.g. something
>> > like this (the diff for the generated part
>> > would look indeed nicer with that:
>> > https://gist.github.com/lewurm/2e7b0e00447696c75e00febb83034ba1 ):
>> > [...]
>>
>> Yes, better. Thanks.
>
> Great, I've updated the PR. Thank you!
Thanks, Andrew for catching that. I have made the needful changes.
-Monica
> _Mailing list message from [Andrew Haley](mailto:a...@redhat.com) on
> [build-dev](mailto:build-dev@openjdk.java.net):_
>
> On 18/09/2020 11:14, 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]
>
> It's still wrong, I'm afraid. This is not a full barrier:
>
> +#define FULL_MEM_BARRIER atomic_thread_fence(std::memory_order_acq_rel);
>
> it is only StoreStore|LoadStore|LoadLoad, but you need StoreLoad as
> well. It might well be that you get the same DMB ISH instruction, but
> unless you use a StoreLoad barrier here it's theoretically possible
> for a compiler to reorder accesses so that a processor sees its own
> stores before other processors do. (And it's confusing for the reader
> too.)
>
> Use:
>
> +#define FULL_MEM_BARRIER atomic_thread_fence(std::memory_order_seq_cst);
>
> See here:
>
> https://en.cppreference.com/w/cpp/atomic/memory_order
>
> memory_order_seq_cst "...plus a single total order exists in which all
> threads observe all modifications in the same order (see
> Sequentially-consistent ordering below)"
>
> --
> Andrew Haley (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd.
> https://keybase.io/andrewhaley
>
Re: How can I know which vulnerabilities (CVEs) are fixed in specific tag of open JDK?
Thanks! But the problem here is that this list includes only vulnerabilities, dated by 2019-2020. Vulnerabilities we (our customer) are interested in - are of 2014-2015. ср, 23 сент. 2020 г. в 13:38, Alan Bateman : > On 23/09/2020 11:29, Moshe Zuisman wrote: > > Hi. > > I have the following problem. We provide OpenJDK binary distro with our > > product. > > With the current version we provided JDK8u-b222 > > Customer comes with a list of CVEs and asks if they are fixed in distro, > we > > provided with our product. > > For example he asks about cve-2014-3566, jre-vuln-cve-2017-3241(it is > only > > a part of the full list he asks about). > > In the release note of b222 ( > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-July/009840.html) > I > > do not see any info about fixed CVEs. > > Is there any way I figure out what is a full list of CVEs - fixed in > > specific, or opposite - can I somehow know if some specific CVE fixed in > > some build? > Advisories are posted to the vuln-announce mailing list and also linked > from the advisories page [1]. > > -Alan > > [1] https://openjdk.java.net/groups/vulnerability/advisories/ >
Re: RFR: 8216497: javadoc should auto-link to platform classes [v2]
On Tue, 22 Sep 2020 17:30:19 GMT, Jonathan Gibbons wrote:
>> Hannes Wallnöfer has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Merge pull request #1 from lahodaj/JDK-8216497
>>
>>Automatically generate the elements-list data from the ct.sym for
>> releases 11+, including the current release under
>>development
>> - Generating current release list for javadoc; using hardcoded lists for
>> versions < 11
>> - Attempting to (mostly) generate the javadoc release manifests from ct.sym
>> historical data.
>
> test/langtools/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java
> line 49:
>
>> 47: javadoc("-d", "out-1",
>> 48: "-sourcepath", testSrc,
>> 49: "--no-platform-link",
>
> I see lots of instances of `no-platform-link` in this and subsequent tests.
> `JavadocTester` does have the concept of
> default options, although that may be more for the behavior after executing
> javadoc and not for the options given to
> javadoc itself. Is it worth supporting default javadoc options, since that
> the default can be disabled for specific
> tests?
I can't really find how `JavadocTester` uses or supports default options. My
concern with this would be that it would
make JavadocTester less transparent and intuitive to use, as you'd have to be
aware what the default options are.
-
PR: https://git.openjdk.java.net/jdk/pull/171
Re: How can I know which vulnerabilities (CVEs) are fixed in specific tag of open JDK?
On 23/09/2020 11:29, Moshe Zuisman wrote: Hi. I have the following problem. We provide OpenJDK binary distro with our product. With the current version we provided JDK8u-b222 Customer comes with a list of CVEs and asks if they are fixed in distro, we provided with our product. For example he asks about cve-2014-3566, jre-vuln-cve-2017-3241(it is only a part of the full list he asks about). In the release note of b222 ( https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-July/009840.html) I do not see any info about fixed CVEs. Is there any way I figure out what is a full list of CVEs - fixed in specific, or opposite - can I somehow know if some specific CVE fixed in some build? Advisories are posted to the vuln-announce mailing list and also linked from the advisories page [1]. -Alan [1] https://openjdk.java.net/groups/vulnerability/advisories/
How can I know which vulnerabilities (CVEs) are fixed in specific tag of open JDK?
Hi. I have the following problem. We provide OpenJDK binary distro with our product. With the current version we provided JDK8u-b222 Customer comes with a list of CVEs and asks if they are fixed in distro, we provided with our product. For example he asks about cve-2014-3566, jre-vuln-cve-2017-3241(it is only a part of the full list he asks about). In the release note of b222 ( https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-July/009840.html) I do not see any info about fixed CVEs. Is there any way I figure out what is a full list of CVEs - fixed in specific, or opposite - can I somehow know if some specific CVE fixed in some build?
