Re: RFR: 8285755: JDK-8285093 changed the default for --with-output-sync

[Mikael Vidstedt]

On Wed, 27 Apr 2022 19:16:48 GMT, Erik Joelsson  wrote:

> The make option '--output-sync recurse' can be useful in certain situations, 
> especially when dealing with very verbose output from makefiles and you want 
> to parse them after the fact. However, when running make interactively on the 
> command line, it certainly gets in the way, as output from each sub make call 
> is buffered until that make process terminates.
> 
> In [JDK-8285093](https://bugs.openjdk.java.net/browse/JDK-8285093), the 
> configure logic for this configuration was changed and, probably by mistake, 
> the default was changes to default "recurse" if available in the supplied GNU 
> make. This is a regression for most users of the build system and needs to be 
> changed back.

Marked as reviewed by mikael (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/8431

Integrated: 8277517: Bump minimum boot jdk to JDK 18

[Mikael Vidstedt]

On Tue, 5 Apr 2022 03:19:06 GMT, Mikael Vidstedt  wrote:

> With the JDK 18 GA out it's time to bump the minimum boot JDK version for 
> mainline/JDK 19.
> 
> Testing: tier1-5, GHA builds

This pull request has now been integrated.

Changeset: 46ce2ef1
Author:Mikael Vidstedt 
URL:   
https://git.openjdk.java.net/jdk/commit/46ce2ef1d2d81f33cb85c2a99305d558d286da05
Stats: 15 lines in 3 files changed: 0 ins; 0 del; 15 mod

8277517: Bump minimum boot jdk to JDK 18

Reviewed-by: darcy, erikj, iris

-

PR: https://git.openjdk.java.net/jdk/pull/8102

Re: RFR: 8277517: Bump minimum boot jdk to JDK 18

[Mikael Vidstedt]

On Tue, 5 Apr 2022 03:19:06 GMT, Mikael Vidstedt  wrote:

> With the JDK 18 GA out it's time to bump the minimum boot JDK version for 
> mainline/JDK 19.
> 
> Testing: tier1-5, GHA builds

Adding a random comment here in the hopes that it will generate an email and 
give everybody a chance to react to this change.

-

PR: https://git.openjdk.java.net/jdk/pull/8102

Integrated: 8283723: Update Visual Studio 2022 to version 17.1.0 for Oracle builds on Windows

[Mikael Vidstedt]

On Sun, 27 Mar 2022 05:08:52 GMT, Mikael Vidstedt  wrote:

> Oracle is updating the version of Visual Studio for building the JDK on 
> Windows to Visual Studio 2022 17.1.0.
> 
> This change adds support for building devkits based on VS 2022. Instead of 
> creating a new script file for that I decided to combine it with the logic in 
> createWindowsDevkit2019.sh and rename the resulting file. I decided to 
> dropped support for VS 2017 since that version is pretty old now, let me know 
> if you'd prefer to see it kept around.
> 
> Testing: tier1-5 + additional testing.

This pull request has now been integrated.

Changeset: a9a9b901
Author:Mikael Vidstedt 
URL:   
https://git.openjdk.java.net/jdk/commit/a9a9b901b4b340dc573ace72d64edcb0a1b8ef94
Stats: 264 lines in 5 files changed: 29 ins; 225 del; 10 mod

8283723: Update Visual Studio 2022 to version 17.1.0 for Oracle builds on 
Windows

Reviewed-by: erikj, ihse

-

PR: https://git.openjdk.java.net/jdk/pull/7974

Re: RFR: 8283723: Update Visual Studio 2022 to version 17.1.0 for Oracle builds on Windows [v4]

[Mikael Vidstedt]

> Oracle is updating the version of Visual Studio for building the JDK on 
> Windows to Visual Studio 2022 17.1.0.
> 
> This change adds support for building devkits based on VS 2022. Instead of 
> creating a new script file for that I decided to combine it with the logic in 
> createWindowsDevkit2019.sh and rename the resulting file. I decided to 
> dropped support for VS 2017 since that version is pretty old now, let me know 
> if you'd prefer to see it kept around.
> 
> Testing: tier1-5 + additional testing.

Mikael Vidstedt 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 seven additional 
commits since the last revision:

 - Merge branch 'master' into 8283723-vs2022-17.1.0
 - Merge branch 'master' into 8283723-vs2022-17.1.0
 - Convert PROGRAMFILES to unix path
 - Remove PROGRAMFILES workaround
 - Remove old devkit scripts
 - Update doc/building.md
 - 8283723: Update Visual Studio 2022 to version 17.1.0 for Oracle builds on 
Windows

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7974/files
  - new: https://git.openjdk.java.net/jdk/pull/7974/files/5a3bd52b..17efc834

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7974=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7974=02-03

  Stats: 1594 lines in 57 files changed: 1373 ins; 56 del; 165 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7974.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7974/head:pull/7974

PR: https://git.openjdk.java.net/jdk/pull/7974

Re: RFR: 8283723: Update Visual Studio 2022 to version 17.1.0 for Oracle builds on Windows [v3]

[Mikael Vidstedt]

On Mon, 28 Mar 2022 16:05:03 GMT, Mikael Vidstedt  wrote:

>> make/devkit/createWindowsDevkit.sh line 74:
>> 
>>> 72: # Work around the insanely named ProgramFiles(x86) env variable
>>> 73: PROGRAMFILES_X86="$($WINDOWS_PATH_TO_UNIX_PATH "$(cmd.exe /c set | sed 
>>> -n 's/^ProgramFiles(x86)=//p' | tr -d '\r')")"
>>> 74: PROGRAMFILES="$($WINDOWS_PATH_TO_UNIX_PATH "$(cmd.exe /c set | sed -n 
>>> 's/^PROGRAMFILES=//p' | tr -d '\r')")"
>> 
>> This complex dance isn't necessary; it's a special operation for just the 
>> "ProgramFiles(x86)" variable, since cygwin can't handle environment 
>> variables with `()` in the name. (See the comment above as well)
>> 
>> I think you will be able to access it with just a simple `$PROGRAMFILES`.
>
> Good point, thank you. I removed that whole line and verified that creating 
> the devkit still works.

While it did seem to work I realized that `PROGRAMFILES` wasn't converted to a 
unix path anymore, so I added back that conversion but without the special 
handling needed for the x86 variable.

-

PR: https://git.openjdk.java.net/jdk/pull/7974

Re: RFR: 8283723: Update Visual Studio 2022 to version 17.1.0 for Oracle builds on Windows [v3]

[Mikael Vidstedt]

> Oracle is updating the version of Visual Studio for building the JDK on 
> Windows to Visual Studio 2022 17.1.0.
> 
> This change adds support for building devkits based on VS 2022. Instead of 
> creating a new script file for that I decided to combine it with the logic in 
> createWindowsDevkit2019.sh and rename the resulting file. I decided to 
> dropped support for VS 2017 since that version is pretty old now, let me know 
> if you'd prefer to see it kept around.
> 
> Testing: tier1-5 + additional testing.

Mikael Vidstedt has updated the pull request incrementally with one additional 
commit since the last revision:

  Convert PROGRAMFILES to unix path

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7974/files
  - new: https://git.openjdk.java.net/jdk/pull/7974/files/8a1072cb..5a3bd52b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7974=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7974=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7974.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7974/head:pull/7974

PR: https://git.openjdk.java.net/jdk/pull/7974

Re: RFR: 8283723: Update Visual Studio 2022 to version 17.1.0 for Oracle builds on Windows [v2]

[Mikael Vidstedt]

> Oracle is updating the version of Visual Studio for building the JDK on 
> Windows to Visual Studio 2022 17.1.0.
> 
> This change adds support for building devkits based on VS 2022. Instead of 
> creating a new script file for that I decided to combine it with the logic in 
> createWindowsDevkit2019.sh and rename the resulting file. I decided to 
> dropped support for VS 2017 since that version is pretty old now, let me know 
> if you'd prefer to see it kept around.
> 
> Testing: tier1-5 + additional testing.

Mikael Vidstedt has updated the pull request incrementally with one additional 
commit since the last revision:

  Remove PROGRAMFILES workaround

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7974/files
  - new: https://git.openjdk.java.net/jdk/pull/7974/files/6413e7ff..8a1072cb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7974=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7974=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7974.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7974/head:pull/7974

PR: https://git.openjdk.java.net/jdk/pull/7974

Re: RFR: 8283723: Update Visual Studio 2022 to version 17.1.0 for Oracle builds on Windows [v2]

[Mikael Vidstedt]

On Mon, 28 Mar 2022 11:54:28 GMT, Magnus Ihse Bursie  wrote:

>> Mikael Vidstedt has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Remove PROGRAMFILES workaround
>
> make/devkit/createWindowsDevkit.sh line 74:
> 
>> 72: # Work around the insanely named ProgramFiles(x86) env variable
>> 73: PROGRAMFILES_X86="$($WINDOWS_PATH_TO_UNIX_PATH "$(cmd.exe /c set | sed 
>> -n 's/^ProgramFiles(x86)=//p' | tr -d '\r')")"
>> 74: PROGRAMFILES="$($WINDOWS_PATH_TO_UNIX_PATH "$(cmd.exe /c set | sed -n 
>> 's/^PROGRAMFILES=//p' | tr -d '\r')")"
> 
> This complex dance isn't necessary; it's a special operation for just the 
> "ProgramFiles(x86)" variable, since cygwin can't handle environment variables 
> with `()` in the name. (See the comment above as well)
> 
> I think you will be able to access it with just a simple `$PROGRAMFILES`.

Good point, thank you. I removed that whole line and verified that creating the 
devkit still works.

-

PR: https://git.openjdk.java.net/jdk/pull/7974

RFR: 8283723: Update Visual Studio 2022 to version 17.1.0 for Oracle builds on Windows

[Mikael Vidstedt]

Oracle is updating the version of Visual Studio for building the JDK on Windows 
to Visual Studio 2022 17.1.0.

This change adds support for building devkits based on VS 2022. Instead of 
creating a new script file for that I decided to combine it with the logic in 
createWindowsDevkit2019.sh and rename the resulting file. I decided to dropped 
support for VS 2017 since that version is pretty old now, let me know if you'd 
prefer to see it kept around.

Testing: tier1-5 + additional testing.

-

Commit messages:
 - Remove old devkit scripts
 - Update doc/building.md
 - 8283723: Update Visual Studio 2022 to version 17.1.0 for Oracle builds on 
Windows

Changes: https://git.openjdk.java.net/jdk/pull/7974/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7974=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283723
  Stats: 264 lines in 5 files changed: 29 ins; 225 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7974.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7974/head:pull/7974

PR: https://git.openjdk.java.net/jdk/pull/7974

Integrated: 8283057: Update GCC to version 11.2 for Oracle builds on Linux

[Mikael Vidstedt]

On Fri, 18 Mar 2022 20:33:54 GMT, Mikael Vidstedt  wrote:

> Oracle is updating the version of GCC for building the JDK on Linux to 11.2. 
> 
> Testing: tier1-5 + additional significant testing. Re-running 
> tier1,builds-tier{2,3,4,5} now for good luck.

This pull request has now been integrated.

Changeset: 8384ac4e
Author:Mikael Vidstedt 
URL:   
https://git.openjdk.java.net/jdk/commit/8384ac4ed3eaaa18998ab88e1ca36358c212e699
Stats: 17 lines in 4 files changed: 9 ins; 0 del; 8 mod

8283057: Update GCC to version 11.2 for Oracle builds on Linux

Reviewed-by: erikj

-

PR: https://git.openjdk.java.net/jdk/pull/7871

RFR: 8283057: Update GCC to version 11.2 for Oracle builds on Linux

[Mikael Vidstedt]

Oracle is updating the version of GCC for building the JDK on Linux to 11.2. 

Testing: tier1-5 + additional significant testing. Re-running 
tier1,builds-tier{2,3,4,5} now for good luck.

-

Commit messages:
 - gcc11.2.0

Changes: https://git.openjdk.java.net/jdk/pull/7871/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7871=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283057
  Stats: 17 lines in 4 files changed: 9 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7871.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7871/head:pull/7871

PR: https://git.openjdk.java.net/jdk/pull/7871

Integrated: 8283062: Uninitialized warnings in libgtest with GCC 11.2

[Mikael Vidstedt]

On Sat, 12 Mar 2022 03:26:29 GMT, Mikael Vidstedt  wrote:

> Background, from JBS:
> 
> In file included from 
> googletest-release-1.8.1/googletest/src/gtest-all.cc:42: 
> googletest-release-1.8.1/googletest/src/gtest-death-test.cc: In function 
> 'bool testing::internal::StackGrowsDown()': 
> googletest-release-1.8.1/googletest/src/gtest-death-test.cc:1224:24: error: 
> 'dummy' may be used uninitialized [-Werror=maybe-uninitialized] 
>  1224 | StackLowerThanAddress(, ); 
>   | ~^ 
> googletest-release-1.8.1/googletest/src/gtest-death-test.cc:1214:13: note: by 
> argument 1 of type 'const void*' to 'void 
> testing::internal::StackLowerThanAddress(const void*, bool*)' declared here 
>  1214 | static void StackLowerThanAddress(const void* ptr, bool* result) { 
>   | ^ 
> googletest-release-1.8.1/googletest/src/gtest-death-test.cc:1222:7: note: 
> 'dummy' declared here 
>  1222 | int dummy;
> 
> 
> Details:
> 
> Since googletest is external code this change disable the relevant warning.
> 
> Testing:
> 
> tier1, builds-tier{2,3,4,5}

This pull request has now been integrated.

Changeset: a244051a
Author:Mikael Vidstedt 
URL:   
https://git.openjdk.java.net/jdk/commit/a244051a8c967039d7639afcaf83f7d92af49613
Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8283062: Uninitialized warnings in libgtest with GCC 11.2

Reviewed-by: jiefu, erikj

-

PR: https://git.openjdk.java.net/jdk/pull/7798

RFR: 8283062: Uninitialized warnings in libgtest with GCC 11.2

[Mikael Vidstedt]

Background, from JBS:

In file included from googletest-release-1.8.1/googletest/src/gtest-all.cc:42: 
googletest-release-1.8.1/googletest/src/gtest-death-test.cc: In function 'bool 
testing::internal::StackGrowsDown()': 
googletest-release-1.8.1/googletest/src/gtest-death-test.cc:1224:24: error: 
'dummy' may be used uninitialized [-Werror=maybe-uninitialized] 
 1224 | StackLowerThanAddress(, ); 
  | ~^ 
googletest-release-1.8.1/googletest/src/gtest-death-test.cc:1214:13: note: by 
argument 1 of type 'const void*' to 'void 
testing::internal::StackLowerThanAddress(const void*, bool*)' declared here 
 1214 | static void StackLowerThanAddress(const void* ptr, bool* result) { 
  | ^ 
googletest-release-1.8.1/googletest/src/gtest-death-test.cc:1222:7: note: 
'dummy' declared here 
 1222 | int dummy;


Details:

Since googletest is external code this change disable the relevant warning.

Testing:

tier1, builds-tier{2,3,4,5}

-

Commit messages:
 - 8283062: Uninitialized warnings in libgtest with GCC 11.2

Changes: https://git.openjdk.java.net/jdk/pull/7798/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7798=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283062
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7798.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7798/head:pull/7798

PR: https://git.openjdk.java.net/jdk/pull/7798

Integrated: 8279884: Use better file for cygwin source permission check

[Mikael Vidstedt]

On Tue, 11 Jan 2022 21:07:17 GMT, Mikael Vidstedt  wrote:

> For sanity, configure tries to verify that source files have the right 
> permissions by checking the LICENSE file in TOPDIR. That file may not always 
> be available, and for builds where it isn't configure will generate a 
> (harmless) error along the lines of:

This pull request has now been integrated.

Changeset: 36f41cbe
Author:Mikael Vidstedt 
URL:   
https://git.openjdk.java.net/jdk/commit/36f41cbe1126c6d9a00b21a1a68cf5f44e2f443f
Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8279884: Use better file for cygwin source permission check

Reviewed-by: erikj

-

PR: https://git.openjdk.java.net/jdk/pull/7038

RFR: 8279884: Use better file for cygwin source permission check

[Mikael Vidstedt]

For sanity, configure tries to verify that source files have the right 
permissions by checking the LICENSE file in TOPDIR. That file may not always be 
available, and for builds where it isn't configure will generate a (harmless) 
error along the lines of:

-

Commit messages:
 - 8279884: Use better file for cygwin source permission check

Changes: https://git.openjdk.java.net/jdk/pull/7038/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7038=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279884
  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7038.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7038/head:pull/7038

PR: https://git.openjdk.java.net/jdk/pull/7038

Integrated: 8266839: Enable pandoc on macosx-aarch64 at Oracle

[Mikael Vidstedt]

On Wed, 1 Dec 2021 18:37:53 GMT, Mikael Vidstedt  wrote:

> Enabling pandoc on macosx-aarch64 at Oracle to produce man pages etc.
> 
> Testing:
> 
> * Passes tier1
> * Verified that the product bundle includes man pages as expected
> * Sampling a few of the man pages they look as expected

This pull request has now been integrated.

Changeset: 51d6d7a3
Author:Mikael Vidstedt 
URL:   
https://git.openjdk.java.net/jdk/commit/51d6d7a36b760b2b2b77269cc06438108a9931a2
Stats: 13 lines in 1 file changed: 11 ins; 0 del; 2 mod

8266839: Enable pandoc on macosx-aarch64 at Oracle

Reviewed-by: erikj

-

PR: https://git.openjdk.java.net/jdk/pull/6650

Re: RFR: 8266839: Enable pandoc on macosx-aarch64 at Oracle

[Mikael Vidstedt]

On Wed, 1 Dec 2021 18:37:53 GMT, Mikael Vidstedt  wrote:

> Enabling pandoc on macosx-aarch64 at Oracle to produce man pages etc.
> 
> Testing:
> 
> * Passes tier1
> * Verified that the product bundle includes man pages as expected
> * Sampling a few of the man pages they look as expected

Yes, I agree that we can and should investigate using the same pandoc version 
across all the platforms.

-

PR: https://git.openjdk.java.net/jdk/pull/6650

RFR: 8266839: Enable pandoc on macosx-aarch64 at Oracle

[Mikael Vidstedt]

Enabling pandoc on macosx-aarch64 at Oracle to produce man pages etc.

Testing:

* Passes tier1
* Verified that the product bundle includes man pages as expected
* Sampling a few of the man pages they look as expected

-

Commit messages:
 - 8266839: Enable pandoc on macosx-aarch64

Changes: https://git.openjdk.java.net/jdk/pull/6650/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6650=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266839
  Stats: 13 lines in 1 file changed: 11 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6650.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6650/head:pull/6650

PR: https://git.openjdk.java.net/jdk/pull/6650

Re: RFR: JDK-8273146: Start of release updates for JDK 19 [v2]

[Mikael Vidstedt]

On Mon, 22 Nov 2021 04:30:38 GMT, Joe Darcy  wrote:

>> The time to get JDK 19 underway draws nigh, please review this usual set of 
>> start-of-release updates, including CSRs for the javac and javax.lang.model 
>> updates:
>> 
>> JDK-8277512: Add SourceVersion.RELEASE_19
>> https://bugs.openjdk.java.net/browse/JDK-8277512
>> 
>> JDK-8277514: Add source 19 and target 19 to javac
>> https://bugs.openjdk.java.net/browse/JDK-8277514
>> 
>> Clean local tier 1 test runs for langtools, jdk, and hotspot.
>
> Joe Darcy has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by mikael (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/6493

Integrated: 8267636: Bump minimum boot jdk to JDK 17

[Mikael Vidstedt]

On Wed, 22 Sep 2021 20:03:55 GMT, Mikael Vidstedt  wrote:

> With the JDK 17 GA out it's time to bump the minimum boot JDK version for 
> mainline/JDK 18.
> 
> Testing: tier1-5, GHA builds

This pull request has now been integrated.

Changeset: 75404ea2
Author:Mikael Vidstedt 
URL:   
https://git.openjdk.java.net/jdk/commit/75404ea25ed5ed77fda41afc6662b1fe7ea2fb43
Stats: 23 lines in 3 files changed: 0 ins; 9 del; 14 mod

8267636: Bump minimum boot jdk to JDK 17

Reviewed-by: darcy, erikj, iris

-

PR: https://git.openjdk.java.net/jdk/pull/5639

RFR: 8267636: Bump minimum boot jdk to JDK 17

[Mikael Vidstedt]

With the JDK 17 GA out it's time to bump the minimum boot JDK version for 
mainline/JDK 18.

Testing: tier1-5, GHA builds

-

Commit messages:
 - 8267636: Bump minimum boot jdk to JDK 17

Changes: https://git.openjdk.java.net/jdk/pull/5639/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5639=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267636
  Stats: 23 lines in 3 files changed: 0 ins; 9 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5639.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5639/head:pull/5639

PR: https://git.openjdk.java.net/jdk/pull/5639

Re: RFR: Merge jdk17 [v2]

[Mikael Vidstedt]

On Mon, 2 Aug 2021 23:53:59 GMT, Jesper Wilhelmsson  
wrote:

>> Forwardport JDK 17 -> JDK 18
>
> Jesper Wilhelmsson has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Revert "8271150: Remove EA from JDK 17 version string starting with Initial 
> RC promotion on Aug 5, 2021(B34)"
>   
>   This reverts commit f8fb5713074b8960f5530d7aca954f84d57c1f30.

Marked as reviewed by mikael (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/4964

Re: [jdk17] RFR: 8271150: Remove EA from JDK 17 version string starting with Initial RC promotion on Aug 5, 2021(B34)

[Mikael Vidstedt]

On Fri, 30 Jul 2021 06:47:07 GMT, Saravana Kumar Vijayasekaran 
 wrote:

> 8271150: Remove EA from JDK 17 version string starting with Initial RC 
> promotion on Aug 5, 2021(B34)

Marked as reviewed by mikael (Reviewer).

-

PR: https://git.openjdk.java.net/jdk17/pull/297

Re: RFR: 8271148: static-libs-image target --with-native-debug-symbols=external doesn't produce debug info

[Mikael Vidstedt]

On Thu, 22 Jul 2021 16:43:26 GMT, Severin Gehwolf  wrote:

> Hi!
> 
> Please review this tiny patch which removes the special casing of 
> `--with-native-debug-symbols=external` for the static libs build. I don't see 
> why this is needed. If no debug symbols are wanted 
> `--with-native-debug-symbols=none` can be used to achieve the same effect. 
> Therefore, I propose to remove this hunk.
> 
> Testing: Inspecting of the log files and seeing that `-g` switch is there. 
> Run the reproducer test on the resulting static libraries.
> 
> Thoughts?

If I understand things correctly (and I may well be misunderstanding 
something), with this change the debug symbols are included in release versions 
of the static libraries when --with-native-debug-symbols=external is specified. 
That's a significant change - people may be depending on debug symbols *not* 
being included in the resulting release binaries.

Doesn't --with-native-debug-symbols=none turn off debug symbols completely for 
all native code? What if one wants external debug symbols for other 
(non-static) libraries?

-

PR: https://git.openjdk.java.net/jdk/pull/4876

Re: [jdk17] RFR: 8270422: Test build/AbsPathsInImage.java fails after JDK-8259848

[Mikael Vidstedt]

On Wed, 14 Jul 2021 07:34:58 GMT, Erik Joelsson  wrote:

> This patch extends the filter for marker files when creating jmods. Our 
> latest established marker file format is `_*.marker` and through 
> ExecuteWithLog, we regularly append additional suffixes to such file names. 
> Thus I propose we simply extend the filter pattern to `_*.marker*`.

Marked as reviewed by mikael (Reviewer).

-

PR: https://git.openjdk.java.net/jdk17/pull/249

Re: [jdk17] RFR: 8268861: Disable Windows-Aarch64 build in GitHub Actions [v3]

[Mikael Vidstedt]

On Wed, 16 Jun 2021 04:53:08 GMT, David Holmes  wrote:

>> This has been failing for a while so disabling it until it can be fixed.
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Completely remove windows-aarch64 entries - take 2

Marked as reviewed by mikael (Reviewer).

-

PR: https://git.openjdk.java.net/jdk17/pull/71

Integrated: 8268214: Use system zlib and disable dtrace when building linux-aarch64 at Oracle

[Mikael Vidstedt]

On Thu, 3 Jun 2021 21:24:21 GMT, Mikael Vidstedt  wrote:

> Mimic what's being done on linux-x64 for consistency.

This pull request has now been integrated.

Changeset: e2d5ff9d
Author:    Mikael Vidstedt 
URL:   
https://git.openjdk.java.net/jdk/commit/e2d5ff9d456dd339ccd21df2f75c4e34e5784d9a
Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8268214: Use system zlib and disable dtrace when building linux-aarch64 at 
Oracle

Reviewed-by: dholmes

-

PR: https://git.openjdk.java.net/jdk/pull/4347

RFR: 8268214: Use system zlib and disable dtrace when building linux-aarch64 at Oracle

[Mikael Vidstedt]

Mimic what's being done on linux-x64 for consistency.

-

Commit messages:
 - 8268214: Use system zlib and disable dtrace when building linux-aarch64 at 
Oracle

Changes: https://git.openjdk.java.net/jdk/pull/4347/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4347=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268214
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4347.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4347/head:pull/4347

PR: https://git.openjdk.java.net/jdk/pull/4347

Integrated: 8268142: Switch to jdk-17+24 for macosx-aarch64 at Oracle

[Mikael Vidstedt]

On Thu, 3 Jun 2021 18:24:51 GMT, Mikael Vidstedt  wrote:

> With promoted builds available it's a good time to switch the boot JDK etc.

This pull request has now been integrated.

Changeset: 1b4378e5
Author:    Mikael Vidstedt 
URL:   
https://git.openjdk.java.net/jdk/commit/1b4378e58e601dae379db851eae2610acf5f3ff7
Stats: 10 lines in 1 file changed: 6 ins; 0 del; 4 mod

8268142: Switch to jdk-17+24 for macosx-aarch64 at Oracle

Reviewed-by: erikj

-

PR: https://git.openjdk.java.net/jdk/pull/4341

RFR: 8268142: Switch to jdk-17+24 for macosx-aarch64 at Oracle

[Mikael Vidstedt]

With promoted builds available it's a good time to switch the boot JDK etc.

-

Commit messages:
 - Merge branch 'master' into 8268142-macos-aarch64-jdk17
 - 8268142: Switch to jdk-17+24 for macosx-aarch64 at Oracle

Changes: https://git.openjdk.java.net/jdk/pull/4341/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4341=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268142
  Stats: 10 lines in 1 file changed: 6 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4341.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4341/head:pull/4341

PR: https://git.openjdk.java.net/jdk/pull/4341

Re: RFR: 8266318: Switch to macos prefix for macOS bundles [v2]

[Mikael Vidstedt]

On Fri, 30 Apr 2021 03:51:18 GMT, Mikael Vidstedt  wrote:

>> Apple rebranded the operating system as "macOS" back in 2016. The JDK 
>> bundles files are still use the legacy "osx" string. They should be 
>> modernized to use "macos" instead.
>
> Mikael Vidstedt has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Fix GHA

Phil, Iris, Erik - thank you for the reviews!

-

PR: https://git.openjdk.java.net/jdk/pull/3801

Integrated: 8266318: Switch to macos prefix for macOS bundles

[Mikael Vidstedt]

On Thu, 29 Apr 2021 19:15:52 GMT, Mikael Vidstedt  wrote:

> Apple rebranded the operating system as "macOS" back in 2016. The JDK bundles 
> files are still use the legacy "osx" string. They should be modernized to use 
> "macos" instead.

This pull request has now been integrated.

Changeset: 096e9e5d
Author:Mikael Vidstedt 
URL:   
https://git.openjdk.java.net/jdk/commit/096e9e5d13183f947089b5c7923890591490a2ce
Stats: 21 lines in 3 files changed: 2 ins; 4 del; 15 mod

8266318: Switch to macos prefix for macOS bundles

Reviewed-by: prr, erikj, iris

-

PR: https://git.openjdk.java.net/jdk/pull/3801

Re: RFR: 8266318: Switch to macos prefix for macOS bundles [v2]

[Mikael Vidstedt]

> Apple rebranded the operating system as "macOS" back in 2016. The JDK bundles 
> files are still use the legacy "osx" string. They should be modernized to use 
> "macos" instead.

Mikael Vidstedt has updated the pull request incrementally with one additional 
commit since the last revision:

  Fix GHA

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3801/files
  - new: https://git.openjdk.java.net/jdk/pull/3801/files/1732c917..fb851a34

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3801=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3801=00-01

  Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3801.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3801/head:pull/3801

PR: https://git.openjdk.java.net/jdk/pull/3801

RFR: 8266318: Switch to macos prefix for macOS bundles

[Mikael Vidstedt]

Apple rebranded the operating system as "macOS" back in 2016. The JDK bundles 
files are still use the legacy "osx" string. They should be modernized to use 
"macos" instead.

-

Commit messages:
 - 8266318: Switch to macos prefix for macOS bundles

Changes: https://git.openjdk.java.net/jdk/pull/3801/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3801=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266318
  Stats: 11 lines in 2 files changed: 2 ins; 4 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3801.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3801/head:pull/3801

PR: https://git.openjdk.java.net/jdk/pull/3801

Integrated: 8265782: Bump bootjdk to jdk-17+19 on macosx-aarch64 at Oracle

[Mikael Vidstedt]

On Thu, 22 Apr 2021 18:15:58 GMT, Mikael Vidstedt  wrote:

> The bootjdk used for macosx-aarch64 at Oracle is a custom build of JDK 16 
> from early December, so does not include all the JDK 16 GA functionality. 
> This leads to build issues after JDK-8263621 which uses a method not included 
> in the custom version. Let's bump the bootjdk used for macosx-aarch64 to 
> jdk-17+19 instead.

This pull request has now been integrated.

Changeset: 0e005989
Author:Mikael Vidstedt 
URL:   https://git.openjdk.java.net/jdk/commit/0e005989
Stats: 28 lines in 1 file changed: 5 ins; 12 del; 11 mod

8265782: Bump bootjdk to jdk-17+19 on macosx-aarch64 at Oracle

Reviewed-by: iignatyev, tbell, iris, erikj

-

PR: https://git.openjdk.java.net/jdk/pull/3636

RFR: 8265782: Bump bootjdk to jdk-17+19 on macosx-aarch64 at Oracle

[Mikael Vidstedt]

The bootjdk used for macosx-aarch64 at Oracle is a custom build of JDK 16 from 
early December, so does not include all the JDK 16 GA functionality. This leads 
to build issues after JDK-8263621 which uses a method not included in the 
custom version. Let's bump the bootjdk used for macosx-aarch64 to jdk-17+19 
instead.

-

Commit messages:
 - 8265782: Bump bootjdk to jdk-17+19 on macosx-aarch64 at Oracle

Changes: https://git.openjdk.java.net/jdk/pull/3636/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3636=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265782
  Stats: 28 lines in 1 file changed: 5 ins; 12 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3636.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3636/head:pull/3636

PR: https://git.openjdk.java.net/jdk/pull/3636

Integrated: 8257459: Bump minimum boot jdk to JDK 16

[Mikael Vidstedt]

On Sat, 17 Apr 2021 07:20:21 GMT, Mikael Vidstedt  wrote:

> With JDK 16 having gone GA about a month ago it's time to bump the minimum 
> boot JDK version for mainline/JDK 17.
> 
> Testing: tier1-5.

This pull request has now been integrated.

Changeset: 72c88fc4
Author:Mikael Vidstedt 
URL:   https://git.openjdk.java.net/jdk/commit/72c88fc4
Stats: 13 lines in 3 files changed: 0 ins; 0 del; 13 mod

8257459: Bump minimum boot jdk to JDK 16

Reviewed-by: darcy, iris, erikj

-

PR: https://git.openjdk.java.net/jdk/pull/3555

Re: RFR: 8257459: Bump minimum boot jdk to JDK 16

[Mikael Vidstedt]

On Sat, 17 Apr 2021 07:20:21 GMT, Mikael Vidstedt  wrote:

> With JDK 16 having gone GA about a month ago it's time to bump the minimum 
> boot JDK version for mainline/JDK 17.
> 
> Testing: tier1-5.

Joe, Iris, Erik - thank you for the reviews!

-

PR: https://git.openjdk.java.net/jdk/pull/3555

RFR: 8257459: Bump minimum boot jdk to JDK 16

[Mikael Vidstedt]

With JDK 16 having gone GA about a month ago it's time to bump the minimum boot 
JDK version for mainline/JDK 17.

Testing: tier1-5.

-

Commit messages:
 - Update GHA configuration
 - 8257459: Bump minimum boot jdk to JDK 16

Changes: https://git.openjdk.java.net/jdk/pull/3555/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3555=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257459
  Stats: 13 lines in 3 files changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3555.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3555/head:pull/3555

PR: https://git.openjdk.java.net/jdk/pull/3555

Re: RFR: JDK-8265373: Change to GCC 10.3 for building on Linux at Oracle [v2]

[Mikael Vidstedt]

On Fri, 16 Apr 2021 20:36:05 GMT, Erik Joelsson  wrote:

>> Oracle is updating the version of GCC for building the JDK to 10.3.
>> 
>> In addition to the version bump, I'm also enabling cross compilation OOTB 
>> using jib from a linux-aarch64 to linux-x64 binaries, which was the last 
>> missing combination. (Native x64, native aarch64, cross from x64 to aarch64 
>> all worked already and will continue to do so.)
>
> Erik Joelsson has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Fix configure args for linux-x64

Marked as reviewed by mikael (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3551

Re: RFR: JDK-8265373: Change to GCC 10.3 for building on Linux at Oracle

[Mikael Vidstedt]

On Fri, 16 Apr 2021 19:21:11 GMT, Erik Joelsson  wrote:

> Oracle is updating the version of GCC for building the JDK to 10.3.
> 
> In addition to the version bump, I'm also enabling cross compilation OOTB 
> using jib from a linux-aarch64 to linux-x64 binaries, which was the last 
> missing combination. (Native x64, native aarch64, cross from x64 to aarch64 
> all worked already and will continue to do so.)

make/conf/jib-profiles.js line 426:

> 424: (input.build_cpu == "x64" ? common.configure_args_64bit 
> : "--openjdk-target=x86_64-linux-gnu"),
> 425: "--with-zlib=system", "--disable-dtrace",
> 426: (input.build_cpu != "x64" ? 
> "--openjdk-target=x86_64-linux-gnu" : null),

Doesn't this add `--openjdk-target=x86_64-linux-gnu` twice when build_cpu is 
not "x64"?

-

PR: https://git.openjdk.java.net/jdk/pull/3551

Re: RFR: JDK-8265371: Change to Visual Studio 2019 16.9.3 for building on Windows at Oracle

[Mikael Vidstedt]

On Fri, 16 Apr 2021 18:58:27 GMT, Erik Joelsson  wrote:

> Oracle is updating the minor version of Visual Studio for building the JDK to 
> 16.9.3.

Marked as reviewed by mikael (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3550

Integrated: 8264224: Add macosx-aarch64 to Oracle build configurations

[Mikael Vidstedt]

On Tue, 30 Mar 2021 06:25:21 GMT, Mikael Vidstedt  wrote:

> This adds the necessary macosx-aarch64 support to the build configurations at 
> Oracle.

This pull request has now been integrated.

Changeset: 008fc75a
Author:Mikael Vidstedt 
URL:   https://git.openjdk.java.net/jdk/commit/008fc75a
Stats: 41 lines in 1 file changed: 25 ins; 0 del; 16 mod

8264224: Add macosx-aarch64 to Oracle build configurations

Reviewed-by: serb, erikj

-

PR: https://git.openjdk.java.net/jdk/pull/3258

Re: RFR: 8264224: Add macosx-aarch64 to Oracle build configurations [v4]

[Mikael Vidstedt]

> This adds the necessary macosx-aarch64 support to the build configurations at 
> Oracle.

Mikael Vidstedt has updated the pull request with a new target base due to a 
merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into 8264224-macosx-aarch64
 - Merge branch 'master' into 8264224-macosx-aarch64
 - Merge branch 'master' into 8264224-macosx-aarch64
 - Remove SETFILE override
 - 8264224: Add macosx-aarch64 to Oracle build configurations

-

Changes: https://git.openjdk.java.net/jdk/pull/3258/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3258=03
  Stats: 41 lines in 1 file changed: 25 ins; 0 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3258.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3258/head:pull/3258

PR: https://git.openjdk.java.net/jdk/pull/3258

Re: RFR: 8264224: Add macosx-aarch64 to Oracle build configurations [v3]

[Mikael Vidstedt]

On Wed, 31 Mar 2021 19:02:46 GMT, Mikael Vidstedt  wrote:

>> This adds the necessary macosx-aarch64 support to the build configurations 
>> at Oracle.
>
> Mikael Vidstedt has updated the pull request with a new target base due to a 
> merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into 8264224-macosx-aarch64
>  - Remove SETFILE override
>  - 8264224: Add macosx-aarch64 to Oracle build configurations

The Xcode12.4 pre-requisite change (JDK-8264623) was integrated earlier today 
and I have merged in latest master in the PR. Please review.

-

PR: https://git.openjdk.java.net/jdk/pull/3258

Integrated: 8264623: Change to Xcode 12.4 for building on Macos at Oracle

[Mikael Vidstedt]

On Wed, 7 Apr 2021 22:22:55 GMT, Mikael Vidstedt  wrote:

> Switch to Xcode 12.4 for building macosx-x64 at Oracle. The new lldb 
> dependency is needed to ensure that we can collect information when testing 
> on older versions of macOS which do not support Xcode 12.4.

This pull request has now been integrated.

Changeset: 27f4b271
Author:    Mikael Vidstedt 
URL:   https://git.openjdk.java.net/jdk/commit/27f4b271
Stats: 15 lines in 1 file changed: 12 ins; 0 del; 3 mod

8264623: Change to Xcode 12.4 for building on Macos at Oracle

Reviewed-by: erikj

-

PR: https://git.openjdk.java.net/jdk/pull/3388

RFR: 8264623: Change to Xcode 12.4 for building on Macos at Oracle

[Mikael Vidstedt]

Switch to Xcode 12.4 for building macosx-x64 at Oracle. The new lldb dependency 
is needed to ensure that we can collect information when testing on older 
versions of macOS which do not support Xcode 12.4.

-

Commit messages:
 - 8264623: Change to Xcode 12.4 for building on Macos at Oracle

Changes: https://git.openjdk.java.net/jdk/pull/3388/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3388=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264623
  Stats: 15 lines in 1 file changed: 12 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3388.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3388/head:pull/3388

PR: https://git.openjdk.java.net/jdk/pull/3388

Re: RFR: 8264224: Add macosx-aarch64 to Oracle build configurations [v3]

[Mikael Vidstedt]

> This adds the necessary macosx-aarch64 support to the build configurations at 
> Oracle.

Mikael Vidstedt 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 three additional 
commits since the last revision:

 - Merge branch 'master' into 8264224-macosx-aarch64
 - Remove SETFILE override
 - 8264224: Add macosx-aarch64 to Oracle build configurations

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3258/files
  - new: https://git.openjdk.java.net/jdk/pull/3258/files/6673a4f9..20fdddad

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3258=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3258=01-02

  Stats: 3451 lines in 160 files changed: 2380 ins; 555 del; 516 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3258.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3258/head:pull/3258

PR: https://git.openjdk.java.net/jdk/pull/3258

Re: RFR: 8264224: Add macosx-aarch64 to Oracle build configurations [v2]

[Mikael Vidstedt]

On Tue, 30 Mar 2021 14:42:22 GMT, Kevin Rushforth  wrote:

>> To answer Magnus, on line 1133, we define a different dependency, called 
>> "lldb". That dependency is an older devkit which only purpose is to provide 
>> lldb for the failure handler when running tests. We need this because we are 
>> still running tests on Macos < 10.15, but the new devkit requires 10.15.
>
> I agree that it would be ideal for the update to Xcode 12.x to be done 
> separately. Is there a JBS issue filed for this update? Alternatively, you 
> could use `/issue add nnn` to add that JBS issue to this PR.

Thank you for catching the accidental Xcode update for macosx-x64. It was not 
my intention to include that as part of this change.

That said, right now it's looking highly likely that we will have bumped it for 
macosx-x64 before this PR is ready for integration anyway. Therefore, for now I 
will keep it as-is, but integration of this PR is effectively blocked until it 
has been resolved - either by making it conditional on the architecture or by 
the switch to "Xcode12.4+1.0" for macosx-x64 making it into mainline.

As Erik mentions, the new "lldb" dependency is needed to support running the 
failure handler+lldb when testing on older macOS versions which do not support 
Xcode 12.4. Assuming the switch to Xcode 12.4 as devkit for macosx-x64 makes it 
into mainline I believe the logic is correct.

-

PR: https://git.openjdk.java.net/jdk/pull/3258

Re: RFR: 8264224: Add macosx-aarch64 to Oracle build configurations [v2]

[Mikael Vidstedt]

On Tue, 30 Mar 2021 12:31:25 GMT, Erik Joelsson  wrote:

>> I don't think we need to set SETFILE anymore. This used to be needed because 
>> the SetFile binary in older Xcode versions was 32 bit and Catalina no longer 
>> supports 32 bit apps. This should definitely not be a problem on aarch64.
>
> I don't think we need the compatible cds alignment here. This was added for 
> x64 mainly to make it run correctly in rosetta IIRC. Macos aarch64 binaries 
> will most likely run well in their native environment without this.

I'll drop the SETFILE override - I removed it, ran a test job and everything 
seems to work just as expected.

I agree with Erik that the CDS alignment shouldn't be an issue here.

-

PR: https://git.openjdk.java.net/jdk/pull/3258

Re: RFR: 8264224: Add macosx-aarch64 to Oracle build configurations [v2]

[Mikael Vidstedt]

> This adds the necessary macosx-aarch64 support to the build configurations at 
> Oracle.

Mikael Vidstedt has updated the pull request incrementally with one additional 
commit since the last revision:

  Remove SETFILE override

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3258/files
  - new: https://git.openjdk.java.net/jdk/pull/3258/files/dbfe5dd7..6673a4f9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3258=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3258=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3258.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3258/head:pull/3258

PR: https://git.openjdk.java.net/jdk/pull/3258

RFR: 8264224: Add macosx-aarch64 to Oracle build configurations

[Mikael Vidstedt]

This adds the necessary macosx-aarch64 support to the build configurations at 
Oracle.

-

Commit messages:
 - 8264224: Add macosx-aarch64 to Oracle build configurations

Changes: https://git.openjdk.java.net/jdk/pull/3258/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3258=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264224
  Stats: 55 lines in 1 file changed: 38 ins; 0 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3258.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3258/head:pull/3258

PR: https://git.openjdk.java.net/jdk/pull/3258

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

[Mikael Vidstedt]

On Wed, 3 Feb 2021 20:08:28 GMT, Mikael Vidstedt  wrote:

>>> I wonder if this is the right choice
>>> ...
>>> ```
>>> OopStorageParIterPerf::~OopStorageParIterPerf() {
>>> ...
>>> ```
>>> 
>> 
>> The transition in OopStorageParIterPerf was made for gtest setup to execute 
>> in WXWrite context. For tests themselves, defining macro set WXWrite.
>> 
>> I've simplified the scheme and now we switch to WXWrite once at the gtest 
>> launcher. So this transition was dropped.
>> 
>> I've also refreshed my memory and tried to switch to WXWrite as close as 
>> possible to each place where we'll be writing executable memory. There are a 
>> lot of such places! As you correctly noted, code cache contains objects, not 
>> plain data. For example, CodeCache memory management structures, 
>> CompiledMethod, ...  are there, so we need more WXWrite switches than we 
>> have in the current approach. I had a comparable amount of them just to run 
>> -version, but certainly not enough to run tier1 tests.
>> 
>> Following your advice, I don't require a known "from" state anymore. So a 
>> few W^X transitions were dropped, e.g. when the JVM code calls a JNI entry 
>> function, which expects to be called from the native code. I had to switch 
>> to WXExec just only to satisfy the expectations. After the update, we don't 
>> need this anymore.
>> 
>> W^X switches are mostly hidden by VM_ENTRY and similar macros. Some JVM 
>> functions are not marked as entries for some reason, although they are 
>> called directly from e.g. interpreter. I added W^X management to such 
>> functions.
>> 
>> Thank you!
>
> Out of curiosity, have you looked at the performance of the W^X state 
> transition? In particular I'm wondering if the cost is effectively negligible 
> so doing it unconditionally on JVM entry is a no-brainer and just 
> easier/cleaner than the alternatives, or if there are reasons to look at only 
> doing the transition if/when needed (perhaps do it lazily and revert back to 
> X when leaving the JVM?).

You read my mind, Andrew. Unless, of course, it's optimized to leverage the 
fact that it's thread-specific..

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

[Mikael Vidstedt]

On Wed, 3 Feb 2021 20:05:29 GMT, Anton Kozlov  wrote:

>> Thank you all for your comments regarding W^X implementation. I've made a 
>> change that reduces the footprint of the implementation, also addressing 
>> most of the comments. I'll revisit them individually to make sure nothing is 
>> forgotten.
>> 
>> The basic principle has not changed: when we execute JVM code (owned by 
>> libjvm.so, starting from JVM entry function), we switch to Write state. When 
>> we leave JVM to execute generated or JNI code, we switch to Executable 
>> state. I would like to highlight that JVM code does not mean the VM state of 
>> the java thread. After @stefank's suggestion, I could also drop a few W^X 
>> state switches, so now it should be more clear that switches are tied to JVM 
>> entry functions.
>
>> I wonder if this is the right choice
>> ...
>> ```
>> OopStorageParIterPerf::~OopStorageParIterPerf() {
>> ...
>> ```
>> 
> 
> The transition in OopStorageParIterPerf was made for gtest setup to execute 
> in WXWrite context. For tests themselves, defining macro set WXWrite.
> 
> I've simplified the scheme and now we switch to WXWrite once at the gtest 
> launcher. So this transition was dropped.
> 
> I've also refreshed my memory and tried to switch to WXWrite as close as 
> possible to each place where we'll be writing executable memory. There are a 
> lot of such places! As you correctly noted, code cache contains objects, not 
> plain data. For example, CodeCache memory management structures, 
> CompiledMethod, ...  are there, so we need more WXWrite switches than we have 
> in the current approach. I had a comparable amount of them just to run 
> -version, but certainly not enough to run tier1 tests.
> 
> Following your advice, I don't require a known "from" state anymore. So a few 
> W^X transitions were dropped, e.g. when the JVM code calls a JNI entry 
> function, which expects to be called from the native code. I had to switch to 
> WXExec just only to satisfy the expectations. After the update, we don't need 
> this anymore.
> 
> W^X switches are mostly hidden by VM_ENTRY and similar macros. Some JVM 
> functions are not marked as entries for some reason, although they are called 
> directly from e.g. interpreter. I added W^X management to such functions.

Out of curiosity, have you looked at the performance of the W^X state 
transition? In particular I'm wondering if the cost is effectively negligible 
so doing it unconditionally on JVM entry is a no-brainer and just 
easier/cleaner than the alternatives, or if there are reasons to look at only 
doing the transition if/when needed (perhaps do it lazily and revert back to X 
when leaving the JVM?).

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: [jdk16] RFR: 8259794: Remove EA from JDK 16 version string starting with Initial RC promotion on Feb 04, 2021(B35)

[Mikael Vidstedt]

On Tue, 2 Feb 2021 18:17:55 GMT, Jesper Wilhelmsson  
wrote:

> We have our (first) RC candidate build for JDK 16 on Feb 04, 2021. We need to 
> remove the EA from version string for this build (b35) and going forward.
> 
> Pushing this for @pashh

Marked as reviewed by mikael (Reviewer).

-

PR: https://git.openjdk.java.net/jdk16/pull/146

Re: RFR: JDK-8260669: Missing quotes in fixpath.sh

[Mikael Vidstedt]

On Fri, 29 Jan 2021 19:54:12 GMT, Erik Joelsson  wrote:

> The build on Windows can fail if certain directory names are present in root 
> directory of the workspace. In particular I've observed that the single 
> letter 'p' is triggering this problem. This is caused by missing quotes 
> around [:upper:] in a 'tr' call in fixpath.sh.

Marked as reviewed by mikael (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/2318

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

[Mikael Vidstedt]

On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy  wrote:

> Start of JDK 17 updates.

Marked as reviewed by mikael (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/1531

Re: RFR: JDK-8257633: Missing -mmacosx-version-min=X flag when linking libjvm

[Mikael Vidstedt]

On Fri, 4 Dec 2020 14:44:49 GMT, Erik Joelsson  wrote:

> We have historically provided -mmacosx-version-min=10.9.0 flags when 
> compiling and linking all our native executables and libraries on Macosx. 
> That flag seems to have disappeared when linking libjvm. This is sometimes 
> causing our macosx builds to not be able to run on older versions of macosx.

Marked as reviewed by mikael (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/1623

Re: RFR: JDK-8256810: Incremental rebuild broken on Macosx

[Mikael Vidstedt]

On Sat, 21 Nov 2020 00:12:30 GMT, Erik Joelsson  wrote:

> After fixing JDK-8256751, I noticed that the fix-deps-file macro isn't 
> actually doing the right thing at all. It seems clang on Macosx is 
> inconsistent with outputting relative or absolute paths in the deps files, so 
> some files end up with double WORKSPACE_ROOT in the paths. It's also not 
> handling the trailing slash after WORKSPACE_ROOT correctly, so some files are 
> missing the slash between WORKSPACE_ROOT and the original relative path.
> 
> This time I have checked the output carefully.

Marked as reviewed by mikael (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/1360

Re: RFR: 8255785: X11 libraries should not be required by configure for headless only

[Mikael Vidstedt]

On Tue, 3 Nov 2020 00:33:09 GMT, Magnus Ihse Bursie  wrote:

> If we build a headless only JDK, configure will require X11 libraries and 
> headers to be present. This used to be necessary, but thanks to massive 
> cleanups in the AWT headless code, this is no longer the case.
> 
> We should fix configure so that headless can be built without X11 libraries 
> and headers.

Marked as reviewed by mikael (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/1025

Re: RFR: JDK-8255612: Explicitly disable dtrace for Oracle OpenJDK Linux builds

[Mikael Vidstedt]

On Thu, 29 Oct 2020 20:53:00 GMT, Erik Joelsson  wrote:

> The OpenJDK build on Linux will determine if the JVM feature "dtrace" should 
> be enabled based on the availability of dtrace on the build host. For Oracle 
> produced OpenJDK builds, we implicitly had this disabled because our build 
> environment didn't have it installed. Rather than having to trust the build 
> host to not have dtrace installed, we would like to make this setting 
> explicit. We don't want to change the default behavior of OpenJDK, so we are 
> adding this configure flag to the jib-profiles.js configuration where 
> appropriate, so it only affects Oracle produced builds.

Marked as reviewed by mikael (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/946

Re: RFR: 8254862: lldb in devkit doesn't work

[Mikael Vidstedt]

On Fri, 16 Oct 2020 20:34:15 GMT, Erik Joelsson  wrote:

> This patch adds the lldb framework to the macosx devkit to make it possible 
> to run the lldb debugger.

Marked as reviewed by mikael (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/711

Integrated: 8248984: Bump minimum boot jdk to JDK 15

[Mikael Vidstedt]

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.

This pull request has now been integrated.

Changeset: 527b0e44
Author:Mikael Vidstedt 
URL:   https://git.openjdk.java.net/jdk/commit/527b0e44
Stats: 18 lines in 2 files changed: 0 ins; 13 del; 5 mod

8248984: Bump minimum boot jdk to JDK 15

Reviewed-by: darcy, erikj, dholmes

-

PR: https://git.openjdk.java.net/jdk/pull/326

Integrated: 8253616: Change to GCC 10.2 for building on Linux at Oracle

[Mikael Vidstedt]

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.

This pull request has now been integrated.

Changeset: d25b03e9
Author:    Mikael Vidstedt 
URL:   https://git.openjdk.java.net/jdk/commit/d25b03e9
Stats: 33 lines in 4 files changed: 20 ins; 0 del; 13 mod

8253616: Change to GCC 10.2 for building on Linux at Oracle

Reviewed-by: erikj

-

PR: https://git.openjdk.java.net/jdk/pull/349

Re: RFR: 8253616: Change to GCC 10.2 for building on Linux at Oracle [v2]

[Mikael Vidstedt]

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

Mikael Vidstedt has updated the pull request with a new target base due to a 
merge or a rebase. The pull request now
contains two commits:

 - Merge
 - 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=01
  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

Re: RFR: 8253615: Change to Visual Studio 2019 16.7.2 for building on Windows at Oracle [v2]

[Mikael Vidstedt]

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

RFR: 8253616: Change to GCC 10.2 for building on Linux at Oracle

[Mikael Vidstedt]

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

Re: RFR: 8253615: Change to Visual Studio 2019 16.7.2 for building on Windows at Oracle

[Mikael Vidstedt]

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

RFR: 8248984: Bump minimum boot jdk to JDK 15

[Mikael Vidstedt]

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: RFC: 8229469 JEP 386: Alpine Linux/x64 Port

[Mikael Vidstedt]

Great to see this - thank you for all the great work you’re putting into it!

The changes are in line with what I’m expecting given that I’ve looked at them 
before, so looks good to me! That said, I’ve looked at this so many times now - 
and after all even authored some of the original changes - so I would very much 
appreciate some other hotspot and core libs eyes on it. :)

One very minor thing I realized:

WB_GetLibcName now returns “glibc” by default (unless MUSL_LIBC is defined) 
which means it may return “glibc” on platforms where the default library really 
isn’t GNU libc. I will work just fine for what it’s currently being used for 
(isMusl), but is potentially a bit misleading.

Cheers,
Mikael

> On Sep 1, 2020, at 4:41 AM, Aleksei Voitylov  
> wrote:
> 
> Hi,
> 
> JEP 386 is now Candidate [1] and as we resolved all outstanding issues
> within the Portola project I'd like to ask for comments from HotSpot,
> Core Libs (changes in libjli/java_md.c), and Build groups before moving
> the JEP to Proposed to Target:
> 
> http://cr.openjdk.java.net/~avoitylov/webrev.8247589.01/
> 
> Testing:
> 
> JTReg, VM TestBase on all platforms (Linux x86_64, Linux x86, Linux Arm,
> Linux AArch64, Linux PPC, Windows x86_64, Windows x86, Mac) with no
> regressions. A downport of these changes to 14 passes JCK 14 on these
> platforms.
> 
> The port was tested on Alpine Linux 3.8 and 3.11 with JTReg, VM
> TestBase. There are no differences with Linux x86_64  with the exception
> of SA which is not supported as per the JEP. A downport of these changes
> to 14 passes JCK 14 on Alpine Linux.
> 
> Thanks,
> 
> -Aleksei
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8229469
> 
> 

RFR(XS): 8251316: Sanity check the JDK under test before running tests

[Mikael Vidstedt]

Please review this small change which adds a sanity check run of the JDK under 
test before running jtreg tests.

JBS: https://bugs.openjdk.java.net/browse/JDK-8251316 

webrev: 
https://cr.openjdk.java.net/~mikael/webrevs/8251316/webrev.00/open/webrev 


* Background (from JBS)

If the JDK under test is severely broken, if for example it crashes on startup, 
jtreg will typically just report "Error: cannot determine version for JDK: 
/path/to/bin/java" without any additional information. To make it faster to 
diagnose the problem it would be useful to do some sanity checking of the JDK 
before invoking jtreg.

* Testing

I verified locally that a crashing VM does produce the expected output both on 
the console and in the sanity.log log file
Running tier1 now for good luck.

Cheers,
Mikael

RFR(XS): 8250899: Backout JDK-8249628 from jdk/jdk

[Mikael Vidstedt]

Please review this small change which will back out/revert the upcoming 
change[1] to remove the “ea” suffix from the JDK 15 version string. 
Specifically, when that change gets pushed to jdk/jdk15 and then bulk 
integrated to jdk/jdk it needs to be immediately reverted to ensure that 
jdk/jdk remains in “ea” mode.

--- old/make/autoconf/version-numbers   2020-07-31 13:44:01.220895013 -0700
+++ new/make/autoconf/version-numbers   2020-07-31 13:44:00.932889446 -0700
@@ -38,7 +38,7 @@
 DEFAULT_VERSION_CLASSFILE_MINOR=0
 DEFAULT_ACCEPTABLE_BOOT_VERSIONS="14 15 16"
 DEFAULT_JDK_SOURCE_TARGET_VERSION=16
-DEFAULT_PROMOTED_VERSION_PRE=
+DEFAULT_PROMOTED_VERSION_PRE=ea
 
 LAUNCHER_NAME=openjdk
 PRODUCT_NAME=OpenJDK

Cheers,
Mikael

[1] https://bugs.openjdk.java.net/browse/JDK-8249628 

Re: RFR: JDK-8213214: Set -Djava.io.tmpdir= when running tests

[Mikael Vidstedt]

The makefile changes look good to me!

Cheers,
Mikael

> On Jun 16, 2020, at 12:22 PM, Erik Joelsson  wrote:
> 
> (re-sending this as it doesn't look like it was delivered)
> 
> There are a lot of jtreg tests that use temporary files. These temporary 
> files add up over time and fill up the global temp directories on our test 
> systems. To tackle this, we should try to redirect these temporary files into 
> a directory controlled by the test framework. Jtreg does not do this, but we 
> can set -Djava.io.tmpdir from RunTest.gmk. This will not prevent all temp 
> files from being created outside of the work dir, but at least most.
> 
> 
> I have found one test where this becomes an issue, 
> java/nio/file/Path/Misc.java on Windows when running in elevated mode with 
> the workspace on a subst drive. This looks like an actual issue in the 
> product, so I have filed a separate bug for it [1]. Since we currently use 
> subst in our distributed test system to get around Windows path length 
> issues, we are hitting this problem. While the bug is being evaluated, I have 
> implemented a workaround in the test so that it is able to handle the known 
> situation. I would like to have someone from core-libs look at the workaround.
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8213214/webrev.01/
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8213214
> 
> /Erik
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8213216
> 
> 

Re: [16] RFR (XS) 8246803: Update link to license in Docs.gmk

[Mikael Vidstedt]

Looks good.

Cheers,
Mikael

> On Jun 8, 2020, at 10:31 PM, Iris Clark  wrote:
> 
> Hi.
> 
> Please review this small change to update the link to the Specification 
> license referenced
> by the JavaDoc API for JDK 16:
> 
> bug:
> 
>8246803: Update link to spec license in Docs.gmk
>https://bugs.openjdk.java.net/browse/JDK-8246803
> 
> webrev:
> 
>https://cr.openjdk.java.net/~iris/8246803/webrev/
> 
> Due to changes in the server hosting the Spec license redirect, we must use a 
> new URL
> in JDK 16 which omits the "technetwork" token.  The following link for 16 is 
> now live:
> 
>https://www.oracle.com/java/javase/terms/license/java16speclicense.html
> 
> It should correspond to the new link generated at JDK 16 build time  The link 
> for
> JDK 15 is unchanged.
> 
> Thanks,
> Iris

Re: OpenJDK 10 zero For Mips32el java -version IncompatilveClassChangeError

[Mikael Vidstedt]

Glad you got it working!

Still curious though: any particular reason for building jdk10 specifically? :)

Cheers,
Mikael

> On Jun 5, 2020, at 3:30 PM, William Larson  wrote:
> 
> Hello Mikael,
> This is how I get the sources
> 
> hg clone http://hg.openjdk.java.net/jdk10/jdk10 
> 
> cd jdk10
> bash get_source.sh
> 
> I checked my current build and this is what I see (note the 9
> 
> AC_DEFUN([BOOTJDK_CHECK_BUILD_JDK],
> [
>   
> # Extra M4 quote needed to protect [] in grep expression.
> [FOUND_CORRECT_VERSION=`echo $BUILD_JDK_VERSION | $EGREP 
> '\"9([\.+-].*)?\"'`]
> if test "x$FOUND_CORRECT_VERSION" = x; then
>   AC_MSG_NOTICE([Potential Build JDK found at $BUILD_JDK is incorrect 
> JDK version ($BUILD_JDK_VERSION); ignoring])
>   AC_MSG_NOTICE([(Your Build JDK must be version 9)])
>   BUILD_JDK_FOUND=no
>   
> ])
> 
> To be sure I wasn't going insane I ran the above (hg clone 
> http://hg.openjdk.java.net/jdk10/jdk10 
> ) in a new directory 
> 
> Then I noticed something your URL is 
> http://hg.openjdk.java.net/jdk/jdk10 
> Mine is (note the extra 10 after .net/jdk)
> http://hg.openjdk.java.net/jdk10/jdk10 
> 
> 
> Maybe I misread something but this is highly confusing as this is what is in 
> the build docs
> 
> I just figured it out as well. I build it from your tree ( note .net/jdk not 
> ./net/jdk10 http://hg.openjdk.java.net/jdk/jdk10)  
> it works perfectly  thanks again.
> For Mips You must apply patch ( I did it by hand)
> Here is the link for that as well: 
> https://groups.google.com/forum/#!topic/linux.debian.bugs.dist/Tmgse0HIzDc 
> 
> 
> 
> Make images works and runs on the qemu.
> 
> Thanks for this project  and the support I truly appreciate it.
> 

Re: OpenJDK 10 zero For Mips32el java -version IncompatilveClassChangeError

[Mikael Vidstedt]

> On Jun 5, 2020, at 1:16 PM, Mikael Vidstedt  <mailto:mikael.vidst...@oracle.com>> wrote:
> 
> 
> 
>> On Jun 5, 2020, at 10:27 AM, William Larson > <mailto:wlars...@gmail.com>> wrote:
>> 
>> Hello Magnus
>> 
>> I got the source code from the openjdk mercurial repository following the
>> building.html exactly.
> 
> Can you give some more details here please - exactly how do you get the 
> sources?

Ah! I’m going to guess that you grabbed the sources from here:

http://hg.openjdk.java.net/jdk10/jdk10 <http://hg.openjdk.java.net/jdk10/jdk10>

That’s the “old” forest for jdk10, used before the repo consolidation work in 
JEP 296 https://openjdk.java.net/jeps/296 <https://openjdk.java.net/jeps/296>. 
The jdk10 work moved into this repo after that:

http://hg.openjdk.java.net/jdk/jdk10 <http://hg.openjdk.java.net/jdk/jdk10>

Which is where you’ll find the “GA” for JDK 10. Please use that repo instead.

Out of curiosity btw - why JDK 10?

Cheers,
Mikael

> 
>> Here is the version numbers
>> DEFAULT_VERSION_MAJOR=10
>> DEFAULT_VERSION_MINOR=0
>> DEFAULT_VERSION_SECURITY=0
>> DEFAULT_VERSION_PATCH=0
>> 
>> LAUNCHER_NAME=openjdk
>> PRODUCT_NAME=OpenJDK
>> PRODUCT_SUFFIX="Runtime Environment"
>> JDK_RC_PLATFORM_NAME=Platform
>> COMPANY_NAME=N/A
>> HOTSPOT_VM_DISTRO="OpenJDK"
>> 
>> # Might need better names for these
>> MACOSX_BUNDLE_NAME_BASE="OpenJDK"
>> MACOSX_BUNDLE_ID_BASE="net.java.openjdk"
>> 
>> The JDK10 is modified with this patch for mips
>> https://groups.google.com/forum/#!topic/linux.debian.bugs.dist/Tmgse0HIzDc 
>> <https://groups.google.com/forum/#!topic/linux.debian.bugs.dist/Tmgse0HIzDc>
>> 
>> After the above modification (note I have tried unmodified and modified
>> JDK10 for the x64 build with no difference in outcome)
>> - First I run in JDK 10
>> When I run this configure in jdk 10 (builds JDK for Linux x64)
>> bash configure --with-conf-name=buildjdk && make jdk CONF=buildjdk
>> 
>> It Compiles Successfully
>> 
>> Then I run in JDK 10
>> 
>> bash configure --openjdk-target=mipsel-oe-linux
>> --with-sysroot=/usr/local/oecore-i686/sysroots/mips32el-nf-oe-linux
>> --with-toolchain-path=/usr/local/oecore-i686/sysroots/i686-oesdk-linux/usr/bin/mipsel-oe-linux
>> --with-libffi=/usr/local/oecore-i686/sysroots/mips32el-nf-oe-linux/usr/src/debug/libffi/3.0.13-r0/libffi-3.0.13
>> --with-jvm-variants=zero
>> --with-build-jdk=/opt/FaceClockJava/jdk10/build/buildjdk/jdk
>> --with-stdc++lib=dynamic
>> 
>> checking for Boot JDK... /usr/lib/jvm/java-8-oracle
>> checking Boot JDK version... java version "1.8.0_171" Java(TM) SE Runtime
>> Environment (build 1.8.0_171-b11) Java HotSpot(TM) 64-Bit Server VM (build
>> 25.171-b11, mixed mode)
>> checking for java in Boot JDK... ok
>> checking for javac in Boot JDK... ok
>> checking for javah in Boot JDK... ok
>> checking for jar in Boot JDK... ok
>> checking for jarsigner in Boot JDK... ok
>> checking if Boot JDK supports modules... no
>> checking if Boot JDK is 32 or 64 bits... 64
>> configure: Found potential Build JDK using configure arguments
>> configure: Potential Build JDK found at
>> /opt/FaceClockJava/jdk10/build/buildjdk/jdk is incorrect JDK version
>> (openjdk version "10-internal"); ignoring
>> configure: (Your Build JDK must be version 9)
> 
> This part doesn’t make sense. Here’s the error message line in jdk10:
> 
> http://hg.openjdk.java.net/jdk/jdk10/file/b09e56145e11/make/autoconf/boot-jdk.m4#l491
>  
> <http://hg.openjdk.java.net/jdk/jdk10/file/b09e56145e11/make/autoconf/boot-jdk.m4#l491><http://hg.openjdk.java.net/jdk/jdk10/file/b09e56145e11/make/autoconf/boot-jdk.m4#l491
>  
> <http://hg.openjdk.java.net/jdk/jdk10/file/b09e56145e11/make/autoconf/boot-jdk.m4#l491>>
> 
> As you can see the “hard coded” error message is "Your Build JDK must be 
> version 10”. Can you check what that file and line looks like in your sources?
> 
> It would be very helpful to know exactly where you got the sources from 
> and/or why your error message does not match the expected one.
> 
> Cheers,
> Mikael
> 
>> checking for Build JDK... no
>> configure: error: Could not find a suitable Build JDK
>> 
>> I get this result.
>> 
>> I then downloaded JDK 9and did not modify it and ran
>> bash configure --with-conf-name=buildjdk && make jdk CONF=buildjdk
>> 
>> Then back in JDK10 I ran (Note the jdk9 in the --with-build-jdk)
>> ba

Re: OpenJDK 10 zero For Mips32el java -version IncompatilveClassChangeError

[Mikael Vidstedt]

> On Jun 5, 2020, at 10:27 AM, William Larson  wrote:
> 
> Hello Magnus
> 
> I got the source code from the openjdk mercurial repository following the
> building.html exactly.

Can you give some more details here please - exactly how do you get the sources?

> Here is the version numbers
> DEFAULT_VERSION_MAJOR=10
> DEFAULT_VERSION_MINOR=0
> DEFAULT_VERSION_SECURITY=0
> DEFAULT_VERSION_PATCH=0
> 
> LAUNCHER_NAME=openjdk
> PRODUCT_NAME=OpenJDK
> PRODUCT_SUFFIX="Runtime Environment"
> JDK_RC_PLATFORM_NAME=Platform
> COMPANY_NAME=N/A
> HOTSPOT_VM_DISTRO="OpenJDK"
> 
> # Might need better names for these
> MACOSX_BUNDLE_NAME_BASE="OpenJDK"
> MACOSX_BUNDLE_ID_BASE="net.java.openjdk"
> 
> The JDK10 is modified with this patch for mips
> https://groups.google.com/forum/#!topic/linux.debian.bugs.dist/Tmgse0HIzDc
> 
> After the above modification (note I have tried unmodified and modified
> JDK10 for the x64 build with no difference in outcome)
> - First I run in JDK 10
> When I run this configure in jdk 10 (builds JDK for Linux x64)
> bash configure --with-conf-name=buildjdk && make jdk CONF=buildjdk
> 
> It Compiles Successfully
> 
> Then I run in JDK 10
> 
> bash configure --openjdk-target=mipsel-oe-linux
> --with-sysroot=/usr/local/oecore-i686/sysroots/mips32el-nf-oe-linux
> --with-toolchain-path=/usr/local/oecore-i686/sysroots/i686-oesdk-linux/usr/bin/mipsel-oe-linux
> --with-libffi=/usr/local/oecore-i686/sysroots/mips32el-nf-oe-linux/usr/src/debug/libffi/3.0.13-r0/libffi-3.0.13
> --with-jvm-variants=zero
> --with-build-jdk=/opt/FaceClockJava/jdk10/build/buildjdk/jdk
> --with-stdc++lib=dynamic
> 
> checking for Boot JDK... /usr/lib/jvm/java-8-oracle
> checking Boot JDK version... java version "1.8.0_171" Java(TM) SE Runtime
> Environment (build 1.8.0_171-b11) Java HotSpot(TM) 64-Bit Server VM (build
> 25.171-b11, mixed mode)
> checking for java in Boot JDK... ok
> checking for javac in Boot JDK... ok
> checking for javah in Boot JDK... ok
> checking for jar in Boot JDK... ok
> checking for jarsigner in Boot JDK... ok
> checking if Boot JDK supports modules... no
> checking if Boot JDK is 32 or 64 bits... 64
> configure: Found potential Build JDK using configure arguments
> configure: Potential Build JDK found at
> /opt/FaceClockJava/jdk10/build/buildjdk/jdk is incorrect JDK version
> (openjdk version "10-internal"); ignoring
> configure: (Your Build JDK must be version 9)

This part doesn’t make sense. Here’s the error message line in jdk10:

http://hg.openjdk.java.net/jdk/jdk10/file/b09e56145e11/make/autoconf/boot-jdk.m4#l491
 


As you can see the “hard coded” error message is "Your Build JDK must be 
version 10”. Can you check what that file and line looks like in your sources?

It would be very helpful to know exactly where you got the sources from and/or 
why your error message does not match the expected one.

Cheers,
Mikael

> checking for Build JDK... no
> configure: error: Could not find a suitable Build JDK
> 
> I get this result.
> 
> I then downloaded JDK 9and did not modify it and ran
> bash configure --with-conf-name=buildjdk && make jdk CONF=buildjdk
> 
> Then back in JDK10 I ran (Note the jdk9 in the --with-build-jdk)
> bash configure --openjdk-target=mipsel-oe-linux
> --with-sysroot=/usr/local/oecore-i686/sysroots/mips32el-nf-oe-linux
> --with-toolchain-path=/usr/local/oecore-i686/sysroots/i686-oesdk-linux/usr/bin/mipsel-oe-linux
> --with-libffi=/usr/local/oecore-i686/sysroots/mips32el-nf-oe-linux/usr/src/debug/libffi/3.0.13-r0/libffi-3.0.13
> --with-jvm-variants=zero
> --with-build-jdk=/opt/FaceClockJava/jdk9/build/buildjdk/jdk
> --with-stdc++lib=dynamic
> 
> and it works and compiles with
> CONF=linux-mipsel-normal-zero-release make
> 
> However
> CONF=linux-mipsel-normal-zero-release make images  also works but when i
> copy the jdk/jre from the images folder into my qemu based on the same
> sysroots and the compiler it gives me
> 
> ./java -version
> Error occurred during initialization of boot layer
> java.lang.IncompatibleClassChangeError: Implementing class
> 
> If I copy the entire jdk (the jdk folder next to images folder not the one
> inside)
> It works and I can even compile a HelloWorld.java on mipsel target
> 
> ./java -version
> openjdk version "10-internal"
> OpenJDK Runtime Environment (build 10-internal+0-adhoc.will.jdk10)
> OpenJDK Zero VM (build 10-internal+0-adhoc.will.jdk10, interpreted mode)
> 
> Will
> 
> 
> On Fri, Jun 5, 2020 at 3:42 AM Magnus Ihse Bursie <
> magnus.ihse.bur...@oracle.com> wrote:
> 
>> On 2020-06-05 08:06, William Larson wrote:
>>> Hello David,
>>> 
>>> When running configure
>>> --with-buildjdk=./jdk/build/linux-x86_64-normal-server-release/jdk
>>> 
>>> I get the following error
>>> 
>>> configure: Potential Build JDK found at
>>> /opt/FaceClockJava/jdk10l/build/linux-x86_64-normal-server-release/jdk is
>>> incorrect JDK version (openjdk version "10-internal"); 

Re: OpenJDK 10 zero For Mips32el java -version IncompatilveClassChangeError

[Mikael Vidstedt]

Where did you grab the source code for the JDK you’re trying to build?

Cheers,
Mikael

> On Jun 4, 2020, at 11:07 PM, William Larson  wrote:
> 
> Hello David,
> 
> When running configure
> --with-buildjdk=./jdk/build/linux-x86_64-normal-server-release/jdk
> 
> I get the following error
> 
> configure: Potential Build JDK found at
> /opt/FaceClockJava/jdk10l/build/linux-x86_64-normal-server-release/jdk is
> incorrect JDK version (openjdk version "10-internal"); ignoring
> configure: (Your Build JDK must be version 9)
> checking for Build JDK... no
> configure: error: Could not find a suitable Build JDK
> configure exiting with result code 1
> 
> How do I build with buildjdk10 when it's asking for 9?
> 
> 
>>> On Thu, Jun 4, 2020, 9:16 PM David Holmes  wrote:
>> William,
>> You need a JDK 10 build JDK not JDK 9 - as Mikael already stated and as
>> Magnus wrote:
>> "When we cross-compile, we need not only a Boot JDK (of version current
>> N-1) running on the build host platform, but we also need a Build JDK,
>> based on the current source code, running on the build host. (This is
>> for running jmod/jlink; it needs to be up to date)."
>> With your JDK 9 build JDK you are getting invalid jmod/jlink output
>> files that prevent the full image from executing. But the exploded image
>> that doesn't use all of those and so may execute okay.
>> David
>>> On 5/06/2020 12:22 pm, William Larson wrote:
>>> Hello David,
>>> I copied everything under
>>> build/linux-mipsel-normal-zero-release/images/jdk
>>> Got error
>>> I then tried just
>>> build/linux-mipsel-normal-zero-release/images/jre
>>> Got the error
>>> I even copied
>>> build/linux-mipsel-normal-zero-release/images/jmods
>>> Along side jre and jdk
>>> Still got the error
>>> I copied: (note the image folder is missing)
>>> This is a much much bigger folder
>>> build/linux-mipsel-normal-zero-release/jdk
>>> To the target and it works albeit very slowly.
>>> I just want the jre ideally.
>>> Thanks for the help,
>>> Will
>>> On Thu, Jun 4, 2020, 7:12 PM David Holmes >> > wrote:
>>>   Hi William,
>>>   On 5/06/2020 10:00 am, William Larson wrote:
 Hello,
 I was able to successfully compile/build OpenJDK 10 with
>>>   following configure
 bash configure
 --openjdk-target=mipsel-oe-linux
>> --with-sysroot=/usr/local/oecore-i686/sysroots/mips32el-nf-oe-linux
>> --with-toolchain-path=/usr/local/oecore-i686/sysroots/i686-oesdk-linux/usr/bin/mipsel-oe-linux
>> --with-libffi=/usr/local/oecore-i686/sysroots/mips32el-nf-oe-linux/usr/src/debug/libffi/3.0.13-r0/libffi-3.0.13
 --with-jvm-variants=zero
 --with-build-jdk=./jdk9/build/buildjdk/jdk
 --with-boot-jdk=./jdk9/build/buildjdk/jdk
 I applied this patch to OpenJDK 10 as mips has 128 signals not 64
>> https://groups.google.com/forum/#!topic/linux.debian.bugs.dist/Tmgse0HIzDc
 I also Reference this mail from Magnus
>> https://mail.openjdk.java.net/pipermail/build-dev/2019-January/024735.html
 Where he suggests using a boot JDK
 CONF=linux-mipsel-normal-zero-release make images
 Works
 However if i copy the images to my QEMU based on the same sysroot
>> and
 compiler above I get
 ./java -version
 Error occurred during initialization of boot layer
 java.lang.IncompatibleClassChangeError: Implementing class
 If I copy the JDK folder just outside of images folder
 (build/linux-mipsel-normal-zero-release/jdk) it works OK albeit
>>>   it takes a
 LONG time to print
>>>   That is not part of the image built by "make images", it is what is
>>>   called the exploded image. So I'm not clear exactly what you copied
>>>   which did not work? Was it everything under
>>>   build/linux-mipsel-normal-zero-release/images/jdk
>>>   ?
>>>   Cheers,
>>>   David
 ./java -version
 openjdk version "10-internal"
 OpenJDK Runtime Environment (build 10-internal+0-adhoc.will.jdk10)
 OpenJDK Zero VM (build 10-internal+0-adhoc.will.jdk10,
>>>   interpreted mode)
 Why is does
 CONF=linux-mipsel-normal-zero-release make images
 not work?

Re: OpenJDK 10 zero For Mips32el java -version IncompatilveClassChangeError

[Mikael Vidstedt]

Looks like you’re using jdk9 as build jdk for jdk10. The build jdk does need to 
match the jdk you’re building. As Magnus points out in the email you linked to:

"In theory, you should rebuild your buildjdk for each and every change 
("make jdk CONF=buildjdk && make images CONF=mips"); but in reality, I 
don't believe there is really any need to rebuild the buildjdk (unless 
major changes in jlink/jmod happens).”

There are likely to be some of those “major changes” between jdk9 and jdk10.

Cheers,
Mikael

> On Jun 4, 2020, at 5:00 PM, William Larson  wrote:
> 
> Hello,
> I was able to successfully compile/build OpenJDK 10 with following configure
> 
> bash configure
> --openjdk-target=mipsel-oe-linux
> --with-sysroot=/usr/local/oecore-i686/sysroots/mips32el-nf-oe-linux
> --with-toolchain-path=/usr/local/oecore-i686/sysroots/i686-oesdk-linux/usr/bin/mipsel-oe-linux
> --with-libffi=/usr/local/oecore-i686/sysroots/mips32el-nf-oe-linux/usr/src/debug/libffi/3.0.13-r0/libffi-3.0.13
> 
> --with-jvm-variants=zero
> --with-build-jdk=./jdk9/build/buildjdk/jdk
> --with-boot-jdk=./jdk9/build/buildjdk/jdk
> 
> I applied this patch to OpenJDK 10 as mips has 128 signals not 64
> https://groups.google.com/forum/#!topic/linux.debian.bugs.dist/Tmgse0HIzDc
> 
> I also Reference this mail from Magnus
> https://mail.openjdk.java.net/pipermail/build-dev/2019-January/024735.html
> 
> Where he suggests using a boot JDK
> 
> CONF=linux-mipsel-normal-zero-release make images
> 
> Works
> 
> However if i copy the images to my QEMU based on the same sysroot and
> compiler above I get
> 
> ./java -version
> Error occurred during initialization of boot layer
> java.lang.IncompatibleClassChangeError: Implementing class
> 
> If I copy the JDK folder just outside of images folder
> (build/linux-mipsel-normal-zero-release/jdk) it works OK albeit it takes a
> LONG time to print
> ./java -version
> openjdk version "10-internal"
> OpenJDK Runtime Environment (build 10-internal+0-adhoc.will.jdk10)
> OpenJDK Zero VM (build 10-internal+0-adhoc.will.jdk10, interpreted mode)
> 
> Why is does
> CONF=linux-mipsel-normal-zero-release make images
> not work?
> -- 
> -William Larson

Re: RFR: JDK-8245401: AbsPathsInImage.java fails on Windows on jdwp.dll

[Mikael Vidstedt]

Looks good.

Cheers,
Mikael

> On May 20, 2020, at 10:51 AM, Erik Joelsson  wrote:
> 
> After some recent changes in JDI related code, we now have a new failure in 
> AbsPathsInImage.java on Windows. This keeps cropping up, so in this change 
> I'm changing the exception in the test to simply ignore all *.dll files.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8245401
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8245401/webrev.01/index.html
> 
> /Erik
> 

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (build system)

[Mikael Vidstedt]

Including hotspot-runtime-dev since the zero patch touches hotspot (os_linux) - 
please review!

> On May 12, 2020, at 3:05 PM, John Paul Adrian Glaubitz 
>  wrote:
> 
> Hi Mikael!
> 
> On 5/12/20 12:08 AM, John Paul Adrian Glaubitz wrote:
>>> Adrian, did you have a chance to look at the zero patch? I’m running out of 
>>> things to
>>> address and I’m planning on moving forward with the JEP targeting and 
>>> integration shortly.
>> 
>> I haven't tested the changes by Magnus yet, but they look good to me. Magnus
>> create a repo on the Linux SPARC porterbox which I can pull from for testing.
>> 
>> I finally have time to look into it tomorrow morning (CEST) so I can
>> officially ACK the changes.
> 
> Changes look fine to me with the additional changes by Magnus squashed
> into yours - unless you already have done so in your latest revision.

Thank you for verifying it! Webrev here:

http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.04/zero.incr/open/webrev/


I’m only including the incremental change. It builds on the previously reviewed 
build system and hotspot webrevs:

build: 
http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.02/build/open/webrev/
hotspot: 
http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/hotspot/open/webrev/

(Note that I already included the UTIL_DEPRECATED_ARG_ENABLE(deprecated-ports) 
part of Magnus’ change in the build/webrev.02 change)

> PS: I was just wondering: Would I be eligible to apply to become a reviewer?

One one and only one condition: Review the webrev to make sure I got it right ;)

Cheers,
Mikael

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (build system)

[Mikael Vidstedt]

> On May 11, 2020, at 3:08 PM, John Paul Adrian Glaubitz 
>  wrote:
> 
> Hi Mikael!
> 
> On 5/12/20 12:05 AM, Mikael Vidstedt wrote:
>>>> * GNM - Magnus to file a follow-up RFE
>>>> 
>>>> * Zero - Waiting for somebody (Adrian?) to provide more information about 
>>>> what needs to be preserved
>>> I haven't had the time to look at this yet due to $DAYJOB@SUSE, but I 
>>> should have time tomorrow
>>> as there is a public holiday tomorrow.
>>> 
>>> Also, Magnus should get to a SPARC-T5 running Debian unstable within the 
>>> next hours so he
>>> will be able to perform build tests as well and provide feedback.
>>> 
>>> Sorry for not being able to reply earlier.
>> 
>> Adrian, did you have a chance to look at the zero patch? I’m running out of 
>> things to
>> address and I’m planning on moving forward with the JEP targeting and 
>> integration shortly.
> 
> I haven't tested the changes by Magnus yet, but they look good to me. Magnus
> create a repo on the Linux SPARC porterbox which I can pull from for testing.
> 
> I finally have time to look into it tomorrow morning (CEST) so I can
> officially ACK the changes.

Awesome, let me know how the verification goes and if there are any additional 
changes needed!

Cheers,
Mikael

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (build system)

[Mikael Vidstedt]

> On May 7, 2020, at 4:18 AM, John Paul Adrian Glaubitz 
>  wrote:
> 
> Hi Mikael!
> 
> On 5/7/20 2:47 AM, Mikael Vidstedt wrote:
>> New webrev available here:
>> 
>> webrev: 
>> http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/build/open/webrev/
>>  
>> <http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/build/open/webrev/>
>> incremental: 
>> http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/build.incr/open/webrev/
>>  
>> <http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/build.incr/open/webrev/>
>> 
>> I believe I have addressed all the review comments apart from:
>> 
>> * GNM - Magnus to file a follow-up RFE
>> 
>> * Zero - Waiting for somebody (Adrian?) to provide more information about 
>> what needs to be preserved
> I haven't had the time to look at this yet due to $DAYJOB@SUSE, but I should 
> have time tomorrow
> as there is a public holiday tomorrow.
> 
> Also, Magnus should get to a SPARC-T5 running Debian unstable within the next 
> hours so he
> will be able to perform build tests as well and provide feedback.
> 
> Sorry for not being able to reply earlier.

Adrian, did you have a chance to look at the zero patch? I’m running out of 
things to address and I’m planning on moving forward with the JEP targeting and 
integration shortly.

Cheers,
Mikael

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (build system)

[Mikael Vidstedt]

Good catch on the deprecation argument! Updated webrev here:

webrev: 
http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.02/build/open/webrev/ 
<http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.02/build/open/webrev/>
incremental: 
http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.02/build.incr/open/webrev/
 
<http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.02/build.incr/open/webrev/>

I did not include the zero related part of the patch to avoid conflating things 
- I’ll wait for Adrian to provide a complete patch instead.

Cheers,
Mikael

> On May 7, 2020, at 8:53 AM, Magnus Ihse Bursie 
>  wrote:
> 
> 
> 
> On 2020-05-07 13:18, John Paul Adrian Glaubitz wrote:
>> Hi Mikael!
>> 
>> On 5/7/20 2:47 AM, Mikael Vidstedt wrote:
>>> New webrev available here:
>>> 
>>> webrev: 
>>> http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/build/open/webrev/
>>>  
>>> <http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/build/open/webrev/>
>>> incremental: 
>>> http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/build.incr/open/webrev/
>>>  
>>> <http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/build.incr/open/webrev/>
>>> 
>>> I believe I have addressed all the review comments apart from:
>>> 
>>> * GNM - Magnus to file a follow-up RFE
>>> 
>>> * Zero - Waiting for somebody (Adrian?) to provide more information about 
>>> what needs to be preserved
>> I haven't had the time to look at this yet due to $DAYJOB@SUSE, but I should 
>> have time tomorrow
>> as there is a public holiday tomorrow.
>> 
>> Also, Magnus should get to a SPARC-T5 running Debian unstable within the 
>> next hours so he
>> will be able to perform build tests as well and provide feedback.
> That was quite painless, actually. Two files needed partial restoration, then 
> everything worked fine.
> 
> Mikael, if you apply this patch on top of your patchset, it should back out 
> those of your changes that broke linux-sparc-zero. Also, I missed that you 
> removed a configure option without deprecating it, something we have as a 
> policy not to do. This patch also fixes that.
> 
> diff --git a/make/autoconf/platform.m4 b/make/autoconf/platform.m4
> --- a/make/autoconf/platform.m4
> +++ b/make/autoconf/platform.m4
> @@ -150,6 +150,18 @@
>VAR_CPU_BITS=32
>VAR_CPU_ENDIAN=little
>;;
> +sparc)
> +  VAR_CPU=sparc
> +  VAR_CPU_ARCH=sparc
> +  VAR_CPU_BITS=32
> +  VAR_CPU_ENDIAN=big
> +  ;;
> +sparcv9|sparc64)
> +  VAR_CPU=sparcv9
> +  VAR_CPU_ARCH=sparc
> +  VAR_CPU_BITS=64
> +  VAR_CPU_ENDIAN=big
> +  ;;
>  *)
>AC_MSG_ERROR([unsupported cpu $1])
>;;
> @@ -308,8 +320,10 @@
>OPENJDK_TARGET_CPU_BITS=32
>if test "x$OPENJDK_TARGET_CPU_ARCH" = "xx86"; then
>  OPENJDK_TARGET_CPU=x86
> +  elif test "x$OPENJDK_TARGET_CPU_ARCH" = "xsparc"; then
> +OPENJDK_TARGET_CPU=sparc
>else
> -AC_MSG_ERROR([Reduced build (--with-target-bits=32) is only 
> supported on x86_64])
> +AC_MSG_ERROR([Reduced build (--with-target-bits=32) is only 
> supported on x86_64 and sparcv9])
>fi
>  elif test "x$with_target_bits" = x64 && test "x$OPENJDK_TARGET_CPU_BITS" 
> = x32; then
>AC_MSG_ERROR([It is not possible to use --with-target-bits=64 on a 32 
> bit system. Use proper cross-compilation instead.])
> @@ -422,6 +436,8 @@
>HOTSPOT_$1_CPU=${OPENJDK_$1_CPU}
>if test "x$OPENJDK_$1_CPU" = xx86; then
>  HOTSPOT_$1_CPU=x86_32
> +  elif test "x$OPENJDK_$1_CPU" = xsparcv9; then
> +HOTSPOT_$1_CPU=sparc
>elif test "x$OPENJDK_$1_CPU" = xppc64; then
>  HOTSPOT_$1_CPU=ppc_64
>elif test "x$OPENJDK_$1_CPU" = xppc64le; then
> @@ -440,6 +456,8 @@
>  HOTSPOT_$1_CPU_DEFINE=AMD64
>elif test "x$OPENJDK_$1_CPU" = xx32; then
>  HOTSPOT_$1_CPU_DEFINE=X32
> +  elif test "x$OPENJDK_$1_CPU" = xsparcv9; then
> +HOTSPOT_$1_CPU_DEFINE=SPARC
>elif test "x$OPENJDK_$1_CPU" = xaarch64; then
>  HOTSPOT_$1_CPU_DEFINE=AARCH64
>elif test "x$OPENJDK_$1_CPU" = xppc64; then
> @@ -448,6 +466,8 @@
>  HOTSPOT_$1_CPU_DEFINE=PPC64
> 
># The cpu defines below are for zero, we don't support them directly.
> +  elif test "x$OPENJDK_$1_CPU" = xsparc; then
> +HOTSPOT_$1_CPU_DEFINE=SPARC
>elif test "x$O

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (build system)

[Mikael Vidstedt]

New webrev available here:

webrev: 
http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/build/open/webrev/ 
<http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/build/open/webrev/>
incremental: 
http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/build.incr/open/webrev/
 
<http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/build.incr/open/webrev/>

I believe I have addressed all the review comments apart from:

* GNM - Magnus to file a follow-up RFE

* Zero - Waiting for somebody (Adrian?) to provide more information about what 
needs to be preserved

Cheers,
Mikael

> On May 3, 2020, at 10:12 PM, Mikael Vidstedt  
> wrote:
> 
> 
> Please review this change which implements part of JEP 381:
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224
> webrev: 
> http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/build/open/webrev/
> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787
> 
> 
> Note: When reviewing this, please be aware that this exercise was *extremely* 
> mind-numbing, so I appreciate your help reviewing all the individual changes 
> carefully. You may want to get that coffee cup filled up (or whatever keeps 
> you awake)!
> 
> 
> Background:
> 
> Because of the size of the total patch and wide range of areas touched, this 
> patch is one out of in total six partial patches which together make up the 
> necessary changes to remove the Solaris and SPARC ports. The other patches 
> are being sent out for review to mailing lists appropriate for the respective 
> areas the touch. An email will be sent to jdk-dev summarizing all the 
> patches/reviews. To be clear: this patch is *not* in itself complete and 
> stand-alone - all of the (six) patches are needed to form a complete patch. 
> Some changes in this patch may look wrong or incomplete unless also looking 
> at the corresponding changes in other areas.
> 
> For convenience, I’m including a link below[1] to the full webrev, but in 
> case you have comments on changes in other areas, outside of the files 
> included in this thread, please provide those comments directly in the thread 
> on the appropriate mailing list for that area if possible.
> 
> In case it helps, the changes were effectively produced by searching for and 
> updating any code mentioning “solaris", “sparc”, “solstudio”, “sunos”, etc. 
> More information about the areas impacted can be found in the JEP itself.
> 
> 
> Testing:
> 
> A slightly earlier version of this change successfully passed tier1-8, as 
> well as client tier1-2. Additional testing will be done after the first round 
> of reviews has been completed.
> 
> Cheers,
> Mikael
> 
> [1] 
> http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/
> 

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (build system)

[Mikael Vidstedt]

Magnus, thank you so much for the thorough review!! Will send out a new webrev 
in a bit, meanwhile some comments inline..

> On May 6, 2020, at 4:04 AM, Magnus Ihse Bursie 
>  wrote:
> 
> Hi Mikael,
> 
> On 2020-05-04 07:12, Mikael Vidstedt wrote:
>> Please review this change which implements part of JEP 381:
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224
>> webrev: 
>> http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/build/open/webrev/
> 
> It's a massive change. So you're getting a massive review from me. :-)
> 
> In the following comments, the line numbers refer to the old files. (I 
> realize now that it might have been more convenient for you to have the new 
> numbers. I'm sorry I did not think of it before.)

Not a problem!

> 
> ---
> 
> First of all, I notice that you have not updated any copyright years. Do you 
> plan to do that by a script before pushing?

Correct - whether I’ll end up using a script or not remains to be seen, but 
I’ll fix the copyright years when the reviews/changes have settled down a bit. 
I chose not to change all the copyright years since that would distract from 
the “actual” changes, and also pretty much guarantee conflicts when I pull in 
the latest changes.. It’s challenging enough as it is :)

> ---
> 
> Several variables are not needed anymore and can be removed. These include:
> 
> * TAR_CREATE_EXTRA_PARAM. Remove from Bundles.gmk, autoconf/basic_tools.m4 
> and autoconf/spec.gmk.in.
> 
> * ELFEDIT. Remove from autoconf/spec.gmk.in.
> 
> * STLPORT_LIB. Remove from autoconf/spec.gmk.in.
> 
> * SA_LDFLAGS. Remove from modules/jdk.hotspot.agent/Lib.gmk.
> 
> * GLOBAL_LIBS (as has been noted by Kim as well). Remove from 
> common/NativeCompilation.gmk, autoconf/spec.gmk.in and autoconf/libraries.m4.
> 
> * LDFLAGS_WARNINGS_ARE_ERRORS was (unfortunately!) only supported on 
> solstudio. No reason to keep it anymore. Remove from 
> common/NativeCompilation.gmk, autoconf/flags-ldflags.m4 and 
> autoconf/spec.gmk.in.

Fixed all of the above.

> * GNM is not needed anymore, but there is certainly a need for related 
> cleanup (we do not need the if statement, but could use "UTIL_CHECK_TOOLS(NM, 
> nm gcc-nm)" for all platforms). I understand if you do not want to mess 
> around with it, let me know and I'll file a separate follow-up bug.

Would definitely appreciate if you could file a follow-up, thank you!

> ---
> 
> In some places we used to have a variable that was passed into 
> Setup*Compilation, but the variable was removed. However, the argument to the 
> function was left in place. (Make do not warn for unknown variables, 
> unfortunately.)
> 
> lib/CompileJvm.gmk:EXTRA_OBJECT_FILES := $(DTRACE_EXTRA_OBJECT_FILES), \
> 
> Awt2dLibraries.gmk:ASFLAGS := $(LIBAWT_ASFLAGS), \

Fixed.

> Also, the documentation of SetupNativeCompilation has not been updated to 
> match the implementation. Please remove the the "REORDER" line there as well.

I’ve removed REORDER completely now. For completeness: In webrev.00 I (only) 
removed C_FLAG_REORDER, and didn’t touch the REORDER argument to 
SetupNativeCompilation. As you noted though, the REORDER functionality is not 
actually used anywhere - that is true even in mainline today. Turns out the 
last uses of the REORDER functionality disappeared with 
https://bugs.openjdk.java.net/browse/JDK-8200178 
<https://bugs.openjdk.java.net/browse/JDK-8200178> / 
http://hg.openjdk.java.net/jdk/jdk/rev/396ea30afbd5 
<http://hg.openjdk.java.net/jdk/jdk/rev/396ea30afbd5> authored by … would you 
look at that - “ihse”! Wonder who that is? ;)

> ---
> 
> For dtrace, I want to make sure that the removal is complete (cleanse it with 
> fire, please! :-)).
> 
> The build tool generateJvmOffsets is not used anymore, so 
> generateJvmOffsets.cpp can be removed (actually, that means the entire 
> hotspot/src/native/).
> 
> I assume you remove src/java.base/solaris/native/libjvm_dtrace and libjvm_db 
> in the core-libs patch, right?
> 
> I also want to make sure that you actually remove hotspot_jni.d, hotspot.d 
> and hs_private.d from src/hotspot/os/posix/dtrace, and 
> src/hotspot/os/solaris/dtrace/jhelper.d. (Done in the hotspot patch, I hope.)

I will not remove all traces of dtrace (no pun intended) as part of this JEP, 
but (separate from this JEP) we should certainly discuss and decide how to move 
forward with dtrace on the other platforms. The stuff under 
src/java.base/solaris is indeed removed as part of the core-libs patch, and the 
src/hotspot/os/solaris stuff is removed as part of the hotspot patch, but 
AFAICT the src/hotspot/os/posix/dtrace files still do get picked up by the 
logic in GensrcDtrace.gmk so I’m going to leave those files 

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (build system)

[Mikael Vidstedt]

> On May 4, 2020, at 12:44 AM, John Paul Adrian Glaubitz 
>  wrote:
> 
> On 5/4/20 9:39 AM, John Paul Adrian Glaubitz wrote:
>> I haven't looked at the changes yet, but please make sure you don't kill the
>> possibility to build Zero on SPARC on Linux because that should still work
>> without many extra ado.
> This change should be dropped from make/autoconf/platform.m4:
> 
> @@ -148,22 +148,10 @@
>   VAR_CPU=sh
>   VAR_CPU_ARCH=sh
>   VAR_CPU_BITS=32
>   VAR_CPU_ENDIAN=little
>   ;;
> -sparc)
> -  VAR_CPU=sparc
> -  VAR_CPU_ARCH=sparc
> -  VAR_CPU_BITS=32
> -  VAR_CPU_ENDIAN=big
> -  ;;
> -sparcv9|sparc64)
> -  VAR_CPU=sparcv9
> -  VAR_CPU_ARCH=sparc
> -  VAR_CPU_BITS=64
> -  VAR_CPU_ENDIAN=big
> -  ;;
> *)
>   AC_MSG_ERROR([unsupported cpu $1])
>   ;;
>   esac
> ])

Is that the only part that needs to be preserved for linux/sparc+zero? Nothing 
needed in the rest of the make files, source code, tests, etc.?

> And wouldn't it make sense to keep this change for the future for the
> future removal of other architectures?
> 
> @@ -564,29 +524,10 @@
>   PLATFORM_EXTRACT_TARGET_AND_BUILD
>   PLATFORM_SETUP_TARGET_CPU_BITS
>   PLATFORM_SET_MODULE_TARGET_OS_VALUES
>   PLATFORM_SET_RELEASE_FILE_OS_VALUES
>   PLATFORM_SETUP_LEGACY_VARS
> -  PLATFORM_CHECK_DEPRECATION
> -])
> -
> -AC_DEFUN([PLATFORM_CHECK_DEPRECATION],
> -[
> -  UTIL_ARG_ENABLE(NAME: deprecated-ports, DEFAULT: false,
> -  RESULT: ENABLE_DEPRECATED_PORTS,
> -  DESC: [suppress the error when configuring for a deprecated port])
> -
> -  if test "x$OPENJDK_TARGET_OS" = xsolaris || \
> -  (test "x$OPENJDK_TARGET_CPU_ARCH" = xsparc && \
> -  test "x$with_jvm_variants" != xzero); then
> -if test "x$ENABLE_DEPRECATED_PORTS" = "xtrue"; then
> -  AC_MSG_WARN([The Solaris and SPARC ports are deprecated and may be 
> removed in a future release.])
> -else
> -  AC_MSG_ERROR(m4_normalize([The Solaris and SPARC ports are deprecated 
> and may be removed in a
> -future release. Use --enable-deprecated-ports=yes to suppress this 
> error.]))
> -fi
> -  fi
> ])
> 
> AC_DEFUN_ONCE([PLATFORM_SETUP_OPENJDK_BUILD_OS_VERSION],
> [
>   
> ###


What are you planning on removing? ;)

Jokes aside - that logic is not complex enough to motivate having around just 
in case. If we need to reintroduce it we can always go back and get some 
inspiration from the VCS history.

Cheers,
Mikael

> 
> Adrian
> 
> -- 
> .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (build system)

[Mikael Vidstedt]

Please review this change which implements part of JEP 381:

JBS: https://bugs.openjdk.java.net/browse/JDK-8244224
webrev: 
http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/build/open/webrev/
JEP: https://bugs.openjdk.java.net/browse/JDK-8241787


Note: When reviewing this, please be aware that this exercise was *extremely* 
mind-numbing, so I appreciate your help reviewing all the individual changes 
carefully. You may want to get that coffee cup filled up (or whatever keeps you 
awake)!


Background:

Because of the size of the total patch and wide range of areas touched, this 
patch is one out of in total six partial patches which together make up the 
necessary changes to remove the Solaris and SPARC ports. The other patches are 
being sent out for review to mailing lists appropriate for the respective areas 
the touch. An email will be sent to jdk-dev summarizing all the 
patches/reviews. To be clear: this patch is *not* in itself complete and 
stand-alone - all of the (six) patches are needed to form a complete patch. 
Some changes in this patch may look wrong or incomplete unless also looking at 
the corresponding changes in other areas.

For convenience, I’m including a link below[1] to the full webrev, but in case 
you have comments on changes in other areas, outside of the files included in 
this thread, please provide those comments directly in the thread on the 
appropriate mailing list for that area if possible.

In case it helps, the changes were effectively produced by searching for and 
updating any code mentioning “solaris", “sparc”, “solstudio”, “sunos”, etc. 
More information about the areas impacted can be found in the JEP itself.


Testing:

A slightly earlier version of this change successfully passed tier1-8, as well 
as client tier1-2. Additional testing will be done after the first round of 
reviews has been completed.

Cheers,
Mikael

[1] 
http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/

Re: RFR: JDK-8244214: Change to VS2019 for building on Windows at Oracle

[Mikael Vidstedt]

Looks good.

Cheers,
Mikael

> On Apr 30, 2020, at 3:37 PM, Erik Joelsson  wrote:
> 
> Please review this change which changes the compiler version used to build 
> for Windows at Oracle to Visual Studio 2019.
> 
> http://cr.openjdk.java.net/~erikj/8244214/webrev.01/
> 
> https://bugs.openjdk.java.net/browse/JDK-8244214
> 
> /Erik
> 

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

[Mikael Vidstedt]

Vladimir/Magnus/Erik,

Thanks for the reviews, change pushed.

Cheers,
Mikael

> On Apr 29, 2020, at 5:45 AM, Erik Joelsson  wrote:
> 
> Looks good.
> 
> /Erik
> 
> On 2020-04-28 21:12, Mikael Vidstedt wrote:
>> Please review this small change which disables JVMCI, Graal, and AOT when 
>> building linux-aarch64 at Oracle, for now.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244061
>> webrev: 
>> http://cr.openjdk.java.net/~mikael/webrevs/8244061/webrev.00/open/webrev/
>> 
>> Cheers,
>> Mikael
>> 

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

[Mikael Vidstedt]

> On Apr 29, 2020, at 3:44 AM, Andrew Haley  wrote:
> 
> On 4/29/20 10:02 AM, Mikael Vidstedt wrote:
>> 
>>> On Apr 29, 2020, at 12:46 AM, Andrew Haley  wrote:
>>> 
>>> On 4/29/20 5:12 AM, Mikael Vidstedt wrote:
>>>> Please review this small change which disables JVMCI, Graal, and AOT when 
>>>> building linux-aarch64 at Oracle, for now.
>>>> 
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244061
>>>> webrev: 
>>>> http://cr.openjdk.java.net/~mikael/webrevs/8244061/webrev.00/open/webrev/
>>> 
>>> Why? Are there problems with it? If so, I need bug reports.
>> 
>> No specific problems or bugs that I’m aware of. We’re simply opting not to 
>> include Graal/JVMTI/AOT in the linux-aarch64 builds we do at Oracle, for now.
> 
> Cool, NP. Obvs. I'd prefer it if y'all built and tested it all,
> but fair enough.

One small step at a time :)

Cheers,
Mikael

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

[Mikael Vidstedt]

> On Apr 29, 2020, at 12:46 AM, Andrew Haley  wrote:
> 
> On 4/29/20 5:12 AM, Mikael Vidstedt wrote:
>> Please review this small change which disables JVMCI, Graal, and AOT when 
>> building linux-aarch64 at Oracle, for now.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244061
>> webrev: 
>> http://cr.openjdk.java.net/~mikael/webrevs/8244061/webrev.00/open/webrev/
> 
> Why? Are there problems with it? If so, I need bug reports.

No specific problems or bugs that I’m aware of. We’re simply opting not to 
include Graal/JVMTI/AOT in the linux-aarch64 builds we do at Oracle, for now.

Cheers,
Mikael

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

[Mikael Vidstedt]

JIB is an Oracle (internal) tool, meaning the jib-profiles.js configuration 
file is only relevant at Oracle, so this really only affects builds done at 
Oracle. Does that address your concern?

Cheers,
Mikael

> On Apr 29, 2020, at 1:45 AM, Doug Simon  wrote:
> 
> 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 disables JVMCI, Graal, and AOT when 
>> building linux-aarch64 at Oracle, for now.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244061
>> webrev: 
>> http://cr.openjdk.java.net/~mikael/webrevs/8244061/webrev.00/open/webrev/
>> 
>> Cheers,
>> Mikael
>> 
> 

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

[Mikael Vidstedt]

Please review this small change which disables JVMCI, Graal, and AOT when 
building linux-aarch64 at Oracle, for now.

JBS: https://bugs.openjdk.java.net/browse/JDK-8244061
webrev: 
http://cr.openjdk.java.net/~mikael/webrevs/8244061/webrev.00/open/webrev/

Cheers,
Mikael

Re: RFR: 8243634: Add pandoc dependency when building linux-aarch64 at Oracle

[Mikael Vidstedt]

I take that back - the original change (webrev.00) is good, so I’ll use that.

Cheers,
Mikael

> On Apr 28, 2020, at 6:13 PM, Mikael Vidstedt  
> wrote:
> 
> 
> New version which only adds the dependency when cross compiling, for now:
> 
> http://cr.openjdk.java.net/~mikael/webrevs/8243634/webrev.01/open/webrev/
> 
> Cheers,
> Mikael
> 
>> On Apr 27, 2020, at 1:00 AM, Magnus Ihse Bursie 
>>  wrote:
>> 
>> On 2020-04-27 07:51, Mikael Vidstedt wrote:
>>> Add the explicit pandoc dependency since it may not be available on the 
>>> build node.
>>> 
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8243634
>>> webrev:  
>>> http://cr.openjdk.java.net/~mikael/webrevs/8243634/webrev.00/open/webrev/
>> Looks good to me.
>> 
>> /Magnus
>>> 
>>> Cheers,
>>> Mikael
>> 
> 

Re: RFR: 8243634: Add pandoc dependency when building linux-aarch64 at Oracle

[Mikael Vidstedt]

New version which only adds the dependency when cross compiling, for now:

http://cr.openjdk.java.net/~mikael/webrevs/8243634/webrev.01/open/webrev/

Cheers,
Mikael

> On Apr 27, 2020, at 1:00 AM, Magnus Ihse Bursie 
>  wrote:
> 
> On 2020-04-27 07:51, Mikael Vidstedt wrote:
>> Add the explicit pandoc dependency since it may not be available on the 
>> build node.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8243634
>> webrev:  
>> http://cr.openjdk.java.net/~mikael/webrevs/8243634/webrev.00/open/webrev/
> Looks good to me.
> 
> /Magnus
>> 
>> Cheers,
>> Mikael
> 

Re: RFR: 8243633: Remove cups dependency when building linux at Oracle

[Mikael Vidstedt]

Magnus/Tim/Erik, thanks for the reviews! Change pushed.

Cheers,
Mikael

> On Apr 27, 2020, at 1:58 PM, Erik Joelsson  wrote:
> 
> Looks good.
> 
> /Erik
> 
> On 2020-04-27 12:30, Mikael Vidstedt wrote:
>> Ah, good point/catch! I updated the title of the JBS issue. New webrev:
>> 
>> webrev: 
>> http://cr.openjdk.java.net/~mikael/webrevs/8243633/webrev.01/open/webrev/
>> incremental: 
>> http://cr.openjdk.java.net/~mikael/webrevs/8243633/webrev.01.incr/open/webrev/
>> 
>> Cheers,
>> Mikael
>> 
>>> On Apr 27, 2020, at 2:06 AM, Magnus Ihse Bursie 
>>>  wrote:
>>> 
>>> On 2020-04-27 07:49, Mikael Vidstedt wrote:
>>>> As on linux-x64, cups is already in the devkit, so no need for the 
>>>> explicit extra dependency.
>>> Actually, I realized this goes for all our cross-platform linux devkits, 
>>> i.e. ppc64le, s390x and arm32 as well. Can you remove cups from them too 
>>> while you're at it?
>>> 
>>> /Magnus
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8243633
>>>> webrev: 
>>>> http://cr.openjdk.java.net/~mikael/webrevs/8243633/webrev.00/open/webrev/
>>>> 
>>>> Cheers,
>>>> Mikael

Re: RFR: 8243633: Remove cups dependency when building linux at Oracle (was: Remove cups dependency when building linux-aarch64 at Oracle)

[Mikael Vidstedt]

Ah, good point/catch! I updated the title of the JBS issue. New webrev:

webrev: 
http://cr.openjdk.java.net/~mikael/webrevs/8243633/webrev.01/open/webrev/
incremental: 
http://cr.openjdk.java.net/~mikael/webrevs/8243633/webrev.01.incr/open/webrev/

Cheers,
Mikael

> On Apr 27, 2020, at 2:06 AM, Magnus Ihse Bursie 
>  wrote:
> 
> On 2020-04-27 07:49, Mikael Vidstedt wrote:
>> As on linux-x64, cups is already in the devkit, so no need for the explicit 
>> extra dependency.
> Actually, I realized this goes for all our cross-platform linux devkits, i.e. 
> ppc64le, s390x and arm32 as well. Can you remove cups from them too while 
> you're at it?
> 
> /Magnus
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8243633
>> webrev: 
>> http://cr.openjdk.java.net/~mikael/webrevs/8243633/webrev.00/open/webrev/
>> 
>> Cheers,
>> Mikael
> 

RFR: 8243633: Remove cups dependency when building linux-aarch64 at Oracle

[Mikael Vidstedt]

As on linux-x64, cups is already in the devkit, so no need for the explicit 
extra dependency.

JBS: https://bugs.openjdk.java.net/browse/JDK-8243633
webrev: 
http://cr.openjdk.java.net/~mikael/webrevs/8243633/webrev.00/open/webrev/

Cheers,
Mikael