Re: RFR: 8257450: Start of release updates for JDK 17 [v2]

2020-12-07 Thread Alan Bateman
On Mon, 7 Dec 2020 21:14:55 GMT, Joe Darcy wrote: >> test/jdk/java/lang/module/ClassFileVersionsTest.java line 107: >> >>> 105: { 61, 0, Set.of(STATIC, TRANSITIVE) }, >>> 106: >>> 107: { 62, 0, Set.of()}, // JDK 18 >> >> This seems

Re: RFR: 8256657: Add cross-compiled build for Windows+Arm64 to submit workflow [v4]

2020-12-07 Thread Aleksey Shipilev
On Tue, 8 Dec 2020 06:58:49 GMT, Aleksey Shipilev wrote: >> Bernhard Urban-Forster has updated the pull request incrementally with one >> additional commit since the last revision: >> >> merge mistakes > > Minor nits. Also merge from master to get the clean workflow run everywhere?

Re: RFR: 8256657: Add cross-compiled build for Windows+Arm64 to submit workflow [v4]

2020-12-07 Thread Aleksey Shipilev
On Mon, 7 Dec 2020 19:34:26 GMT, Bernhard Urban-Forster wrote: >> This adds the cross-compiled build only, as no Windows+Arm64 machines are >> available on GitHub Action that we could use to run the tests. >> >> Due to cross-compilation a build JDK is required. Initially I added EA >> builds

Re: RFR: 8257450: Start of release updates for JDK 17 [v4]

2020-12-07 Thread Joe Darcy
> Start of JDK 17 updates. Joe Darcy 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 10 additional commits since the last revision: - Merge branch

Re: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v3]

2020-12-07 Thread Yumin Qi
> Hi, Please review > Windows mapping for file into memory could not happen to reserved memory. > In mapping CDS archive we first reserve enough memory then before mapping, > release them. For cds archive and using class space, need split the whole > space into two, that is, release the whole

Re: RFR: 8257450: Start of release updates for JDK 17 [v3]

2020-12-07 Thread Joe Darcy
> Start of JDK 17 updates. Joe Darcy 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 ten additional commits since the last revision: - Merge branch

Re: RFR: 8257733: Move module-specific data from make to respective module [v2]

2020-12-07 Thread Mandy Chung
On Mon, 7 Dec 2020 19:31:59 GMT, Jonathan Gibbons wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Move to share/data, and move jdwp.spec to java.se > > I have reviewed all lines in the patch file with or

Re: RFR: JDK-8257789: Fix incremental build of test-image and bundles

2020-12-07 Thread Magnus Ihse Bursie
On Fri, 4 Dec 2020 23:01:26 GMT, Erik Joelsson wrote: > When building the test-bundle incrementally, it always gets rebuilt. This is > caused by the prepare-test-image target in TestImage.gmk, where we create a > README file as part of a recipe for a PHONY target. This means that the > README

Re: RFR: 8257450: Start of release updates for JDK 17 [v2]

2020-12-07 Thread Joe Darcy
On Mon, 7 Dec 2020 20:20:58 GMT, Jesper Wilhelmsson wrote: >> Joe Darcy 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 eight additional

Integrated: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal

2020-12-07 Thread David Holmes
On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: > The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago > and supported three different Linux signal API's: sigset, signal and > sigaction: > >

Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal

2020-12-07 Thread David Holmes
On 7/12/2020 11:35 pm, Erik Joelsson wrote: On 2020-12-04 21:22, David Holmes wrote: Hi Erik, On 4/12/2020 12:07 am, Erik Joelsson wrote: In general, I would prefer if a flag like this was just inlined in the SetupJdkLibrary call, as there are no complex conditionals for setting it.

Re: RFR: 8257450: Start of release updates for JDK 17 [v2]

2020-12-07 Thread Joe Darcy
On Mon, 7 Dec 2020 20:08:59 GMT, Jonathan Gibbons wrote: >> Joe Darcy 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 eight additional commits

Re: RFR: 8256657: Add cross-compiled build for Windows+Arm64 to submit workflow [v4]

2020-12-07 Thread Magnus Ihse Bursie
On Mon, 7 Dec 2020 19:34:26 GMT, Bernhard Urban-Forster wrote: >> This adds the cross-compiled build only, as no Windows+Arm64 machines are >> available on GitHub Action that we could use to run the tests. >> >> Due to cross-compilation a build JDK is required. Initially I added EA >> builds

Re: RFR: 8257450: Start of release updates for JDK 17 [v2]

2020-12-07 Thread Jesper Wilhelmsson
On Mon, 7 Dec 2020 19:38:41 GMT, Joe Darcy wrote: >> Start of JDK 17 updates. > > Joe Darcy 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 eight

Re: RFR: 8257450: Start of release updates for JDK 17 [v2]

2020-12-07 Thread Jan Lahoda
On Mon, 7 Dec 2020 19:38:41 GMT, Joe Darcy wrote: >> Start of JDK 17 updates. > > Joe Darcy 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 eight

Re: RFR: 8257450: Start of release updates for JDK 17 [v2]

2020-12-07 Thread Jonathan Gibbons
On Mon, 7 Dec 2020 19:38:41 GMT, Joe Darcy wrote: >> Start of JDK 17 updates. > > Joe Darcy 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 eight

Re: RFR: 8257450: Start of release updates for JDK 17 [v2]

2020-12-07 Thread Joe Darcy
On Mon, 7 Dec 2020 16:10:42 GMT, Jan Lahoda wrote: > > > The langtools changes look fine to me. There were additions/changes to jcod > files under `test/hotspot/jtreg/runtime/sealedClasses/` made under > JDK-8246778, so these may need an update. Sorry about that. After a merge, the tests in

Re: RFR: 8257450: Start of release updates for JDK 17 [v2]

2020-12-07 Thread Joe Darcy
> Start of JDK 17 updates. Joe Darcy 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 eight additional commits since the last revision: - Merge

Re: RFR: 8257733: Move module-specific data from make to respective module [v2]

2020-12-07 Thread Jonathan Gibbons
On Mon, 7 Dec 2020 14:27:45 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. >> For instance, the publicsuffixlist is used by java.base, and fontconfig by >> java.desktop. (A few directories, like mainmanifest, is *actually* used by

Re: RFR: 8256657: Add cross-compiled build for Windows+Arm64 to submit workflow [v4]

2020-12-07 Thread Bernhard Urban-Forster
> This adds the cross-compiled build only, as no Windows+Arm64 machines are > available on GitHub Action that we could use to run the tests. > > Due to cross-compilation a build JDK is required. Initially I added EA builds > to be downloaded from https://jdk.java.net/16/ and used for that, but

Re: RFR: 8256657: Add cross-compiled build for Windows+Arm64 to submit workflow [v3]

2020-12-07 Thread Bernhard Urban-Forster
> This adds the cross-compiled build only, as no Windows+Arm64 machines are > available on GitHub Action that we could use to run the tests. > > Due to cross-compilation a build JDK is required. Initially I added EA builds > to be downloaded from https://jdk.java.net/16/ and used for that, but

Re: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal

2020-12-07 Thread Lois Foltan
On Mon, 7 Dec 2020 15:50:55 GMT, Harold Seigel wrote: >> Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100). >> >> Development has been broken into 5 tasks, each with its own JBS issue: >> - Deprecate wrapper class constructors for removal (rriggs) >> - Revise

Re: RFR: 8257450: Start of release updates for JDK 17

2020-12-07 Thread Jan Lahoda
On Sat, 5 Dec 2020 03:17:56 GMT, Mikael Vidstedt wrote: >> Start of JDK 17 updates. > > Marked as reviewed by mikael (Reviewer). The langtools changes look fine to me. There were additions/changes to jcod files under `test/hotspot/jtreg/runtime/sealedClasses/` made under JDK-8246778, so these

Integrated: 8257679: Improved unix compatibility layer in Windows build (winenv)

2020-12-07 Thread Magnus Ihse Bursie
On Thu, 3 Dec 2020 14:19:13 GMT, Magnus Ihse Bursie wrote: > For the build to work on Windows, we need a unix compatibility layer (known > as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The > build system then needs to adapt various aspect to get the build to work in >

Re: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal

2020-12-07 Thread Harold Seigel
On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith wrote: > Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100). > > Development has been broken into 5 tasks, each with its own JBS issue: > - Deprecate wrapper class constructors for removal (rriggs) > - Revise "value-based class"

Re: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal

2020-12-07 Thread Roger Riggs
On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith wrote: > Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100). > > Development has been broken into 5 tasks, each with its own JBS issue: > - Deprecate wrapper class constructors for removal (rriggs) > - Revise "value-based class"

Re: RFR: JDK-8257789: Fix incremental build of test-image and bundles

2020-12-07 Thread Tim Bell
On Fri, 4 Dec 2020 23:01:26 GMT, Erik Joelsson wrote: > When building the test-bundle incrementally, it always gets rebuilt. This is > caused by the prepare-test-image target in TestImage.gmk, where we create a > README file as part of a recipe for a PHONY target. This means that the > README

Re: RFR: 8257679: Improved unix compatibility layer in Windows build (winenv) [v7]

2020-12-07 Thread Erik Joelsson
On Sat, 5 Dec 2020 01:13:34 GMT, Magnus Ihse Bursie wrote: >> For the build to work on Windows, we need a unix compatibility layer (known >> as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The >> build system then needs to adapt various aspect to get the build to work in

Re: RFR: 8257733: Move module-specific data from make to respective module

2020-12-07 Thread Magnus Ihse Bursie
On Mon, 7 Dec 2020 14:20:07 GMT, Magnus Ihse Bursie wrote: >> @erikj79 Good point, that makes much more sense. > > I'm not sure about the formal process for suggesting changes to a delivered > JEP, but this is the text I suggest should replace the current definition of > the new scheme: > >

Re: RFR: 8257733: Move module-specific data from make to respective module

2020-12-07 Thread Magnus Ihse Bursie
On Fri, 4 Dec 2020 15:17:06 GMT, Magnus Ihse Bursie wrote: >> Regarding the chosen layout. Did you consider following the existing pattern >> of src//{share,}/data? > > @erikj79 Good point, that makes much more sense. I'm not sure about the formal process for suggesting changes to a delivered

Re: RFR: 8257733: Move module-specific data from make to respective module [v2]

2020-12-07 Thread Magnus Ihse Bursie
> A lot (but not all) of the data in make/data is tied to a specific module. > For instance, the publicsuffixlist is used by java.base, and fontconfig by > java.desktop. (A few directories, like mainmanifest, is *actually* used by > make for the whole build.) > > These data files should move

Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal

2020-12-07 Thread Erik Joelsson
On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: > The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago > and supported three different Linux signal API's: sigset, signal and > sigaction: > >

Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal

2020-12-07 Thread Erik Joelsson
On 2020-12-04 21:22, David Holmes wrote: Hi Erik, On 4/12/2020 12:07 am, Erik Joelsson wrote: In general, I would prefer if a flag like this was just inlined in the SetupJdkLibrary call, as there are no complex conditionals for setting it. Looking a bit further, the variable

Re: RFR: 8257679: Improved unix compatibility layer in Windows build (winenv) [v7]

2020-12-07 Thread Bernhard Urban-Forster
On Sat, 5 Dec 2020 01:13:34 GMT, Magnus Ihse Bursie wrote: >> For the build to work on Windows, we need a unix compatibility layer (known >> as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The >> build system then needs to adapt various aspect to get the build to work in

Re: RFR: 8257679: Improved unix compatibility layer in Windows build (winenv) [v7]

2020-12-07 Thread Bernhard Urban-Forster
On Sat, 5 Dec 2020 01:13:34 GMT, Magnus Ihse Bursie wrote: >> For the build to work on Windows, we need a unix compatibility layer (known >> as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The >> build system then needs to adapt various aspect to get the build to work in