From duke at openjdk.java.net  Wed Jun  1 00:59:33 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Wed, 1 Jun 2022 00:59:33 GMT
Subject: RFR: 8287171: Refactor null caller tests to a single directory
 [v4]
In-Reply-To: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
Message-ID: <Gy3Z1gKq5Un6CkwwhXKkrF_EyOlz51JWtxd6FZAWVQE=.7ac7d906-5e1b-4341-ab22-fe1db85e0316@github.com>

> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  Moved the tests test/jdk/jni/nullCaller.  Added to the jdk_other group
  which runs as part of tier2.  Made the other requested changes such as
  not using the bugid as the function name for the test and using the
  name of the main method being tested instead.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8934/files
  - new: https://git.openjdk.java.net/jdk/pull/8934/files/f1406a45..7eb5dbcb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8934&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8934&range=02-03

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

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


From mchung at openjdk.java.net  Wed Jun  1 02:45:25 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 1 Jun 2022 02:45:25 GMT
Subject: RFR: 8287171: Refactor null caller tests to a single directory
 [v4]
In-Reply-To: <Gy3Z1gKq5Un6CkwwhXKkrF_EyOlz51JWtxd6FZAWVQE=.7ac7d906-5e1b-4341-ab22-fe1db85e0316@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
 <Gy3Z1gKq5Un6CkwwhXKkrF_EyOlz51JWtxd6FZAWVQE=.7ac7d906-5e1b-4341-ab22-fe1db85e0316@github.com>
Message-ID: <61nkWjC5VtxN1XbFahrQXRUSI2vbRq_v-ArjhRYSFyg=.2bcd1526-3048-4cd0-9064-2e85109b20fb@github.com>

On Wed, 1 Jun 2022 00:59:33 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved the tests test/jdk/jni/nullCaller.  Added to the jdk_other group
>   which runs as part of tier2.  Made the other requested changes such as
>   not using the bugid as the function name for the test and using the
>   name of the main method being tested instead.

jdk_other is for other modules.  jdk_lang may be an option  since this is to test when attached with JNI thread.

-------------

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


From duke at openjdk.java.net  Wed Jun  1 02:45:24 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Wed, 1 Jun 2022 02:45:24 GMT
Subject: RFR: 8287171: Refactor null caller tests to a single directory
 [v5]
In-Reply-To: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
Message-ID: <rWPdHuUalDMsqQ3Zw3CgTX7xauWNxWAMnWTuUUS8UiM=.fefad5d1-92cf-43ff-bd37-8bf0131ea11a@github.com>

> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  improve comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8934/files
  - new: https://git.openjdk.java.net/jdk/pull/8934/files/7eb5dbcb..777c4f5f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8934&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8934&range=03-04

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

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


From duke at openjdk.java.net  Wed Jun  1 02:51:32 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Wed, 1 Jun 2022 02:51:32 GMT
Subject: RFR: 8287171: Refactor null caller tests to a single directory
 [v5]
In-Reply-To: <rWPdHuUalDMsqQ3Zw3CgTX7xauWNxWAMnWTuUUS8UiM=.fefad5d1-92cf-43ff-bd37-8bf0131ea11a@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
 <rWPdHuUalDMsqQ3Zw3CgTX7xauWNxWAMnWTuUUS8UiM=.fefad5d1-92cf-43ff-bd37-8bf0131ea11a@github.com>
Message-ID: <ojAuM8jTFWCHwAqeT_9rfyrew-K5Oeet9tz5AhspgoE=.fc9bdba0-6afc-43ac-89ba-dc77a1ef8afb@github.com>

On Wed, 1 Jun 2022 02:45:24 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve comment

The tests are mostly java/lang, but also java/util so I was looking for something else.  The jdk_lang seems fairly reasonable and they run tier1 as the tests used to run before the move if I put them there.  I'll update TEST.groups.

-------------

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


From duke at openjdk.java.net  Wed Jun  1 03:01:35 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Wed, 1 Jun 2022 03:01:35 GMT
Subject: RFR: 8287171: Refactor null caller tests to a single directory
 [v6]
In-Reply-To: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
Message-ID: <7EHGNYrG5dROegqb9WUzfwcN1ho9UNc55vSWQvc2Af0=.47fcaf76-9b41-4f55-8140-1d7b98bd930b@github.com>

> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  move jni/nullCaller tests to jdk_lang group

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8934/files
  - new: https://git.openjdk.java.net/jdk/pull/8934/files/777c4f5f..8bf4f597

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8934&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8934&range=04-05

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

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


From darcy at openjdk.java.net  Wed Jun  1 03:18:44 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 1 Jun 2022 03:18:44 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v4]
In-Reply-To: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
Message-ID: <5sIL5TbJnFl6ceoDWAQo0fMC32NgEdJ-9wrutOdz2TA=.8ae1c7e2-d98b-4609-a8af-d63e7cb843c9@github.com>

> Time to start getting ready for JDK 20...

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 38 additional commits since the last revision:

 - Adjust deprecated options test.
 - Merge branch 'master' into JDK-8284858
 - Update deprecated options test.
 - Merge branch 'master' into JDK-8284858
 - Respond to review feedback.
 - Update symbol information for JDK 19 b24.
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - ... and 28 more: https://git.openjdk.java.net/jdk/compare/2ffc9a25...54e872b5

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8236/files
  - new: https://git.openjdk.java.net/jdk/pull/8236/files/eedd36bd..54e872b5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=02-03

  Stats: 1101 lines in 21 files changed: 708 ins; 170 del; 223 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8236.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236

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


From jjg at openjdk.java.net  Wed Jun  1 03:27:40 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 1 Jun 2022 03:27:40 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v3]
In-Reply-To: <6jNbvqpG9h3UaeXfoS-E3E83XWEHgxobxKm2GWeaxJA=.aba8eef4-b036-46f7-9a6c-e668c80f5aac@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <6jNbvqpG9h3UaeXfoS-E3E83XWEHgxobxKm2GWeaxJA=.aba8eef4-b036-46f7-9a6c-e668c80f5aac@github.com>
Message-ID: <GmyrRLk_MX9e34aqLobfdvQjpkjXU5kY0t2JSikbE9Y=.07123259-b005-4395-b546-bf105c719ba6@github.com>

On Tue, 31 May 2022 20:32:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 36 additional commits since the last revision:
> 
>  - Update deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Respond to review feedback.
>  - Update symbol information for JDK 19 b24.
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Update symbol information for JDK 19 b23.
>  - ... and 26 more: https://git.openjdk.java.net/jdk/compare/44ff5c88...eedd36bd

langtools files look OK, although I did skim through the auto-generated new data/symbols files.

There are possibilities in the langtools file to simplify naming and default initialization of member fields in various places, in a separate PR, separate from these changes.

-------------

Marked as reviewed by jjg (Reviewer).

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


From dholmes at openjdk.java.net  Wed Jun  1 04:44:39 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 1 Jun 2022 04:44:39 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v4]
In-Reply-To: <5sIL5TbJnFl6ceoDWAQo0fMC32NgEdJ-9wrutOdz2TA=.8ae1c7e2-d98b-4609-a8af-d63e7cb843c9@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <5sIL5TbJnFl6ceoDWAQo0fMC32NgEdJ-9wrutOdz2TA=.8ae1c7e2-d98b-4609-a8af-d63e7cb843c9@github.com>
Message-ID: <p6o4WrONmMn3MP2XfJ7lN8SCQEe3QJk03gt_i5R7K04=.9c343d94-dc8b-48c5-9756-6552a7cb16f9@github.com>

On Wed, 1 Jun 2022 03:18:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 38 additional commits since the last revision:
> 
>  - Adjust deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Update deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Respond to review feedback.
>  - Update symbol information for JDK 19 b24.
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - ... and 28 more: https://git.openjdk.java.net/jdk/compare/c1abb195...54e872b5

Updates look good. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

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


From ihse at openjdk.java.net  Wed Jun  1 09:07:34 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 1 Jun 2022 09:07:34 GMT
Subject: Integrated: 8287366: Improve test failure reporting in GHA
In-Reply-To: <nVEgC0DFSB9_bgMc97fwOWCNHZSQsVGEnXKZzRibGUg=.13dff674-c481-4a1c-bf31-0341b7c35527@github.com>
References: <nVEgC0DFSB9_bgMc97fwOWCNHZSQsVGEnXKZzRibGUg=.13dff674-c481-4a1c-bf31-0341b7c35527@github.com>
Message-ID: <OY2ojujhtjwYMbsWbql4QA9Jmf86FHQhJDeBiKfh2_Q=.4cb43ffe-ce77-4506-8436-0febce0e193f@github.com>

On Thu, 26 May 2022 12:04:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> It is currently both tricky and tedious to figure out what went wrong when a jtreg test fails in GHA.
> 
> We should utilize the full potential of GitHub Action summaries and error annotations to make finding failures easier and more discoverable.
> 
> With this PR, the overview of failures are presented on the "Summary" page for the action (the top-most line to the left, with the outline house icon). Below the `submit.yml` dependency graph, you'll find the annotations, which will look like this:
> 
> 
> Linux x86 (jdk/tier1 part 1)
> Test run reported 34 test failure(s) and 0 error(s). See summary for details.
> 
> 
> Below the annotations follow the summaries. Go have a look at the runs for this PR to see what it looks like! In short, there is a separate summary per test job. The first part lists the names of the failed tests. This will always be included. Below this (with links from the summary list) are detailed information for each failed test. This include the jtreg output, and the `hs_err` file(s), if present. The latter part has a limit from Github on 1 MB. If this limit is broken, no detailed information at all is presented (sorry 'bout that; GitHub's rules).
> 
> This PR is deliberately based on a commit prior to the fix for JDK-8287137 (Problemlist failing x86_32 tests after Loom integration), so you can see for yourself how the GHA runs looks in case of a "train wreck" testing situation, like on x86 after Loom. As you can see, most of the output part of the summaries got larger than the 1 MB limit, which means they were not shown. Only the summary for `Linux x86 (hs/tier1 runtime)` displays as intended. OTOH, this shows that the system has a "graceful degradation" mode for even large amount of failures like this. And, since I don't see a Loom v2.0 coming anytime soon, I believe this amount of failed tests are unlikely to be a realistic scenario.
> 
> Finally: the duplication in submit.yml is really, really annoying. :-( I have copied the same code block to three places. The fourth place, for Windows, do not get any support at this time. Concurrently with this change, I have started a separate branch where I split up submit.yml into reusable parts, using "callable workflows" and "custom actions". As part of this effort, I will also change the windows jobs to use cygwin bash instead of PowerShell. Until then, I could not be bothered to even think about implementing this functionality in PS. When that change is integrated, Windows will get this functionality for free, too.

This pull request has now been integrated.

Changeset: e0e15def
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e0e15def24c4c93c863ff459788bea23ef99d790
Stats:     285 lines in 1 file changed: 264 ins; 0 del; 21 mod

8287366: Improve test failure reporting in GHA

Reviewed-by: clanger

-------------

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


From asotona at openjdk.java.net  Wed Jun  1 14:02:14 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 1 Jun 2022 14:02:14 GMT
Subject: RFR: 8233269: Improve handling of JAVA_ARGS
Message-ID: <sc-pQEHJQmawDVFDNrb-zV1SvlQTgY27QvJ-aWmDT14=.8865939e-2223-4e3b-ad61-17f9bdff0c34@github.com>

LauncherCommon.gmk is unfortunately defining JAVA_ARGS with `-J-ms8m` option for all JDK launchers, including java launcher.
JAVA_ARGS  should not be defined for java launcher (in contrast to the other JDK launchers), and the command line option `-J-ms8m` is obsolete for java launcher.

Proposed patch removes JAVA_ARGS from java launcher, while keeping status quo for all other JDK launchers.
The patch of LauncherCommon.gmk identifies java launcher by undefined MAIN_CLASS.

Thanks for review,
Adam

-------------

Commit messages:
 - 8233269: Improve handling of JAVA_ARGS

Changes: https://git.openjdk.java.net/jdk/pull/8972/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8972&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8233269
  Stats: 8 lines in 1 file changed: 4 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8972.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8972/head:pull/8972

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


From mchung at openjdk.java.net  Wed Jun  1 16:57:28 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 1 Jun 2022 16:57:28 GMT
Subject: RFR: 8287171: Refactor null caller tests to a single directory
 [v6]
In-Reply-To: <7EHGNYrG5dROegqb9WUzfwcN1ho9UNc55vSWQvc2Af0=.47fcaf76-9b41-4f55-8140-1d7b98bd930b@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
 <7EHGNYrG5dROegqb9WUzfwcN1ho9UNc55vSWQvc2Af0=.47fcaf76-9b41-4f55-8140-1d7b98bd930b@github.com>
Message-ID: <sfpAZ9gHY9Kx1AQM8qyHw8jtMSwCW2FdrF8kREVJ3Y0=.8816b9eb-00d3-4784-8f05-ea37718be8fa@github.com>

On Wed, 1 Jun 2022 03:01:35 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move jni/nullCaller tests to jdk_lang group

test/jdk/jni/nullCaller/exeNullCallerTest.cpp line 27:

> 25: 
> 26: /* Test for JDK-8280902
> 27:  * ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame

This comment isn't correct.  `ResourceBundle::getBundle` defaults to the system class loader if invoked by a null caller and I don't expect it may throw NPE.   Looks like you copy the summary of the JBS issue here, which isn't helpful to the readers.    I expect it a description of the test case.

Same comments to all other test cases.

-------------

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


From tprinzing at openjdk.java.net  Wed Jun  1 17:20:24 2022
From: tprinzing at openjdk.java.net (Tim Prinzing)
Date: Wed, 1 Jun 2022 17:20:24 GMT
Subject: RFR: 8287171: Refactor null caller tests to a single directory
 [v7]
In-Reply-To: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
Message-ID: <l5GVl_4BlCXWrmaAE_4vVujeju3GcQ885lb9spQ_UrU=.de7cb409-acae-4fbe-a23f-16526b1a9ecd@github.com>

> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  formatting cleanup

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8934/files
  - new: https://git.openjdk.java.net/jdk/pull/8934/files/8bf4f597..865713fc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8934&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8934&range=05-06

  Stats: 21 lines in 3 files changed: 2 ins; 10 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8934.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8934/head:pull/8934

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


From tprinzing at openjdk.java.net  Wed Jun  1 19:27:33 2022
From: tprinzing at openjdk.java.net (Tim Prinzing)
Date: Wed, 1 Jun 2022 19:27:33 GMT
Subject: RFR: 8287171: Refactor null caller tests to a single directory
 [v8]
In-Reply-To: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
Message-ID: <wdBGPAUgqbyql-GBG_9SWAQ6gIZuB-yABvYPZ5tv3XQ=.6372127f-109e-41ab-984c-082f696139a8@github.com>

> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  comment changes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8934/files
  - new: https://git.openjdk.java.net/jdk/pull/8934/files/865713fc..30fd6e27

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8934&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8934&range=06-07

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

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


From mchung at openjdk.java.net  Wed Jun  1 19:43:44 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 1 Jun 2022 19:43:44 GMT
Subject: RFR: 8287171: Refactor null caller tests to a single directory
 [v8]
In-Reply-To: <wdBGPAUgqbyql-GBG_9SWAQ6gIZuB-yABvYPZ5tv3XQ=.6372127f-109e-41ab-984c-082f696139a8@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
 <wdBGPAUgqbyql-GBG_9SWAQ6gIZuB-yABvYPZ5tv3XQ=.6372127f-109e-41ab-984c-082f696139a8@github.com>
Message-ID: <nl_TmYMZl_GbCC_C1k9mlHEYDgI9yDLW99Wg2rpLIXI=.e98eb701-6a1e-445e-9c72-0aa804557a98@github.com>

On Wed, 1 Jun 2022 19:27:33 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment changes

Marked as reviewed by mchung (Reviewer).

-------------

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


From erikj at openjdk.java.net  Wed Jun  1 20:00:18 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 1 Jun 2022 20:00:18 GMT
Subject: RFR: 8233269: Improve handling of JAVA_ARGS
In-Reply-To: <sc-pQEHJQmawDVFDNrb-zV1SvlQTgY27QvJ-aWmDT14=.8865939e-2223-4e3b-ad61-17f9bdff0c34@github.com>
References: <sc-pQEHJQmawDVFDNrb-zV1SvlQTgY27QvJ-aWmDT14=.8865939e-2223-4e3b-ad61-17f9bdff0c34@github.com>
Message-ID: <E2fGfqc49pRvwC-SaQuW2SXfUaVkzuf9Tz5vfNXf4z8=.12324691-f76a-4714-944f-125ff89c80fb@github.com>

On Wed, 1 Jun 2022 13:52:46 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> LauncherCommon.gmk is unfortunately defining JAVA_ARGS with `-J-ms8m` option for all JDK launchers, including java launcher.
> JAVA_ARGS  should not be defined for java launcher (in contrast to the other JDK launchers), and the command line option `-J-ms8m` is obsolete for java launcher.
> 
> Proposed patch removes JAVA_ARGS from java launcher, while keeping status quo for all other JDK launchers.
> The patch of LauncherCommon.gmk identifies java launcher by undefined MAIN_CLASS.
> 
> Thanks for review,
> Adam

Marked as reviewed by erikj (Reviewer).

-------------

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


From asotona at openjdk.java.net  Thu Jun  2 06:24:32 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Thu, 2 Jun 2022 06:24:32 GMT
Subject: Integrated: 8233269: Improve handling of JAVA_ARGS
In-Reply-To: <sc-pQEHJQmawDVFDNrb-zV1SvlQTgY27QvJ-aWmDT14=.8865939e-2223-4e3b-ad61-17f9bdff0c34@github.com>
References: <sc-pQEHJQmawDVFDNrb-zV1SvlQTgY27QvJ-aWmDT14=.8865939e-2223-4e3b-ad61-17f9bdff0c34@github.com>
Message-ID: <sFEtcp4OVB-zBn2_b8DJC6clyizp6SaKGEjgojW2WqY=.55177867-1877-4ca3-be8c-5dcd2115a046@github.com>

On Wed, 1 Jun 2022 13:52:46 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> LauncherCommon.gmk is unfortunately defining JAVA_ARGS with `-J-ms8m` option for all JDK launchers, including java launcher.
> JAVA_ARGS  should not be defined for java launcher (in contrast to the other JDK launchers), and the command line option `-J-ms8m` is obsolete for java launcher.
> 
> Proposed patch removes JAVA_ARGS from java launcher, while keeping status quo for all other JDK launchers.
> The patch of LauncherCommon.gmk identifies java launcher by undefined MAIN_CLASS.
> 
> Thanks for review,
> Adam

This pull request has now been integrated.

Changeset: a82417fa
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a82417fa190a132313f6734a75f1998858c164fd
Stats:     8 lines in 1 file changed: 4 ins; 1 del; 3 mod

8233269: Improve handling of JAVA_ARGS

Reviewed-by: erikj

-------------

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


From ihse at openjdk.java.net  Thu Jun  2 09:24:51 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 2 Jun 2022 09:24:51 GMT
Subject: RFR: 8287724: Fix various issues with msys2
Message-ID: <BL2e-t41394uLAkjqISDeTYe6R5A5CPNoSu_fOspVD0=.b5810340-6d79-4d5a-851d-7650665ad2e9@github.com>

I encountered a bunch of issues when running with msys2 on Windows (but one of them could have happened on cygwin as well).

* fixpath must set MSYS2_ARG_CONV_EXCL="*" before running cmd.exe to figure out the temp directory, or msys might interfere with the command line to cmd.

* Paths like "/c/s/source/jdk", meaning to point to "c:\s\source\jdk", would be interpreted by fixpath as "/cs:\source\jdk", since the leading "/c" would be considered a prefix. This is not a problem on cygwin, where the /cygpath prefix makes paths unambiguous. I countered this by checking if the file exists (as written, or just the basepath, or the first 3 parts of the path). If so, I treat it as a filename, rather than a prefix.

* Configure is supposed to handle windows-style input paths, but `--with-bootjdk=c:\java\jdk-17` or similar would break, since we started to look for files in that directory without having to normalized the path first.

* Finally, configure.guess sometimes reports msys as `mingw` and sometimes as `msys`, depending on the value of MSYSTEM. (And for some values, the old autoconf-configure.guess breaks -- I did not bother fixing this.)

-------------

Commit messages:
 - 8287724: Fix various issues with msys2

Changes: https://git.openjdk.java.net/jdk/pull/8989/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8989&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287724
  Stats: 38 lines in 3 files changed: 23 ins; 7 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8989.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8989/head:pull/8989

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


From chagedorn at openjdk.java.net  Thu Jun  2 11:33:43 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Thu, 2 Jun 2022 11:33:43 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v10]
In-Reply-To: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
Message-ID: <AeVBsr1kvyVMgW2YX9iF_ku0oYzBKe5JfIoXQXK1Fpg=.6ee96ffb-d27f-4d38-a6e6-c309f4048271@github.com>

> When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method:
> 
> Stack: [0x00007f6e01739000,0x00007f6e0183a000],  sp=0x00007f6e01838110,  free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64
> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec
> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899
> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df
> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69
> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d
> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167
> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180
> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f
> 
> This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method.
> 
> This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)):
> 
> Stack: [0x00007f34fca18000,0x00007f34fcb19000],  sp=0x00007f34fcb17110,  free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64  (c1_Compilation.cpp:607)
> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec  (c1_Compiler.cpp:250)
> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899  (compileBroker.cpp:2291)
> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df  (compileBroker.cpp:1966)
> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69  (compilerThread.cpp:59)
> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d  (thread.cpp:1297)
> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167  (thread.cpp:1280)
> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180  (thread.cpp:358)
> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f  (os_linux.cpp:705)
> 
> For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. 
> 
> The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf
> I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. 
> 
> The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability.
> 
> Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. 
> 
> **Testing:**
> Apart from manual testing, I've added two kinds of tests:
> - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers.
> - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename.
> 
> On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation.
> 
> To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional  `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number.
> 
> I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user).
> 
> Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`!
>  
> Thanks,
> Christian

Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits:

 - Fix TestDwarf for older GCC versions
 - Change logging from UL to tty based with new TraceDwarfLevel develop flag
 - Add support to parse the .debug_line section in DWARF 2 as emitted by GCC 8, add some comments
 - Merge branch 'master' into JDK-8242181
 - Merge branch 'master' into JDK-8242181
 - Merge branch 'master' into JDK-8242181
 - Fix build, add GCC flag gdwarf-4 to exclude DWARF 5, add assertions
 - Apply remaining review comments from Thomas Stuefe
 - Change load_dwarf_file with DwarfFilePath and DebugInfo
 - Revert renaming on Windows
 - ... and 55 more: https://git.openjdk.java.net/jdk/compare/6e55a72f...8c2c4ab4

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7126/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7126&range=09
  Stats: 2784 lines in 18 files changed: 2687 ins; 41 del; 56 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7126.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7126/head:pull/7126

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


From chagedorn at openjdk.java.net  Thu Jun  2 11:33:44 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Thu, 2 Jun 2022 11:33:44 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v9]
In-Reply-To: <UUR3Xr8cHQMT1iC6sgEy5vOYj0Np7I_2_-yKC2_eNaQ=.e79645d9-d7e3-4e00-aca1-bc0beccbbbab@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
 <qzR7-THzprQvPm2icCX-LHOb68Y7M_r7HOMaDCuTWFo=.f452c2fd-9787-48ee-9823-4a10dbc66257@github.com>
 <yMt7s6pHlciJmkO9lVt6p2KCRLiU_4tP2MBwtGcBDUc=.fe56c895-a352-4318-a6e4-3f32a4da7ae6@github.com>
 <UUR3Xr8cHQMT1iC6sgEy5vOYj0Np7I_2_-yKC2_eNaQ=.e79645d9-d7e3-4e00-aca1-bc0beccbbbab@github.com>
Message-ID: <REqNCKORi0CJSnixJ1fTYafdhKDziOItAIXe2u52Z2w=.7c455c20-f6c7-44e5-ae91-2f94d040249a@github.com>

On Wed, 25 May 2022 09:05:13 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Thanks Thomas for doing the testing!
>
>> Thanks Thomas for doing the testing!
> 
> Hi Christian,
> 
> I can see no problems on ppcle attributable to your test. However, I may overlook something since tests are still failing all over the place because of loom.
> 
> I see test errors in TestDwarf on ppcle and x64, however. On x64:
> 
> 
> ----------System.out:(52/5198)----------
> Command line: [/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/bin/java -cp /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/classes/runtime/ErrorHandling/TestDwarf.d:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/grmpf/testdata/jtreg/jtreg_test_19/test/hotspot/jtreg/runtime/ErrorHandling:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/classes:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/grmpf/testdata/jtreg/jtreg_test_19/test/hotspot/jtreg:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/classes/test/lib:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/grmpf/testdata/jtreg/jtreg_test_19/test/lib:/net/sapmnt.sapjvm_work/openjdk/tools/jtreg-6+2/lib/javatest.jar:/net/sapmnt.sapjvm_work/openjdk/tools/jtreg-6+2/lib/jtreg.jar -Xmx768m -Djava.awt.headless=true -Djava.util.prefs.userRoot=/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hot
 spot_tier1_work/tmp -Djava.io.tmpdir=/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/tmp -Dtest.getfreeport.max.tries=40 -ea -esa -Xlog:dwarf=info -XX:-CreateCoredumpOnCrash -Xcomp -XX:CICrashAt=1 --version ]
> [2022-05-24T18:37:00.974121691Z] Gathering output for process 44490
> [2022-05-24T18:37:02.872100892Z] Waiting for completion for process 44490
> [2022-05-24T18:37:02.872338192Z] Waiting for completion finished for process 44490
> Output and diagnostic info for process 44490 was saved into 'pid-44490-output.log'
> [2022-05-24T18:37:02.889455876Z] Waiting for completion for process 44490
> [2022-05-24T18:37:02.889604189Z] Waiting for completion finished for process 44490
> # To suppress the following error report, specify this argument
> # after -XX: or in .hotspotrc:  SuppressErrorAt=/c1_Compilation.cpp:616
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/sapmnt/sapjvm_work/openjdk/nb/linuxx86_64/jdk-dev/src/hotspot/share/c1/c1_Compilation.cpp:616), pid=44490, tid=44505
> #  assert(CICrashAt < 0 || (uintx)_env->compile_id() != (uintx)CICrashAt) failed: just as planned
> #
> # JRE version: OpenJDK Runtime Environment (19.0) (fastdebug build 19-internal-adhoc.openjdk.jdk-dev)
> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 19-internal-adhoc.openjdk.jdk-dev, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0x73ca34]  Compilation::~Compilation()+0x84
> #
> # CreateCoredumpOnCrash turned off, no core file dumped
> #
> # An error report file with more information is saved as:
> # /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/scratch/hs_err_pid44490.log
> [1.835s][info][dwarf] Open DWARF file: /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.debuginfo
> [1.842s][info][dwarf] Failed to parse the line number program header correctly.
> [1.842s][info][dwarf] Failed to process the line number program correctly.
> [1.842s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x0074176a
> [1.843s][info][dwarf] Failed to parse the line number program header correctly.
> [1.843s][info][dwarf] Failed to process the line number program correctly.
> [1.843s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x00a05011
> [1.845s][info][dwarf] Failed to parse the line number program header correctly.
> [1.845s][info][dwarf] Failed to process the line number program correctly.
> [1.845s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x00a05b78
> [1.849s][info][dwarf] Failed to parse the line number program header correctly.
> [1.849s][info][dwarf] Failed to process the line number program correctly.
> [1.849s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x018d49d3
> [1.852s][info][dwarf] Failed to parse the line number program header correctly.
> [1.852s][info][dwarf] Failed to process the line number program correctly.
> [1.852s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x018de546
> [1.855s][info][dwarf] Failed to parse the line number program header correctly.
> [1.855s][info][dwarf] Failed to process the line number program correctly.
> [1.855s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x014d86e9
> #
> # Compiler replay data is saved as:
> # /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/scratch/replay_pid44490.log
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> #
> 
> hs_err_file: hs_err_pid44490.log
> ----------System.err:(15/1242)----------
> java.lang.RuntimeException: Could not find filename or line number in "V  [libjvm.so+0x74176a]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1aa": expected true, was false
> 	at jdk.test.lib.Asserts.fail(Asserts.java:594)
> 	at jdk.test.lib.Asserts.assertTrue(Asserts.java:486)
> 	at TestDwarf.runAndCheck(TestDwarf.java:163)
> 	at TestDwarf.test(TestDwarf.java:99)
> 	at TestDwarf.main(TestDwarf.java:90)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> 	at java.base/java.lang.Thread.run(Thread.java:1585)

After getting some more logs from @tstuefe, it turns out that they are using GCC 8 in the testing which emits the `.debug_line` section in DWARF 2 format which we do not allow and we bail out during parsing. This lets `TestDwarf` fail. 

The `.debug_line` section is already handled differently by the parser compared to the other sections. GCC 10 emits DWARF 3 for some reason (even though it should emit DWARF 4 as for the other sections) while GCC 11 emits DWARF 4. Therefore, the parser can handle both DWARF 3 and 4 for `.debug_line`. Having a look at the DWARF 2 spec, it turns out that we can reuse the code for parsing DWARF 3. This allows us to update the version bailout of `.debug_line` to allow DWARF 2 as valid version. I've tested this change by building HotSpot with GCC 8.2 and playing around with it.

In this process, I've also changed `TestDwarf.java` to skip all its tests if there was a bailout of the parser due to an unsupported DWARF format. I've added some more error logging.

I've also decided to get rid of UL as discussed before and replaced it by `tty` logging in combination with a new `TraceDwarfLevel` develop flag (for the different log levels).

-------------

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


From erikj at openjdk.java.net  Thu Jun  2 12:34:23 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 2 Jun 2022 12:34:23 GMT
Subject: RFR: 8287724: Fix various issues with msys2
In-Reply-To: <BL2e-t41394uLAkjqISDeTYe6R5A5CPNoSu_fOspVD0=.b5810340-6d79-4d5a-851d-7650665ad2e9@github.com>
References: <BL2e-t41394uLAkjqISDeTYe6R5A5CPNoSu_fOspVD0=.b5810340-6d79-4d5a-851d-7650665ad2e9@github.com>
Message-ID: <gv0Bvc-AWnPFvsRzxu-LUY3w7vUcx60aq4lW6lmLLIA=.a57f57ef-6133-4e39-870e-07390cf66ed6@github.com>

On Thu, 2 Jun 2022 09:17:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I encountered a bunch of issues when running with msys2 on Windows (but one of them could have happened on cygwin as well).
> 
> * fixpath must set MSYS2_ARG_CONV_EXCL="*" before running cmd.exe to figure out the temp directory, or msys might interfere with the command line to cmd.
> 
> * Paths like "/c/s/source/jdk", meaning to point to "c:\s\source\jdk", would be interpreted by fixpath as "/cs:\source\jdk", since the leading "/c" would be considered a prefix. This is not a problem on cygwin, where the /cygpath prefix makes paths unambiguous. I countered this by checking if the file exists (as written, or just the basepath, or the first 3 parts of the path). If so, I treat it as a filename, rather than a prefix.
> 
> * Configure is supposed to handle windows-style input paths, but `--with-bootjdk=c:\java\jdk-17` or similar would break, since we started to look for files in that directory without having to normalized the path first.
> 
> * Finally, configure.guess sometimes reports msys as `mingw` and sometimes as `msys`, depending on the value of MSYSTEM. (And for some values, the old autoconf-configure.guess breaks -- I did not bother fixing this.)

Marked as reviewed by erikj (Reviewer).

-------------

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


From ihse at openjdk.java.net  Thu Jun  2 12:53:18 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 2 Jun 2022 12:53:18 GMT
Subject: Integrated: 8287724: Fix various issues with msys2
In-Reply-To: <BL2e-t41394uLAkjqISDeTYe6R5A5CPNoSu_fOspVD0=.b5810340-6d79-4d5a-851d-7650665ad2e9@github.com>
References: <BL2e-t41394uLAkjqISDeTYe6R5A5CPNoSu_fOspVD0=.b5810340-6d79-4d5a-851d-7650665ad2e9@github.com>
Message-ID: <nGC9m8WNQE3GPCmJ8kri30oqA8WutVmehAn6806ZtJc=.3fea9a32-96fa-4f51-a063-07f1986fcaf6@github.com>

On Thu, 2 Jun 2022 09:17:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I encountered a bunch of issues when running with msys2 on Windows (but one of them could have happened on cygwin as well).
> 
> * fixpath must set MSYS2_ARG_CONV_EXCL="*" before running cmd.exe to figure out the temp directory, or msys might interfere with the command line to cmd.
> 
> * Paths like "/c/s/source/jdk", meaning to point to "c:\s\source\jdk", would be interpreted by fixpath as "/cs:\source\jdk", since the leading "/c" would be considered a prefix. This is not a problem on cygwin, where the /cygpath prefix makes paths unambiguous. I countered this by checking if the file exists (as written, or just the basepath, or the first 3 parts of the path). If so, I treat it as a filename, rather than a prefix.
> 
> * Configure is supposed to handle windows-style input paths, but `--with-bootjdk=c:\java\jdk-17` or similar would break, since we started to look for files in that directory without having to normalized the path first.
> 
> * Finally, configure.guess sometimes reports msys as `mingw` and sometimes as `msys`, depending on the value of MSYSTEM. (And for some values, the old autoconf-configure.guess breaks -- I did not bother fixing this.)

This pull request has now been integrated.

Changeset: bddef715
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bddef7151849a213926ffdd86a7e228db66606b1
Stats:     38 lines in 3 files changed: 23 ins; 7 del; 8 mod

8287724: Fix various issues with msys2

Reviewed-by: erikj

-------------

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


From tprinzing at openjdk.java.net  Thu Jun  2 16:49:33 2022
From: tprinzing at openjdk.java.net (Tim Prinzing)
Date: Thu, 2 Jun 2022 16:49:33 GMT
Subject: Integrated: 8287171: Refactor null caller tests to a single directory
In-Reply-To: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
Message-ID: <7EtpUri8E-MDJyVv5PR3FNvOMqe3pmxKrJ9G4tjXK5c=.c04e70d5-81f5-4dd1-ab6a-4f32d141ad1a@github.com>

On Sat, 28 May 2022 11:50:19 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.

This pull request has now been integrated.

Changeset: e51ca1de
Author:    Tim Prinzing <tprinzing at openjdk.org>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e51ca1dee33d69c74f7f1dc2292db2f04c4ccf4c
Stats:     1303 lines in 19 files changed: 520 ins; 780 del; 3 mod

8287171: Refactor null caller tests to a single directory

Reviewed-by: ihse, mchung

-------------

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


From darcy at openjdk.java.net  Thu Jun  2 17:00:35 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 2 Jun 2022 17:00:35 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v5]
In-Reply-To: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
Message-ID: <A7OpC5JI4w4admJiIDEZCuA3QlFyyWnEj_8yBZugqbM=.b0c1cc33-91c7-47e1-b85a-cc152e805516@github.com>

> Time to start getting ready for JDK 20...

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 40 additional commits since the last revision:

 - Update symbols for JDK 19 b25.
 - Merge branch 'master' into JDK-8284858
 - Adjust deprecated options test.
 - Merge branch 'master' into JDK-8284858
 - Update deprecated options test.
 - Merge branch 'master' into JDK-8284858
 - Respond to review feedback.
 - Update symbol information for JDK 19 b24.
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - ... and 30 more: https://git.openjdk.java.net/jdk/compare/f7a25d65...e495a579

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8236/files
  - new: https://git.openjdk.java.net/jdk/pull/8236/files/54e872b5..e495a579

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=03-04

  Stats: 7203 lines in 242 files changed: 5859 ins; 868 del; 476 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8236.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236

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


From jjg at openjdk.java.net  Thu Jun  2 21:06:56 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 2 Jun 2022 21:06:56 GMT
Subject: RFR: JDK-8252717: Integrate/merge legacy standard doclet diagnostics
 and doclint
Message-ID: <xiqTEalX1TwzgKHPkpLCSXJMR072Nfyhe3Srp408b3Y=.ab4c509a-0ab0-4b12-8ea7-1ff43884fd90@github.com>

Please review a moderate change to enable (most) doclet warnings even if doclint is enabled.

Since the introduction of doclint, there was some (small) overlap between the small set of warnings generated by the doclet and the new larger set of diagnostics that could be generated by doclint.  The solution, until now, has been to disable doclet warnings when doclint is enabled. But, the sets do not overlap, and the policy has inappropriately suppressed some warnings and inhibited the generation of new warnings by the doclet that could only be done by the doclet, and not doclint.

One notable group of warnings that has been inappropriately suppressed is the warnings generated by using the `-serial warn` option.

The fundamental core of the change is to remove the conditional checks in the doclet `Messages.java`, which would suppress messages when doclint was enabled.  A consequence is that some specific messages have to disabled if they are duplicate checks if doclint is enabled. (The messages cannot be removed altogether because doclint might _not_ be enabled.)   A test is added to verify that either one message or the other is generated, but never both.

As previously noted, an issue with the earlier policy is that warnings generated by using the `-serial warn` option were inappropriately suppressed, and this change fixes that ... revealing a number of latent warnings in the JDK API that need to be addressed.  The short term fix here is to temporarily remove the use of the `-serialwarn` option. See [JDK-8287749](https://bugs.openjdk.java.net/browse/JDK-8287749).

-------------

Commit messages:
 - JDK-8252717: Integrate/merge legacy standard doclet diagnostics and doclint

Changes: https://git.openjdk.java.net/jdk/pull/9006/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9006&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252717
  Stats: 267 lines in 11 files changed: 228 ins; 21 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9006.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9006/head:pull/9006

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


From turbanoff at gmail.com  Thu Jun  2 19:26:30 2022
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Thu, 2 Jun 2022 22:26:30 +0300
Subject: Warning about git from 'make test' on Windows
Message-ID: <CAF+DQ5fxyDtf4X5vXXeL-8TQEoZupecp_9O4KQsNSSwN2pOLJg@mail.gmail.com>

Hello.
I noticed strange warnings produced by 'make test' recently on my
Win11 installation. For example:

$ make test TEST="tier1"
Building target 'test' in configuration 'windows-x86_64-server-release'
/usr/bin/bash: Files/Git/cmd/git: No such file or directory
/usr/bin/bash: Files/Git/cmd/git: No such file or directory
Test selection 'tier1', will run:


Also found this in
build\windows-x86_64-server-release\configure-support\config.log

configure:29274: checking for git
configure:29502: result:  Files/Git/cmd/git

Seems like space in git path is incorrectly handled.
Is it a known issue or is it a limitation of autoconf?

Andrey Turbanov


From iris at openjdk.java.net  Thu Jun  2 21:29:37 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 2 Jun 2022 21:29:37 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v5]
In-Reply-To: <A7OpC5JI4w4admJiIDEZCuA3QlFyyWnEj_8yBZugqbM=.b0c1cc33-91c7-47e1-b85a-cc152e805516@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <A7OpC5JI4w4admJiIDEZCuA3QlFyyWnEj_8yBZugqbM=.b0c1cc33-91c7-47e1-b85a-cc152e805516@github.com>
Message-ID: <JHtXFR9mN8psVmhAOvRFenF52uKdoxjuVefqcVw1M4s=.39da768e-4da9-4dc4-aad5-4b7460bef47b@github.com>

On Thu, 2 Jun 2022 17:00:35 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 40 additional commits since the last revision:
> 
>  - Update symbols for JDK 19 b25.
>  - Merge branch 'master' into JDK-8284858
>  - Adjust deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Update deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Respond to review feedback.
>  - Update symbol information for JDK 19 b24.
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - ... and 30 more: https://git.openjdk.java.net/jdk/compare/5a6d202d...e495a579

Changes still look good.

-------------

Marked as reviewed by iris (Reviewer).

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


From erikj at openjdk.java.net  Thu Jun  2 21:57:32 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 2 Jun 2022 21:57:32 GMT
Subject: RFR: JDK-8252717: Integrate/merge legacy standard doclet
 diagnostics and doclint
In-Reply-To: <xiqTEalX1TwzgKHPkpLCSXJMR072Nfyhe3Srp408b3Y=.ab4c509a-0ab0-4b12-8ea7-1ff43884fd90@github.com>
References: <xiqTEalX1TwzgKHPkpLCSXJMR072Nfyhe3Srp408b3Y=.ab4c509a-0ab0-4b12-8ea7-1ff43884fd90@github.com>
Message-ID: <uaPZjVlUPmfcA5PDcOFY1xPKu0zBC_r9sWOC00Ymglc=.dedeb132-2f67-4090-9023-cfc5c927e600@github.com>

On Thu, 2 Jun 2022 20:59:26 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a moderate change to enable (most) doclet warnings even if doclint is enabled.
> 
> Since the introduction of doclint, there was some (small) overlap between the small set of warnings generated by the doclet and the new larger set of diagnostics that could be generated by doclint.  The solution, until now, has been to disable doclet warnings when doclint is enabled. But, the sets do not overlap, and the policy has inappropriately suppressed some warnings and inhibited the generation of new warnings by the doclet that could only be done by the doclet, and not doclint.
> 
> One notable group of warnings that has been inappropriately suppressed is the warnings generated by using the `-serial warn` option.
> 
> The fundamental core of the change is to remove the conditional checks in the doclet `Messages.java`, which would suppress messages when doclint was enabled.  A consequence is that some specific messages have to disabled if they are duplicate checks if doclint is enabled. (The messages cannot be removed altogether because doclint might _not_ be enabled.)   A test is added to verify that either one message or the other is generated, but never both.
> 
> As previously noted, an issue with the earlier policy is that warnings generated by using the `-serial warn` option were inappropriately suppressed, and this change fixes that ... revealing a number of latent warnings in the JDK API that need to be addressed.  The short term fix here is to temporarily remove the use of the `-serialwarn` option. See [JDK-8287749](https://bugs.openjdk.java.net/browse/JDK-8287749).

Build change looks ok.

-------------

Marked as reviewed by erikj (Reviewer).

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


From magnus.ihse.bursie at oracle.com  Thu Jun  2 23:10:09 2022
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 3 Jun 2022 01:10:09 +0200
Subject: Warning about git from 'make test' on Windows
In-Reply-To: <CAF+DQ5fxyDtf4X5vXXeL-8TQEoZupecp_9O4KQsNSSwN2pOLJg@mail.gmail.com>
References: <CAF+DQ5fxyDtf4X5vXXeL-8TQEoZupecp_9O4KQsNSSwN2pOLJg@mail.gmail.com>
Message-ID: <cefd3097-41e8-3d2f-1c42-3d31005169be@oracle.com>


On 2022-06-02 21:26, Andrey Turbanov wrote:
> Hello.
> I noticed strange warnings produced by 'make test' recently on my
> Win11 installation. For example:
>
> $ make test TEST="tier1"
> Building target 'test' in configuration 'windows-x86_64-server-release'
> /usr/bin/bash: Files/Git/cmd/git: No such file or directory
> /usr/bin/bash: Files/Git/cmd/git: No such file or directory
> Test selection 'tier1', will run:
>
>
> Also found this in
> build\windows-x86_64-server-release\configure-support\config.log
>
> configure:29274: checking for git
> configure:29502: result:  Files/Git/cmd/git
>
> Seems like space in git path is incorrectly handled.
> Is it a known issue or is it a limitation of autoconf?
Spaces in paths is always tricky and is best avoided. That being said, 
we try to make autoconf robust for tools in directories with space in them.

Are you running in Cygwin?

Can you verify that your C: drive can use short paths. See 
https://openjdk.java.net/groups/build/doc/building.html#spaces-in-path

/Magnus
>
> Andrey Turbanov



From christoph.langer at sap.com  Fri Jun  3 07:09:17 2022
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 3 Jun 2022 07:09:17 +0000
Subject: Warning about git from 'make test' on Windows
In-Reply-To: <cefd3097-41e8-3d2f-1c42-3d31005169be@oracle.com>
References: <CAF+DQ5fxyDtf4X5vXXeL-8TQEoZupecp_9O4KQsNSSwN2pOLJg@mail.gmail.com>
 <cefd3097-41e8-3d2f-1c42-3d31005169be@oracle.com>
Message-ID: <PAXPR02MB7799A7161D75D758C535D04D8AA19@PAXPR02MB7799.eurprd02.prod.outlook.com>

Hi,

I see the same on my windows build. I verified that 8.3 filenames are enabled.

I took a little closer look. In my PATH env in Cygwin I have: ...:/cygdrive/c/Program Files/Git/cmd:...

The git path is resolved via UTIL_LOOKUP_PROGS(GIT, git) in basic_tools.m4. UTIL_LOOKUP_PROGS, defined in util_paths.m4 must somehow not be capable to correctly resolve the path with spaces. The output in configure is:

checking for git...  Files/Git/cmd/git

Maybe this gives a hint on how to fix it? I guess I can configure my path to use the 8.3 notation. But maybe UTIL_LOOKUP_PROGS could be improved?

Cheers
Christoph

> -----Original Message-----
> From: build-dev <build-dev-retn at openjdk.java.net> On Behalf Of Magnus Ihse
> Bursie
> Sent: Freitag, 3. Juni 2022 01:10
> To: Andrey Turbanov <turbanoff at gmail.com>; build-dev at openjdk.java.net
> Subject: Re: Warning about git from 'make test' on Windows
> 
> 
> On 2022-06-02 21:26, Andrey Turbanov wrote:
> > Hello.
> > I noticed strange warnings produced by 'make test' recently on my
> > Win11 installation. For example:
> >
> > $ make test TEST="tier1"
> > Building target 'test' in configuration 'windows-x86_64-server-release'
> > /usr/bin/bash: Files/Git/cmd/git: No such file or directory
> > /usr/bin/bash: Files/Git/cmd/git: No such file or directory Test
> > selection 'tier1', will run:
> >
> >
> > Also found this in
> > build\windows-x86_64-server-release\configure-support\config.log
> >
> > configure:29274: checking for git
> > configure:29502: result:  Files/Git/cmd/git
> >
> > Seems like space in git path is incorrectly handled.
> > Is it a known issue or is it a limitation of autoconf?
> Spaces in paths is always tricky and is best avoided. That being said, we try to
> make autoconf robust for tools in directories with space in them.
> 
> Are you running in Cygwin?
> 
> Can you verify that your C: drive can use short paths. See
> https://openjdk.java.net/groups/build/doc/building.html#spaces-in-path
> 
> /Magnus
> >
> > Andrey Turbanov


From prappo at openjdk.java.net  Fri Jun  3 07:51:26 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 3 Jun 2022 07:51:26 GMT
Subject: RFR: JDK-8252717: Integrate/merge legacy standard doclet
 diagnostics and doclint
In-Reply-To: <xiqTEalX1TwzgKHPkpLCSXJMR072Nfyhe3Srp408b3Y=.ab4c509a-0ab0-4b12-8ea7-1ff43884fd90@github.com>
References: <xiqTEalX1TwzgKHPkpLCSXJMR072Nfyhe3Srp408b3Y=.ab4c509a-0ab0-4b12-8ea7-1ff43884fd90@github.com>
Message-ID: <UigFkfe0irYwYzajmRqrDSGrXEA1Nj0ZNw-PdKeVt6U=.f2da003c-574b-4c05-acdf-c37ba6b3bbf9@github.com>

On Thu, 2 Jun 2022 20:59:26 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a moderate change to enable (most) doclet warnings even if doclint is enabled.
> 
> Since the introduction of doclint, there was some (small) overlap between the small set of warnings generated by the doclet and the new larger set of diagnostics that could be generated by doclint.  The solution, until now, has been to disable doclet warnings when doclint is enabled. But, the sets do not overlap, and the policy has inappropriately suppressed some warnings and inhibited the generation of new warnings by the doclet that could only be done by the doclet, and not doclint.
> 
> One notable group of warnings that has been inappropriately suppressed is the warnings generated by using the `-serial warn` option.
> 
> The fundamental core of the change is to remove the conditional checks in the doclet `Messages.java`, which would suppress messages when doclint was enabled.  A consequence is that some specific messages have to disabled if they are duplicate checks if doclint is enabled. (The messages cannot be removed altogether because doclint might _not_ be enabled.)   A test is added to verify that either one message or the other is generated, but never both.
> 
> As previously noted, an issue with the earlier policy is that warnings generated by using the `-serial warn` option were inappropriately suppressed, and this change fixes that ... revealing a number of latent warnings in the JDK API that need to be addressed.  The short term fix here is to temporarily remove the use of the `-serialwarn` option. See [JDK-8287749](https://bugs.openjdk.java.net/browse/JDK-8287749).

> Since the introduction of doclint, there was some (small) overlap between the small set ... and the new larger set ... But, the sets do not overlap

Do or do they not overlap? :)

> the policy has inappropriately suppressed some warnings and inhibited the generation of new warnings

What's the difference between "suppressed" and "inhibited" here?

Generally, how can we be sure that we haven't missed any double-reported cases?

test/langtools/jdk/javadoc/doclet/testDoclintDocletMessages/TestDocLintDocletMessages.java line 136:

> 134:         var doclintResult = new Result(Exit.OK, "C.java:8: warning: @param \"x\" has already been specified");
> 135:         var docletResult  = new Result(Exit.OK, "C.java:8: warning: Parameter \"x\" is documented more than once.");
> 136: 

Both are warnings, hence two `Exit.OK` results; I see.

test/langtools/jdk/javadoc/doclet/testDoclintDocletMessages/TestDocLintDocletMessages.java line 190:

> 188:         checkExit(expect.exit);
> 189: 
> 190:         checkOutput(Output.OUT, true,expect.message);

Add whitespace after `true,`

-------------

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


From tprinzing at openjdk.java.net  Fri Jun  3 08:02:58 2022
From: tprinzing at openjdk.java.net (Tim Prinzing)
Date: Fri, 3 Jun 2022 08:02:58 GMT
Subject: RFR: 8287745 jni/nullCaller/NullCallerTest.java fails with
 "exitValue = 1"
Message-ID: <zIN25qcOaiLtiGNz4Vs8CEIHna7wwGSmcJ_X5k21Amo=.3e63c10d-ddf2-4dd9-92aa-96d8eab26f3e@github.com>

Fixed JtregNativeJdk.gmk to include c++ libs for NullCallerTest

-------------

Commit messages:
 - 8287745 Fix JtregNativeJdk.gmk to include c++ libs for NullCallerTest

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

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


From erikj at openjdk.java.net  Fri Jun  3 12:42:34 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 3 Jun 2022 12:42:34 GMT
Subject: RFR: 8287745 jni/nullCaller/NullCallerTest.java fails with
 "exitValue = 1"
In-Reply-To: <zIN25qcOaiLtiGNz4Vs8CEIHna7wwGSmcJ_X5k21Amo=.3e63c10d-ddf2-4dd9-92aa-96d8eab26f3e@github.com>
References: <zIN25qcOaiLtiGNz4Vs8CEIHna7wwGSmcJ_X5k21Amo=.3e63c10d-ddf2-4dd9-92aa-96d8eab26f3e@github.com>
Message-ID: <ImJg5fzr4_EQuRWOpEX16tsijVyMnT_vJPYboF6THxo=.0e1239b1-8e3d-4d2c-94a4-8591237cea64@github.com>

On Fri, 3 Jun 2022 07:56:38 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> Fixed JtregNativeJdk.gmk to include c++ libs for NullCallerTest

Marked as reviewed by erikj (Reviewer).

-------------

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


From jjg at openjdk.java.net  Fri Jun  3 15:49:36 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 3 Jun 2022 15:49:36 GMT
Subject: RFR: JDK-8252717: Integrate/merge legacy standard doclet
 diagnostics and doclint
In-Reply-To: <UigFkfe0irYwYzajmRqrDSGrXEA1Nj0ZNw-PdKeVt6U=.f2da003c-574b-4c05-acdf-c37ba6b3bbf9@github.com>
References: <xiqTEalX1TwzgKHPkpLCSXJMR072Nfyhe3Srp408b3Y=.ab4c509a-0ab0-4b12-8ea7-1ff43884fd90@github.com>
 <UigFkfe0irYwYzajmRqrDSGrXEA1Nj0ZNw-PdKeVt6U=.f2da003c-574b-4c05-acdf-c37ba6b3bbf9@github.com>
Message-ID: <_NKXePhm1uWXlbdYIwKEwlgCk1CiYsOlklzvcNyPS-s=.78e587fb-6b2a-4139-bdce-da407eb4d67a@github.com>

On Fri, 3 Jun 2022 07:48:15 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> > Since the introduction of doclint, there was some (small) overlap between the small set ... and the new larger set ... But, the sets do not overlap
> 
> Do or do they not overlap? :)

Ooops. Wrong word. I was meaning that neither set contains the other.

> 
> > the policy has inappropriately suppressed some warnings and inhibited the generation of new warnings
> 
> What's the difference between "suppressed" and "inhibited" here?

I was using "suppressed" with respect to existing doclet warnings, which have not been displayed if doclint was enabled, and was using "inhibited" with respect to writing code to generate new warnings, meaning that there was not much benefit to adding new warnings if they were typically going to be suppressed when doclint was enabled.


> 
> Generally, how can we be sure that we haven't missed any double-reported cases?

I did a visual inspection over the Checker class. Generally, Checker does more in the area of "missing" comments and HTML issues, with less focus on "reference" issues, while the doclet does not report missing comments and does not even attempt to detect HTML issues. The overlap is "syntax" issues and "reference" issues, which are covered here.

The test is set up to be a framework to accommodate new cases if any should arise.

-------------

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


From prappo at openjdk.java.net  Fri Jun  3 16:02:34 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 3 Jun 2022 16:02:34 GMT
Subject: RFR: JDK-8252717: Integrate/merge legacy standard doclet
 diagnostics and doclint
In-Reply-To: <xiqTEalX1TwzgKHPkpLCSXJMR072Nfyhe3Srp408b3Y=.ab4c509a-0ab0-4b12-8ea7-1ff43884fd90@github.com>
References: <xiqTEalX1TwzgKHPkpLCSXJMR072Nfyhe3Srp408b3Y=.ab4c509a-0ab0-4b12-8ea7-1ff43884fd90@github.com>
Message-ID: <u8fBvHgu7MTFEAMxeXDJlkaAPRo1D_fK_saUqaYdsVw=.885466fd-1170-4b32-9801-d4dc146b8c76@github.com>

On Thu, 2 Jun 2022 20:59:26 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a moderate change to enable (most) doclet warnings even if doclint is enabled.
> 
> Since the introduction of doclint, there was some (small) overlap between the small set of warnings generated by the doclet and the new larger set of diagnostics that could be generated by doclint.  The solution, until now, has been to disable doclet warnings when doclint is enabled. But, the sets do not overlap, and the policy has inappropriately suppressed some warnings and inhibited the generation of new warnings by the doclet that could only be done by the doclet, and not doclint.
> 
> One notable group of warnings that has been inappropriately suppressed is the warnings generated by using the `-serial warn` option.
> 
> The fundamental core of the change is to remove the conditional checks in the doclet `Messages.java`, which would suppress messages when doclint was enabled.  A consequence is that some specific messages have to disabled if they are duplicate checks if doclint is enabled. (The messages cannot be removed altogether because doclint might _not_ be enabled.)   A test is added to verify that either one message or the other is generated, but never both.
> 
> As previously noted, an issue with the earlier policy is that warnings generated by using the `-serial warn` option were inappropriately suppressed, and this change fixes that ... revealing a number of latent warnings in the JDK API that need to be addressed.  The short term fix here is to temporarily remove the use of the `-serialwarn` option. See [JDK-8287749](https://bugs.openjdk.java.net/browse/JDK-8287749).

Looks good.

> I did a visual inspection over the Checker class.

> The test is set up to be a framework to accommodate new cases if any should arise.

This is good. It would be even better if we had a mechanism to reduce risk of diagnostic duplication in the future. I don't have any concrete proposal, but unique internal error codes shared between doclint and doclet come to mind.

-------------

Marked as reviewed by prappo (Reviewer).

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


From jjg at openjdk.java.net  Fri Jun  3 16:13:34 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 3 Jun 2022 16:13:34 GMT
Subject: RFR: JDK-8252717: Integrate/merge legacy standard doclet
 diagnostics and doclint
In-Reply-To: <u8fBvHgu7MTFEAMxeXDJlkaAPRo1D_fK_saUqaYdsVw=.885466fd-1170-4b32-9801-d4dc146b8c76@github.com>
References: <xiqTEalX1TwzgKHPkpLCSXJMR072Nfyhe3Srp408b3Y=.ab4c509a-0ab0-4b12-8ea7-1ff43884fd90@github.com>
 <u8fBvHgu7MTFEAMxeXDJlkaAPRo1D_fK_saUqaYdsVw=.885466fd-1170-4b32-9801-d4dc146b8c76@github.com>
Message-ID: <mpGWTiEp9iAtmDrX9VJsX8kg9fOL_TpgMJJYEHnNNak=.a19fcb9a-2401-44ad-af1e-00ed399a1c13@github.com>

On Fri, 3 Jun 2022 15:59:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> > I did a visual inspection over the Checker class.
> 
> > The test is set up to be a framework to accommodate new cases if any should arise.
> 
> This is good. It would be even better if we had a mechanism to reduce risk of diagnostic duplication in the future. I don't have any concrete proposal, but unique internal error codes shared between doclint and doclet come to mind.

I would also like to have a policy to align the user-facing content of the diagnostic message. This includes the severity (warning or error) as well as the position and message text, including substituted values.

-------------

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


From egahlin at openjdk.java.net  Fri Jun  3 16:16:10 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Fri, 3 Jun 2022 16:16:10 GMT
Subject: RFR: 8287811: JFR: jfr configure error message should not print stack
 trace
Message-ID: <B5G_hgzQPag0OFJgQH0O3zr_FhZVXA6yj8N-HP1WddA=.32af024b-b917-4a5d-856c-46af1b2a43d5@github.com>

Could I have a review of PR that removes a printStackTrace() for the jfr tool. 

Testing: jdk/jfr/tool

Thanks
Erik

-------------

Commit messages:
 - Initial

Changes: https://git.openjdk.java.net/jdk/pull/9018/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9018&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287811
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9018.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9018/head:pull/9018

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


From jjg at openjdk.java.net  Fri Jun  3 16:22:41 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 3 Jun 2022 16:22:41 GMT
Subject: RFR: JDK-8252717: Integrate/merge legacy standard doclet
 diagnostics and doclint [v2]
In-Reply-To: <xiqTEalX1TwzgKHPkpLCSXJMR072Nfyhe3Srp408b3Y=.ab4c509a-0ab0-4b12-8ea7-1ff43884fd90@github.com>
References: <xiqTEalX1TwzgKHPkpLCSXJMR072Nfyhe3Srp408b3Y=.ab4c509a-0ab0-4b12-8ea7-1ff43884fd90@github.com>
Message-ID: <0cAZI-fphZqjw_WXo9BKkRBqeFGv0TDu76EGtpMHRQU=.9c6b1612-5ca7-4d79-b4a9-7c621189b47b@github.com>

> Please review a moderate change to enable (most) doclet warnings even if doclint is enabled.
> 
> Since the introduction of doclint, there was some (small) overlap between the small set of warnings generated by the doclet and the new larger set of diagnostics that could be generated by doclint.  The solution, until now, has been to disable doclet warnings when doclint is enabled. But, neither set contains the other, and the policy has inappropriately suppressed some warnings and inhibited writing new code to generate new warnings by the doclet that could only be done by the doclet, and not doclint.
> 
> One notable group of warnings that has been inappropriately suppressed is the warnings generated by using the `-serial warn` option.
> 
> The fundamental core of the change is to remove the conditional checks in the doclet `Messages.java`, which would suppress messages when doclint was enabled.  A consequence is that some specific messages have to disabled if they are duplicate checks if doclint is enabled. (The messages cannot be removed altogether because doclint might _not_ be enabled.)   A test is added to verify that either one message or the other is generated, but never both.
> 
> As previously noted, an issue with the earlier policy is that warnings generated by using the `-serial warn` option were inappropriately suppressed, and this change fixes that ... revealing a number of latent warnings in the JDK API that need to be addressed.  The short term fix here is to temporarily remove the use of the `-serialwarn` option. See [JDK-8287749](https://bugs.openjdk.java.net/browse/JDK-8287749).

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  fix whitespace

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9006/files
  - new: https://git.openjdk.java.net/jdk/pull/9006/files/2f4bc7fb..55b5576f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9006&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9006&range=00-01

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

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


From jjg at openjdk.java.net  Fri Jun  3 16:22:42 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 3 Jun 2022 16:22:42 GMT
Subject: RFR: JDK-8252717: Integrate/merge legacy standard doclet
 diagnostics and doclint [v2]
In-Reply-To: <UigFkfe0irYwYzajmRqrDSGrXEA1Nj0ZNw-PdKeVt6U=.f2da003c-574b-4c05-acdf-c37ba6b3bbf9@github.com>
References: <xiqTEalX1TwzgKHPkpLCSXJMR072Nfyhe3Srp408b3Y=.ab4c509a-0ab0-4b12-8ea7-1ff43884fd90@github.com>
 <UigFkfe0irYwYzajmRqrDSGrXEA1Nj0ZNw-PdKeVt6U=.f2da003c-574b-4c05-acdf-c37ba6b3bbf9@github.com>
Message-ID: <iDo8xMvIwaHnq0kd9cigDbYE-u-cYohoZyHYSUkigxE=.7ceb31ad-d573-4689-a5cb-4ac0ffa38a96@github.com>

On Thu, 2 Jun 2022 23:33:13 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix whitespace
>
> test/langtools/jdk/javadoc/doclet/testDoclintDocletMessages/TestDocLintDocletMessages.java line 190:
> 
>> 188:         checkExit(expect.exit);
>> 189: 
>> 190:         checkOutput(Output.OUT, true,expect.message);
> 
> Add whitespace after `true,`

?

-------------

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


From jjg at openjdk.java.net  Fri Jun  3 16:22:44 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 3 Jun 2022 16:22:44 GMT
Subject: Integrated: JDK-8252717: Integrate/merge legacy standard doclet
 diagnostics and doclint
In-Reply-To: <xiqTEalX1TwzgKHPkpLCSXJMR072Nfyhe3Srp408b3Y=.ab4c509a-0ab0-4b12-8ea7-1ff43884fd90@github.com>
References: <xiqTEalX1TwzgKHPkpLCSXJMR072Nfyhe3Srp408b3Y=.ab4c509a-0ab0-4b12-8ea7-1ff43884fd90@github.com>
Message-ID: <k2ITxgrXJFNMuJhnf-BRFEQ50F-B8Li3ClqQwz-6ki0=.1790a1dd-0426-4dbc-8874-cf221f200b5e@github.com>

On Thu, 2 Jun 2022 20:59:26 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a moderate change to enable (most) doclet warnings even if doclint is enabled.
> 
> Since the introduction of doclint, there was some (small) overlap between the small set of warnings generated by the doclet and the new larger set of diagnostics that could be generated by doclint.  The solution, until now, has been to disable doclet warnings when doclint is enabled. But, neither set contains the other, and the policy has inappropriately suppressed some warnings and inhibited writing new code to generate new warnings by the doclet that could only be done by the doclet, and not doclint.
> 
> One notable group of warnings that has been inappropriately suppressed is the warnings generated by using the `-serial warn` option.
> 
> The fundamental core of the change is to remove the conditional checks in the doclet `Messages.java`, which would suppress messages when doclint was enabled.  A consequence is that some specific messages have to disabled if they are duplicate checks if doclint is enabled. (The messages cannot be removed altogether because doclint might _not_ be enabled.)   A test is added to verify that either one message or the other is generated, but never both.
> 
> As previously noted, an issue with the earlier policy is that warnings generated by using the `-serial warn` option were inappropriately suppressed, and this change fixes that ... revealing a number of latent warnings in the JDK API that need to be addressed.  The short term fix here is to temporarily remove the use of the `-serialwarn` option. See [JDK-8287749](https://bugs.openjdk.java.net/browse/JDK-8287749).

This pull request has now been integrated.

Changeset: 59e9700c
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/59e9700c4e0ae892f15607bcaa267e5868eb0512
Stats:     267 lines in 11 files changed: 228 ins; 21 del; 18 mod

8252717: Integrate/merge legacy standard doclet diagnostics and doclint

Reviewed-by: erikj, prappo

-------------

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


From mchung at openjdk.java.net  Fri Jun  3 18:20:38 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 3 Jun 2022 18:20:38 GMT
Subject: RFR: 8287745 jni/nullCaller/NullCallerTest.java fails with
 "exitValue = 1"
In-Reply-To: <zIN25qcOaiLtiGNz4Vs8CEIHna7wwGSmcJ_X5k21Amo=.3e63c10d-ddf2-4dd9-92aa-96d8eab26f3e@github.com>
References: <zIN25qcOaiLtiGNz4Vs8CEIHna7wwGSmcJ_X5k21Amo=.3e63c10d-ddf2-4dd9-92aa-96d8eab26f3e@github.com>
Message-ID: <6Jh7Ed-de3W21CDHprxiz7dkCjJkt6zgMAVlTw-ALuo=.631bf732-77b9-4764-9637-a78c9f3d4509@github.com>

On Fri, 3 Jun 2022 07:56:38 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> Fixed JtregNativeJdk.gmk to include c++ libs for NullCallerTest

Marked as reviewed by mchung (Reviewer).

make/test/JtregNativeJdk.gmk line 67:

> 65:   BUILD_JDK_JTREG_EXECUTABLES_LIBS_exeNullCallerTest := $(LIBCXX) jvm.lib
> 66:   BUILD_JDK_JTREG_EXECUTABLES_LIBS_exerevokeall := advapi32.lib
> 67:   BUILD_JDK_JTREG_EXECUTABLES_CFLAGS_exeNullCallerTest := /EHsc

Does this test need this flag?  or the default exception handling behavior is adequate?

-------------

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


From dcubed at openjdk.java.net  Fri Jun  3 22:00:43 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 3 Jun 2022 22:00:43 GMT
Subject: RFR: 8287745 jni/nullCaller/NullCallerTest.java fails with
 "exitValue = 1"
In-Reply-To: <zIN25qcOaiLtiGNz4Vs8CEIHna7wwGSmcJ_X5k21Amo=.3e63c10d-ddf2-4dd9-92aa-96d8eab26f3e@github.com>
References: <zIN25qcOaiLtiGNz4Vs8CEIHna7wwGSmcJ_X5k21Amo=.3e63c10d-ddf2-4dd9-92aa-96d8eab26f3e@github.com>
Message-ID: <XT_5JrRKSWm3QIt8x2hrE_wI366SZ6bAEsUo22VdH8U=.8d0d0110-fad9-4f23-b73a-9b65f5bed131@github.com>

On Fri, 3 Jun 2022 07:56:38 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> Fixed JtregNativeJdk.gmk to include c++ libs for NullCallerTest

I did a Mach5 Tier1 test run on the v00 version of this patch. There were
no failures and all 6 runs of jni/nullCaller/NullCallerTest.java passed.

-------------

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


From mchung at openjdk.java.net  Fri Jun  3 22:39:35 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 3 Jun 2022 22:39:35 GMT
Subject: RFR: 8287745 jni/nullCaller/NullCallerTest.java fails with
 "exitValue = 1"
In-Reply-To: <zIN25qcOaiLtiGNz4Vs8CEIHna7wwGSmcJ_X5k21Amo=.3e63c10d-ddf2-4dd9-92aa-96d8eab26f3e@github.com>
References: <zIN25qcOaiLtiGNz4Vs8CEIHna7wwGSmcJ_X5k21Amo=.3e63c10d-ddf2-4dd9-92aa-96d8eab26f3e@github.com>
Message-ID: <mz60RorhLyE_9Ul2zjutPcjr83wkWGGf79yM0clxHkc=.f95f0d29-4b15-4771-b651-cea846ab5af5@github.com>

On Fri, 3 Jun 2022 07:56:38 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> Fixed JtregNativeJdk.gmk to include c++ libs for NullCallerTest

Thanks for doing the run, Dan.

-------------

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


From tprinzing at openjdk.java.net  Fri Jun  3 22:44:32 2022
From: tprinzing at openjdk.java.net (Tim Prinzing)
Date: Fri, 3 Jun 2022 22:44:32 GMT
Subject: RFR: 8287745 jni/nullCaller/NullCallerTest.java fails with
 "exitValue = 1"
In-Reply-To: <6Jh7Ed-de3W21CDHprxiz7dkCjJkt6zgMAVlTw-ALuo=.631bf732-77b9-4764-9637-a78c9f3d4509@github.com>
References: <zIN25qcOaiLtiGNz4Vs8CEIHna7wwGSmcJ_X5k21Amo=.3e63c10d-ddf2-4dd9-92aa-96d8eab26f3e@github.com>
 <6Jh7Ed-de3W21CDHprxiz7dkCjJkt6zgMAVlTw-ALuo=.631bf732-77b9-4764-9637-a78c9f3d4509@github.com>
Message-ID: <GegwgfWbzc8BRwmse56d63EBNGkPuby25M6aQfZtO6k=.4ea706c7-9e3d-40b1-a6ab-a16fe32b890f@github.com>

On Fri, 3 Jun 2022 18:16:53 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Fixed JtregNativeJdk.gmk to include c++ libs for NullCallerTest
>
> make/test/JtregNativeJdk.gmk line 67:
> 
>> 65:   BUILD_JDK_JTREG_EXECUTABLES_LIBS_exeNullCallerTest := $(LIBCXX) jvm.lib
>> 66:   BUILD_JDK_JTREG_EXECUTABLES_LIBS_exerevokeall := advapi32.lib
>> 67:   BUILD_JDK_JTREG_EXECUTABLES_CFLAGS_exeNullCallerTest := /EHsc
> 
> Does this test need this flag?  or the default exception handling behavior is adequate?

iostreams don't compile without it.  While the tests currently have printf, the 8281001 restores back to using iostream and this file doesn't have to change.

-------------

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


From mchung at openjdk.java.net  Fri Jun  3 22:49:31 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 3 Jun 2022 22:49:31 GMT
Subject: RFR: 8287745 jni/nullCaller/NullCallerTest.java fails with
 "exitValue = 1"
In-Reply-To: <GegwgfWbzc8BRwmse56d63EBNGkPuby25M6aQfZtO6k=.4ea706c7-9e3d-40b1-a6ab-a16fe32b890f@github.com>
References: <zIN25qcOaiLtiGNz4Vs8CEIHna7wwGSmcJ_X5k21Amo=.3e63c10d-ddf2-4dd9-92aa-96d8eab26f3e@github.com>
 <6Jh7Ed-de3W21CDHprxiz7dkCjJkt6zgMAVlTw-ALuo=.631bf732-77b9-4764-9637-a78c9f3d4509@github.com>
 <GegwgfWbzc8BRwmse56d63EBNGkPuby25M6aQfZtO6k=.4ea706c7-9e3d-40b1-a6ab-a16fe32b890f@github.com>
Message-ID: <gvBpgrM-DlVMleGoirNHQgNSDRBOQdsbLmeGl9d1GFY=.1c7c3701-bd27-4980-86ed-d6e53adecf86@github.com>

On Fri, 3 Jun 2022 22:40:52 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> make/test/JtregNativeJdk.gmk line 67:
>> 
>>> 65:   BUILD_JDK_JTREG_EXECUTABLES_LIBS_exeNullCallerTest := $(LIBCXX) jvm.lib
>>> 66:   BUILD_JDK_JTREG_EXECUTABLES_LIBS_exerevokeall := advapi32.lib
>>> 67:   BUILD_JDK_JTREG_EXECUTABLES_CFLAGS_exeNullCallerTest := /EHsc
>> 
>> Does this test need this flag?  or the default exception handling behavior is adequate?
>
> iostreams don't compile without it.  While the tests currently have printf, the 8281001 restores back to using iostream and this file doesn't have to change.

Ok, thanks.

-------------

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


From lkorinth at openjdk.java.net  Sat Jun  4 01:59:04 2022
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Sat, 4 Jun 2022 01:59:04 GMT
Subject: RFR: 8287828: Fix so that one can select jtreg test case by ID from
 make
Message-ID: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>

One can select a testcase by ID when running a jtreg test case directly from jtreg (using the testcase.java#testID syntax). However, this has not been possible to do when launching jtreg indirectly from make.

This fix attempts to address this issue. I have not tested this thoroughly yet, I wanted to show the code to get feedback first. The idea is to *not* emulated destructive imperative assignments through the use of eval. I instead try to handle it in a functional style without reassigning variables. I have tried to make the change as small as possible.

I am not used to change the build system, so I would appreciate thorough review.

-------------

Commit messages:
 - 8287828: Fix so that one can select jtreg test case by ID from make

Changes: https://git.openjdk.java.net/jdk/pull/9028/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9028&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287828
  Stats: 48 lines in 1 file changed: 24 ins; 21 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9028.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9028/head:pull/9028

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


From dholmes at openjdk.java.net  Mon Jun  6 07:48:20 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 6 Jun 2022 07:48:20 GMT
Subject: RFR: 8287745 jni/nullCaller/NullCallerTest.java fails with
 "exitValue = 1"
In-Reply-To: <zIN25qcOaiLtiGNz4Vs8CEIHna7wwGSmcJ_X5k21Amo=.3e63c10d-ddf2-4dd9-92aa-96d8eab26f3e@github.com>
References: <zIN25qcOaiLtiGNz4Vs8CEIHna7wwGSmcJ_X5k21Amo=.3e63c10d-ddf2-4dd9-92aa-96d8eab26f3e@github.com>
Message-ID: <GFESpV7wctIPePQDShvYmr_HtwdgsZZegBQ-1jYzAIQ=.088f0795-0c8c-44e9-a15c-817430933982@github.com>

On Fri, 3 Jun 2022 07:56:38 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> Fixed JtregNativeJdk.gmk to include c++ libs for NullCallerTest

Hi Tim,

Sorry but I have to ask why this test was created as a C++ program instead of keeping it as a C program likes it predecessors? No need for C++ libs or special exception handling flags in that case.

-------------

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


From erikj at openjdk.java.net  Mon Jun  6 08:01:26 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 6 Jun 2022 08:01:26 GMT
Subject: RFR: 8287828: Fix so that one can select jtreg test case by ID
 from make
In-Reply-To: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
References: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
Message-ID: <Erswt-axXqntJXKoWwjzyGdVw1u-ZUx-wlVxWN6p0b8=.492d4206-60d9-4858-b3ad-7358be799d73@github.com>

On Sat, 4 Jun 2022 01:51:20 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> One can select a testcase by ID when running a jtreg test case directly from jtreg (using the testcase.java#testID syntax). However, this has not been possible to do when launching jtreg indirectly from make.
> 
> This fix attempts to address this issue. I have not tested this thoroughly yet, I wanted to show the code to get feedback first. The idea is to *not* emulated destructive imperative assignments through the use of eval. I instead try to handle it in a functional style without reassigning variables. I have tried to make the change as small as possible.
> 
> I am not used to change the build system, so I would appreciate thorough review.
> 
> `IfAppend` and `IfPrepend` are general purpose functions. If similar functions exists elsewhere inside the code base or in make itself I should probably use those instead. If they do not exist, they might be useful elsewhere and maybe should be placed in a common make file instead of the RunTests.gmk file.

I think this is a nice fix. I mostly have style opinions. I would also like to have Magnus look at this as he wrote this originally.

As for testing, it would be good to verify a decently sized job in Mach5, as well as trying to use the TestID selection on multiple platforms.

make/RunTests.gmk line 39:

> 37: ################################################################################
> 38: 
> 39: HASH:=\#

HASH is already defined in MakeBase.gmk so should be available here.

make/RunTests.gmk line 47:

> 45: define IfPrepend
> 46: $(if $(strip $1),$(strip $2)$(strip $1),)
> 47: endef

These two probably fits better in make/common/Utils.gmk. 

Also please have a look at the [Code Conventions for the Build System](http://openjdk.java.net/groups/build/doc/code-conventions.html). One liner macros like this we like to format like this:


IfPrepend = \
  $(if $(strip $1),$(strip $2)$(strip $1),)

make/RunTests.gmk line 51:

> 49: define TestID
> 50: $(subst .java,,$(subst .java$(HASH),,$(suffix $(notdir $1))))
> 51: endef

This macro deserves a comment explaining what it's trying to do.

make/RunTests.gmk line 53:

> 51: endef
> 52: 
> 53: define HashTestID

This one too.

make/RunTests.gmk line 377:

> 375: # either absolute or relative to any of the TEST_BASEDIRS or test roots.
> 376: define ParseJtregTestSelection
> 377: $(call IfAppend, \

Please adjust indentation of the whole body here.

make/RunTests.gmk line 444:

> 442: $(strip $(foreach parser,ParseCustomTestSelection ParseGtestTestSelection ParseMicroTestSelection ParseJtregTestSelection ParseSpecialTestSelection \
> 443:  ,$(call $(parser),$1)))
> 444: endef

As this is logically a one-liner macro, please format according to guidelines. Also try to keep lines shortish. Something like this:

Suggestion:

ParseTestSelection = \
  $(strip $(foreach parser, ParseCustomTestSelection ParseGtestTestSelection ParseMicroTestSelection \ 
      ParseJtregTestSelection ParseSpecialTestSelection, \
    $(call $(parser), $1) \
  ))

make/RunTests.gmk line 448:

> 446: # Now intelligently convert the test selection given by the user in TEST
> 447: # into a list of fully qualified test descriptors of the tests to run.
> 448: TESTS_TO_RUN:=$(strip $(foreach test,$(TEST),$(call ParseTestSelection,$(test))))

I think this rewrite is more elegant, but logically there is a difference as it no longer breaks early. I would like to have Magnus' opinion on this as he wrote this originally.

Style wise, please leave spaces around operators and space after comma when possible. The top level strip should handle any whitespace issues caused by this.

-------------

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


From dholmes at openjdk.java.net  Mon Jun  6 10:51:31 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 6 Jun 2022 10:51:31 GMT
Subject: RFR: 8287828: Fix so that one can select jtreg test case by ID
 from make
In-Reply-To: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
References: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
Message-ID: <XFetdwE-qaEBR5A6V3z3izVpKEiUziF7fzv4pJ7yd20=.0139d5e6-a41b-405d-8ed9-572afda58395@github.com>

On Sat, 4 Jun 2022 01:51:20 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> One can select a testcase by ID when running a jtreg test case directly from jtreg (using the testcase.java#testID syntax). However, this has not been possible to do when launching jtreg indirectly from make.
> 
> This fix attempts to address this issue. I have not tested this thoroughly yet, I wanted to show the code to get feedback first. The idea is to *not* emulated destructive imperative assignments through the use of eval. I instead try to handle it in a functional style without reassigning variables. I have tried to make the change as small as possible.
> 
> I am not used to change the build system, so I would appreciate thorough review.
> 
> `IfAppend` and `IfPrepend` are general purpose functions. If similar functions exists elsewhere inside the code base or in make itself I should probably use those instead. If they do not exist, they might be useful elsewhere and maybe should be placed in a common make file instead of the RunTests.gmk file.

Let me ask the obvious "dumb" question ... why does this have to be so complicated? Why isn't the name of the test simply passed through to jtreg as typed?

-------------

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


From jpai at openjdk.java.net  Mon Jun  6 13:01:57 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 6 Jun 2022 13:01:57 GMT
Subject: RFR: 8287366: Improve test failure reporting in GHA
In-Reply-To: <nVEgC0DFSB9_bgMc97fwOWCNHZSQsVGEnXKZzRibGUg=.13dff674-c481-4a1c-bf31-0341b7c35527@github.com>
References: <nVEgC0DFSB9_bgMc97fwOWCNHZSQsVGEnXKZzRibGUg=.13dff674-c481-4a1c-bf31-0341b7c35527@github.com>
Message-ID: <akkiOYShelphlqtexxEAtlp1cDS_onr0XLFJJjRPjgo=.7913b2a9-e788-47e6-83c6-9dd885d012f7@github.com>

On Thu, 26 May 2022 12:04:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> With this PR, the overview of failures are presented on the "Summary" page for the action (the top-most line to the left, with the outline house icon).

@magicus, thank you. This is really useful. I didn't even know that this "Summary" page existed. I now checked this page on one of my PRs (which includes this commit) and it does indeed make it much simpler to analyze these failures.

-------------

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


From mgronlun at openjdk.java.net  Mon Jun  6 13:12:05 2022
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 6 Jun 2022 13:12:05 GMT
Subject: RFR: 8287811: JFR: jfr configure error message should not print
 stack trace
In-Reply-To: <B5G_hgzQPag0OFJgQH0O3zr_FhZVXA6yj8N-HP1WddA=.32af024b-b917-4a5d-856c-46af1b2a43d5@github.com>
References: <B5G_hgzQPag0OFJgQH0O3zr_FhZVXA6yj8N-HP1WddA=.32af024b-b917-4a5d-856c-46af1b2a43d5@github.com>
Message-ID: <XHNRFOG6VwPU3Ry-DqMmdb5SuCYeEttPdKK-cQwuDTk=.b3e32736-843d-45e0-94fc-90f8ea2dbd10@github.com>

On Fri, 3 Jun 2022 15:54:47 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of PR that removes a printStackTrace() for the jfr tool. 
> 
> Testing: jdk/jfr/tool
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

-------------

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


From iklam at openjdk.java.net  Mon Jun  6 20:35:53 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 6 Jun 2022 20:35:53 GMT
Subject: RFR: 8287828: Fix so that one can select jtreg test case by ID
 from make
In-Reply-To: <XFetdwE-qaEBR5A6V3z3izVpKEiUziF7fzv4pJ7yd20=.0139d5e6-a41b-405d-8ed9-572afda58395@github.com>
References: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
 <XFetdwE-qaEBR5A6V3z3izVpKEiUziF7fzv4pJ7yd20=.0139d5e6-a41b-405d-8ed9-572afda58395@github.com>
Message-ID: <AFeeZUyb-HgZ2JcU6X5C0MHugNp5syOl-RAyAwaZ0HI=.6a618d7a-8b78-43bc-a60b-ac26ef725199@github.com>

On Mon, 6 Jun 2022 10:48:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Let me ask the obvious "dumb" question ... why does this have to be so complicated? Why isn't the name of the test simply passed through to jtreg as typed?

Is it because `#` is treated as comment by the shell? Could it be encoded by something like `TestName.java%38testID`?

-------------

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


From tprinzing at openjdk.java.net  Mon Jun  6 20:55:05 2022
From: tprinzing at openjdk.java.net (Tim Prinzing)
Date: Mon, 6 Jun 2022 20:55:05 GMT
Subject: RFR: 8287745 jni/nullCaller/NullCallerTest.java fails with
 "exitValue = 1"
In-Reply-To: <GFESpV7wctIPePQDShvYmr_HtwdgsZZegBQ-1jYzAIQ=.088f0795-0c8c-44e9-a15c-817430933982@github.com>
References: <zIN25qcOaiLtiGNz4Vs8CEIHna7wwGSmcJ_X5k21Amo=.3e63c10d-ddf2-4dd9-92aa-96d8eab26f3e@github.com>
 <GFESpV7wctIPePQDShvYmr_HtwdgsZZegBQ-1jYzAIQ=.088f0795-0c8c-44e9-a15c-817430933982@github.com>
Message-ID: <s2__e_4yYg6d-7TDOQuY04D3puIR8Znyle_gexHWXnY=.45a3a1f4-2615-4292-bd5a-0d91daa55273@github.com>

On Mon, 6 Jun 2022 07:45:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Tim,
> 
> Sorry but I have to ask why this test was created as a C++ program instead of keeping it as a C program likes it predecessors? No need for C++ libs or special exception handling flags in that case.

The idea was to reduce duplicate code.  Changing to use objects to encapsulate the up calls got rid of a lot of repeated code and made things simpler and clearer.  Objects are created with the class, method, and signature strings and then calls can be made and the the error reporting has a context.  It was simply easier to do in c++ and there was no reason not to use it.

-------------

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


From ihse at openjdk.java.net  Mon Jun  6 21:11:26 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 6 Jun 2022 21:11:26 GMT
Subject: RFR: 8287366: Improve test failure reporting in GHA
In-Reply-To: <akkiOYShelphlqtexxEAtlp1cDS_onr0XLFJJjRPjgo=.7913b2a9-e788-47e6-83c6-9dd885d012f7@github.com>
References: <nVEgC0DFSB9_bgMc97fwOWCNHZSQsVGEnXKZzRibGUg=.13dff674-c481-4a1c-bf31-0341b7c35527@github.com>
 <akkiOYShelphlqtexxEAtlp1cDS_onr0XLFJJjRPjgo=.7913b2a9-e788-47e6-83c6-9dd885d012f7@github.com>
Message-ID: <yX-YAg04MF8g2TjJJoGaXGcJgZnLyoNo3IMhpsRNCQ0=.582907a2-f349-421d-be20-041eb54b2546@github.com>

On Mon, 6 Jun 2022 12:57:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> It is currently both tricky and tedious to figure out what went wrong when a jtreg test fails in GHA.
>> 
>> We should utilize the full potential of GitHub Action summaries and error annotations to make finding failures easier and more discoverable.
>> 
>> With this PR, the overview of failures are presented on the "Summary" page for the action (the top-most line to the left, with the outline house icon). Below the `submit.yml` dependency graph, you'll find the annotations, which will look like this:
>> 
>> 
>> Linux x86 (jdk/tier1 part 1)
>> Test run reported 34 test failure(s) and 0 error(s). See summary for details.
>> 
>> 
>> Below the annotations follow the summaries. Go have a look at the runs for this PR to see what it looks like! In short, there is a separate summary per test job. The first part lists the names of the failed tests. This will always be included. Below this (with links from the summary list) are detailed information for each failed test. This include the jtreg output, and the `hs_err` file(s), if present. The latter part has a limit from Github on 1 MB. If this limit is broken, no detailed information at all is presented (sorry 'bout that; GitHub's rules).
>> 
>> This PR is deliberately based on a commit prior to the fix for JDK-8287137 (Problemlist failing x86_32 tests after Loom integration), so you can see for yourself how the GHA runs looks in case of a "train wreck" testing situation, like on x86 after Loom. As you can see, most of the output part of the summaries got larger than the 1 MB limit, which means they were not shown. Only the summary for `Linux x86 (hs/tier1 runtime)` displays as intended. OTOH, this shows that the system has a "graceful degradation" mode for even large amount of failures like this. And, since I don't see a Loom v2.0 coming anytime soon, I believe this amount of failed tests are unlikely to be a realistic scenario.
>> 
>> Finally: the duplication in submit.yml is really, really annoying. :-( I have copied the same code block to three places. The fourth place, for Windows, do not get any support at this time. Concurrently with this change, I have started a separate branch where I split up submit.yml into reusable parts, using "callable workflows" and "custom actions". As part of this effort, I will also change the windows jobs to use cygwin bash instead of PowerShell. Until then, I could not be bothered to even think about implementing this functionality in PS. When that change is integrated, Windows will get this functionality for free, too.
>
>> With this PR, the overview of failures are presented on the "Summary" page for the action (the top-most line to the left, with the outline house icon).
> 
> @magicus, thank you. This is really useful. I didn't even know that this "Summary" page existed. I now checked this page on one of my PRs (which includes this commit) and it does indeed make it much simpler to analyze these failures.

@jaikiran Thanks for the kind words. I think I should perhaps do some tweaking to the Skara bots that link to the GHA runs, so it easier to go to the summary page.

-------------

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


From chagedorn at openjdk.java.net  Tue Jun  7 07:52:59 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 7 Jun 2022 07:52:59 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v11]
In-Reply-To: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
Message-ID: <n1ZXoTCX1cIq8psTxCOs7ci7MqisUQGrQPZhbAs0F_4=.1a2ba165-2251-449d-83f4-0c7bf08bde8d@github.com>

> When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method:
> 
> Stack: [0x00007f6e01739000,0x00007f6e0183a000],  sp=0x00007f6e01838110,  free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64
> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec
> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899
> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df
> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69
> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d
> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167
> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180
> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f
> 
> This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method.
> 
> This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)):
> 
> Stack: [0x00007f34fca18000,0x00007f34fcb19000],  sp=0x00007f34fcb17110,  free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64  (c1_Compilation.cpp:607)
> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec  (c1_Compiler.cpp:250)
> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899  (compileBroker.cpp:2291)
> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df  (compileBroker.cpp:1966)
> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69  (compilerThread.cpp:59)
> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d  (thread.cpp:1297)
> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167  (thread.cpp:1280)
> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180  (thread.cpp:358)
> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f  (os_linux.cpp:705)
> 
> For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. 
> 
> The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf
> I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. 
> 
> The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability.
> 
> Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. 
> 
> **Testing:**
> Apart from manual testing, I've added two kinds of tests:
> - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers.
> - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename.
> 
> On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation.
> 
> To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional  `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number.
> 
> I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user).
> 
> Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`!
>  
> Thanks,
> Christian

Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits:

 - Merge branch 'master' into JDK-8242181
 - Fix TestDwarf for older GCC versions
 - Change logging from UL to tty based with new TraceDwarfLevel develop flag
 - Add support to parse the .debug_line section in DWARF 2 as emitted by GCC 8, add some comments
 - Merge branch 'master' into JDK-8242181
 - Merge branch 'master' into JDK-8242181
 - Merge branch 'master' into JDK-8242181
 - Fix build, add GCC flag gdwarf-4 to exclude DWARF 5, add assertions
 - Apply remaining review comments from Thomas Stuefe
 - Change load_dwarf_file with DwarfFilePath and DebugInfo
 - ... and 56 more: https://git.openjdk.java.net/jdk/compare/42261d75...dbb687ef

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7126/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7126&range=10
  Stats: 2784 lines in 18 files changed: 2687 ins; 41 del; 56 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7126.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7126/head:pull/7126

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


From duke at openjdk.java.net  Tue Jun  7 07:52:59 2022
From: duke at openjdk.java.net (openjdk-notifier[bot])
Date: Tue, 7 Jun 2022 07:52:59 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v9]
In-Reply-To: <REqNCKORi0CJSnixJ1fTYafdhKDziOItAIXe2u52Z2w=.7c455c20-f6c7-44e5-ae91-2f94d040249a@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
 <qzR7-THzprQvPm2icCX-LHOb68Y7M_r7HOMaDCuTWFo=.f452c2fd-9787-48ee-9823-4a10dbc66257@github.com>
 <yMt7s6pHlciJmkO9lVt6p2KCRLiU_4tP2MBwtGcBDUc=.fe56c895-a352-4318-a6e4-3f32a4da7ae6@github.com>
 <UUR3Xr8cHQMT1iC6sgEy5vOYj0Np7I_2_-yKC2_eNaQ=.e79645d9-d7e3-4e00-aca1-bc0beccbbbab@github.com>
 <REqNCKORi0CJSnixJ1fTYafdhKDziOItAIXe2u52Z2w=.7c455c20-f6c7-44e5-ae91-2f94d040249a@github.com>
Message-ID: <bvmH6vLxldXnXRSrxC2bS6XyX3zio9Cz4JK8fIMFBdQ=.62e319bc-4de5-4acc-9afb-e4e0deab0c1e@github.com>

On Thu, 2 Jun 2022 11:29:58 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>>> Thanks Thomas for doing the testing!
>> 
>> Hi Christian,
>> 
>> I can see no problems on ppcle attributable to your test. However, I may overlook something since tests are still failing all over the place because of loom.
>> 
>> I see test errors in TestDwarf on ppcle and x64, however. On x64:
>> 
>> 
>> ----------System.out:(52/5198)----------
>> Command line: [/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/bin/java -cp /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/classes/runtime/ErrorHandling/TestDwarf.d:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/grmpf/testdata/jtreg/jtreg_test_19/test/hotspot/jtreg/runtime/ErrorHandling:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/classes:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/grmpf/testdata/jtreg/jtreg_test_19/test/hotspot/jtreg:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/classes/test/lib:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/grmpf/testdata/jtreg/jtreg_test_19/test/lib:/net/sapmnt.sapjvm_work/openjdk/tools/jtreg-6+2/lib/javatest.jar:/net/sapmnt.sapjvm_work/openjdk/tools/jtreg-6+2/lib/jtreg.jar -Xmx768m -Djava.awt.headless=true -Djava.util.prefs.userRoot=/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_ho
 tspot_tier1_work/tmp -Djava.io.tmpdir=/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/tmp -Dtest.getfreeport.max.tries=40 -ea -esa -Xlog:dwarf=info -XX:-CreateCoredumpOnCrash -Xcomp -XX:CICrashAt=1 --version ]
>> [2022-05-24T18:37:00.974121691Z] Gathering output for process 44490
>> [2022-05-24T18:37:02.872100892Z] Waiting for completion for process 44490
>> [2022-05-24T18:37:02.872338192Z] Waiting for completion finished for process 44490
>> Output and diagnostic info for process 44490 was saved into 'pid-44490-output.log'
>> [2022-05-24T18:37:02.889455876Z] Waiting for completion for process 44490
>> [2022-05-24T18:37:02.889604189Z] Waiting for completion finished for process 44490
>> # To suppress the following error report, specify this argument
>> # after -XX: or in .hotspotrc:  SuppressErrorAt=/c1_Compilation.cpp:616
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (/sapmnt/sapjvm_work/openjdk/nb/linuxx86_64/jdk-dev/src/hotspot/share/c1/c1_Compilation.cpp:616), pid=44490, tid=44505
>> #  assert(CICrashAt < 0 || (uintx)_env->compile_id() != (uintx)CICrashAt) failed: just as planned
>> #
>> # JRE version: OpenJDK Runtime Environment (19.0) (fastdebug build 19-internal-adhoc.openjdk.jdk-dev)
>> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 19-internal-adhoc.openjdk.jdk-dev, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
>> # Problematic frame:
>> # V  [libjvm.so+0x73ca34]  Compilation::~Compilation()+0x84
>> #
>> # CreateCoredumpOnCrash turned off, no core file dumped
>> #
>> # An error report file with more information is saved as:
>> # /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/scratch/hs_err_pid44490.log
>> [1.835s][info][dwarf] Open DWARF file: /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.debuginfo
>> [1.842s][info][dwarf] Failed to parse the line number program header correctly.
>> [1.842s][info][dwarf] Failed to process the line number program correctly.
>> [1.842s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x0074176a
>> [1.843s][info][dwarf] Failed to parse the line number program header correctly.
>> [1.843s][info][dwarf] Failed to process the line number program correctly.
>> [1.843s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x00a05011
>> [1.845s][info][dwarf] Failed to parse the line number program header correctly.
>> [1.845s][info][dwarf] Failed to process the line number program correctly.
>> [1.845s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x00a05b78
>> [1.849s][info][dwarf] Failed to parse the line number program header correctly.
>> [1.849s][info][dwarf] Failed to process the line number program correctly.
>> [1.849s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x018d49d3
>> [1.852s][info][dwarf] Failed to parse the line number program header correctly.
>> [1.852s][info][dwarf] Failed to process the line number program correctly.
>> [1.852s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x018de546
>> [1.855s][info][dwarf] Failed to parse the line number program header correctly.
>> [1.855s][info][dwarf] Failed to process the line number program correctly.
>> [1.855s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x014d86e9
>> #
>> # Compiler replay data is saved as:
>> # /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/scratch/replay_pid44490.log
>> #
>> # If you would like to submit a bug report, please visit:
>> #   https://bugreport.java.com/bugreport/crash.jsp
>> #
>> 
>> hs_err_file: hs_err_pid44490.log
>> ----------System.err:(15/1242)----------
>> java.lang.RuntimeException: Could not find filename or line number in "V  [libjvm.so+0x74176a]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1aa": expected true, was false
>> 	at jdk.test.lib.Asserts.fail(Asserts.java:594)
>> 	at jdk.test.lib.Asserts.assertTrue(Asserts.java:486)
>> 	at TestDwarf.runAndCheck(TestDwarf.java:163)
>> 	at TestDwarf.test(TestDwarf.java:99)
>> 	at TestDwarf.main(TestDwarf.java:90)
>> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:1585)
>
> After getting some more logs from @tstuefe, it turns out that they are using GCC 8 in the testing which emits the `.debug_line` section in DWARF 2 format which we do not allow and we bail out during parsing. This lets `TestDwarf` fail. 
> 
> The `.debug_line` section is already handled differently by the parser compared to the other sections. GCC 10 emits DWARF 3 for some reason (even though it should emit DWARF 4 as for the other sections) while GCC 11 emits DWARF 4. Therefore, the parser can handle both DWARF 3 and 4 for `.debug_line`. Having a look at the DWARF 2 spec, it turns out that we can reuse the code for parsing DWARF 3. This allows us to update the version bailout of `.debug_line` to allow DWARF 2 as valid version. I've tested this change by building HotSpot with GCC 8.2 and playing around with it.
> 
> In this process, I've also changed `TestDwarf.java` to skip all its tests if there was a bailout of the parser due to an unsupported DWARF format. I've added some more error logging.
> 
> I've also decided to get rid of UL as discussed before and replaced it by `tty` logging in combination with a new `TraceDwarfLevel` develop flag (for the different log levels).

@chhagedorn Please do not rebase or force-push to an active PR as it invalidates existing review comments. All changes will be squashed into a single commit automatically when integrating. See [OpenJDK Developers? Guide](https://openjdk.java.net/guide/#working-with-pull-requests) for more information.

-------------

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


From lkorinth at openjdk.java.net  Tue Jun  7 08:13:06 2022
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Tue, 7 Jun 2022 08:13:06 GMT
Subject: RFR: 8287828: Fix so that one can select jtreg test case by ID
 from make
In-Reply-To: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
References: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
Message-ID: <p1Z5m3u33D7bOi6wQ0s0-OLJi-ie8AGIl3qjaYN9xEo=.5a392265-b6b0-47d9-abba-3db78a66c05b@github.com>

On Sat, 4 Jun 2022 01:51:20 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> One can select a testcase by ID when running a jtreg test case directly from jtreg (using the testcase.java#testID syntax). However, this has not been possible to do when launching jtreg indirectly from make.
> 
> This fix attempts to address this issue. I have not tested this thoroughly yet, I wanted to show the code to get feedback first. The idea is to *not* emulated destructive imperative assignments through the use of eval. I instead try to handle it in a functional style without reassigning variables. I have tried to make the change as small as possible.
> 
> I am not used to change the build system, so I would appreciate thorough review.
> 
> `IfAppend` and `IfPrepend` are general purpose functions. If similar functions exists elsewhere inside the code base or in make itself I should probably use those instead. If they do not exist, they might be useful elsewhere and maybe should be placed in a common make file instead of the RunTests.gmk file.

`#` is treated as a comment by make itself. And the make file is using `eval` to set variables. Thus the test case selection will be regarded as comment (and stripped).

-------------

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


From ihse at openjdk.java.net  Tue Jun  7 13:14:58 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 7 Jun 2022 13:14:58 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests
Message-ID: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>

With project Skara, the ability to run a set of sanity build and test jobs on selected platforms was added. This functionality was driven by `.github/workflows/submit.yml`. This file unfortunately lacks any real structure, and contains a lot of code duplication and redundancy. This has made it hard to add functionality, and new platforms to test, and it has made it even harder to debug issues. (This is hard enough as it is, since we have no direct access to the platforms that GHA runs on.)

Since the GHA tests are important for a large subset of the community, we need to do better. 

## GitHub Actions framework rewrite
 
This is a complete overhaul of the GHA testing framework. I started out trying to just tease the old `submit.yml` apart, trying to de-duplicate code, but I soon realized a much more thorough rework was needed.

### Design description

The principle for the new design was to avoid code duplication, and to improve readability of the code. The latter is extra important since the GHA "language" is very limited, needs a lot of quirks and workarounds, and is probably not well known by many OpenJDK developers. I've strived to find useful layers of abstraction to make the expressions as clear as possible.

Unfortunately, the Workflow/Action YAML language is quite limited. There are two ways to avoid duplication, "local composite actions" and "callable workflows". They both have several limitations:

 * "Callable workflows" can only be used in a single redirection. They are (apparently) inlined into the "calling workflow" at run time, and as such, they are present without having to check out the source code. (Which is a lengthy process.)

 * "Local composite actions" can use other actions, but you must start by checking out the repo.

To use the strength of both kinds of sub-modules, I'm using "callable workflows" from `main.yml` to call `build-<platform>.yml` and `test.yml`. It is not allowed to mix "strategies" (that is, the method of automatically creating a test matrix) when calling callable workflows, so I needed to have some amount of duplication in `main.yml` that could have been avoided otherwise.

All the callable workflows need to check out the source code anyway, so there is no real additional cost of using "local composite actions" for abstraction of these workflows. (A bit of a lucky break.) I've created "high level" actions, corresponding to something like a function call. The goal here was both to avoid duplication, and to improve readability of the workflows.

The four `build-<platform>.yml` files are very similar. But in the end of the day, only like 50% of the source code is shared, and the platform specific changes permeate the files. So I decided to keep them separately, since mixing them all into one would have made a mess, due to the lack of proper abstraction mechanisms. But that also mean that if we change platform independent code in building, we need to remember to update it in all four places.

In the strictest sense, this is a "refactoring" in that the functionality should be equal to the old `submit.yml`. The same platforms should build, with the same arguments, and the same tests should run. When I look at the code now, I see lots of potential for improvement here, by rethinking what we do run. But let's save that discussion for the next PR.

There is one major change, though. Windows is no longer running on Cygwin, but on MSYS2. This was not really triggered by the recurring build issues on Cygwin (though that certainly did help me in thinking I made the right choice), but the sheer impossibility of getting Cygwin to behave as a normal unix shell on GHA Windows hosts. I spent countless hours trying to work out limitations, by setting `SHELLOPTS=igncr`, by running `set +x posix` to turn of the POSIX compliance mode that kept turning on by itself and made bash choke on several of our scripts, by playing tricks with the `PATH`, but in the end to no avail. There were no single combination of hacks and workarounds that could get us past the entire chain from configure, to build, to testing. (The old solution user PowerShell instead to get around these limitations.) I'm happy to report that I have had absolutely zero issues with MSYS2 since I made the switch (and understood how to set the PATH properly), and I'm seriously cons
 idering switching stance to recommend using MSYS2 instead of Cygwin as the primary winenv for building the JDK.

### Example run

A good example on how a run looks like with the new GHA system is [the run for this PR](https://github.com/magicus/jdk/actions/runs/2454577164).

### New features

While the primary focus was to convert the old system to a new framework, more accommodating to development, and to wait with further enhancements for the future, I have made a few additional features already in this PR. Most of them are related to needs that arose during development of this PR.

* A build failure summary, similar to the recently added test failure summary, is added when the build step fails

* The test reporting has been extended to all platforms, including Windows

* Test reporting has been improved slightly, and gotten multiple bug fixes

* All artifacts are now available for individual download. This includes:

  * The build bundles, per platform
  * The test results, per platform and test suite
  * Build failure logs, in case of build failure

  The build bundles have a retention period of 24 h, but the rest uses GitHub's default retention period (currently 90 days). The idea is that you can use GHA to download builds for platforms you might not have access to, but after that, conserving the builds does not make sense. GitHub currently provides free, unlimited storage (within the retention period) for artifacts, so we can afford this.

* The GHA process starts up much faster, which mean that e.g. a build failure on an exotic platform will show up earlier. This will not really affect the overall run time though, since it is bounded by variables such as queuing for workers, and waiting on tests with somewhat arbitrarily run times to finish.

### Additional changes outside GHA

I also needed to make a few tweaks to the build system to play nice with the new GHA code.

* The build failure summary is now stored in build/$BUILD/make-support/failure-summary.log

* The configure summary now indicates what devkit or sysroot is used, if any

* The --with-sysroot argument is now properly normalized

### Test failures

A handful of tests, which relies on shell behavior, turned out to fail on Windows when running under MSYS2. I have filed separate bugs, and submitted PRs, to get these fixed:

* https://bugs.openjdk.org/browse/JDK-8287902

* https://bugs.openjdk.org/browse/JDK-8287895

-------------

Commit messages:
 - 8287906: Rewrite of GitHub Actions (GHA) sanity tests

Changes: https://git.openjdk.java.net/jdk/pull/9063/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9063&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287906
  Stats: 3960 lines in 23 files changed: 1862 ins; 2083 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9063.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9063/head:pull/9063

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


From lkorinth at openjdk.java.net  Tue Jun  7 13:37:00 2022
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Tue, 7 Jun 2022 13:37:00 GMT
Subject: RFR: 8287828: Fix so that one can select jtreg test case by ID
 from make [v2]
In-Reply-To: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
References: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
Message-ID: <kHFhPVMMY26EO-4UamcXexjlBryRqqhwIsaawHdPt2s=.67a26e4b-73bc-49ce-b82f-02e3bf4bf2af@github.com>

> One can select a testcase by ID when running a jtreg test case directly from jtreg (using the testcase.java#testID syntax). However, this has not been possible to do when launching jtreg indirectly from make.
> 
> This fix attempts to address this issue. I have not tested this thoroughly yet, I wanted to show the code to get feedback first. The idea is to *not* emulated destructive imperative assignments through the use of eval. I instead try to handle it in a functional style without reassigning variables. I have tried to make the change as small as possible.
> 
> I am not used to change the build system, so I would appreciate thorough review.
> 
> `IfAppend` and `IfPrepend` are general purpose functions. If similar functions exists elsewhere inside the code base or in make itself I should probably use those instead. If they do not exist, they might be useful elsewhere and maybe should be placed in a common make file instead of the RunTests.gmk file.

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  wip

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9028/files
  - new: https://git.openjdk.java.net/jdk/pull/9028/files/553ecc35..704158c8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9028&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9028&range=00-01

  Stats: 82 lines in 2 files changed: 35 ins; 31 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9028.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9028/head:pull/9028

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


From lkorinth at openjdk.java.net  Tue Jun  7 13:37:09 2022
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Tue, 7 Jun 2022 13:37:09 GMT
Subject: RFR: 8287828: Fix so that one can select jtreg test case by ID
 from make [v2]
In-Reply-To: <Erswt-axXqntJXKoWwjzyGdVw1u-ZUx-wlVxWN6p0b8=.492d4206-60d9-4858-b3ad-7358be799d73@github.com>
References: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
 <Erswt-axXqntJXKoWwjzyGdVw1u-ZUx-wlVxWN6p0b8=.492d4206-60d9-4858-b3ad-7358be799d73@github.com>
Message-ID: <VwYD91QKA4z0YZ3Vo0NNAsfuj3vYXBbXEGqJwLWnE4E=.46d6881d-5974-4b69-9615-8312036254c7@github.com>

On Mon, 6 Jun 2022 06:50:44 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   wip
>
> make/RunTests.gmk line 39:
> 
>> 37: ################################################################################
>> 38: 
>> 39: HASH:=\#
> 
> HASH is already defined in MakeBase.gmk so should be available here.

thanks, in the new version I do not even use it.

> make/RunTests.gmk line 47:
> 
>> 45: define IfPrepend
>> 46: $(if $(strip $1),$(strip $2)$(strip $1),)
>> 47: endef
> 
> These two probably fits better in make/common/Utils.gmk. 
> 
> Also please have a look at the [Code Conventions for the Build System](http://openjdk.java.net/groups/build/doc/code-conventions.html). One liner macros like this we like to format like this:
> 
> 
> IfPrepend = \
>   $(if $(strip $1),$(strip $2)$(strip $1),)

I moved them both to `make/common/Utils.gmk`.

> make/RunTests.gmk line 51:
> 
>> 49: define TestID
>> 50: $(subst .java,,$(subst .java$(HASH),,$(suffix $(notdir $1))))
>> 51: endef
> 
> This macro deserves a comment explaining what it's trying to do.

I added a description and made it a one-liner as well

> make/RunTests.gmk line 53:
> 
>> 51: endef
>> 52: 
>> 53: define HashTestID
> 
> This one too.

I removed HashTestID and added the functionality directly into TestID

> make/RunTests.gmk line 377:
> 
>> 375: # either absolute or relative to any of the TEST_BASEDIRS or test roots.
>> 376: define ParseJtregTestSelection
>> 377: $(call IfAppend, \
> 
> Please adjust indentation of the whole body here.

Fixed

> make/RunTests.gmk line 448:
> 
>> 446: # Now intelligently convert the test selection given by the user in TEST
>> 447: # into a list of fully qualified test descriptors of the tests to run.
>> 448: TESTS_TO_RUN:=$(strip $(foreach test,$(TEST),$(call ParseTestSelection,$(test))))
> 
> I think this rewrite is more elegant, but logically there is a difference as it no longer breaks early. I would like to have Magnus' opinion on this as he wrote this originally.
> 
> Style wise, please leave spaces around operators and space after comma when possible. The top level strip should handle any whitespace issues caused by this.

I changed the code to use `$(or)` instead of `$(foreach)`, and I added spaces.

-------------

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


From lkorinth at openjdk.java.net  Tue Jun  7 13:37:11 2022
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Tue, 7 Jun 2022 13:37:11 GMT
Subject: RFR: 8287828: Fix so that one can select jtreg test case by ID
 from make [v2]
In-Reply-To: <VwYD91QKA4z0YZ3Vo0NNAsfuj3vYXBbXEGqJwLWnE4E=.46d6881d-5974-4b69-9615-8312036254c7@github.com>
References: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
 <Erswt-axXqntJXKoWwjzyGdVw1u-ZUx-wlVxWN6p0b8=.492d4206-60d9-4858-b3ad-7358be799d73@github.com>
 <VwYD91QKA4z0YZ3Vo0NNAsfuj3vYXBbXEGqJwLWnE4E=.46d6881d-5974-4b69-9615-8312036254c7@github.com>
Message-ID: <gQD2ZE4JvxYpxeulN2ss8gs1fssaweEATZUBpWroqek=.62a16ae8-0983-4c19-a540-8661f97fcdaa@github.com>

On Tue, 7 Jun 2022 13:26:52 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> make/RunTests.gmk line 47:
>> 
>>> 45: define IfPrepend
>>> 46: $(if $(strip $1),$(strip $2)$(strip $1),)
>>> 47: endef
>> 
>> These two probably fits better in make/common/Utils.gmk. 
>> 
>> Also please have a look at the [Code Conventions for the Build System](http://openjdk.java.net/groups/build/doc/code-conventions.html). One liner macros like this we like to format like this:
>> 
>> 
>> IfPrepend = \
>>   $(if $(strip $1),$(strip $2)$(strip $1),)
>
> I moved them both to `make/common/Utils.gmk`.

(and made them one-liners, but with indentation four to match the code around)

-------------

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


From dholmes at openjdk.java.net  Tue Jun  7 13:39:01 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 7 Jun 2022 13:39:01 GMT
Subject: RFR: 8287745 jni/nullCaller/NullCallerTest.java fails with
 "exitValue = 1"
In-Reply-To: <s2__e_4yYg6d-7TDOQuY04D3puIR8Znyle_gexHWXnY=.45a3a1f4-2615-4292-bd5a-0d91daa55273@github.com>
References: <zIN25qcOaiLtiGNz4Vs8CEIHna7wwGSmcJ_X5k21Amo=.3e63c10d-ddf2-4dd9-92aa-96d8eab26f3e@github.com>
 <GFESpV7wctIPePQDShvYmr_HtwdgsZZegBQ-1jYzAIQ=.088f0795-0c8c-44e9-a15c-817430933982@github.com>
 <s2__e_4yYg6d-7TDOQuY04D3puIR8Znyle_gexHWXnY=.45a3a1f4-2615-4292-bd5a-0d91daa55273@github.com>
Message-ID: <dTHSGcfQlVS7EdBfpWjvHMb4E3POs3o-8FGpDiyDwj8=.a67f2007-72fe-4052-807f-c9f1542cce66@github.com>

On Mon, 6 Jun 2022 15:56:47 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> The idea was to reduce duplicate code. Changing to use objects to encapsulate the up calls got rid of a lot of repeated code and made things simpler and clearer. Objects are created with the class, method, and signature strings and then calls can be made and the the error reporting has a context. It was simply easier to do in c++ and there was no reason not to use it.

Fair enough. At least we will now have a good example of what is needed to build a C++ test like this.

-------------

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


From lkorinth at openjdk.java.net  Tue Jun  7 13:45:47 2022
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Tue, 7 Jun 2022 13:45:47 GMT
Subject: RFR: 8287828: Fix so that one can select jtreg test case by ID
 from make [v3]
In-Reply-To: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
References: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
Message-ID: <Z62bmIflBGulrthBPajbGtNeL2WJyjilBLm53d2qHA8=.13176b2d-0986-4524-932c-21d5c5a8a6a0@github.com>

> One can select a testcase by ID when running a jtreg test case directly from jtreg (using the testcase.java#testID syntax). However, this has not been possible to do when launching jtreg indirectly from make.
> 
> This fix attempts to address this issue. I have not tested this thoroughly yet, I wanted to show the code to get feedback first. The idea is to *not* emulated destructive imperative assignments through the use of eval. I instead try to handle it in a functional style without reassigning variables. I have tried to make the change as small as possible.
> 
> I am not used to change the build system, so I would appreciate thorough review.
> 
> `IfAppend` and `IfPrepend` are general purpose functions. If similar functions exists elsewhere inside the code base or in make itself I should probably use those instead. If they do not exist, they might be useful elsewhere and maybe should be placed in a common make file instead of the RunTests.gmk file.

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  wip

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9028/files
  - new: https://git.openjdk.java.net/jdk/pull/9028/files/704158c8..26a62eb0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9028&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9028&range=01-02

  Stats: 14 lines in 2 files changed: 0 ins; 4 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9028.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9028/head:pull/9028

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


From lkorinth at openjdk.java.net  Tue Jun  7 13:50:12 2022
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Tue, 7 Jun 2022 13:50:12 GMT
Subject: RFR: 8287828: Fix so that one can select jtreg test case by ID
 from make [v3]
In-Reply-To: <Z62bmIflBGulrthBPajbGtNeL2WJyjilBLm53d2qHA8=.13176b2d-0986-4524-932c-21d5c5a8a6a0@github.com>
References: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
 <Z62bmIflBGulrthBPajbGtNeL2WJyjilBLm53d2qHA8=.13176b2d-0986-4524-932c-21d5c5a8a6a0@github.com>
Message-ID: <cOXqs6SsYiR6tU-rswrYgfGGrOA1iqJx91J25xG6DvQ=.472b3f3e-6aeb-4c53-8076-2e3c88b96683@github.com>

On Tue, 7 Jun 2022 13:45:47 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> One can select a testcase by ID when running a jtreg test case directly from jtreg (using the testcase.java#testID syntax). However, this has not been possible to do when launching jtreg indirectly from make.
>> 
>> This fix attempts to address this issue. I have not tested this thoroughly yet, I wanted to show the code to get feedback first. The idea is to *not* emulated destructive imperative assignments through the use of eval. I instead try to handle it in a functional style without reassigning variables. I have tried to make the change as small as possible.
>> 
>> I am not used to change the build system, so I would appreciate thorough review.
>> 
>> `IfAppend` and `IfPrepend` are general purpose functions. If similar functions exists elsewhere inside the code base or in make itself I should probably use those instead. If they do not exist, they might be useful elsewhere and maybe should be placed in a common make file instead of the RunTests.gmk file.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   wip

@magicus could you also take a look please?

-------------

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


From lkorinth at openjdk.java.net  Tue Jun  7 13:50:14 2022
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Tue, 7 Jun 2022 13:50:14 GMT
Subject: RFR: 8287828: Fix so that one can select jtreg test case by ID
 from make [v3]
In-Reply-To: <Erswt-axXqntJXKoWwjzyGdVw1u-ZUx-wlVxWN6p0b8=.492d4206-60d9-4858-b3ad-7358be799d73@github.com>
References: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
 <Erswt-axXqntJXKoWwjzyGdVw1u-ZUx-wlVxWN6p0b8=.492d4206-60d9-4858-b3ad-7358be799d73@github.com>
Message-ID: <9BfNpp8eYHQJhqQxCzvmzVbKdYMJHSSnqVcY_QVPBEY=.ddc7e21e-94ae-48cf-b67d-434126cb645e@github.com>

On Mon, 6 Jun 2022 07:55:09 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   wip
>
> make/RunTests.gmk line 444:
> 
>> 442: $(strip $(foreach parser,ParseCustomTestSelection ParseGtestTestSelection ParseMicroTestSelection ParseJtregTestSelection ParseSpecialTestSelection \
>> 443:  ,$(call $(parser),$1)))
>> 444: endef
> 
> As this is logically a one-liner macro, please format according to guidelines. Also try to keep lines shortish. Something like this:
> 
> Suggestion:
> 
> ParseTestSelection = \
>   $(strip $(foreach parser, ParseCustomTestSelection ParseGtestTestSelection ParseMicroTestSelection \ 
>       ParseJtregTestSelection ParseSpecialTestSelection, \
>     $(call $(parser), $1) \
>   ))

I made it a one-liner, and I refactored the code to use `or`

-------------

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


From erikj at openjdk.java.net  Tue Jun  7 14:09:58 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 7 Jun 2022 14:09:58 GMT
Subject: RFR: 8287828: Fix so that one can select jtreg test case by ID
 from make [v3]
In-Reply-To: <Z62bmIflBGulrthBPajbGtNeL2WJyjilBLm53d2qHA8=.13176b2d-0986-4524-932c-21d5c5a8a6a0@github.com>
References: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
 <Z62bmIflBGulrthBPajbGtNeL2WJyjilBLm53d2qHA8=.13176b2d-0986-4524-932c-21d5c5a8a6a0@github.com>
Message-ID: <X_teMCADtViN4AwXhLpOKNEt7YAp8k1bG1bKdWDGDRk=.eba842db-9d1e-409d-9657-47ade5e75430@github.com>

On Tue, 7 Jun 2022 13:45:47 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> One can select a testcase by ID when running a jtreg test case directly from jtreg (using the testcase.java#testID syntax). However, this has not been possible to do when launching jtreg indirectly from make.
>> 
>> This fix attempts to address this issue. I have not tested this thoroughly yet, I wanted to show the code to get feedback first. The idea is to *not* emulated destructive imperative assignments through the use of eval. I instead try to handle it in a functional style without reassigning variables. I have tried to make the change as small as possible.
>> 
>> I am not used to change the build system, so I would appreciate thorough review.
>> 
>> `IfAppend` and `IfPrepend` are general purpose functions. If similar functions exists elsewhere inside the code base or in make itself I should probably use those instead. If they do not exist, they might be useful elsewhere and maybe should be placed in a common make file instead of the RunTests.gmk file.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   wip

I think this looks good, but Magnus should still take a look.

-------------

Marked as reviewed by erikj (Reviewer).

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


From mchung at openjdk.java.net  Tue Jun  7 16:02:29 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 7 Jun 2022 16:02:29 GMT
Subject: RFR: 8287745 jni/nullCaller/NullCallerTest.java fails with
 "exitValue = 1"
In-Reply-To: <zIN25qcOaiLtiGNz4Vs8CEIHna7wwGSmcJ_X5k21Amo=.3e63c10d-ddf2-4dd9-92aa-96d8eab26f3e@github.com>
References: <zIN25qcOaiLtiGNz4Vs8CEIHna7wwGSmcJ_X5k21Amo=.3e63c10d-ddf2-4dd9-92aa-96d8eab26f3e@github.com>
Message-ID: <KEuVJ3Q0Rit61aFjZM_VOlduJ95z_QXS8O834zeHxoA=.21ed2aea-2226-419f-8e33-296a376c92f0@github.com>

On Fri, 3 Jun 2022 07:56:38 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> Fixed JtregNativeJdk.gmk to include c++ libs for NullCallerTest

There are a few C++ tests under `test/jdk/java/foreign` as well.

-------------

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


From tprinzing at openjdk.java.net  Tue Jun  7 16:06:06 2022
From: tprinzing at openjdk.java.net (Tim Prinzing)
Date: Tue, 7 Jun 2022 16:06:06 GMT
Subject: Integrated: 8287745 jni/nullCaller/NullCallerTest.java fails with
 "exitValue = 1"
In-Reply-To: <zIN25qcOaiLtiGNz4Vs8CEIHna7wwGSmcJ_X5k21Amo=.3e63c10d-ddf2-4dd9-92aa-96d8eab26f3e@github.com>
References: <zIN25qcOaiLtiGNz4Vs8CEIHna7wwGSmcJ_X5k21Amo=.3e63c10d-ddf2-4dd9-92aa-96d8eab26f3e@github.com>
Message-ID: <EYmCAIKuCDT-Y-unQEWR7wlhMMS7qNoGldiFC-nk2Gs=.ecbccaa2-7a0e-452d-8f44-f7cbe4689317@github.com>

On Fri, 3 Jun 2022 07:56:38 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> Fixed JtregNativeJdk.gmk to include c++ libs for NullCallerTest

This pull request has now been integrated.

Changeset: 96641c0c
Author:    Tim Prinzing <tprinzing at openjdk.org>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/96641c0c42ff79d809db1314407d451eb7d494b4
Stats:     4 lines in 2 files changed: 1 ins; 1 del; 2 mod

8287745: jni/nullCaller/NullCallerTest.java fails with "exitValue = 1"

Reviewed-by: erikj, mchung

-------------

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


From egahlin at openjdk.java.net  Tue Jun  7 16:46:08 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Tue, 7 Jun 2022 16:46:08 GMT
Subject: Integrated: 8287811: JFR: jfr configure error message should not print
 stack trace
In-Reply-To: <B5G_hgzQPag0OFJgQH0O3zr_FhZVXA6yj8N-HP1WddA=.32af024b-b917-4a5d-856c-46af1b2a43d5@github.com>
References: <B5G_hgzQPag0OFJgQH0O3zr_FhZVXA6yj8N-HP1WddA=.32af024b-b917-4a5d-856c-46af1b2a43d5@github.com>
Message-ID: <HMQJwuCz6RJux4hdA9SEpH9aiwzBij2oSArN7VXUvpY=.59527c27-790d-4246-a0b2-068733b8a741@github.com>

On Fri, 3 Jun 2022 15:54:47 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of PR that removes a printStackTrace() for the jfr tool. 
> 
> Testing: jdk/jfr/tool
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 41d5809c
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/41d5809caff0a219c2153fe88d0c61c4b5eba62c
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8287811: JFR: jfr configure error message should not print stack trace

Reviewed-by: mgronlun

-------------

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


From lkorinth at openjdk.java.net  Tue Jun  7 17:18:17 2022
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Tue, 7 Jun 2022 17:18:17 GMT
Subject: RFR: 8287828: Fix so that one can select jtreg test case by ID
 from make [v3]
In-Reply-To: <Z62bmIflBGulrthBPajbGtNeL2WJyjilBLm53d2qHA8=.13176b2d-0986-4524-932c-21d5c5a8a6a0@github.com>
References: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
 <Z62bmIflBGulrthBPajbGtNeL2WJyjilBLm53d2qHA8=.13176b2d-0986-4524-932c-21d5c5a8a6a0@github.com>
Message-ID: <lpgAOiExnMKlpFsApv3eyt-gWDw-MN2lZh1GmCEs1O8=.ecf0e36e-0230-4dad-a628-098b5e2a7294@github.com>

On Tue, 7 Jun 2022 13:45:47 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> One can select a testcase by ID when running a jtreg test case directly from jtreg (using the testcase.java#testID syntax). However, this has not been possible to do when launching jtreg indirectly from make.
>> 
>> This fix attempts to address this issue. I have not tested this thoroughly yet, I wanted to show the code to get feedback first. The idea is to *not* emulated destructive imperative assignments through the use of eval. I instead try to handle it in a functional style without reassigning variables. I have tried to make the change as small as possible.
>> 
>> I am not used to change the build system, so I would appreciate thorough review.
>> 
>> `IfAppend` and `IfPrepend` are general purpose functions. If similar functions exists elsewhere inside the code base or in make itself I should probably use those instead. If they do not exist, they might be useful elsewhere and maybe should be placed in a common make file instead of the RunTests.gmk file.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   wip

I will add a comment:

# The test selector starting with a hash (#testid) will be stripped by all evals
# and will be reinserted in the last line by calling TestID (if it is present).


Arguably I should also remove the hash part explicitly, would you like that? I think it might be more clear what the code does, but on the other hand it would maybe signal that it is a parsing strategy which it is not.

-------------

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


From lkorinth at openjdk.java.net  Tue Jun  7 17:39:14 2022
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Tue, 7 Jun 2022 17:39:14 GMT
Subject: RFR: 8287828: Fix so that one can select jtreg test case by ID
 from make [v4]
In-Reply-To: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
References: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
Message-ID: <O4j7CQMWYyMc_hXq8aLv_ixNGouH5xxvKshbWk8e9dw=.be868e18-99ce-40c2-a911-a2192d16c82a@github.com>

> One can select a testcase by ID when running a jtreg test case directly from jtreg (using the testcase.java#testID syntax). However, this has not been possible to do when launching jtreg indirectly from make.
> 
> This fix attempts to address this issue. I have not tested this thoroughly yet, I wanted to show the code to get feedback first. The idea is to *not* emulated destructive imperative assignments through the use of eval. I instead try to handle it in a functional style without reassigning variables. I have tried to make the change as small as possible.
> 
> I am not used to change the build system, so I would appreciate thorough review.
> 
> `IfAppend` and `IfPrepend` are general purpose functions. If similar functions exists elsewhere inside the code base or in make itself I should probably use those instead. If they do not exist, they might be useful elsewhere and maybe should be placed in a common make file instead of the RunTests.gmk file.

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  wip

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9028/files
  - new: https://git.openjdk.java.net/jdk/pull/9028/files/26a62eb0..ac9631e2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9028&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9028&range=02-03

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

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


From lkorinth at openjdk.java.net  Tue Jun  7 17:42:33 2022
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Tue, 7 Jun 2022 17:42:33 GMT
Subject: RFR: 8287828: Fix so that one can select jtreg test case by ID
 from make
In-Reply-To: <AFeeZUyb-HgZ2JcU6X5C0MHugNp5syOl-RAyAwaZ0HI=.6a618d7a-8b78-43bc-a60b-ac26ef725199@github.com>
References: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
 <XFetdwE-qaEBR5A6V3z3izVpKEiUziF7fzv4pJ7yd20=.0139d5e6-a41b-405d-8ed9-572afda58395@github.com>
 <AFeeZUyb-HgZ2JcU6X5C0MHugNp5syOl-RAyAwaZ0HI=.6a618d7a-8b78-43bc-a60b-ac26ef725199@github.com>
Message-ID: <SEjtamhlAUQmB2ZEfCMqSlgHxN72BI5RP0JBBj9eDAw=.ec03859b-610e-4e5c-b56f-8f1b8b6d6ccf@github.com>

On Mon, 6 Jun 2022 16:20:18 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Let me ask the obvious "dumb" question ... why does this have to be so complicated? Why isn't the name of the test simply passed through to jtreg as typed?
>
>> Let me ask the obvious "dumb" question ... why does this have to be so complicated? Why isn't the name of the test simply passed through to jtreg as typed?
> 
> Is it because `#` is treated as comment by the shell? Could it be encoded by something like `TestName.java%38testID`?

After input from @iklam, I made this new version that gives a much cleaner diff. It calls the old code unmodified from a wrapper function. I think this is better.

-------------

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


From iklam at openjdk.java.net  Tue Jun  7 17:50:34 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 7 Jun 2022 17:50:34 GMT
Subject: RFR: 8287828: Fix so that one can select jtreg test case by ID
 from make [v4]
In-Reply-To: <O4j7CQMWYyMc_hXq8aLv_ixNGouH5xxvKshbWk8e9dw=.be868e18-99ce-40c2-a911-a2192d16c82a@github.com>
References: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
 <O4j7CQMWYyMc_hXq8aLv_ixNGouH5xxvKshbWk8e9dw=.be868e18-99ce-40c2-a911-a2192d16c82a@github.com>
Message-ID: <AENzAbpSHGaRipyK9Tzc8L6ukuYRoohILvvzzbvKafc=.c0e5451b-0dcd-4846-a3c3-86fb8a212054@github.com>

On Tue, 7 Jun 2022 17:39:14 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> One can select a testcase by ID when running a jtreg test case directly from jtreg (using the testcase.java#testID syntax). However, this has not been possible to do when launching jtreg indirectly from make.
>> 
>> This fix attempts to address this issue. I have not tested this thoroughly yet, I wanted to show the code to get feedback first. The idea is to *not* emulated destructive imperative assignments through the use of eval. I instead try to handle it in a functional style without reassigning variables. I have tried to make the change as small as possible.
>> 
>> I am not used to change the build system, so I would appreciate thorough review.
>> 
>> `IfAppend` and `IfPrepend` are general purpose functions. If similar functions exists elsewhere inside the code base or in make itself I should probably use those instead. If they do not exist, they might be useful elsewhere and maybe should be placed in a common make file instead of the RunTests.gmk file.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   wip

Marked as reviewed by iklam (Reviewer).

make/RunTests.gmk line 357:

> 355:     $(subst .java,,$(subst .java,,$(suffix $(notdir $1))))
> 356: 
> 357: # The test selector starting with a hash (#testid) will be stripped by all

Small nit - I think "selection" and "test selector" in the comments should be changed to "test id" so you don't call the same thing with 3 different names. But otherwise the change looks good to me.

-------------

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


From lkorinth at openjdk.java.net  Tue Jun  7 18:15:30 2022
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Tue, 7 Jun 2022 18:15:30 GMT
Subject: RFR: 8287828: Fix so that one can select jtreg test case by ID
 from make [v5]
In-Reply-To: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
References: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
Message-ID: <cAyhVq2MlJqN11tPfzcBtbDv4flLqA3z_klrkr1KeuU=.85fc760b-a4ea-4faf-b679-d466eb40a588@github.com>

> One can select a testcase by ID when running a jtreg test case directly from jtreg (using the testcase.java#testID syntax). However, this has not been possible to do when launching jtreg indirectly from make.
> 
> This fix attempts to address this issue. I have not tested this thoroughly yet, I wanted to show the code to get feedback first. The idea is to *not* emulated destructive imperative assignments through the use of eval. I instead try to handle it in a functional style without reassigning variables. I have tried to make the change as small as possible.
> 
> I am not used to change the build system, so I would appreciate thorough review.
> 
> `IfAppend` and `IfPrepend` are general purpose functions. If similar functions exists elsewhere inside the code base or in make itself I should probably use those instead. If they do not exist, they might be useful elsewhere and maybe should be placed in a common make file instead of the RunTests.gmk file.

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  use test id in comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9028/files
  - new: https://git.openjdk.java.net/jdk/pull/9028/files/ac9631e2..a6d51c2a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9028&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9028&range=03-04

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

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


From lkorinth at openjdk.java.net  Tue Jun  7 18:15:50 2022
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Tue, 7 Jun 2022 18:15:50 GMT
Subject: RFR: 8287828: Fix so that one can select jtreg test case by ID
 from make [v4]
In-Reply-To: <AENzAbpSHGaRipyK9Tzc8L6ukuYRoohILvvzzbvKafc=.c0e5451b-0dcd-4846-a3c3-86fb8a212054@github.com>
References: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
 <O4j7CQMWYyMc_hXq8aLv_ixNGouH5xxvKshbWk8e9dw=.be868e18-99ce-40c2-a911-a2192d16c82a@github.com>
 <AENzAbpSHGaRipyK9Tzc8L6ukuYRoohILvvzzbvKafc=.c0e5451b-0dcd-4846-a3c3-86fb8a212054@github.com>
Message-ID: <7TBFXLlDTkl0m-qZr-P4GWSPgB8tOKnidI3iOVSb05c=.fe044496-ce3d-4f99-add9-af92a44a682c@github.com>

On Tue, 7 Jun 2022 17:48:30 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   wip
>
> make/RunTests.gmk line 357:
> 
>> 355:     $(subst .java,,$(subst .java,,$(suffix $(notdir $1))))
>> 356: 
>> 357: # The test selector starting with a hash (#testid) will be stripped by all
> 
> Small nit - I think "selection" and "test selector" in the comments should be changed to "test id" so you don't call the same thing with 3 different names. But otherwise the change looks good to me.

I agree.

-------------

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


From duke at openjdk.java.net  Tue Jun  7 20:07:19 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Tue, 7 Jun 2022 20:07:19 GMT
Subject: RFR: 8287894: Use fixed timestamp as an alternative of __DATE__ macro
 in jdk.jdi to make Windows build reproducible
Message-ID: <EVQZHJ8cwIIMWtEhayX3XorZu6VhwFstYf5WETCJOGk=.37d88f49-e17b-4223-9bf4-f77427087baf@github.com>

Hi!

Here is a fix to jdk.jdi that fixes reproducible build for Windows. The idea of the fix is to re-use value of --with-hotspot-build-time option to generate deterministic timestamp exactly like it's done to hotspot component.

Verification (Windows-10/MSVS-2019): ```bash ./configure --with-boot-jdk=c:/work/boot-jdk/jdk-18 --with-debug-level=fastdebug --with-hotspot-build-time="6/7/2022 2:35pm" --with-extra-cflags="/experimental:deterministic" --with-extra-cxxflags="/experimental:deterministic"```

Regression (Windows-10/MSVS-2019): ```bash ./configure --with-boot-jdk=c:/work/boot-jdk/jdk-18 --with-debug-level=fastdebug```

-------------

Commit messages:
 - 8287894: use fixed timestamp instead of __DATE__ macro to fix reproducible Windows build

Changes: https://git.openjdk.java.net/jdk/pull/9070/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9070&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287894
  Stats: 21 lines in 3 files changed: 14 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9070.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9070/head:pull/9070

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


From jjg at openjdk.java.net  Tue Jun  7 20:09:46 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 7 Jun 2022 20:09:46 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests
In-Reply-To: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
Message-ID: <--Ssk8hhsAYcsAaBFb0ZnrmjtvD5Ju4conxM-iFyZ1g=.aca6fd4e-0164-4396-90ed-84357fb85993@github.com>

On Tue, 7 Jun 2022 13:05:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> With project Skara, the ability to run a set of sanity build and test jobs on selected platforms was added. This functionality was driven by `.github/workflows/submit.yml`. This file unfortunately lacks any real structure, and contains a lot of code duplication and redundancy. This has made it hard to add functionality, and new platforms to test, and it has made it even harder to debug issues. (This is hard enough as it is, since we have no direct access to the platforms that GHA runs on.)
> 
> Since the GHA tests are important for a large subset of the community, we need to do better. 
> 
> ## GitHub Actions framework rewrite
>  
> This is a complete overhaul of the GHA testing framework. I started out trying to just tease the old `submit.yml` apart, trying to de-duplicate code, but I soon realized a much more thorough rework was needed.
> 
> ### Design description
> 
> The principle for the new design was to avoid code duplication, and to improve readability of the code. The latter is extra important since the GHA "language" is very limited, needs a lot of quirks and workarounds, and is probably not well known by many OpenJDK developers. I've strived to find useful layers of abstraction to make the expressions as clear as possible.
> 
> Unfortunately, the Workflow/Action YAML language is quite limited. There are two ways to avoid duplication, "local composite actions" and "callable workflows". They both have several limitations:
> 
>  * "Callable workflows" can only be used in a single redirection. They are (apparently) inlined into the "calling workflow" at run time, and as such, they are present without having to check out the source code. (Which is a lengthy process.)
> 
>  * "Local composite actions" can use other actions, but you must start by checking out the repo.
> 
> To use the strength of both kinds of sub-modules, I'm using "callable workflows" from `main.yml` to call `build-<platform>.yml` and `test.yml`. It is not allowed to mix "strategies" (that is, the method of automatically creating a test matrix) when calling callable workflows, so I needed to have some amount of duplication in `main.yml` that could have been avoided otherwise.
> 
> All the callable workflows need to check out the source code anyway, so there is no real additional cost of using "local composite actions" for abstraction of these workflows. (A bit of a lucky break.) I've created "high level" actions, corresponding to something like a function call. The goal here was both to avoid duplication, and to improve readability of the workflows.
> 
> The four `build-<platform>.yml` files are very similar. But in the end of the day, only like 50% of the source code is shared, and the platform specific changes permeate the files. So I decided to keep them separately, since mixing them all into one would have made a mess, due to the lack of proper abstraction mechanisms. But that also mean that if we change platform independent code in building, we need to remember to update it in all four places.
> 
> In the strictest sense, this is a "refactoring" in that the functionality should be equal to the old `submit.yml`. The same platforms should build, with the same arguments, and the same tests should run. When I look at the code now, I see lots of potential for improvement here, by rethinking what we do run. But let's save that discussion for the next PR.
> 
> There is one major change, though. Windows is no longer running on Cygwin, but on MSYS2. This was not really triggered by the recurring build issues on Cygwin (though that certainly did help me in thinking I made the right choice), but the sheer impossibility of getting Cygwin to behave as a normal unix shell on GHA Windows hosts. I spent countless hours trying to work out limitations, by setting `SHELLOPTS=igncr`, by running `set +x posix` to turn of the POSIX compliance mode that kept turning on by itself and made bash choke on several of our scripts, by playing tricks with the `PATH`, but in the end to no avail. There were no single combination of hacks and workarounds that could get us past the entire chain from configure, to build, to testing. (The old solution user PowerShell instead to get around these limitations.) I'm happy to report that I have had absolutely zero issues with MSYS2 since I made the switch (and understood how to set the PATH properly), and I'm seriously co
 nsidering switching stance to recommend using MSYS2 instead of Cygwin as the primary winenv for building the JDK.
> 
> ### Example run
> 
> A good example on how a run looks like with the new GHA system is [the run for this PR](https://github.com/magicus/jdk/actions/runs/2454577164).
> 
> ### New features
> 
> While the primary focus was to convert the old system to a new framework, more accommodating to development, and to wait with further enhancements for the future, I have made a few additional features already in this PR. Most of them are related to needs that arose during development of this PR.
> 
> * A build failure summary, similar to the recently added test failure summary, is added when the build step fails
> 
> * The test reporting has been extended to all platforms, including Windows
> 
> * Test reporting has been improved slightly, and gotten multiple bug fixes
> 
> * All artifacts are now available for individual download. This includes:
> 
>   * The build bundles, per platform
>   * The test results, per platform and test suite
>   * Build failure logs, in case of build failure
> 
>   The build bundles have a retention period of 24 h, but the rest uses GitHub's default retention period (currently 90 days). The idea is that you can use GHA to download builds for platforms you might not have access to, but after that, conserving the builds does not make sense. GitHub currently provides free, unlimited storage (within the retention period) for artifacts, so we can afford this.
> 
> * The GHA process starts up much faster, which mean that e.g. a build failure on an exotic platform will show up earlier. This will not really affect the overall run time though, since it is bounded by variables such as queuing for workers, and waiting on tests with somewhat arbitrarily run times to finish.
> 
> ### Additional changes outside GHA
> 
> I also needed to make a few tweaks to the build system to play nice with the new GHA code.
> 
> * The build failure summary is now stored in build/$BUILD/make-support/failure-summary.log
> 
> * The configure summary now indicates what devkit or sysroot is used, if any
> 
> * The --with-sysroot argument is now properly normalized
> 
> ### Test failures
> 
> A handful of tests, which relies on shell behavior, turned out to fail on Windows when running under MSYS2. I have filed separate bugs, and submitted PRs, to get these fixed:
> 
> * https://bugs.openjdk.org/browse/JDK-8287902
> 
> * https://bugs.openjdk.org/browse/JDK-8287895

make/conf/github-actions.conf line 31:

> 29: 
> 30: JTREG_URL=https://ci.adoptopenjdk.net/view/Dependencies/job/dependency_pipeline/330/artifact/jtreg/jtreg-6.1+1.tar.gz
> 31: JTREG_SHA256=ccfa21f54bb173f818a5a8d93f77d49301f275f0677c9f914297046c910c5129

This seems questionable, and adds a very suspect blocking dependency on that website for when we want to update the version of jtreg to be used.

-------------

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


From jjg at openjdk.java.net  Tue Jun  7 22:51:31 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 7 Jun 2022 22:51:31 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests
In-Reply-To: <--Ssk8hhsAYcsAaBFb0ZnrmjtvD5Ju4conxM-iFyZ1g=.aca6fd4e-0164-4396-90ed-84357fb85993@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
 <--Ssk8hhsAYcsAaBFb0ZnrmjtvD5Ju4conxM-iFyZ1g=.aca6fd4e-0164-4396-90ed-84357fb85993@github.com>
Message-ID: <QgDB7VqJ2X-Yuo7Ux7GhJdjzZ8FmZBuUUHGNiXINzGo=.a4bdbc9e-7179-43dc-a06a-d4d6b9806a89@github.com>

On Tue, 7 Jun 2022 20:05:26 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> With project Skara, the ability to run a set of sanity build and test jobs on selected platforms was added. This functionality was driven by `.github/workflows/submit.yml`. This file unfortunately lacks any real structure, and contains a lot of code duplication and redundancy. This has made it hard to add functionality, and new platforms to test, and it has made it even harder to debug issues. (This is hard enough as it is, since we have no direct access to the platforms that GHA runs on.)
>> 
>> Since the GHA tests are important for a large subset of the community, we need to do better. 
>> 
>> ## GitHub Actions framework rewrite
>>  
>> This is a complete overhaul of the GHA testing framework. I started out trying to just tease the old `submit.yml` apart, trying to de-duplicate code, but I soon realized a much more thorough rework was needed.
>> 
>> ### Design description
>> 
>> The principle for the new design was to avoid code duplication, and to improve readability of the code. The latter is extra important since the GHA "language" is very limited, needs a lot of quirks and workarounds, and is probably not well known by many OpenJDK developers. I've strived to find useful layers of abstraction to make the expressions as clear as possible.
>> 
>> Unfortunately, the Workflow/Action YAML language is quite limited. There are two ways to avoid duplication, "local composite actions" and "callable workflows". They both have several limitations:
>> 
>>  * "Callable workflows" can only be used in a single redirection. They are (apparently) inlined into the "calling workflow" at run time, and as such, they are present without having to check out the source code. (Which is a lengthy process.)
>> 
>>  * "Local composite actions" can use other actions, but you must start by checking out the repo.
>> 
>> To use the strength of both kinds of sub-modules, I'm using "callable workflows" from `main.yml` to call `build-<platform>.yml` and `test.yml`. It is not allowed to mix "strategies" (that is, the method of automatically creating a test matrix) when calling callable workflows, so I needed to have some amount of duplication in `main.yml` that could have been avoided otherwise.
>> 
>> All the callable workflows need to check out the source code anyway, so there is no real additional cost of using "local composite actions" for abstraction of these workflows. (A bit of a lucky break.) I've created "high level" actions, corresponding to something like a function call. The goal here was both to avoid duplication, and to improve readability of the workflows.
>> 
>> The four `build-<platform>.yml` files are very similar. But in the end of the day, only like 50% of the source code is shared, and the platform specific changes permeate the files. So I decided to keep them separately, since mixing them all into one would have made a mess, due to the lack of proper abstraction mechanisms. But that also mean that if we change platform independent code in building, we need to remember to update it in all four places.
>> 
>> In the strictest sense, this is a "refactoring" in that the functionality should be equal to the old `submit.yml`. The same platforms should build, with the same arguments, and the same tests should run. When I look at the code now, I see lots of potential for improvement here, by rethinking what we do run. But let's save that discussion for the next PR.
>> 
>> There is one major change, though. Windows is no longer running on Cygwin, but on MSYS2. This was not really triggered by the recurring build issues on Cygwin (though that certainly did help me in thinking I made the right choice), but the sheer impossibility of getting Cygwin to behave as a normal unix shell on GHA Windows hosts. I spent countless hours trying to work out limitations, by setting `SHELLOPTS=igncr`, by running `set +x posix` to turn of the POSIX compliance mode that kept turning on by itself and made bash choke on several of our scripts, by playing tricks with the `PATH`, but in the end to no avail. There were no single combination of hacks and workarounds that could get us past the entire chain from configure, to build, to testing. (The old solution user PowerShell instead to get around these limitations.) I'm happy to report that I have had absolutely zero issues with MSYS2 since I made the switch (and understood how to set the PATH properly), and I'm seriously c
 onsidering switching stance to recommend using MSYS2 instead of Cygwin as the primary winenv for building the JDK.
>> 
>> ### Example run
>> 
>> A good example on how a run looks like with the new GHA system is [the run for this PR](https://github.com/magicus/jdk/actions/runs/2454577164).
>> 
>> ### New features
>> 
>> While the primary focus was to convert the old system to a new framework, more accommodating to development, and to wait with further enhancements for the future, I have made a few additional features already in this PR. Most of them are related to needs that arose during development of this PR.
>> 
>> * A build failure summary, similar to the recently added test failure summary, is added when the build step fails
>> 
>> * The test reporting has been extended to all platforms, including Windows
>> 
>> * Test reporting has been improved slightly, and gotten multiple bug fixes
>> 
>> * All artifacts are now available for individual download. This includes:
>> 
>>   * The build bundles, per platform
>>   * The test results, per platform and test suite
>>   * Build failure logs, in case of build failure
>> 
>>   The build bundles have a retention period of 24 h, but the rest uses GitHub's default retention period (currently 90 days). The idea is that you can use GHA to download builds for platforms you might not have access to, but after that, conserving the builds does not make sense. GitHub currently provides free, unlimited storage (within the retention period) for artifacts, so we can afford this.
>> 
>> * The GHA process starts up much faster, which mean that e.g. a build failure on an exotic platform will show up earlier. This will not really affect the overall run time though, since it is bounded by variables such as queuing for workers, and waiting on tests with somewhat arbitrarily run times to finish.
>> 
>> ### Additional changes outside GHA
>> 
>> I also needed to make a few tweaks to the build system to play nice with the new GHA code.
>> 
>> * The build failure summary is now stored in build/$BUILD/make-support/failure-summary.log
>> 
>> * The configure summary now indicates what devkit or sysroot is used, if any
>> 
>> * The --with-sysroot argument is now properly normalized
>> 
>> ### Test failures
>> 
>> A handful of tests, which relies on shell behavior, turned out to fail on Windows when running under MSYS2. I have filed separate bugs, and submitted PRs, to get these fixed:
>> 
>> * https://bugs.openjdk.org/browse/JDK-8287902
>> 
>> * https://bugs.openjdk.org/browse/JDK-8287895
>
> make/conf/github-actions.conf line 31:
> 
>> 29: 
>> 30: JTREG_URL=https://ci.adoptopenjdk.net/view/Dependencies/job/dependency_pipeline/330/artifact/jtreg/jtreg-6.1+1.tar.gz
>> 31: JTREG_SHA256=ccfa21f54bb173f818a5a8d93f77d49301f275f0677c9f914297046c910c5129
> 
> This seems questionable, and adds a very suspect blocking dependency on that website for when we want to update the version of jtreg to be used.

There are many issues at play in this PR. Can we handle "where to get jtreg" separately from the other issues here: rewriting the actions, and whether to switch to use MSYS2 instead of Cygwin.

-------------

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


From duke at openjdk.java.net  Wed Jun  8 07:56:53 2022
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Wed, 8 Jun 2022 07:56:53 GMT
Subject: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default
Message-ID: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>

At default configuration, SOURCE_DATE_EPOCH is exported as environment variable in SetupReproducibleBuild. Then, gcc is affected of SOURCE_DATE_EPOCH environment variable. This value is used only to set SOURCE_DATE_ISO_8601 (except below), so I removed "export" for SOURCE_DATE_EPOCH in SetupReproducibleBuild. And, at building ct.sym, SOURCE_DATE_EPOCH environment variable is needed. So I added setting routine if SOURCE_DATE_EPOCH is not set.

This fix works fine. With default configuration shows -Xinternalversion output same as Windows, and with --with-source-date configuration shows -Xinternalversion output specified timestamp. Would you please review this fix?

-------------

Commit messages:
 - 8288001: SOURCE_DATE_EPOCH should not be set by default
 - 8288001: SOURCE_DATE_EPOCH should not be set by default

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

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


From sgehwolf at openjdk.java.net  Wed Jun  8 09:38:32 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 8 Jun 2022 09:38:32 GMT
Subject: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default
In-Reply-To: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
References: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
Message-ID: <U-R3vVopclgOiL09AZ9Z9wPG9oBtNQQ1JnVhTmDeLDU=.979f33c8-6e94-4943-a05f-fe428b0bd961@github.com>

On Wed, 8 Jun 2022 07:47:24 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

> At default configuration, SOURCE_DATE_EPOCH is exported as environment variable in SetupReproducibleBuild. Then, gcc is affected of SOURCE_DATE_EPOCH environment variable. This value is used only to set SOURCE_DATE_ISO_8601 (except below), so I removed "export" for SOURCE_DATE_EPOCH in SetupReproducibleBuild. And, at building ct.sym, SOURCE_DATE_EPOCH environment variable is needed. So I added setting routine if SOURCE_DATE_EPOCH is not set.
> 
> This fix works fine. With default configuration shows -Xinternalversion output same as Windows, and with --with-source-date configuration shows -Xinternalversion output specified timestamp. Would you please review this fix?

It's not clear **why** you don't want `SOURCE_DATE_EPOCH` set by default. Could you explain? It would be good to make the OpenJDK build reproducible by default. The way it works currently, is a first step towards that goal.

-------------

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


From ihse at openjdk.java.net  Wed Jun  8 09:53:27 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 8 Jun 2022 09:53:27 GMT
Subject: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default
In-Reply-To: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
References: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
Message-ID: <HzifBIxA8d6cIiza9tCi2HpLQwXgivv8oCuQPJOWS00=.783b86e2-9419-4474-b717-c8f5dc06520c@github.com>

On Wed, 8 Jun 2022 07:47:24 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

> At default configuration, SOURCE_DATE_EPOCH is exported as environment variable in SetupReproducibleBuild. Then, gcc is affected of SOURCE_DATE_EPOCH environment variable. This value is used only to set SOURCE_DATE_ISO_8601 (except below), so I removed "export" for SOURCE_DATE_EPOCH in SetupReproducibleBuild. And, at building ct.sym, SOURCE_DATE_EPOCH environment variable is needed. So I added setting routine if SOURCE_DATE_EPOCH is not set.
> 
> This fix works fine. With default configuration shows -Xinternalversion output same as Windows, and with --with-source-date configuration shows -Xinternalversion output specified timestamp. Would you please review this fix?

No no no. The current design is very much intentional. We must export `SOURCE_DATE_EPOCH` for gcc to be able to see it.

I wonder just like Severin: *why* do you think this is a problem?

Also, the long term goal is to *only* make reproducible builds. The sole reason it is possible to do `--disable-reproducible-builds` is out of an abundance of caution, if the changes needed for full reproducibility had unintended negative consequences.

-------------

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


From erikj at openjdk.java.net  Wed Jun  8 10:06:35 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 8 Jun 2022 10:06:35 GMT
Subject: RFR: 8287828: Fix so that one can select jtreg test case by ID
 from make [v5]
In-Reply-To: <cAyhVq2MlJqN11tPfzcBtbDv4flLqA3z_klrkr1KeuU=.85fc760b-a4ea-4faf-b679-d466eb40a588@github.com>
References: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
 <cAyhVq2MlJqN11tPfzcBtbDv4flLqA3z_klrkr1KeuU=.85fc760b-a4ea-4faf-b679-d466eb40a588@github.com>
Message-ID: <IY0M0J8DGLxeBfDZ-jJW_Eh6yr-v0EbY8sfPqnpECTo=.441461cc-903f-46a4-87fc-c387cba08786@github.com>

On Tue, 7 Jun 2022 18:15:30 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> One can select a testcase by ID when running a jtreg test case directly from jtreg (using the testcase.java#testID syntax). However, this has not been possible to do when launching jtreg indirectly from make.
>> 
>> This fix attempts to address this issue. I have not tested this thoroughly yet, I wanted to show the code to get feedback first. The idea is to *not* emulated destructive imperative assignments through the use of eval. I instead try to handle it in a functional style without reassigning variables. I have tried to make the change as small as possible.
>> 
>> I am not used to change the build system, so I would appreciate thorough review.
>> 
>> `IfAppend` and `IfPrepend` are general purpose functions. If similar functions exists elsewhere inside the code base or in make itself I should probably use those instead. If they do not exist, they might be useful elsewhere and maybe should be placed in a common make file instead of the RunTests.gmk file.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use test id in comments

Marked as reviewed by erikj (Reviewer).

-------------

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


From erikj at openjdk.java.net  Wed Jun  8 10:08:27 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 8 Jun 2022 10:08:27 GMT
Subject: RFR: 8287894: Use fixed timestamp as an alternative of __DATE__
 macro in jdk.jdi to make Windows build reproducible
In-Reply-To: <EVQZHJ8cwIIMWtEhayX3XorZu6VhwFstYf5WETCJOGk=.37d88f49-e17b-4223-9bf4-f77427087baf@github.com>
References: <EVQZHJ8cwIIMWtEhayX3XorZu6VhwFstYf5WETCJOGk=.37d88f49-e17b-4223-9bf4-f77427087baf@github.com>
Message-ID: <y4PMUkICON246wJTJBLFdGtukjS8jR1RDBOYkWjXG_c=.6f98c036-f420-480f-8601-6a7f5a766388@github.com>

On Tue, 7 Jun 2022 19:57:48 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

> Hi!
> 
> Here is a fix to jdk.jdi that fixes reproducible build for Windows. The idea of the fix is to re-use value of --with-hotspot-build-time option to generate deterministic timestamp exactly like it's done to hotspot component.
> 
> Verification (Windows-10/MSVS-2019): ```bash ./configure --with-boot-jdk=c:/work/boot-jdk/jdk-18 --with-debug-level=fastdebug --with-hotspot-build-time="6/7/2022 2:35pm" --with-extra-cflags="/experimental:deterministic" --with-extra-cxxflags="/experimental:deterministic"```
> 
> Regression (Windows-10/MSVS-2019): ```bash ./configure --with-boot-jdk=c:/work/boot-jdk/jdk-18 --with-debug-level=fastdebug```

Marked as reviewed by erikj (Reviewer).

-------------

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


From ihse at openjdk.java.net  Wed Jun  8 10:10:38 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 8 Jun 2022 10:10:38 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v5]
In-Reply-To: <A7OpC5JI4w4admJiIDEZCuA3QlFyyWnEj_8yBZugqbM=.b0c1cc33-91c7-47e1-b85a-cc152e805516@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <A7OpC5JI4w4admJiIDEZCuA3QlFyyWnEj_8yBZugqbM=.b0c1cc33-91c7-47e1-b85a-cc152e805516@github.com>
Message-ID: <K3UtWQx-QAzR5uRkyvaJvzkgJFFMuJ2Rx8xSSgxDxFs=.c4e57ba0-3320-480c-9dd2-1d00bb5d08d3@github.com>

On Thu, 2 Jun 2022 17:00:35 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 40 additional commits since the last revision:
> 
>  - Update symbols for JDK 19 b25.
>  - Merge branch 'master' into JDK-8284858
>  - Adjust deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Update deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Respond to review feedback.
>  - Update symbol information for JDK 19 b24.
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - ... and 30 more: https://git.openjdk.java.net/jdk/compare/6a77da51...e495a579

Build changes look good. Thanks for fixing the bug in `generate-symbol-data.sh`.

-------------

Marked as reviewed by ihse (Reviewer).

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


From ihse at openjdk.java.net  Wed Jun  8 10:18:36 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 8 Jun 2022 10:18:36 GMT
Subject: RFR: 8287894: Use fixed timestamp as an alternative of __DATE__
 macro in jdk.jdi to make Windows build reproducible
In-Reply-To: <EVQZHJ8cwIIMWtEhayX3XorZu6VhwFstYf5WETCJOGk=.37d88f49-e17b-4223-9bf4-f77427087baf@github.com>
References: <EVQZHJ8cwIIMWtEhayX3XorZu6VhwFstYf5WETCJOGk=.37d88f49-e17b-4223-9bf4-f77427087baf@github.com>
Message-ID: <4lmDA5FxsPfNtUJMd9U1D9tfak7HvDTix4Tpmz_4FtA=.96211821-4873-481d-94a3-bc71278fb4d0@github.com>

On Tue, 7 Jun 2022 19:57:48 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

> Hi!
> 
> Here is a fix to jdk.jdi that fixes reproducible build for Windows. The idea of the fix is to re-use value of --with-hotspot-build-time option to generate deterministic timestamp exactly like it's done to hotspot component.
> 
> Verification (Windows-10/MSVS-2019): ```bash ./configure --with-boot-jdk=c:/work/boot-jdk/jdk-18 --with-debug-level=fastdebug --with-hotspot-build-time="6/7/2022 2:35pm" --with-extra-cflags="/experimental:deterministic" --with-extra-cxxflags="/experimental:deterministic"```
> 
> Regression (Windows-10/MSVS-2019): ```bash ./configure --with-boot-jdk=c:/work/boot-jdk/jdk-18 --with-debug-level=fastdebug```

Looks good. Thanks for fixing this!

-------------

Marked as reviewed by ihse (Reviewer).

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


From duke at openjdk.java.net  Wed Jun  8 11:46:35 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Wed, 8 Jun 2022 11:46:35 GMT
Subject: Integrated: 8287894: Use fixed timestamp as an alternative of __DATE__
 macro in jdk.jdi to make Windows build reproducible
In-Reply-To: <EVQZHJ8cwIIMWtEhayX3XorZu6VhwFstYf5WETCJOGk=.37d88f49-e17b-4223-9bf4-f77427087baf@github.com>
References: <EVQZHJ8cwIIMWtEhayX3XorZu6VhwFstYf5WETCJOGk=.37d88f49-e17b-4223-9bf4-f77427087baf@github.com>
Message-ID: <Ec6zVk5dOdUAccXBaN58qY02yYttee1AkguG4IFb7_s=.ce128861-81eb-4acd-85bf-aa44a3e461a2@github.com>

On Tue, 7 Jun 2022 19:57:48 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

> Hi!
> 
> Here is a fix to jdk.jdi that fixes reproducible build for Windows. The idea of the fix is to re-use value of --with-hotspot-build-time option to generate deterministic timestamp exactly like it's done to hotspot component.
> 
> Verification (Windows-10/MSVS-2019): ```bash ./configure --with-boot-jdk=c:/work/boot-jdk/jdk-18 --with-debug-level=fastdebug --with-hotspot-build-time="6/7/2022 2:35pm" --with-extra-cflags="/experimental:deterministic" --with-extra-cxxflags="/experimental:deterministic"```
> 
> Regression (Windows-10/MSVS-2019): ```bash ./configure --with-boot-jdk=c:/work/boot-jdk/jdk-18 --with-debug-level=fastdebug```

This pull request has now been integrated.

Changeset: a9d46f34
Author:    Alexey Pavlyutkin <apavlyutkin at azul.com>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a9d46f3413ef64c87520509fd70ac42629fbce91
Stats:     21 lines in 3 files changed: 14 ins; 0 del; 7 mod

8287894: Use fixed timestamp as an alternative of __DATE__ macro in jdk.jdi to make Windows build reproducible

Reviewed-by: erikj, ihse

-------------

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


From ihse at openjdk.java.net  Wed Jun  8 13:25:16 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 8 Jun 2022 13:25:16 GMT
Subject: RFR: 8287828: Fix so that one can select jtreg test case by ID
 from make [v5]
In-Reply-To: <cAyhVq2MlJqN11tPfzcBtbDv4flLqA3z_klrkr1KeuU=.85fc760b-a4ea-4faf-b679-d466eb40a588@github.com>
References: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
 <cAyhVq2MlJqN11tPfzcBtbDv4flLqA3z_klrkr1KeuU=.85fc760b-a4ea-4faf-b679-d466eb40a588@github.com>
Message-ID: <Gf87yEnn-2mSiiVacKrqZ--PsNzXS37PO47ISm8VDws=.6e51452d-1766-44fc-ab0f-f7e94a503b75@github.com>

On Tue, 7 Jun 2022 18:15:30 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> One can select a testcase by ID when running a jtreg test case directly from jtreg (using the testcase.java#testID syntax). However, this has not been possible to do when launching jtreg indirectly from make.
>> 
>> This fix attempts to address this issue. I have not tested this thoroughly yet, I wanted to show the code to get feedback first. The idea is to *not* emulated destructive imperative assignments through the use of eval. I instead try to handle it in a functional style without reassigning variables. I have tried to make the change as small as possible.
>> 
>> I am not used to change the build system, so I would appreciate thorough review.
>> 
>> `IfAppend` and `IfPrepend` are general purpose functions. If similar functions exists elsewhere inside the code base or in make itself I should probably use those instead. If they do not exist, they might be useful elsewhere and maybe should be placed in a common make file instead of the RunTests.gmk file.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use test id in comments

I apologize for the late review. The latest version look very good indeed, arguably even much better than the original. (Apart from it fixing the bug, that is.)

Thank you for contributing to the build system! You're welcome back any time you want. ;-)

-------------

Marked as reviewed by ihse (Reviewer).

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


From ihse at openjdk.java.net  Wed Jun  8 14:46:13 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 8 Jun 2022 14:46:13 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v2]
In-Reply-To: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
Message-ID: <ZGmg8awl8qB82NMFfrmTJBWk6S9wRkLBCfCatrdjZ5Q=.6d3d378f-d5da-4708-a436-2482814bc3ba@github.com>

> With project Skara, the ability to run a set of sanity build and test jobs on selected platforms was added. This functionality was driven by `.github/workflows/submit.yml`. This file unfortunately lacks any real structure, and contains a lot of code duplication and redundancy. This has made it hard to add functionality, and new platforms to test, and it has made it even harder to debug issues. (This is hard enough as it is, since we have no direct access to the platforms that GHA runs on.)
> 
> Since the GHA tests are important for a large subset of the community, we need to do better. 
> 
> ## GitHub Actions framework rewrite
>  
> This is a complete overhaul of the GHA testing framework. I started out trying to just tease the old `submit.yml` apart, trying to de-duplicate code, but I soon realized a much more thorough rework was needed.
> 
> ### Design description
> 
> The principle for the new design was to avoid code duplication, and to improve readability of the code. The latter is extra important since the GHA "language" is very limited, needs a lot of quirks and workarounds, and is probably not well known by many OpenJDK developers. I've strived to find useful layers of abstraction to make the expressions as clear as possible.
> 
> Unfortunately, the Workflow/Action YAML language is quite limited. There are two ways to avoid duplication, "local composite actions" and "callable workflows". They both have several limitations:
> 
>  * "Callable workflows" can only be used in a single redirection. They are (apparently) inlined into the "calling workflow" at run time, and as such, they are present without having to check out the source code. (Which is a lengthy process.)
> 
>  * "Local composite actions" can use other actions, but you must start by checking out the repo.
> 
> To use the strength of both kinds of sub-modules, I'm using "callable workflows" from `main.yml` to call `build-<platform>.yml` and `test.yml`. It is not allowed to mix "strategies" (that is, the method of automatically creating a test matrix) when calling callable workflows, so I needed to have some amount of duplication in `main.yml` that could have been avoided otherwise.
> 
> All the callable workflows need to check out the source code anyway, so there is no real additional cost of using "local composite actions" for abstraction of these workflows. (A bit of a lucky break.) I've created "high level" actions, corresponding to something like a function call. The goal here was both to avoid duplication, and to improve readability of the workflows.
> 
> The four `build-<platform>.yml` files are very similar. But in the end of the day, only like 50% of the source code is shared, and the platform specific changes permeate the files. So I decided to keep them separately, since mixing them all into one would have made a mess, due to the lack of proper abstraction mechanisms. But that also mean that if we change platform independent code in building, we need to remember to update it in all four places.
> 
> In the strictest sense, this is a "refactoring" in that the functionality should be equal to the old `submit.yml`. The same platforms should build, with the same arguments, and the same tests should run. When I look at the code now, I see lots of potential for improvement here, by rethinking what we do run. But let's save that discussion for the next PR.
> 
> There is one major change, though. Windows is no longer running on Cygwin, but on MSYS2. This was not really triggered by the recurring build issues on Cygwin (though that certainly did help me in thinking I made the right choice), but the sheer impossibility of getting Cygwin to behave as a normal unix shell on GHA Windows hosts. I spent countless hours trying to work out limitations, by setting `SHELLOPTS=igncr`, by running `set +x posix` to turn of the POSIX compliance mode that kept turning on by itself and made bash choke on several of our scripts, by playing tricks with the `PATH`, but in the end to no avail. There were no single combination of hacks and workarounds that could get us past the entire chain from configure, to build, to testing. (The old solution user PowerShell instead to get around these limitations.) I'm happy to report that I have had absolutely zero issues with MSYS2 since I made the switch (and understood how to set the PATH properly), and I'm seriously co
 nsidering switching stance to recommend using MSYS2 instead of Cygwin as the primary winenv for building the JDK.
> 
> ### Example run
> 
> A good example on how a run looks like with the new GHA system is [the run for this PR](https://github.com/magicus/jdk/actions/runs/2454577164).
> 
> ### New features
> 
> While the primary focus was to convert the old system to a new framework, more accommodating to development, and to wait with further enhancements for the future, I have made a few additional features already in this PR. Most of them are related to needs that arose during development of this PR.
> 
> * A build failure summary, similar to the recently added test failure summary, is added when the build step fails
> 
> * The test reporting has been extended to all platforms, including Windows
> 
> * Test reporting has been improved slightly, and gotten multiple bug fixes
> 
> * All artifacts are now available for individual download. This includes:
> 
>   * The build bundles, per platform
>   * The test results, per platform and test suite
>   * Build failure logs, in case of build failure
> 
>   The build bundles have a retention period of 24 h, but the rest uses GitHub's default retention period (currently 90 days). The idea is that you can use GHA to download builds for platforms you might not have access to, but after that, conserving the builds does not make sense. GitHub currently provides free, unlimited storage (within the retention period) for artifacts, so we can afford this.
> 
> * The GHA process starts up much faster, which mean that e.g. a build failure on an exotic platform will show up earlier. This will not really affect the overall run time though, since it is bounded by variables such as queuing for workers, and waiting on tests with somewhat arbitrarily run times to finish.
> 
> ### Additional changes outside GHA
> 
> I also needed to make a few tweaks to the build system to play nice with the new GHA code.
> 
> * The build failure summary is now stored in build/$BUILD/make-support/failure-summary.log
> 
> * The configure summary now indicates what devkit or sysroot is used, if any
> 
> * The --with-sysroot argument is now properly normalized
> 
> ### Test failures
> 
> A handful of tests, which relies on shell behavior, turned out to fail on Windows when running under MSYS2. I have filed separate bugs, and submitted PRs, to get these fixed:
> 
> * https://bugs.openjdk.org/browse/JDK-8287902
> 
> * https://bugs.openjdk.org/browse/JDK-8287895

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Build JTReg from source instead of downloading pre-built binary

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9063/files
  - new: https://git.openjdk.java.net/jdk/pull/9063/files/665451a5..d75222c2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9063&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9063&range=00-01

  Stats: 30 lines in 2 files changed: 8 ins; 9 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9063.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9063/head:pull/9063

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


From darcy at openjdk.java.net  Thu Jun  9 01:03:47 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 9 Jun 2022 01:03:47 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v6]
In-Reply-To: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
Message-ID: <n1d8Iv4qjk-lznK-UveaBbbb-EAfIGyDOwkoQ935WAQ=.483638ae-69ba-4731-ad21-f47299ca8ca2@github.com>

> Time to start getting ready for JDK 20...

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 44 additional commits since the last revision:

 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Update symbols for JDK 19 b25.
 - Merge branch 'master' into JDK-8284858
 - Adjust deprecated options test.
 - Merge branch 'master' into JDK-8284858
 - Update deprecated options test.
 - Merge branch 'master' into JDK-8284858
 - ... and 34 more: https://git.openjdk.java.net/jdk/compare/530d16c1...1b29a17c

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8236/files
  - new: https://git.openjdk.java.net/jdk/pull/8236/files/e495a579..1b29a17c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=04-05

  Stats: 16423 lines in 539 files changed: 12382 ins; 2143 del; 1898 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8236.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236

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


From iris at openjdk.java.net  Thu Jun  9 04:23:40 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 9 Jun 2022 04:23:40 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v6]
In-Reply-To: <n1d8Iv4qjk-lznK-UveaBbbb-EAfIGyDOwkoQ935WAQ=.483638ae-69ba-4731-ad21-f47299ca8ca2@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <n1d8Iv4qjk-lznK-UveaBbbb-EAfIGyDOwkoQ935WAQ=.483638ae-69ba-4731-ad21-f47299ca8ca2@github.com>
Message-ID: <GM1p-fYjWEfrt5pYM5rZjVuRnY2fr_nKe_hpB_iTk1w=.3c99866a-5384-41be-bbc9-15dd1affffc1@github.com>

On Thu, 9 Jun 2022 01:03:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 44 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Update symbols for JDK 19 b25.
>  - Merge branch 'master' into JDK-8284858
>  - Adjust deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Update deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - ... and 34 more: https://git.openjdk.java.net/jdk/compare/705cfa36...1b29a17c

Marked as reviewed by iris (Reviewer).

-------------

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


From duke at openjdk.java.net  Thu Jun  9 06:56:55 2022
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Thu, 9 Jun 2022 06:56:55 GMT
Subject: RFR: 8283724: Incorrect description for jtreg-failure-handler option
Message-ID: <h1DNvE0MsYO3NUu0ZyuRPZJJtLNjeyK17QYvgn0huqE=.43f66f4f-fed2-430e-bcb4-7a74079300ab@github.com>

The description for the jtreg-failure-handler option is incorrect, so I fixed it to describe jtreg-failure-handler option.  
Would you please review this fix?

-------------

Commit messages:
 - 8283724: Incorrect description for jtreg-failure-handler option

Changes: https://git.openjdk.java.net/jdk/pull/9099/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9099&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8283724
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9099.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9099/head:pull/9099

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


From erikj at openjdk.java.net  Thu Jun  9 08:23:38 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 9 Jun 2022 08:23:38 GMT
Subject: RFR: 8283724: Incorrect description for jtreg-failure-handler
 option
In-Reply-To: <h1DNvE0MsYO3NUu0ZyuRPZJJtLNjeyK17QYvgn0huqE=.43f66f4f-fed2-430e-bcb4-7a74079300ab@github.com>
References: <h1DNvE0MsYO3NUu0ZyuRPZJJtLNjeyK17QYvgn0huqE=.43f66f4f-fed2-430e-bcb4-7a74079300ab@github.com>
Message-ID: <wZZFQU-iiA41P-e7T8UDIT0-LFVcc71j3DudWDneW40=.6051e59a-be5b-4015-af22-79c81ee8277f@github.com>

On Thu, 9 Jun 2022 06:49:15 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

> The description for the jtreg-failure-handler option is incorrect, so I fixed it to describe jtreg-failure-handler option.  
> Would you please review this fix?

Marked as reviewed by erikj (Reviewer).

-------------

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


From ihse at openjdk.java.net  Thu Jun  9 08:48:24 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 9 Jun 2022 08:48:24 GMT
Subject: RFR: 8283724: Incorrect description for jtreg-failure-handler
 option
In-Reply-To: <h1DNvE0MsYO3NUu0ZyuRPZJJtLNjeyK17QYvgn0huqE=.43f66f4f-fed2-430e-bcb4-7a74079300ab@github.com>
References: <h1DNvE0MsYO3NUu0ZyuRPZJJtLNjeyK17QYvgn0huqE=.43f66f4f-fed2-430e-bcb4-7a74079300ab@github.com>
Message-ID: <heX4jfNMDw2mtp18MjvkMaGyrZ0Ma2kQQ9mx_J7tYgg=.cbef23ef-62c5-4387-81c9-895b32f4d6ec@github.com>

On Thu, 9 Jun 2022 06:49:15 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

> The description for the jtreg-failure-handler option is incorrect, so I fixed it to describe jtreg-failure-handler option.  
> Would you please review this fix?

Marked as reviewed by ihse (Reviewer).

-------------

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


From ihse at openjdk.java.net  Thu Jun  9 10:32:37 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 9 Jun 2022 10:32:37 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v2]
In-Reply-To: <ZGmg8awl8qB82NMFfrmTJBWk6S9wRkLBCfCatrdjZ5Q=.6d3d378f-d5da-4708-a436-2482814bc3ba@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
 <ZGmg8awl8qB82NMFfrmTJBWk6S9wRkLBCfCatrdjZ5Q=.6d3d378f-d5da-4708-a436-2482814bc3ba@github.com>
Message-ID: <v6XRt2q5PbhGlY-2CEAxapEwoVV3JhUaWw5eDVdDV5I=.88ab9b35-f0b5-4044-95b2-ecf6bf2b4f15@github.com>

On Wed, 8 Jun 2022 14:46:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> With project Skara, the ability to run a set of sanity build and test jobs on selected platforms was added. This functionality was driven by `.github/workflows/submit.yml`. This file unfortunately lacks any real structure, and contains a lot of code duplication and redundancy. This has made it hard to add functionality, and new platforms to test, and it has made it even harder to debug issues. (This is hard enough as it is, since we have no direct access to the platforms that GHA runs on.)
>> 
>> Since the GHA tests are important for a large subset of the community, we need to do better. 
>> 
>> ## GitHub Actions framework rewrite
>>  
>> This is a complete overhaul of the GHA testing framework. I started out trying to just tease the old `submit.yml` apart, trying to de-duplicate code, but I soon realized a much more thorough rework was needed.
>> 
>> ### Design description
>> 
>> The principle for the new design was to avoid code duplication, and to improve readability of the code. The latter is extra important since the GHA "language" is very limited, needs a lot of quirks and workarounds, and is probably not well known by many OpenJDK developers. I've strived to find useful layers of abstraction to make the expressions as clear as possible.
>> 
>> Unfortunately, the Workflow/Action YAML language is quite limited. There are two ways to avoid duplication, "local composite actions" and "callable workflows". They both have several limitations:
>> 
>>  * "Callable workflows" can only be used in a single redirection. They are (apparently) inlined into the "calling workflow" at run time, and as such, they are present without having to check out the source code. (Which is a lengthy process.)
>> 
>>  * "Local composite actions" can use other actions, but you must start by checking out the repo.
>> 
>> To use the strength of both kinds of sub-modules, I'm using "callable workflows" from `main.yml` to call `build-<platform>.yml` and `test.yml`. It is not allowed to mix "strategies" (that is, the method of automatically creating a test matrix) when calling callable workflows, so I needed to have some amount of duplication in `main.yml` that could have been avoided otherwise.
>> 
>> All the callable workflows need to check out the source code anyway, so there is no real additional cost of using "local composite actions" for abstraction of these workflows. (A bit of a lucky break.) I've created "high level" actions, corresponding to something like a function call. The goal here was both to avoid duplication, and to improve readability of the workflows.
>> 
>> The four `build-<platform>.yml` files are very similar. But in the end of the day, only like 50% of the source code is shared, and the platform specific changes permeate the files. So I decided to keep them separately, since mixing them all into one would have made a mess, due to the lack of proper abstraction mechanisms. But that also mean that if we change platform independent code in building, we need to remember to update it in all four places.
>> 
>> In the strictest sense, this is a "refactoring" in that the functionality should be equal to the old `submit.yml`. The same platforms should build, with the same arguments, and the same tests should run. When I look at the code now, I see lots of potential for improvement here, by rethinking what we do run. But let's save that discussion for the next PR.
>> 
>> There is one major change, though. Windows is no longer running on Cygwin, but on MSYS2. This was not really triggered by the recurring build issues on Cygwin (though that certainly did help me in thinking I made the right choice), but the sheer impossibility of getting Cygwin to behave as a normal unix shell on GHA Windows hosts. I spent countless hours trying to work out limitations, by setting `SHELLOPTS=igncr`, by running `set +x posix` to turn of the POSIX compliance mode that kept turning on by itself and made bash choke on several of our scripts, by playing tricks with the `PATH`, but in the end to no avail. There were no single combination of hacks and workarounds that could get us past the entire chain from configure, to build, to testing. (The old solution user PowerShell instead to get around these limitations.) I'm happy to report that I have had absolutely zero issues with MSYS2 since I made the switch (and understood how to set the PATH properly), and I'm seriously c
 onsidering switching stance to recommend using MSYS2 instead of Cygwin as the primary winenv for building the JDK.
>> 
>> ### Example run
>> 
>> A good example on how a run looks like with the new GHA system is [the run for this PR](https://github.com/magicus/jdk/actions/runs/2454577164).
>> 
>> ### New features
>> 
>> While the primary focus was to convert the old system to a new framework, more accommodating to development, and to wait with further enhancements for the future, I have made a few additional features already in this PR. Most of them are related to needs that arose during development of this PR.
>> 
>> * A build failure summary, similar to the recently added test failure summary, is added when the build step fails
>> 
>> * The test reporting has been extended to all platforms, including Windows
>> 
>> * Test reporting has been improved slightly, and gotten multiple bug fixes
>> 
>> * All artifacts are now available for individual download. This includes:
>> 
>>   * The build bundles, per platform
>>   * The test results, per platform and test suite
>>   * Build failure logs, in case of build failure
>> 
>>   The build bundles have a retention period of 24 h, but the rest uses GitHub's default retention period (currently 90 days). The idea is that you can use GHA to download builds for platforms you might not have access to, but after that, conserving the builds does not make sense. GitHub currently provides free, unlimited storage (within the retention period) for artifacts, so we can afford this.
>> 
>> * The GHA process starts up much faster, which mean that e.g. a build failure on an exotic platform will show up earlier. This will not really affect the overall run time though, since it is bounded by variables such as queuing for workers, and waiting on tests with somewhat arbitrarily run times to finish.
>> 
>> ### Additional changes outside GHA
>> 
>> I also needed to make a few tweaks to the build system to play nice with the new GHA code.
>> 
>> * The build failure summary is now stored in build/$BUILD/make-support/failure-summary.log
>> 
>> * The configure summary now indicates what devkit or sysroot is used, if any
>> 
>> * The --with-sysroot argument is now properly normalized
>> 
>> ### Test failures
>> 
>> A handful of tests, which relies on shell behavior, turned out to fail on Windows when running under MSYS2. I have filed separate bugs, and submitted PRs, to get these fixed:
>> 
>> * https://bugs.openjdk.org/browse/JDK-8287902
>> 
>> * https://bugs.openjdk.org/browse/JDK-8287895
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Build JTReg from source instead of downloading pre-built binary

Le me clarify a bit a regarding switching from Cygwin to MSYS2. 

First of all, Cygwin as a supported environment is not going away. We use Cygwin for Windows builds in the Oracle internal CI system, and will continue to do so for the foreseeable future. Most individual JDK developers (I assume) will use Cygwin when working on Windows. We will never stop supporting Cygwin as a way of building on Windows.

This change however changes how GHA tests are run. In a way, this could be considered to be a good way of actually getting more testing even of the MSYS2 code, which has hitherto had no automatic testing. But the main point is this: without changing to MSYS2, this entire PR falls. There is no way that we can get this unified unix-like behaviour needed to run the new YAML code, our configure, build and test scripts on GHA Windows hosts with Cygwin. Note that the old script did not use Cygwin. It used Powershell. All YAML rules were written in Powershell, and the only use of Cygwin was that the path to Cygwin utils were passed to configure and jtreg. I spent literally days and days trying to wrangle Cygwin into behaving on GHA, but in the end the tooling provided to us by Github turned out to be insufficient to achieve this. So it's MSYS2, or no unification at all. I don't think that's very controversial -- Cygwin was previously chosen just since it was the most well-known and official
 ly best supported environment, not because of some conscious deliberation between Cygwin and MSYS2. It has in fact turned out to be highly problematic, just go search JBS for how many Cygwin-related bugs on GHA there have been...

And finally, what I meant by my note about recommending MSYS2 is just that the current build README heavily favors Cygwin, and discredits the alternatives (WSL and MSYS2). I think the wordings there might be soften up, and MSYS2 presented as a fully viable alternative to Cygin; and perhaps even presented as the simplest choice for new developers.

-------------

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


From ihse at openjdk.java.net  Thu Jun  9 12:45:06 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 9 Jun 2022 12:45:06 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v3]
In-Reply-To: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
Message-ID: <taQyFbMnQ93CKb9-5xRGIfR2jI6gf3QlsHkh3_bs_5c=.57946e86-6a6c-464a-9321-0f62712ef837@github.com>

> With project Skara, the ability to run a set of sanity build and test jobs on selected platforms was added. This functionality was driven by `.github/workflows/submit.yml`. This file unfortunately lacks any real structure, and contains a lot of code duplication and redundancy. This has made it hard to add functionality, and new platforms to test, and it has made it even harder to debug issues. (This is hard enough as it is, since we have no direct access to the platforms that GHA runs on.)
> 
> Since the GHA tests are important for a large subset of the community, we need to do better. 
> 
> ## GitHub Actions framework rewrite
>  
> This is a complete overhaul of the GHA testing framework. I started out trying to just tease the old `submit.yml` apart, trying to de-duplicate code, but I soon realized a much more thorough rework was needed.
> 
> ### Design description
> 
> The principle for the new design was to avoid code duplication, and to improve readability of the code. The latter is extra important since the GHA "language" is very limited, needs a lot of quirks and workarounds, and is probably not well known by many OpenJDK developers. I've strived to find useful layers of abstraction to make the expressions as clear as possible.
> 
> Unfortunately, the Workflow/Action YAML language is quite limited. There are two ways to avoid duplication, "local composite actions" and "callable workflows". They both have several limitations:
> 
>  * "Callable workflows" can only be used in a single redirection. They are (apparently) inlined into the "calling workflow" at run time, and as such, they are present without having to check out the source code. (Which is a lengthy process.)
> 
>  * "Local composite actions" can use other actions, but you must start by checking out the repo.
> 
> To use the strength of both kinds of sub-modules, I'm using "callable workflows" from `main.yml` to call `build-<platform>.yml` and `test.yml`. It is not allowed to mix "strategies" (that is, the method of automatically creating a test matrix) when calling callable workflows, so I needed to have some amount of duplication in `main.yml` that could have been avoided otherwise.
> 
> All the callable workflows need to check out the source code anyway, so there is no real additional cost of using "local composite actions" for abstraction of these workflows. (A bit of a lucky break.) I've created "high level" actions, corresponding to something like a function call. The goal here was both to avoid duplication, and to improve readability of the workflows.
> 
> The four `build-<platform>.yml` files are very similar. But in the end of the day, only like 50% of the source code is shared, and the platform specific changes permeate the files. So I decided to keep them separately, since mixing them all into one would have made a mess, due to the lack of proper abstraction mechanisms. But that also mean that if we change platform independent code in building, we need to remember to update it in all four places.
> 
> In the strictest sense, this is a "refactoring" in that the functionality should be equal to the old `submit.yml`. The same platforms should build, with the same arguments, and the same tests should run. When I look at the code now, I see lots of potential for improvement here, by rethinking what we do run. But let's save that discussion for the next PR.
> 
> There is one major change, though. Windows is no longer running on Cygwin, but on MSYS2. This was not really triggered by the recurring build issues on Cygwin (though that certainly did help me in thinking I made the right choice), but the sheer impossibility of getting Cygwin to behave as a normal unix shell on GHA Windows hosts. I spent countless hours trying to work out limitations, by setting `SHELLOPTS=igncr`, by running `set +x posix` to turn of the POSIX compliance mode that kept turning on by itself and made bash choke on several of our scripts, by playing tricks with the `PATH`, but in the end to no avail. There were no single combination of hacks and workarounds that could get us past the entire chain from configure, to build, to testing. (The old solution user PowerShell instead to get around these limitations.) I'm happy to report that I have had absolutely zero issues with MSYS2 since I made the switch (and understood how to set the PATH properly), and I'm seriously co
 nsidering switching stance to recommend using MSYS2 instead of Cygwin as the primary winenv for building the JDK.
> 
> ### Example run
> 
> A good example on how a run looks like with the new GHA system is [the run for this PR](https://github.com/magicus/jdk/actions/runs/2454577164).
> 
> ### New features
> 
> While the primary focus was to convert the old system to a new framework, more accommodating to development, and to wait with further enhancements for the future, I have made a few additional features already in this PR. Most of them are related to needs that arose during development of this PR.
> 
> * A build failure summary, similar to the recently added test failure summary, is added when the build step fails
> 
> * The test reporting has been extended to all platforms, including Windows
> 
> * Test reporting has been improved slightly, and gotten multiple bug fixes
> 
> * All artifacts are now available for individual download. This includes:
> 
>   * The build bundles, per platform
>   * The test results, per platform and test suite
>   * Build failure logs, in case of build failure
> 
>   The build bundles have a retention period of 24 h, but the rest uses GitHub's default retention period (currently 90 days). The idea is that you can use GHA to download builds for platforms you might not have access to, but after that, conserving the builds does not make sense. GitHub currently provides free, unlimited storage (within the retention period) for artifacts, so we can afford this.
> 
> * The GHA process starts up much faster, which mean that e.g. a build failure on an exotic platform will show up earlier. This will not really affect the overall run time though, since it is bounded by variables such as queuing for workers, and waiting on tests with somewhat arbitrarily run times to finish.
> 
> ### Additional changes outside GHA
> 
> I also needed to make a few tweaks to the build system to play nice with the new GHA code.
> 
> * The build failure summary is now stored in build/$BUILD/make-support/failure-summary.log
> 
> * The configure summary now indicates what devkit or sysroot is used, if any
> 
> * The --with-sysroot argument is now properly normalized
> 
> ### Test failures
> 
> A handful of tests, which relies on shell behavior, turned out to fail on Windows when running under MSYS2. I have filed separate bugs, and submitted PRs, to get these fixed:
> 
> * https://bugs.openjdk.org/browse/JDK-8287902
> 
> * https://bugs.openjdk.org/browse/JDK-8287895

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Use Java 11 to build jtreg. Also temporarily switch out jtreg source ref to PR that fixes build on msys2. (This will be updated once the fix is in an official jtreg release.)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9063/files
  - new: https://git.openjdk.java.net/jdk/pull/9063/files/d75222c2..220f9209

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9063&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9063&range=01-02

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

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


From ihse at openjdk.java.net  Thu Jun  9 12:51:26 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 9 Jun 2022 12:51:26 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v3]
In-Reply-To: <QgDB7VqJ2X-Yuo7Ux7GhJdjzZ8FmZBuUUHGNiXINzGo=.a4bdbc9e-7179-43dc-a06a-d4d6b9806a89@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
 <--Ssk8hhsAYcsAaBFb0ZnrmjtvD5Ju4conxM-iFyZ1g=.aca6fd4e-0164-4396-90ed-84357fb85993@github.com>
 <QgDB7VqJ2X-Yuo7Ux7GhJdjzZ8FmZBuUUHGNiXINzGo=.a4bdbc9e-7179-43dc-a06a-d4d6b9806a89@github.com>
Message-ID: <_h851NTLuGAF_r2YjpVCFQNwJOQTzhFGnY_7QZfXbEI=.3918899b-5e21-493e-a45f-0dc6503fd9fa@github.com>

On Tue, 7 Jun 2022 22:47:32 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> make/conf/github-actions.conf line 31:
>> 
>>> 29: 
>>> 30: JTREG_URL=https://ci.adoptopenjdk.net/view/Dependencies/job/dependency_pipeline/330/artifact/jtreg/jtreg-6.1+1.tar.gz
>>> 31: JTREG_SHA256=ccfa21f54bb173f818a5a8d93f77d49301f275f0677c9f914297046c910c5129
>> 
>> This seems questionable, and adds a very suspect blocking dependency on that website for when we want to update the version of jtreg to be used.
>
> There are many issues at play in this PR. Can we handle "where to get jtreg" separately from the other issues here: rewriting the actions, and whether to switch to use MSYS2 instead of Cygwin.

I reverted to the old method of building jtreg locally, with some changes. I do not attempt to build it before starting all runs, but instead each build job will start by building it if it is not in the cache. This adds < 60 seconds of build time so I think this is fully acceptable to avoid the complexity of the old solution.

Most of the time a cache hit is likely to happen. GHA caches are indirectly keyed on runner OS (this also means that the explicit `runner.os` in the cache key for bootjdk is not strictly necessary, but only there to make it more obvious), so in theory this needs to be built at least once for Windows, macOS and Linux. After this, it is cached, and only removed from the cache if not having been accessed for 7 days.

The 6.1+1 release of jtreg can not be built on msys2. There is a PR open (https://github.com/openjdk/jtreg/pull/87) with a fix. For the time being, while I address some additional issues in this PR, I have set the JTReg ref to checkout to this PR. Hopefully this fix will be included in a proper JTReg release when this PR is ready for integration.

I still think it would be superior to download a prebuilt binary, though.

-------------

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


From ihse at openjdk.java.net  Thu Jun  9 12:57:05 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 9 Jun 2022 12:57:05 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v4]
In-Reply-To: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
Message-ID: <zkK7RAg7izSW-Rg0g37Snuj8ucIZ6WnN6WMtgrlbig0=.9836fc74-86e6-423a-b7d7-6ce6136f24cf@github.com>

> With project Skara, the ability to run a set of sanity build and test jobs on selected platforms was added. This functionality was driven by `.github/workflows/submit.yml`. This file unfortunately lacks any real structure, and contains a lot of code duplication and redundancy. This has made it hard to add functionality, and new platforms to test, and it has made it even harder to debug issues. (This is hard enough as it is, since we have no direct access to the platforms that GHA runs on.)
> 
> Since the GHA tests are important for a large subset of the community, we need to do better. 
> 
> ## GitHub Actions framework rewrite
>  
> This is a complete overhaul of the GHA testing framework. I started out trying to just tease the old `submit.yml` apart, trying to de-duplicate code, but I soon realized a much more thorough rework was needed.
> 
> ### Design description
> 
> The principle for the new design was to avoid code duplication, and to improve readability of the code. The latter is extra important since the GHA "language" is very limited, needs a lot of quirks and workarounds, and is probably not well known by many OpenJDK developers. I've strived to find useful layers of abstraction to make the expressions as clear as possible.
> 
> Unfortunately, the Workflow/Action YAML language is quite limited. There are two ways to avoid duplication, "local composite actions" and "callable workflows". They both have several limitations:
> 
>  * "Callable workflows" can only be used in a single redirection. They are (apparently) inlined into the "calling workflow" at run time, and as such, they are present without having to check out the source code. (Which is a lengthy process.)
> 
>  * "Local composite actions" can use other actions, but you must start by checking out the repo.
> 
> To use the strength of both kinds of sub-modules, I'm using "callable workflows" from `main.yml` to call `build-<platform>.yml` and `test.yml`. It is not allowed to mix "strategies" (that is, the method of automatically creating a test matrix) when calling callable workflows, so I needed to have some amount of duplication in `main.yml` that could have been avoided otherwise.
> 
> All the callable workflows need to check out the source code anyway, so there is no real additional cost of using "local composite actions" for abstraction of these workflows. (A bit of a lucky break.) I've created "high level" actions, corresponding to something like a function call. The goal here was both to avoid duplication, and to improve readability of the workflows.
> 
> The four `build-<platform>.yml` files are very similar. But in the end of the day, only like 50% of the source code is shared, and the platform specific changes permeate the files. So I decided to keep them separately, since mixing them all into one would have made a mess, due to the lack of proper abstraction mechanisms. But that also mean that if we change platform independent code in building, we need to remember to update it in all four places.
> 
> In the strictest sense, this is a "refactoring" in that the functionality should be equal to the old `submit.yml`. The same platforms should build, with the same arguments, and the same tests should run. When I look at the code now, I see lots of potential for improvement here, by rethinking what we do run. But let's save that discussion for the next PR.
> 
> There is one major change, though. Windows is no longer running on Cygwin, but on MSYS2. This was not really triggered by the recurring build issues on Cygwin (though that certainly did help me in thinking I made the right choice), but the sheer impossibility of getting Cygwin to behave as a normal unix shell on GHA Windows hosts. I spent countless hours trying to work out limitations, by setting `SHELLOPTS=igncr`, by running `set +x posix` to turn of the POSIX compliance mode that kept turning on by itself and made bash choke on several of our scripts, by playing tricks with the `PATH`, but in the end to no avail. There were no single combination of hacks and workarounds that could get us past the entire chain from configure, to build, to testing. (The old solution user PowerShell instead to get around these limitations.) I'm happy to report that I have had absolutely zero issues with MSYS2 since I made the switch (and understood how to set the PATH properly), and I'm seriously co
 nsidering switching stance to recommend using MSYS2 instead of Cygwin as the primary winenv for building the JDK.
> 
> ### Example run
> 
> A good example on how a run looks like with the new GHA system is [the run for this PR](https://github.com/magicus/jdk/actions/runs/2454577164).
> 
> ### New features
> 
> While the primary focus was to convert the old system to a new framework, more accommodating to development, and to wait with further enhancements for the future, I have made a few additional features already in this PR. Most of them are related to needs that arose during development of this PR.
> 
> * A build failure summary, similar to the recently added test failure summary, is added when the build step fails
> 
> * The test reporting has been extended to all platforms, including Windows
> 
> * Test reporting has been improved slightly, and gotten multiple bug fixes
> 
> * All artifacts are now available for individual download. This includes:
> 
>   * The build bundles, per platform
>   * The test results, per platform and test suite
>   * Build failure logs, in case of build failure
> 
>   The build bundles have a retention period of 24 h, but the rest uses GitHub's default retention period (currently 90 days). The idea is that you can use GHA to download builds for platforms you might not have access to, but after that, conserving the builds does not make sense. GitHub currently provides free, unlimited storage (within the retention period) for artifacts, so we can afford this.
> 
> * The GHA process starts up much faster, which mean that e.g. a build failure on an exotic platform will show up earlier. This will not really affect the overall run time though, since it is bounded by variables such as queuing for workers, and waiting on tests with somewhat arbitrarily run times to finish.
> 
> ### Additional changes outside GHA
> 
> I also needed to make a few tweaks to the build system to play nice with the new GHA code.
> 
> * The build failure summary is now stored in build/$BUILD/make-support/failure-summary.log
> 
> * The configure summary now indicates what devkit or sysroot is used, if any
> 
> * The --with-sysroot argument is now properly normalized
> 
> ### Test failures
> 
> A handful of tests, which relies on shell behavior, turned out to fail on Windows when running under MSYS2. I have filed separate bugs, and submitted PRs, to get these fixed:
> 
> * https://bugs.openjdk.org/browse/JDK-8287902
> 
> * https://bugs.openjdk.org/browse/JDK-8287895

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Apparently that was not a legal reference to actions/checkout. Try another way.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9063/files
  - new: https://git.openjdk.java.net/jdk/pull/9063/files/220f9209..9cbf5875

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9063&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9063&range=02-03

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

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


From darcy at openjdk.java.net  Thu Jun  9 16:21:25 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 9 Jun 2022 16:21:25 GMT
Subject: Integrated: JDK-8284858: Start of release updates for JDK 20
In-Reply-To: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
Message-ID: <b1Cu-1h4TvuAVVuAlcZi4SoVs0KQOh8UxvL9CUKz3IE=.3792f081-f3fe-444c-981a-af47a3d6f123@github.com>

On Thu, 14 Apr 2022 05:09:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Time to start getting ready for JDK 20...

This pull request has now been integrated.

Changeset: edff51e5
Author:    Joe Darcy <darcy at openjdk.org>
Committer: Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/edff51e5fdb5282830ecfb3792a88c7b28ca6557
Stats:     6453 lines in 69 files changed: 6403 ins; 5 del; 45 mod

8284858: Start of release updates for JDK 20
8286035: Add source 20 and target 20 to javac
8286034: Add SourceVersion.RELEASE_20

Reviewed-by: dholmes, kcr, iris, erikj, jjg, ihse

-------------

PR: https://git.openjdk.org/jdk/pull/8236


From duke at openjdk.java.net  Fri Jun 10 06:40:05 2022
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Fri, 10 Jun 2022 06:40:05 GMT
Subject: RFR: 8283724: Incorrect description for jtreg-failure-handler
 option
In-Reply-To: <h1DNvE0MsYO3NUu0ZyuRPZJJtLNjeyK17QYvgn0huqE=.43f66f4f-fed2-430e-bcb4-7a74079300ab@github.com>
References: <h1DNvE0MsYO3NUu0ZyuRPZJJtLNjeyK17QYvgn0huqE=.43f66f4f-fed2-430e-bcb4-7a74079300ab@github.com>
Message-ID: <fAlwkK3OaG104xkNvb5PKH9C44iLUxdeudL9JFD0brU=.c11c8644-3e21-4b19-be75-b86ab879c97f@github.com>

On Thu, 9 Jun 2022 06:49:15 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

> The description for the jtreg-failure-handler option is incorrect, so I fixed it to describe jtreg-failure-handler option.  
> Would you please review this fix?

I appreciate all reviews. I hope this change is integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/9099


From shade at openjdk.java.net  Fri Jun 10 07:33:11 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 10 Jun 2022 07:33:11 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v4]
In-Reply-To: <zkK7RAg7izSW-Rg0g37Snuj8ucIZ6WnN6WMtgrlbig0=.9836fc74-86e6-423a-b7d7-6ce6136f24cf@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
 <zkK7RAg7izSW-Rg0g37Snuj8ucIZ6WnN6WMtgrlbig0=.9836fc74-86e6-423a-b7d7-6ce6136f24cf@github.com>
Message-ID: <1tumB9d27f6IoTicUyMNbGlYGjomWoQ_nL2R1LgqfFA=.7bcb0c2c-54db-47cf-b471-e46e0da74f87@github.com>

On Thu, 9 Jun 2022 12:57:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> With project Skara, the ability to run a set of sanity build and test jobs on selected platforms was added. This functionality was driven by `.github/workflows/submit.yml`. This file unfortunately lacks any real structure, and contains a lot of code duplication and redundancy. This has made it hard to add functionality, and new platforms to test, and it has made it even harder to debug issues. (This is hard enough as it is, since we have no direct access to the platforms that GHA runs on.)
>> 
>> Since the GHA tests are important for a large subset of the community, we need to do better. 
>> 
>> ## GitHub Actions framework rewrite
>>  
>> This is a complete overhaul of the GHA testing framework. I started out trying to just tease the old `submit.yml` apart, trying to de-duplicate code, but I soon realized a much more thorough rework was needed.
>> 
>> ### Design description
>> 
>> The principle for the new design was to avoid code duplication, and to improve readability of the code. The latter is extra important since the GHA "language" is very limited, needs a lot of quirks and workarounds, and is probably not well known by many OpenJDK developers. I've strived to find useful layers of abstraction to make the expressions as clear as possible.
>> 
>> Unfortunately, the Workflow/Action YAML language is quite limited. There are two ways to avoid duplication, "local composite actions" and "callable workflows". They both have several limitations:
>> 
>>  * "Callable workflows" can only be used in a single redirection. They are (apparently) inlined into the "calling workflow" at run time, and as such, they are present without having to check out the source code. (Which is a lengthy process.)
>> 
>>  * "Local composite actions" can use other actions, but you must start by checking out the repo.
>> 
>> To use the strength of both kinds of sub-modules, I'm using "callable workflows" from `main.yml` to call `build-<platform>.yml` and `test.yml`. It is not allowed to mix "strategies" (that is, the method of automatically creating a test matrix) when calling callable workflows, so I needed to have some amount of duplication in `main.yml` that could have been avoided otherwise.
>> 
>> All the callable workflows need to check out the source code anyway, so there is no real additional cost of using "local composite actions" for abstraction of these workflows. (A bit of a lucky break.) I've created "high level" actions, corresponding to something like a function call. The goal here was both to avoid duplication, and to improve readability of the workflows.
>> 
>> The four `build-<platform>.yml` files are very similar. But in the end of the day, only like 50% of the source code is shared, and the platform specific changes permeate the files. So I decided to keep them separately, since mixing them all into one would have made a mess, due to the lack of proper abstraction mechanisms. But that also mean that if we change platform independent code in building, we need to remember to update it in all four places.
>> 
>> In the strictest sense, this is a "refactoring" in that the functionality should be equal to the old `submit.yml`. The same platforms should build, with the same arguments, and the same tests should run. When I look at the code now, I see lots of potential for improvement here, by rethinking what we do run. But let's save that discussion for the next PR.
>> 
>> There is one major change, though. Windows is no longer running on Cygwin, but on MSYS2. This was not really triggered by the recurring build issues on Cygwin (though that certainly did help me in thinking I made the right choice), but the sheer impossibility of getting Cygwin to behave as a normal unix shell on GHA Windows hosts. I spent countless hours trying to work out limitations, by setting `SHELLOPTS=igncr`, by running `set +x posix` to turn of the POSIX compliance mode that kept turning on by itself and made bash choke on several of our scripts, by playing tricks with the `PATH`, but in the end to no avail. There were no single combination of hacks and workarounds that could get us past the entire chain from configure, to build, to testing. (The old solution user PowerShell instead to get around these limitations.) I'm happy to report that I have had absolutely zero issues with MSYS2 since I made the switch (and understood how to set the PATH properly), and I'm seriously c
 onsidering switching stance to recommend using MSYS2 instead of Cygwin as the primary winenv for building the JDK.
>> 
>> ### Example run
>> 
>> A good example on how a run looks like with the new GHA system is [the run for this PR](https://github.com/magicus/jdk/actions/runs/2454577164).
>> 
>> ### New features
>> 
>> While the primary focus was to convert the old system to a new framework, more accommodating to development, and to wait with further enhancements for the future, I have made a few additional features already in this PR. Most of them are related to needs that arose during development of this PR.
>> 
>> * A build failure summary, similar to the recently added test failure summary, is added when the build step fails
>> 
>> * The test reporting has been extended to all platforms, including Windows
>> 
>> * Test reporting has been improved slightly, and gotten multiple bug fixes
>> 
>> * All artifacts are now available for individual download. This includes:
>> 
>>   * The build bundles, per platform
>>   * The test results, per platform and test suite
>>   * Build failure logs, in case of build failure
>> 
>>   The build bundles have a retention period of 24 h, but the rest uses GitHub's default retention period (currently 90 days). The idea is that you can use GHA to download builds for platforms you might not have access to, but after that, conserving the builds does not make sense. GitHub currently provides free, unlimited storage (within the retention period) for artifacts, so we can afford this.
>> 
>> * The GHA process starts up much faster, which mean that e.g. a build failure on an exotic platform will show up earlier. This will not really affect the overall run time though, since it is bounded by variables such as queuing for workers, and waiting on tests with somewhat arbitrarily run times to finish.
>> 
>> ### Additional changes outside GHA
>> 
>> I also needed to make a few tweaks to the build system to play nice with the new GHA code.
>> 
>> * The build failure summary is now stored in build/$BUILD/make-support/failure-summary.log
>> 
>> * The configure summary now indicates what devkit or sysroot is used, if any
>> 
>> * The --with-sysroot argument is now properly normalized
>> 
>> ### Test failures
>> 
>> A handful of tests, which relies on shell behavior, turned out to fail on Windows when running under MSYS2. I have filed separate bugs, and submitted PRs, to get these fixed:
>> 
>> * https://bugs.openjdk.org/browse/JDK-8287902
>> 
>> * https://bugs.openjdk.org/browse/JDK-8287895
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apparently that was not a legal reference to actions/checkout. Try another way.

This all looks very nice. I have a few inline comments.

The general one is that we need to make sure:
 - jtreg needs to be built from its mainline at a given tag;
 - tests need to pass (I assume you are waiting for test fixes to land first);

.github/actions/get-bootjdk/action.yml line 26:

> 24: #
> 25: 
> 26: name: 'Get BootJDK'

Here and later, polishing: "BootJDK" -> "boot JDK"?

.github/actions/get-bundles/action.yml line 103:

> 101:           jdk_dir="$(cygpath $jdk_dir)"
> 102:           symbols_dir="$(cygpath $symbols_dir)"
> 103:           tests_dir="$(cygpath $tests_dir)"

Here, and maybe later: how safe it is to use Cygwin utilities like `cygpath` in MSYS2 context?

.github/actions/get-jtreg/action.yml line 55:

> 53:         ref: 7903206-build-on-msys2
> 54:         path: jtreg/src
> 55:       if: steps.get-cached-jtreg.outputs.cache-hit != 'true'

Just leaving the comment here so we don't forget to change it to mainline jtreg location before integrating this PR :)

.github/actions/get-msys/action.yml line 26:

> 24: #
> 25: 
> 26: name: 'Get msys'

Here and later, polishing: call it consistently "msys2" or "MSYS2"?

.github/workflows/build-cross-compile.yml line 89:

> 87:           sudo apt-get install gcc-${{ inputs.apt-gcc-version }} g++-${{ inputs.apt-gcc-version }} libxrandr-dev${{ inputs.apt-architecture }} libxtst-dev${{ inputs.apt-architecture }} libcups2-dev${{ inputs.apt-architecture }} libasound2-dev${{ inputs.apt-architecture }}
> 88:           sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-10 100 --slave /usr/bin/g++ g++ /usr/bin/g++-10
> 89:           sudo apt-get install gcc-10-${{ matrix.gnu-arch }}-linux-gnu${{ matrix.gnu-abi}}=10.3.0-1ubuntu1~20.04cross1 g++-10-${{ matrix.gnu-arch }}-linux-gnu${{ matrix.gnu-abi}}=10.3.0-1ubuntu1~20.04cross1

Should `10.3.0-1ubuntu1~20.04cross1` also go into common "var", like `apt-gcc-version` did?

.github/workflows/build-cross-compile.yml line 111:

> 109:           buster
> 110:           sysroot
> 111:           http://httpredir.debian.org/debian/

While we are at it, we can change to `https://` in cases like these...

.github/workflows/main.yml line 138:

> 136:       apt-gcc-version: '10-multilib'
> 137:       apt-architecture: ':i386'
> 138:       apt-add-architecture: 'sudo dpkg --add-architecture i386'

Feels a bit weird to have the entire command line here. I'd expect to see something like `apt-add-architecture: i386`.

make/InitSupport.gmk line 456:

> 454: 	      $(PRINTF) "\n* All command lines available in $(MAKESUPPORT_OUTPUTDIR)/failure-logs.\n" ; \
> 455: 	      $(PRINTF) "=== End of repeated output ===\n" ; \
> 456: 	    )  >> $(MAKESUPPORT_OUTPUTDIR)/failure-summary.log  \

Changes in this file look like a generic build system improvement, so maybe it should be forked out as separate issue? In case this part of build system change regresses something, I would be odd to track it down to GHA workflow improvement.

-------------

PR: https://git.openjdk.org/jdk/pull/9063


From shade at openjdk.java.net  Fri Jun 10 07:33:12 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 10 Jun 2022 07:33:12 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v4]
In-Reply-To: <1tumB9d27f6IoTicUyMNbGlYGjomWoQ_nL2R1LgqfFA=.7bcb0c2c-54db-47cf-b471-e46e0da74f87@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
 <zkK7RAg7izSW-Rg0g37Snuj8ucIZ6WnN6WMtgrlbig0=.9836fc74-86e6-423a-b7d7-6ce6136f24cf@github.com>
 <1tumB9d27f6IoTicUyMNbGlYGjomWoQ_nL2R1LgqfFA=.7bcb0c2c-54db-47cf-b471-e46e0da74f87@github.com>
Message-ID: <FFCe_9UR_89GHWX61o31TGP3pS94RmNUZPpb_NRpKrM=.6c819f17-c24a-481f-bb76-073d72607cb4@github.com>

On Fri, 10 Jun 2022 07:13:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apparently that was not a legal reference to actions/checkout. Try another way.
>
> .github/workflows/build-cross-compile.yml line 89:
> 
>> 87:           sudo apt-get install gcc-${{ inputs.apt-gcc-version }} g++-${{ inputs.apt-gcc-version }} libxrandr-dev${{ inputs.apt-architecture }} libxtst-dev${{ inputs.apt-architecture }} libcups2-dev${{ inputs.apt-architecture }} libasound2-dev${{ inputs.apt-architecture }}
>> 88:           sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-10 100 --slave /usr/bin/g++ g++ /usr/bin/g++-10
>> 89:           sudo apt-get install gcc-10-${{ matrix.gnu-arch }}-linux-gnu${{ matrix.gnu-abi}}=10.3.0-1ubuntu1~20.04cross1 g++-10-${{ matrix.gnu-arch }}-linux-gnu${{ matrix.gnu-abi}}=10.3.0-1ubuntu1~20.04cross1
> 
> Should `10.3.0-1ubuntu1~20.04cross1` also go into common "var", like `apt-gcc-version` did?

Also, I think we can speed up this part by merging two `apt-get install` invocation lines together. It was separate before, because it was two steps, unnecessary now.

-------------

PR: https://git.openjdk.org/jdk/pull/9063


From duke at openjdk.java.net  Fri Jun 10 09:23:06 2022
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Fri, 10 Jun 2022 09:23:06 GMT
Subject: Integrated: 8283724: Incorrect description for jtreg-failure-handler
 option
In-Reply-To: <h1DNvE0MsYO3NUu0ZyuRPZJJtLNjeyK17QYvgn0huqE=.43f66f4f-fed2-430e-bcb4-7a74079300ab@github.com>
References: <h1DNvE0MsYO3NUu0ZyuRPZJJtLNjeyK17QYvgn0huqE=.43f66f4f-fed2-430e-bcb4-7a74079300ab@github.com>
Message-ID: <S4FgfQNJMDPP9u79PCpQEQBaQinA7C5qHV2TTWcG9gI=.5b30b509-ac0c-4e82-9f06-80c87480e00c@github.com>

On Thu, 9 Jun 2022 06:49:15 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

> The description for the jtreg-failure-handler option is incorrect, so I fixed it to describe jtreg-failure-handler option.  
> Would you please review this fix?

This pull request has now been integrated.

Changeset: 09015488
Author:    KIRIYAMA Takuya <kiriyama.takuya at fujitsu.com>
Committer: Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0901548833a0125f15fede64bc2e7dbe84fed42d
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8283724: Incorrect description for jtreg-failure-handler option

Reviewed-by: erikj, ihse

-------------

PR: https://git.openjdk.org/jdk/pull/9099


From ihse at openjdk.java.net  Fri Jun 10 09:34:53 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 10 Jun 2022 09:34:53 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v5]
In-Reply-To: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
Message-ID: <6vW3YQ0zp1nh_VRNxyEmGEHP2L7OCRHU4qol-UkVTuc=.1315ca8e-230b-470b-ab12-e5e5ce7440dd@github.com>

> With project Skara, the ability to run a set of sanity build and test jobs on selected platforms was added. This functionality was driven by `.github/workflows/submit.yml`. This file unfortunately lacks any real structure, and contains a lot of code duplication and redundancy. This has made it hard to add functionality, and new platforms to test, and it has made it even harder to debug issues. (This is hard enough as it is, since we have no direct access to the platforms that GHA runs on.)
> 
> Since the GHA tests are important for a large subset of the community, we need to do better. 
> 
> ## GitHub Actions framework rewrite
>  
> This is a complete overhaul of the GHA testing framework. I started out trying to just tease the old `submit.yml` apart, trying to de-duplicate code, but I soon realized a much more thorough rework was needed.
> 
> ### Design description
> 
> The principle for the new design was to avoid code duplication, and to improve readability of the code. The latter is extra important since the GHA "language" is very limited, needs a lot of quirks and workarounds, and is probably not well known by many OpenJDK developers. I've strived to find useful layers of abstraction to make the expressions as clear as possible.
> 
> Unfortunately, the Workflow/Action YAML language is quite limited. There are two ways to avoid duplication, "local composite actions" and "callable workflows". They both have several limitations:
> 
>  * "Callable workflows" can only be used in a single redirection. They are (apparently) inlined into the "calling workflow" at run time, and as such, they are present without having to check out the source code. (Which is a lengthy process.)
> 
>  * "Local composite actions" can use other actions, but you must start by checking out the repo.
> 
> To use the strength of both kinds of sub-modules, I'm using "callable workflows" from `main.yml` to call `build-<platform>.yml` and `test.yml`. It is not allowed to mix "strategies" (that is, the method of automatically creating a test matrix) when calling callable workflows, so I needed to have some amount of duplication in `main.yml` that could have been avoided otherwise.
> 
> All the callable workflows need to check out the source code anyway, so there is no real additional cost of using "local composite actions" for abstraction of these workflows. (A bit of a lucky break.) I've created "high level" actions, corresponding to something like a function call. The goal here was both to avoid duplication, and to improve readability of the workflows.
> 
> The four `build-<platform>.yml` files are very similar. But in the end of the day, only like 50% of the source code is shared, and the platform specific changes permeate the files. So I decided to keep them separately, since mixing them all into one would have made a mess, due to the lack of proper abstraction mechanisms. But that also mean that if we change platform independent code in building, we need to remember to update it in all four places.
> 
> In the strictest sense, this is a "refactoring" in that the functionality should be equal to the old `submit.yml`. The same platforms should build, with the same arguments, and the same tests should run. When I look at the code now, I see lots of potential for improvement here, by rethinking what we do run. But let's save that discussion for the next PR.
> 
> There is one major change, though. Windows is no longer running on Cygwin, but on MSYS2. This was not really triggered by the recurring build issues on Cygwin (though that certainly did help me in thinking I made the right choice), but the sheer impossibility of getting Cygwin to behave as a normal unix shell on GHA Windows hosts. I spent countless hours trying to work out limitations, by setting `SHELLOPTS=igncr`, by running `set +x posix` to turn of the POSIX compliance mode that kept turning on by itself and made bash choke on several of our scripts, by playing tricks with the `PATH`, but in the end to no avail. There were no single combination of hacks and workarounds that could get us past the entire chain from configure, to build, to testing. (The old solution user PowerShell instead to get around these limitations.) I'm happy to report that I have had absolutely zero issues with MSYS2 since I made the switch (and understood how to set the PATH properly), and I'm seriously co
 nsidering switching stance to recommend using MSYS2 instead of Cygwin as the primary winenv for building the JDK.
> 
> ### Example run
> 
> A good example on how a run looks like with the new GHA system is [the run for this PR](https://github.com/magicus/jdk/actions/runs/2454577164).
> 
> ### New features
> 
> While the primary focus was to convert the old system to a new framework, more accommodating to development, and to wait with further enhancements for the future, I have made a few additional features already in this PR. Most of them are related to needs that arose during development of this PR.
> 
> * A build failure summary, similar to the recently added test failure summary, is added when the build step fails
> 
> * The test reporting has been extended to all platforms, including Windows
> 
> * Test reporting has been improved slightly, and gotten multiple bug fixes
> 
> * All artifacts are now available for individual download. This includes:
> 
>   * The build bundles, per platform
>   * The test results, per platform and test suite
>   * Build failure logs, in case of build failure
> 
>   The build bundles have a retention period of 24 h, but the rest uses GitHub's default retention period (currently 90 days). The idea is that you can use GHA to download builds for platforms you might not have access to, but after that, conserving the builds does not make sense. GitHub currently provides free, unlimited storage (within the retention period) for artifacts, so we can afford this.
> 
> * The GHA process starts up much faster, which mean that e.g. a build failure on an exotic platform will show up earlier. This will not really affect the overall run time though, since it is bounded by variables such as queuing for workers, and waiting on tests with somewhat arbitrarily run times to finish.
> 
> ### Additional changes outside GHA
> 
> I also needed to make a few tweaks to the build system to play nice with the new GHA code.
> 
> * The build failure summary is now stored in build/$BUILD/make-support/failure-summary.log
> 
> * The configure summary now indicates what devkit or sysroot is used, if any
> 
> * The --with-sysroot argument is now properly normalized
> 
> ### Test failures
> 
> A handful of tests, which relies on shell behavior, turned out to fail on Windows when running under MSYS2. I have filed separate bugs, and submitted PRs, to get these fixed:
> 
> * https://bugs.openjdk.org/browse/JDK-8287902
> 
> * https://bugs.openjdk.org/browse/JDK-8287895

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix test failure regex

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9063/files
  - new: https://git.openjdk.org/jdk/pull/9063/files/9cbf5875..8ce043c1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9063&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9063&range=03-04

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9063.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9063/head:pull/9063

PR: https://git.openjdk.org/jdk/pull/9063


From ihse at openjdk.java.net  Fri Jun 10 09:39:04 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 10 Jun 2022 09:39:04 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v4]
In-Reply-To: <1tumB9d27f6IoTicUyMNbGlYGjomWoQ_nL2R1LgqfFA=.7bcb0c2c-54db-47cf-b471-e46e0da74f87@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
 <zkK7RAg7izSW-Rg0g37Snuj8ucIZ6WnN6WMtgrlbig0=.9836fc74-86e6-423a-b7d7-6ce6136f24cf@github.com>
 <1tumB9d27f6IoTicUyMNbGlYGjomWoQ_nL2R1LgqfFA=.7bcb0c2c-54db-47cf-b471-e46e0da74f87@github.com>
Message-ID: <1Th3digBmcMQ0R_DEy98ofNH6ugVXYjHQ2F5Vr4GVVk=.ab63e0cd-f0e3-467f-aef3-11139761bcce@github.com>

On Fri, 10 Jun 2022 07:07:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apparently that was not a legal reference to actions/checkout. Try another way.
>
> .github/actions/get-bundles/action.yml line 103:
> 
>> 101:           jdk_dir="$(cygpath $jdk_dir)"
>> 102:           symbols_dir="$(cygpath $symbols_dir)"
>> 103:           tests_dir="$(cygpath $tests_dir)"
> 
> Here, and maybe later: how safe it is to use Cygwin utilities like `cygpath` in MSYS2 context?

Perfectly safe and officially supported. MSYS2 is related to MSYS(1) by name only, it is in reality a fork/clone of Cygwin. The principal difference is that MSYS2 is more pragmatic when it comes to choosing between perfect POSIX compliance, or have tooling that is helpful in creating a POSIX-like build environment on Windows.

-------------

PR: https://git.openjdk.org/jdk/pull/9063


From ihse at openjdk.java.net  Fri Jun 10 09:48:17 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 10 Jun 2022 09:48:17 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v4]
In-Reply-To: <1tumB9d27f6IoTicUyMNbGlYGjomWoQ_nL2R1LgqfFA=.7bcb0c2c-54db-47cf-b471-e46e0da74f87@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
 <zkK7RAg7izSW-Rg0g37Snuj8ucIZ6WnN6WMtgrlbig0=.9836fc74-86e6-423a-b7d7-6ce6136f24cf@github.com>
 <1tumB9d27f6IoTicUyMNbGlYGjomWoQ_nL2R1LgqfFA=.7bcb0c2c-54db-47cf-b471-e46e0da74f87@github.com>
Message-ID: <YUVUu2zw5RzKcI74xvPC5baQYIw9VBn-ufag3sPnOzY=.2c6e9b2e-13d7-40d1-aa68-6a8508cfd8ba@github.com>

On Fri, 10 Jun 2022 07:09:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apparently that was not a legal reference to actions/checkout. Try another way.
>
> .github/actions/get-bootjdk/action.yml line 26:
> 
>> 24: #
>> 25: 
>> 26: name: 'Get BootJDK'
> 
> Here and later, polishing: "BootJDK" -> "boot JDK"?

I think we've mostly been using "BootJDK" as a specialized term in the build system, but we've not been very consistent about it: 

ihse at mercurius:~/git/jdk-ALT/open/make$ gr -i "Boot JDK" | wc
      61     673    5606
ihse at mercurius:~/git/jdk-ALT/open/make$ gr -i BootJDK | wc
      79     298    5947


but I can switch it out to `Boot JDK` if that makes you happier.

> .github/actions/get-msys/action.yml line 26:
> 
>> 24: #
>> 25: 
>> 26: name: 'Get msys'
> 
> Here and later, polishing: call it consistently "msys2" or "MSYS2"?

The official name is `MSYS2` so I've tried to use that, unless lower case were needed/preferred to keep things consistent. I'll check over the code to see what places I've missed. (I agree that in this description it should definitely be MSYS2).

-------------

PR: https://git.openjdk.org/jdk/pull/9063


From ihse at openjdk.java.net  Fri Jun 10 09:48:19 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 10 Jun 2022 09:48:19 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v4]
In-Reply-To: <FFCe_9UR_89GHWX61o31TGP3pS94RmNUZPpb_NRpKrM=.6c819f17-c24a-481f-bb76-073d72607cb4@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
 <zkK7RAg7izSW-Rg0g37Snuj8ucIZ6WnN6WMtgrlbig0=.9836fc74-86e6-423a-b7d7-6ce6136f24cf@github.com>
 <1tumB9d27f6IoTicUyMNbGlYGjomWoQ_nL2R1LgqfFA=.7bcb0c2c-54db-47cf-b471-e46e0da74f87@github.com>
 <FFCe_9UR_89GHWX61o31TGP3pS94RmNUZPpb_NRpKrM=.6c819f17-c24a-481f-bb76-073d72607cb4@github.com>
Message-ID: <RL2hwIS7h0kz4LR6ztL0E9FEQFC9aLhZCwUd2UNIpFc=.08ff076f-5873-4b9b-8666-dfd991702743@github.com>

On Fri, 10 Jun 2022 07:14:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> .github/workflows/build-cross-compile.yml line 89:
>> 
>>> 87:           sudo apt-get install gcc-${{ inputs.apt-gcc-version }} g++-${{ inputs.apt-gcc-version }} libxrandr-dev${{ inputs.apt-architecture }} libxtst-dev${{ inputs.apt-architecture }} libcups2-dev${{ inputs.apt-architecture }} libasound2-dev${{ inputs.apt-architecture }}
>>> 88:           sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-10 100 --slave /usr/bin/g++ g++ /usr/bin/g++-10
>>> 89:           sudo apt-get install gcc-10-${{ matrix.gnu-arch }}-linux-gnu${{ matrix.gnu-abi}}=10.3.0-1ubuntu1~20.04cross1 g++-10-${{ matrix.gnu-arch }}-linux-gnu${{ matrix.gnu-abi}}=10.3.0-1ubuntu1~20.04cross1
>> 
>> Should `10.3.0-1ubuntu1~20.04cross1` also go into common "var", like `apt-gcc-version` did?
>
> Also, I think we can speed up this part by merging two `apt-get install` invocation lines together. It was separate before, because it was two steps, unnecessary now.

Ideally, all version information should be centralized somewhere. I plan to take a second round on this code when it's been pushed to try to figure out the best way to achieve this. (Possibly in github-versions.conf, possibly in main.yml, depending on what makes the most sense given the GHA limitations). 

But I can extract out the cross-compilation suffix already in this PR, yes.

-------------

PR: https://git.openjdk.org/jdk/pull/9063


From ihse at openjdk.java.net  Fri Jun 10 09:48:20 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 10 Jun 2022 09:48:20 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v4]
In-Reply-To: <RL2hwIS7h0kz4LR6ztL0E9FEQFC9aLhZCwUd2UNIpFc=.08ff076f-5873-4b9b-8666-dfd991702743@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
 <zkK7RAg7izSW-Rg0g37Snuj8ucIZ6WnN6WMtgrlbig0=.9836fc74-86e6-423a-b7d7-6ce6136f24cf@github.com>
 <1tumB9d27f6IoTicUyMNbGlYGjomWoQ_nL2R1LgqfFA=.7bcb0c2c-54db-47cf-b471-e46e0da74f87@github.com>
 <FFCe_9UR_89GHWX61o31TGP3pS94RmNUZPpb_NRpKrM=.6c819f17-c24a-481f-bb76-073d72607cb4@github.com>
 <RL2hwIS7h0kz4LR6ztL0E9FEQFC9aLhZCwUd2UNIpFc=.08ff076f-5873-4b9b-8666-dfd991702743@github.com>
Message-ID: <4zwYTrlQeKNGUCa59omO_j9PA8Zopoz4jeBmMnNz8RQ=.2a769d01-3090-4d5e-8207-0c0704a0c31b@github.com>

On Fri, 10 Jun 2022 09:43:47 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Also, I think we can speed up this part by merging two `apt-get install` invocation lines together. It was separate before, because it was two steps, unnecessary now.
>
> Ideally, all version information should be centralized somewhere. I plan to take a second round on this code when it's been pushed to try to figure out the best way to achieve this. (Possibly in github-versions.conf, possibly in main.yml, depending on what makes the most sense given the GHA limitations). 
> 
> But I can extract out the cross-compilation suffix already in this PR, yes.

I can merge the two `apt-get install` lines, if you say that it is not necessary to call `update-alternatives` before the second install line. (But does it really speed things up?)

-------------

PR: https://git.openjdk.org/jdk/pull/9063


From ihse at openjdk.java.net  Fri Jun 10 09:53:03 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 10 Jun 2022 09:53:03 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v4]
In-Reply-To: <1tumB9d27f6IoTicUyMNbGlYGjomWoQ_nL2R1LgqfFA=.7bcb0c2c-54db-47cf-b471-e46e0da74f87@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
 <zkK7RAg7izSW-Rg0g37Snuj8ucIZ6WnN6WMtgrlbig0=.9836fc74-86e6-423a-b7d7-6ce6136f24cf@github.com>
 <1tumB9d27f6IoTicUyMNbGlYGjomWoQ_nL2R1LgqfFA=.7bcb0c2c-54db-47cf-b471-e46e0da74f87@github.com>
Message-ID: <msGZIh04Yibpl6G2WPTESAxD2WiDc7Cw8k5_BHOmhP4=.f2559f42-dcf7-4902-ae37-72006ab88d02@github.com>

On Fri, 10 Jun 2022 07:18:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apparently that was not a legal reference to actions/checkout. Try another way.
>
> .github/workflows/main.yml line 138:
> 
>> 136:       apt-gcc-version: '10-multilib'
>> 137:       apt-architecture: ':i386'
>> 138:       apt-add-architecture: 'sudo dpkg --add-architecture i386'
> 
> Feels a bit weird to have the entire command line here. I'd expect to see something like `apt-add-architecture: i386`.

If I do that, there need to be some kind of if statement in the called workflow, since if that input argument is left out, we'd get a command line like `sudo dpkg --add-architecture` which I assume is illegal syntax (or, possibly worse, does something other than a no-op).

I think there can be room for additional improvement in especially the "special" linux builds, but I had to draw the line somewhere, to be able to finish this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/9063


From ihse at openjdk.java.net  Fri Jun 10 10:03:32 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 10 Jun 2022 10:03:32 GMT
Subject: RFR: 8288195: Prepare build system for GHA changes
Message-ID: <bJMLzcqYQbOzUii7M7t3s5zDs6dc1-eXJpCQBRrqjTI=.1a8f1ff5-aec4-4b0c-a628-102ac5813a81@github.com>

A few changes to the build system is needed for the GHA rewrite ([JDK-8287906](https://bugs.openjdk.org/browse/JDK-8287906)).

-------------

Commit messages:
 - 8288195: Prepare build system for GHA changes

Changes: https://git.openjdk.org/jdk/pull/9122/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9122&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288195
  Stats: 28 lines in 3 files changed: 13 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/9122.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9122/head:pull/9122

PR: https://git.openjdk.org/jdk/pull/9122


From shade at openjdk.java.net  Fri Jun 10 10:10:02 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 10 Jun 2022 10:10:02 GMT
Subject: RFR: 8288195: Prepare build system for GHA changes
In-Reply-To: <bJMLzcqYQbOzUii7M7t3s5zDs6dc1-eXJpCQBRrqjTI=.1a8f1ff5-aec4-4b0c-a628-102ac5813a81@github.com>
References: <bJMLzcqYQbOzUii7M7t3s5zDs6dc1-eXJpCQBRrqjTI=.1a8f1ff5-aec4-4b0c-a628-102ac5813a81@github.com>
Message-ID: <Pg9OxISxNCQyyinpDucBthirBCzxu7GNuqOk1S26c0c=.75646308-5075-4fbb-b675-4bb1ffa4f431@github.com>

On Fri, 10 Jun 2022 09:54:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A few changes to the build system is needed for the GHA rewrite ([JDK-8287906](https://bugs.openjdk.org/browse/JDK-8287906)).

Looks fine!

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9122


From shade at openjdk.java.net  Fri Jun 10 11:28:16 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 10 Jun 2022 11:28:16 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v4]
In-Reply-To: <YUVUu2zw5RzKcI74xvPC5baQYIw9VBn-ufag3sPnOzY=.2c6e9b2e-13d7-40d1-aa68-6a8508cfd8ba@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
 <zkK7RAg7izSW-Rg0g37Snuj8ucIZ6WnN6WMtgrlbig0=.9836fc74-86e6-423a-b7d7-6ce6136f24cf@github.com>
 <1tumB9d27f6IoTicUyMNbGlYGjomWoQ_nL2R1LgqfFA=.7bcb0c2c-54db-47cf-b471-e46e0da74f87@github.com>
 <YUVUu2zw5RzKcI74xvPC5baQYIw9VBn-ufag3sPnOzY=.2c6e9b2e-13d7-40d1-aa68-6a8508cfd8ba@github.com>
Message-ID: <FjW215bUfcBIzyJZS0aaA6HwrpwUpfKGa99XOPsMlXg=.adfd2558-5b41-41f0-af15-d2079b9a0e99@github.com>

On Fri, 10 Jun 2022 09:39:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> .github/actions/get-bootjdk/action.yml line 26:
>> 
>>> 24: #
>>> 25: 
>>> 26: name: 'Get BootJDK'
>> 
>> Here and later, polishing: "BootJDK" -> "boot JDK"?
>
> I think we've mostly been using "BootJDK" as a specialized term in the build system, but we've not been very consistent about it: 
> 
> ihse at mercurius:~/git/jdk-ALT/open/make$ gr -i "Boot JDK" | wc
>       61     673    5606
> ihse at mercurius:~/git/jdk-ALT/open/make$ gr -i BootJDK | wc
>       79     298    5947
> 
> 
> but I can switch it out to `Boot JDK` if that makes you happier.

Nevermind then.

>> .github/workflows/main.yml line 138:
>> 
>>> 136:       apt-gcc-version: '10-multilib'
>>> 137:       apt-architecture: ':i386'
>>> 138:       apt-add-architecture: 'sudo dpkg --add-architecture i386'
>> 
>> Feels a bit weird to have the entire command line here. I'd expect to see something like `apt-add-architecture: i386`.
>
> If I do that, there need to be some kind of if statement in the called workflow, since if that input argument is left out, we'd get a command line like `sudo dpkg --add-architecture` which I assume is illegal syntax (or, possibly worse, does something other than a no-op).
> 
> I think there can be room for additional improvement in especially the "special" linux builds, but I had to draw the line somewhere, to be able to finish this PR.

I think you can make a conditionalized step that runs in case the value is not empty, and skip the step otherwise. If that is hard, it can be done in the followup, sure.

-------------

PR: https://git.openjdk.org/jdk/pull/9063


From shade at openjdk.java.net  Fri Jun 10 11:28:17 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 10 Jun 2022 11:28:17 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v4]
In-Reply-To: <4zwYTrlQeKNGUCa59omO_j9PA8Zopoz4jeBmMnNz8RQ=.2a769d01-3090-4d5e-8207-0c0704a0c31b@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
 <zkK7RAg7izSW-Rg0g37Snuj8ucIZ6WnN6WMtgrlbig0=.9836fc74-86e6-423a-b7d7-6ce6136f24cf@github.com>
 <1tumB9d27f6IoTicUyMNbGlYGjomWoQ_nL2R1LgqfFA=.7bcb0c2c-54db-47cf-b471-e46e0da74f87@github.com>
 <FFCe_9UR_89GHWX61o31TGP3pS94RmNUZPpb_NRpKrM=.6c819f17-c24a-481f-bb76-073d72607cb4@github.com>
 <RL2hwIS7h0kz4LR6ztL0E9FEQFC9aLhZCwUd2UNIpFc=.08ff076f-5873-4b9b-8666-dfd991702743@github.com>
 <4zwYTrlQeKNGUCa59omO_j9PA8Zopoz4jeBmMnNz8RQ=.2a769d01-3090-4d5e-8207-0c0704a0c31b@github.com>
Message-ID: <Ke7yZnTBMWqHvwU3zQ-AevoMX58kYv8HSSIn3o7Waow=.6cfdf5bb-09d2-4d37-ae01-ad3125cb2b10@github.com>

On Fri, 10 Jun 2022 09:45:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> (But does it really speed things up?)

Yes, I think it does: `apt` would read the package database once, and do the post-install actions once. `update-alternatives` does not have to happen between those two lines.

-------------

PR: https://git.openjdk.org/jdk/pull/9063


From erikj at openjdk.java.net  Fri Jun 10 11:34:08 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 10 Jun 2022 11:34:08 GMT
Subject: RFR: 8288195: Prepare build system for GHA changes
In-Reply-To: <bJMLzcqYQbOzUii7M7t3s5zDs6dc1-eXJpCQBRrqjTI=.1a8f1ff5-aec4-4b0c-a628-102ac5813a81@github.com>
References: <bJMLzcqYQbOzUii7M7t3s5zDs6dc1-eXJpCQBRrqjTI=.1a8f1ff5-aec4-4b0c-a628-102ac5813a81@github.com>
Message-ID: <efjUlO5cO019XdyX1Tad9unX7O-7n9NTnXssnAwncjM=.aee7295a-273d-498f-af69-da46adadb1ee@github.com>

On Fri, 10 Jun 2022 09:54:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A few changes to the build system is needed for the GHA rewrite ([JDK-8287906](https://bugs.openjdk.org/browse/JDK-8287906)).

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9122


From jjg at openjdk.java.net  Fri Jun 10 15:10:05 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 10 Jun 2022 15:10:05 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v5]
In-Reply-To: <6vW3YQ0zp1nh_VRNxyEmGEHP2L7OCRHU4qol-UkVTuc=.1315ca8e-230b-470b-ab12-e5e5ce7440dd@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
 <6vW3YQ0zp1nh_VRNxyEmGEHP2L7OCRHU4qol-UkVTuc=.1315ca8e-230b-470b-ab12-e5e5ce7440dd@github.com>
Message-ID: <w33ZPssXAN1gVgBEbkimzAhkvdcQ5GNoYO1f75jw8bc=.4f3ca8a3-7e0a-420c-a30a-ae8e8f416d71@github.com>

On Fri, 10 Jun 2022 09:34:53 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> With project Skara, the ability to run a set of sanity build and test jobs on selected platforms was added. This functionality was driven by `.github/workflows/submit.yml`. This file unfortunately lacks any real structure, and contains a lot of code duplication and redundancy. This has made it hard to add functionality, and new platforms to test, and it has made it even harder to debug issues. (This is hard enough as it is, since we have no direct access to the platforms that GHA runs on.)
>> 
>> Since the GHA tests are important for a large subset of the community, we need to do better. 
>> 
>> ## GitHub Actions framework rewrite
>>  
>> This is a complete overhaul of the GHA testing framework. I started out trying to just tease the old `submit.yml` apart, trying to de-duplicate code, but I soon realized a much more thorough rework was needed.
>> 
>> ### Design description
>> 
>> The principle for the new design was to avoid code duplication, and to improve readability of the code. The latter is extra important since the GHA "language" is very limited, needs a lot of quirks and workarounds, and is probably not well known by many OpenJDK developers. I've strived to find useful layers of abstraction to make the expressions as clear as possible.
>> 
>> Unfortunately, the Workflow/Action YAML language is quite limited. There are two ways to avoid duplication, "local composite actions" and "callable workflows". They both have several limitations:
>> 
>>  * "Callable workflows" can only be used in a single redirection. They are (apparently) inlined into the "calling workflow" at run time, and as such, they are present without having to check out the source code. (Which is a lengthy process.)
>> 
>>  * "Local composite actions" can use other actions, but you must start by checking out the repo.
>> 
>> To use the strength of both kinds of sub-modules, I'm using "callable workflows" from `main.yml` to call `build-<platform>.yml` and `test.yml`. It is not allowed to mix "strategies" (that is, the method of automatically creating a test matrix) when calling callable workflows, so I needed to have some amount of duplication in `main.yml` that could have been avoided otherwise.
>> 
>> All the callable workflows need to check out the source code anyway, so there is no real additional cost of using "local composite actions" for abstraction of these workflows. (A bit of a lucky break.) I've created "high level" actions, corresponding to something like a function call. The goal here was both to avoid duplication, and to improve readability of the workflows.
>> 
>> The four `build-<platform>.yml` files are very similar. But in the end of the day, only like 50% of the source code is shared, and the platform specific changes permeate the files. So I decided to keep them separately, since mixing them all into one would have made a mess, due to the lack of proper abstraction mechanisms. But that also mean that if we change platform independent code in building, we need to remember to update it in all four places.
>> 
>> In the strictest sense, this is a "refactoring" in that the functionality should be equal to the old `submit.yml`. The same platforms should build, with the same arguments, and the same tests should run. When I look at the code now, I see lots of potential for improvement here, by rethinking what we do run. But let's save that discussion for the next PR.
>> 
>> There is one major change, though. Windows is no longer running on Cygwin, but on MSYS2. This was not really triggered by the recurring build issues on Cygwin (though that certainly did help me in thinking I made the right choice), but the sheer impossibility of getting Cygwin to behave as a normal unix shell on GHA Windows hosts. I spent countless hours trying to work out limitations, by setting `SHELLOPTS=igncr`, by running `set +x posix` to turn of the POSIX compliance mode that kept turning on by itself and made bash choke on several of our scripts, by playing tricks with the `PATH`, but in the end to no avail. There were no single combination of hacks and workarounds that could get us past the entire chain from configure, to build, to testing. (The old solution user PowerShell instead to get around these limitations.) I'm happy to report that I have had absolutely zero issues with MSYS2 since I made the switch (and understood how to set the PATH properly), and I'm seriously c
 onsidering switching stance to recommend using MSYS2 instead of Cygwin as the primary winenv for building the JDK.
>> 
>> ### Example run
>> 
>> A good example on how a run looks like with the new GHA system is [the run for this PR](https://github.com/magicus/jdk/actions/runs/2454577164).
>> 
>> ### New features
>> 
>> While the primary focus was to convert the old system to a new framework, more accommodating to development, and to wait with further enhancements for the future, I have made a few additional features already in this PR. Most of them are related to needs that arose during development of this PR.
>> 
>> * A build failure summary, similar to the recently added test failure summary, is added when the build step fails
>> 
>> * The test reporting has been extended to all platforms, including Windows
>> 
>> * Test reporting has been improved slightly, and gotten multiple bug fixes
>> 
>> * All artifacts are now available for individual download. This includes:
>> 
>>   * The build bundles, per platform
>>   * The test results, per platform and test suite
>>   * Build failure logs, in case of build failure
>> 
>>   The build bundles have a retention period of 24 h, but the rest uses GitHub's default retention period (currently 90 days). The idea is that you can use GHA to download builds for platforms you might not have access to, but after that, conserving the builds does not make sense. GitHub currently provides free, unlimited storage (within the retention period) for artifacts, so we can afford this.
>> 
>> * The GHA process starts up much faster, which mean that e.g. a build failure on an exotic platform will show up earlier. This will not really affect the overall run time though, since it is bounded by variables such as queuing for workers, and waiting on tests with somewhat arbitrarily run times to finish.
>> 
>> ### Additional changes outside GHA
>> 
>> I also needed to make a few tweaks to the build system to play nice with the new GHA code.
>> 
>> * The build failure summary is now stored in build/$BUILD/make-support/failure-summary.log
>> 
>> * The configure summary now indicates what devkit or sysroot is used, if any
>> 
>> * The --with-sysroot argument is now properly normalized
>> 
>> ### Test failures
>> 
>> A handful of tests, which relies on shell behavior, turned out to fail on Windows when running under MSYS2. I have filed separate bugs, and submitted PRs, to get these fixed:
>> 
>> * https://bugs.openjdk.org/browse/JDK-8287902
>> 
>> * https://bugs.openjdk.org/browse/JDK-8287895
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test failure regex

The jtreg changes to build with MSYS2 should now be available in the main jtreg repo.

-------------

PR: https://git.openjdk.org/jdk/pull/9063


From aivanov at openjdk.java.net  Fri Jun 10 17:20:30 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 10 Jun 2022 17:20:30 GMT
Subject: RFR: 8288114: Update JIRA link in vcs.xml
Message-ID: <kUYuV5md8sfEcVrehSWXg2g9ddAyK8Z-__C1eGv6KiY=.93b555b6-102d-4b19-a617-c775c4fa06e1@github.com>

Update the link to JBS in `vcs.xml` template to https://bugs.openjdk.org/

It will affect newly generated project files only.  
Edit `vcs.xml` manually or in UI to update in existing projects.

-------------

Commit messages:
 - 8288114: Update JIRA link in vcs.xml

Changes: https://git.openjdk.org/jdk/pull/9130/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9130&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288114
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9130.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9130/head:pull/9130

PR: https://git.openjdk.org/jdk/pull/9130


From ihse at openjdk.java.net  Fri Jun 10 19:34:17 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 10 Jun 2022 19:34:17 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v4]
In-Reply-To: <1tumB9d27f6IoTicUyMNbGlYGjomWoQ_nL2R1LgqfFA=.7bcb0c2c-54db-47cf-b471-e46e0da74f87@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
 <zkK7RAg7izSW-Rg0g37Snuj8ucIZ6WnN6WMtgrlbig0=.9836fc74-86e6-423a-b7d7-6ce6136f24cf@github.com>
 <1tumB9d27f6IoTicUyMNbGlYGjomWoQ_nL2R1LgqfFA=.7bcb0c2c-54db-47cf-b471-e46e0da74f87@github.com>
Message-ID: <GxpDIt5jlKn3O9B2bkDk37NleZKgOtAgc9Tduc8j9cQ=.7f787067-1368-4980-b3b2-30f0ea97cd88@github.com>

On Fri, 10 Jun 2022 07:23:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apparently that was not a legal reference to actions/checkout. Try another way.
>
> make/InitSupport.gmk line 456:
> 
>> 454: 	      $(PRINTF) "\n* All command lines available in $(MAKESUPPORT_OUTPUTDIR)/failure-logs.\n" ; \
>> 455: 	      $(PRINTF) "=== End of repeated output ===\n" ; \
>> 456: 	    )  >> $(MAKESUPPORT_OUTPUTDIR)/failure-summary.log  \
> 
> Changes in this file look like a generic build system improvement, so maybe it should be forked out as separate issue? In case this part of build system change regresses something, I would be odd to track it down to GHA workflow improvement.

Integrated as JDK-8288195.

-------------

PR: https://git.openjdk.org/jdk/pull/9063


From ihse at openjdk.java.net  Fri Jun 10 19:35:01 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 10 Jun 2022 19:35:01 GMT
Subject: Integrated: 8288195: Prepare build system for GHA changes
In-Reply-To: <bJMLzcqYQbOzUii7M7t3s5zDs6dc1-eXJpCQBRrqjTI=.1a8f1ff5-aec4-4b0c-a628-102ac5813a81@github.com>
References: <bJMLzcqYQbOzUii7M7t3s5zDs6dc1-eXJpCQBRrqjTI=.1a8f1ff5-aec4-4b0c-a628-102ac5813a81@github.com>
Message-ID: <eVflGEPFeQTJRSLITjRzMs4fcsGY04CToU2YoUAOTpo=.4e103f73-dd9f-44d0-81c8-2890e4aa5310@github.com>

On Fri, 10 Jun 2022 09:54:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A few changes to the build system is needed for the GHA rewrite ([JDK-8287906](https://bugs.openjdk.org/browse/JDK-8287906)).

This pull request has now been integrated.

Changeset: d0c8ff8f
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d0c8ff8fdfe86a4251290d4c1c7b3dbd4cfaf018
Stats:     28 lines in 3 files changed: 13 ins; 0 del; 15 mod

8288195: Prepare build system for GHA changes

Reviewed-by: shade, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/9122


From ihse at openjdk.java.net  Fri Jun 10 19:46:00 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 10 Jun 2022 19:46:00 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v6]
In-Reply-To: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
Message-ID: <MqFVGwACO2fYFMV2Beo-XO3MK5BNfk2cKPQfiEKRUd8=.63d525cd-b950-4480-8b67-aefbe5b28973@github.com>

> With project Skara, the ability to run a set of sanity build and test jobs on selected platforms was added. This functionality was driven by `.github/workflows/submit.yml`. This file unfortunately lacks any real structure, and contains a lot of code duplication and redundancy. This has made it hard to add functionality, and new platforms to test, and it has made it even harder to debug issues. (This is hard enough as it is, since we have no direct access to the platforms that GHA runs on.)
> 
> Since the GHA tests are important for a large subset of the community, we need to do better. 
> 
> ## GitHub Actions framework rewrite
>  
> This is a complete overhaul of the GHA testing framework. I started out trying to just tease the old `submit.yml` apart, trying to de-duplicate code, but I soon realized a much more thorough rework was needed.
> 
> ### Design description
> 
> The principle for the new design was to avoid code duplication, and to improve readability of the code. The latter is extra important since the GHA "language" is very limited, needs a lot of quirks and workarounds, and is probably not well known by many OpenJDK developers. I've strived to find useful layers of abstraction to make the expressions as clear as possible.
> 
> Unfortunately, the Workflow/Action YAML language is quite limited. There are two ways to avoid duplication, "local composite actions" and "callable workflows". They both have several limitations:
> 
>  * "Callable workflows" can only be used in a single redirection. They are (apparently) inlined into the "calling workflow" at run time, and as such, they are present without having to check out the source code. (Which is a lengthy process.)
> 
>  * "Local composite actions" can use other actions, but you must start by checking out the repo.
> 
> To use the strength of both kinds of sub-modules, I'm using "callable workflows" from `main.yml` to call `build-<platform>.yml` and `test.yml`. It is not allowed to mix "strategies" (that is, the method of automatically creating a test matrix) when calling callable workflows, so I needed to have some amount of duplication in `main.yml` that could have been avoided otherwise.
> 
> All the callable workflows need to check out the source code anyway, so there is no real additional cost of using "local composite actions" for abstraction of these workflows. (A bit of a lucky break.) I've created "high level" actions, corresponding to something like a function call. The goal here was both to avoid duplication, and to improve readability of the workflows.
> 
> The four `build-<platform>.yml` files are very similar. But in the end of the day, only like 50% of the source code is shared, and the platform specific changes permeate the files. So I decided to keep them separately, since mixing them all into one would have made a mess, due to the lack of proper abstraction mechanisms. But that also mean that if we change platform independent code in building, we need to remember to update it in all four places.
> 
> In the strictest sense, this is a "refactoring" in that the functionality should be equal to the old `submit.yml`. The same platforms should build, with the same arguments, and the same tests should run. When I look at the code now, I see lots of potential for improvement here, by rethinking what we do run. But let's save that discussion for the next PR.
> 
> There is one major change, though. Windows is no longer running on Cygwin, but on MSYS2. This was not really triggered by the recurring build issues on Cygwin (though that certainly did help me in thinking I made the right choice), but the sheer impossibility of getting Cygwin to behave as a normal unix shell on GHA Windows hosts. I spent countless hours trying to work out limitations, by setting `SHELLOPTS=igncr`, by running `set +x posix` to turn of the POSIX compliance mode that kept turning on by itself and made bash choke on several of our scripts, by playing tricks with the `PATH`, but in the end to no avail. There were no single combination of hacks and workarounds that could get us past the entire chain from configure, to build, to testing. (The old solution user PowerShell instead to get around these limitations.) I'm happy to report that I have had absolutely zero issues with MSYS2 since I made the switch (and understood how to set the PATH properly), and I'm seriously co
 nsidering switching stance to recommend using MSYS2 instead of Cygwin as the primary winenv for building the JDK.
> 
> ### Example run
> 
> A good example on how a run looks like with the new GHA system is [the run for this PR](https://github.com/magicus/jdk/actions/runs/2454577164).
> 
> ### New features
> 
> While the primary focus was to convert the old system to a new framework, more accommodating to development, and to wait with further enhancements for the future, I have made a few additional features already in this PR. Most of them are related to needs that arose during development of this PR.
> 
> * A build failure summary, similar to the recently added test failure summary, is added when the build step fails
> 
> * The test reporting has been extended to all platforms, including Windows
> 
> * Test reporting has been improved slightly, and gotten multiple bug fixes
> 
> * All artifacts are now available for individual download. This includes:
> 
>   * The build bundles, per platform
>   * The test results, per platform and test suite
>   * Build failure logs, in case of build failure
> 
>   The build bundles have a retention period of 24 h, but the rest uses GitHub's default retention period (currently 90 days). The idea is that you can use GHA to download builds for platforms you might not have access to, but after that, conserving the builds does not make sense. GitHub currently provides free, unlimited storage (within the retention period) for artifacts, so we can afford this.
> 
> * The GHA process starts up much faster, which mean that e.g. a build failure on an exotic platform will show up earlier. This will not really affect the overall run time though, since it is bounded by variables such as queuing for workers, and waiting on tests with somewhat arbitrarily run times to finish.
> 
> ### Additional changes outside GHA
> 
> I also needed to make a few tweaks to the build system to play nice with the new GHA code.
> 
> * The build failure summary is now stored in build/$BUILD/make-support/failure-summary.log
> 
> * The configure summary now indicates what devkit or sysroot is used, if any
> 
> * The --with-sysroot argument is now properly normalized
> 
> ### Test failures
> 
> A handful of tests, which relies on shell behavior, turned out to fail on Windows when running under MSYS2. I have filed separate bugs, and submitted PRs, to get these fixed:
> 
> * https://bugs.openjdk.org/browse/JDK-8287902
> 
> * https://bugs.openjdk.org/browse/JDK-8287895

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Use MSYS2 as name as consistently as possible

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9063/files
  - new: https://git.openjdk.org/jdk/pull/9063/files/8ce043c1..b17e031c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9063&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9063&range=04-05

  Stats: 94 lines in 4 files changed: 44 ins; 46 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9063.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9063/head:pull/9063

PR: https://git.openjdk.org/jdk/pull/9063


From ihse at openjdk.java.net  Fri Jun 10 19:58:10 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 10 Jun 2022 19:58:10 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v7]
In-Reply-To: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
Message-ID: <VnSlNExgkt4dZNf5sxnQYxy_pw3_rjvvOR5fk0UcN7Y=.f992e8d5-5e91-450b-8a8d-79c7aeed4f28@github.com>

> With project Skara, the ability to run a set of sanity build and test jobs on selected platforms was added. This functionality was driven by `.github/workflows/submit.yml`. This file unfortunately lacks any real structure, and contains a lot of code duplication and redundancy. This has made it hard to add functionality, and new platforms to test, and it has made it even harder to debug issues. (This is hard enough as it is, since we have no direct access to the platforms that GHA runs on.)
> 
> Since the GHA tests are important for a large subset of the community, we need to do better. 
> 
> ## GitHub Actions framework rewrite
>  
> This is a complete overhaul of the GHA testing framework. I started out trying to just tease the old `submit.yml` apart, trying to de-duplicate code, but I soon realized a much more thorough rework was needed.
> 
> ### Design description
> 
> The principle for the new design was to avoid code duplication, and to improve readability of the code. The latter is extra important since the GHA "language" is very limited, needs a lot of quirks and workarounds, and is probably not well known by many OpenJDK developers. I've strived to find useful layers of abstraction to make the expressions as clear as possible.
> 
> Unfortunately, the Workflow/Action YAML language is quite limited. There are two ways to avoid duplication, "local composite actions" and "callable workflows". They both have several limitations:
> 
>  * "Callable workflows" can only be used in a single redirection. They are (apparently) inlined into the "calling workflow" at run time, and as such, they are present without having to check out the source code. (Which is a lengthy process.)
> 
>  * "Local composite actions" can use other actions, but you must start by checking out the repo.
> 
> To use the strength of both kinds of sub-modules, I'm using "callable workflows" from `main.yml` to call `build-<platform>.yml` and `test.yml`. It is not allowed to mix "strategies" (that is, the method of automatically creating a test matrix) when calling callable workflows, so I needed to have some amount of duplication in `main.yml` that could have been avoided otherwise.
> 
> All the callable workflows need to check out the source code anyway, so there is no real additional cost of using "local composite actions" for abstraction of these workflows. (A bit of a lucky break.) I've created "high level" actions, corresponding to something like a function call. The goal here was both to avoid duplication, and to improve readability of the workflows.
> 
> The four `build-<platform>.yml` files are very similar. But in the end of the day, only like 50% of the source code is shared, and the platform specific changes permeate the files. So I decided to keep them separately, since mixing them all into one would have made a mess, due to the lack of proper abstraction mechanisms. But that also mean that if we change platform independent code in building, we need to remember to update it in all four places.
> 
> In the strictest sense, this is a "refactoring" in that the functionality should be equal to the old `submit.yml`. The same platforms should build, with the same arguments, and the same tests should run. When I look at the code now, I see lots of potential for improvement here, by rethinking what we do run. But let's save that discussion for the next PR.
> 
> There is one major change, though. Windows is no longer running on Cygwin, but on MSYS2. This was not really triggered by the recurring build issues on Cygwin (though that certainly did help me in thinking I made the right choice), but the sheer impossibility of getting Cygwin to behave as a normal unix shell on GHA Windows hosts. I spent countless hours trying to work out limitations, by setting `SHELLOPTS=igncr`, by running `set +x posix` to turn of the POSIX compliance mode that kept turning on by itself and made bash choke on several of our scripts, by playing tricks with the `PATH`, but in the end to no avail. There were no single combination of hacks and workarounds that could get us past the entire chain from configure, to build, to testing. (The old solution user PowerShell instead to get around these limitations.) I'm happy to report that I have had absolutely zero issues with MSYS2 since I made the switch (and understood how to set the PATH properly), and I'm seriously co
 nsidering switching stance to recommend using MSYS2 instead of Cygwin as the primary winenv for building the JDK.
> 
> ### Example run
> 
> A good example on how a run looks like with the new GHA system is [the run for this PR](https://github.com/magicus/jdk/actions/runs/2454577164).
> 
> ### New features
> 
> While the primary focus was to convert the old system to a new framework, more accommodating to development, and to wait with further enhancements for the future, I have made a few additional features already in this PR. Most of them are related to needs that arose during development of this PR.
> 
> * A build failure summary, similar to the recently added test failure summary, is added when the build step fails
> 
> * The test reporting has been extended to all platforms, including Windows
> 
> * Test reporting has been improved slightly, and gotten multiple bug fixes
> 
> * All artifacts are now available for individual download. This includes:
> 
>   * The build bundles, per platform
>   * The test results, per platform and test suite
>   * Build failure logs, in case of build failure
> 
>   The build bundles have a retention period of 24 h, but the rest uses GitHub's default retention period (currently 90 days). The idea is that you can use GHA to download builds for platforms you might not have access to, but after that, conserving the builds does not make sense. GitHub currently provides free, unlimited storage (within the retention period) for artifacts, so we can afford this.
> 
> * The GHA process starts up much faster, which mean that e.g. a build failure on an exotic platform will show up earlier. This will not really affect the overall run time though, since it is bounded by variables such as queuing for workers, and waiting on tests with somewhat arbitrarily run times to finish.
> 
> ### Additional changes outside GHA
> 
> I also needed to make a few tweaks to the build system to play nice with the new GHA code.
> 
> * The build failure summary is now stored in build/$BUILD/make-support/failure-summary.log
> 
> * The configure summary now indicates what devkit or sysroot is used, if any
> 
> * The --with-sysroot argument is now properly normalized
> 
> ### Test failures
> 
> A handful of tests, which relies on shell behavior, turned out to fail on Windows when running under MSYS2. I have filed separate bugs, and submitted PRs, to get these fixed:
> 
> * https://bugs.openjdk.org/browse/JDK-8287902
> 
> * https://bugs.openjdk.org/browse/JDK-8287895

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - https instead of http
 - Clean up cross compilation according to code review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9063/files
  - new: https://git.openjdk.org/jdk/pull/9063/files/b17e031c..79f5ee64

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9063&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9063&range=05-06

  Stats: 18 lines in 1 file changed: 13 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/9063.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9063/head:pull/9063

PR: https://git.openjdk.org/jdk/pull/9063


From ihse at openjdk.java.net  Fri Jun 10 19:58:12 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 10 Jun 2022 19:58:12 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v4]
In-Reply-To: <Ke7yZnTBMWqHvwU3zQ-AevoMX58kYv8HSSIn3o7Waow=.6cfdf5bb-09d2-4d37-ae01-ad3125cb2b10@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
 <zkK7RAg7izSW-Rg0g37Snuj8ucIZ6WnN6WMtgrlbig0=.9836fc74-86e6-423a-b7d7-6ce6136f24cf@github.com>
 <1tumB9d27f6IoTicUyMNbGlYGjomWoQ_nL2R1LgqfFA=.7bcb0c2c-54db-47cf-b471-e46e0da74f87@github.com>
 <FFCe_9UR_89GHWX61o31TGP3pS94RmNUZPpb_NRpKrM=.6c819f17-c24a-481f-bb76-073d72607cb4@github.com>
 <RL2hwIS7h0kz4LR6ztL0E9FEQFC9aLhZCwUd2UNIpFc=.08ff076f-5873-4b9b-8666-dfd991702743@github.com>
 <4zwYTrlQeKNGUCa59omO_j9PA8Zopoz4jeBmMnNz8RQ=.2a769d01-3090-4d5e-8207-0c0704a0c31b@github.com>
 <Ke7yZnTBMWqHvwU3zQ-AevoMX58kYv8HSSIn3o7Waow=.6cfdf5bb-09d2-4d37-ae01-ad3125cb2b10@github.com>
Message-ID: <U7SgUWh0ptd5tCj4jaNxav9wj-SvvOdLOoZLGr0X4dM=.7bc611f4-0b1e-4679-838b-1385883418bb@github.com>

On Fri, 10 Jun 2022 11:22:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I can merge the two `apt-get install` lines, if you say that it is not necessary to call `update-alternatives` before the second install line. (But does it really speed things up?)
>
>> (But does it really speed things up?)
> 
> Yes, I think it does: `apt` would read the package database once, and do the post-install actions once. `update-alternatives` does not have to happen between those two lines.

I hope I made the abstractions of the apt version strings correct. If not, we'll have to adjust it when we upgrade compilers.

-------------

PR: https://git.openjdk.org/jdk/pull/9063


From ihse at openjdk.java.net  Fri Jun 10 20:20:42 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 10 Jun 2022 20:20:42 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v8]
In-Reply-To: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
Message-ID: <eEqAGup9VdXBAC-ovCGc2Mwr5894t2mK5JAqLnBOmo8=.45a4057e-ba2d-4d66-9a3d-c818dd5ba2f5@github.com>

> With project Skara, the ability to run a set of sanity build and test jobs on selected platforms was added. This functionality was driven by `.github/workflows/submit.yml`. This file unfortunately lacks any real structure, and contains a lot of code duplication and redundancy. This has made it hard to add functionality, and new platforms to test, and it has made it even harder to debug issues. (This is hard enough as it is, since we have no direct access to the platforms that GHA runs on.)
> 
> Since the GHA tests are important for a large subset of the community, we need to do better. 
> 
> ## GitHub Actions framework rewrite
>  
> This is a complete overhaul of the GHA testing framework. I started out trying to just tease the old `submit.yml` apart, trying to de-duplicate code, but I soon realized a much more thorough rework was needed.
> 
> ### Design description
> 
> The principle for the new design was to avoid code duplication, and to improve readability of the code. The latter is extra important since the GHA "language" is very limited, needs a lot of quirks and workarounds, and is probably not well known by many OpenJDK developers. I've strived to find useful layers of abstraction to make the expressions as clear as possible.
> 
> Unfortunately, the Workflow/Action YAML language is quite limited. There are two ways to avoid duplication, "local composite actions" and "callable workflows". They both have several limitations:
> 
>  * "Callable workflows" can only be used in a single redirection. They are (apparently) inlined into the "calling workflow" at run time, and as such, they are present without having to check out the source code. (Which is a lengthy process.)
> 
>  * "Local composite actions" can use other actions, but you must start by checking out the repo.
> 
> To use the strength of both kinds of sub-modules, I'm using "callable workflows" from `main.yml` to call `build-<platform>.yml` and `test.yml`. It is not allowed to mix "strategies" (that is, the method of automatically creating a test matrix) when calling callable workflows, so I needed to have some amount of duplication in `main.yml` that could have been avoided otherwise.
> 
> All the callable workflows need to check out the source code anyway, so there is no real additional cost of using "local composite actions" for abstraction of these workflows. (A bit of a lucky break.) I've created "high level" actions, corresponding to something like a function call. The goal here was both to avoid duplication, and to improve readability of the workflows.
> 
> The four `build-<platform>.yml` files are very similar. But in the end of the day, only like 50% of the source code is shared, and the platform specific changes permeate the files. So I decided to keep them separately, since mixing them all into one would have made a mess, due to the lack of proper abstraction mechanisms. But that also mean that if we change platform independent code in building, we need to remember to update it in all four places.
> 
> In the strictest sense, this is a "refactoring" in that the functionality should be equal to the old `submit.yml`. The same platforms should build, with the same arguments, and the same tests should run. When I look at the code now, I see lots of potential for improvement here, by rethinking what we do run. But let's save that discussion for the next PR.
> 
> There is one major change, though. Windows is no longer running on Cygwin, but on MSYS2. This was not really triggered by the recurring build issues on Cygwin (though that certainly did help me in thinking I made the right choice), but the sheer impossibility of getting Cygwin to behave as a normal unix shell on GHA Windows hosts. I spent countless hours trying to work out limitations, by setting `SHELLOPTS=igncr`, by running `set +x posix` to turn of the POSIX compliance mode that kept turning on by itself and made bash choke on several of our scripts, by playing tricks with the `PATH`, but in the end to no avail. There were no single combination of hacks and workarounds that could get us past the entire chain from configure, to build, to testing. (The old solution user PowerShell instead to get around these limitations.) I'm happy to report that I have had absolutely zero issues with MSYS2 since I made the switch (and understood how to set the PATH properly), and I'm seriously co
 nsidering switching stance to recommend using MSYS2 instead of Cygwin as the primary winenv for building the JDK.
> 
> ### Example run
> 
> A good example on how a run looks like with the new GHA system is [the run for this PR](https://github.com/magicus/jdk/actions/runs/2454577164).
> 
> ### New features
> 
> While the primary focus was to convert the old system to a new framework, more accommodating to development, and to wait with further enhancements for the future, I have made a few additional features already in this PR. Most of them are related to needs that arose during development of this PR.
> 
> * A build failure summary, similar to the recently added test failure summary, is added when the build step fails
> 
> * The test reporting has been extended to all platforms, including Windows
> 
> * Test reporting has been improved slightly, and gotten multiple bug fixes
> 
> * All artifacts are now available for individual download. This includes:
> 
>   * The build bundles, per platform
>   * The test results, per platform and test suite
>   * Build failure logs, in case of build failure
> 
>   The build bundles have a retention period of 24 h, but the rest uses GitHub's default retention period (currently 90 days). The idea is that you can use GHA to download builds for platforms you might not have access to, but after that, conserving the builds does not make sense. GitHub currently provides free, unlimited storage (within the retention period) for artifacts, so we can afford this.
> 
> * The GHA process starts up much faster, which mean that e.g. a build failure on an exotic platform will show up earlier. This will not really affect the overall run time though, since it is bounded by variables such as queuing for workers, and waiting on tests with somewhat arbitrarily run times to finish.
> 
> ### Additional changes outside GHA
> 
> I also needed to make a few tweaks to the build system to play nice with the new GHA code.
> 
> * The build failure summary is now stored in build/$BUILD/make-support/failure-summary.log
> 
> * The configure summary now indicates what devkit or sysroot is used, if any
> 
> * The --with-sysroot argument is now properly normalized
> 
> ### Test failures
> 
> A handful of tests, which relies on shell behavior, turned out to fail on Windows when running under MSYS2. I have filed separate bugs, and submitted PRs, to get these fixed:
> 
> * https://bugs.openjdk.org/browse/JDK-8287902
> 
> * https://bugs.openjdk.org/browse/JDK-8287895

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Clean up apt architecture handling, inspired by suggestions in code review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9063/files
  - new: https://git.openjdk.org/jdk/pull/9063/files/79f5ee64..2ebeee99

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9063&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9063&range=06-07

  Stats: 19 lines in 3 files changed: 10 ins; 5 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9063.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9063/head:pull/9063

PR: https://git.openjdk.org/jdk/pull/9063


From ihse at openjdk.java.net  Fri Jun 10 20:20:42 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 10 Jun 2022 20:20:42 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v4]
In-Reply-To: <FjW215bUfcBIzyJZS0aaA6HwrpwUpfKGa99XOPsMlXg=.adfd2558-5b41-41f0-af15-d2079b9a0e99@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
 <zkK7RAg7izSW-Rg0g37Snuj8ucIZ6WnN6WMtgrlbig0=.9836fc74-86e6-423a-b7d7-6ce6136f24cf@github.com>
 <1tumB9d27f6IoTicUyMNbGlYGjomWoQ_nL2R1LgqfFA=.7bcb0c2c-54db-47cf-b471-e46e0da74f87@github.com>
 <YUVUu2zw5RzKcI74xvPC5baQYIw9VBn-ufag3sPnOzY=.2c6e9b2e-13d7-40d1-aa68-6a8508cfd8ba@github.com>
 <FjW215bUfcBIzyJZS0aaA6HwrpwUpfKGa99XOPsMlXg=.adfd2558-5b41-41f0-af15-d2079b9a0e99@github.com>
Message-ID: <46NGWHNAK7RzOyYw1qZs5bveHRF2O5wRnJk23nC5qUQ=.f6a6f0de-f210-4a84-b282-81299c3406c1@github.com>

On Fri, 10 Jun 2022 11:23:57 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> If I do that, there need to be some kind of if statement in the called workflow, since if that input argument is left out, we'd get a command line like `sudo dpkg --add-architecture` which I assume is illegal syntax (or, possibly worse, does something other than a no-op).
>> 
>> I think there can be room for additional improvement in especially the "special" linux builds, but I had to draw the line somewhere, to be able to finish this PR.
>
> I think you can make a conditionalized step that runs in case the value is not empty, and skip the step otherwise. If that is hard, it can be done in the followup, sure.

I cleaned up the entire "apt architecture" handling a bit. Some part of the code got more complex, but overall I think it was worth it due to the higher level of abstraction.

-------------

PR: https://git.openjdk.org/jdk/pull/9063


From ihse at openjdk.java.net  Fri Jun 10 20:30:06 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 10 Jun 2022 20:30:06 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v9]
In-Reply-To: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
Message-ID: <jqGsN9RBT8XGe9IhBkTjB3kmkhS4wLJkYV0l77jRRVk=.c681af5f-e2c8-4d75-8483-426b87283af6@github.com>

> With project Skara, the ability to run a set of sanity build and test jobs on selected platforms was added. This functionality was driven by `.github/workflows/submit.yml`. This file unfortunately lacks any real structure, and contains a lot of code duplication and redundancy. This has made it hard to add functionality, and new platforms to test, and it has made it even harder to debug issues. (This is hard enough as it is, since we have no direct access to the platforms that GHA runs on.)
> 
> Since the GHA tests are important for a large subset of the community, we need to do better. 
> 
> ## GitHub Actions framework rewrite
>  
> This is a complete overhaul of the GHA testing framework. I started out trying to just tease the old `submit.yml` apart, trying to de-duplicate code, but I soon realized a much more thorough rework was needed.
> 
> ### Design description
> 
> The principle for the new design was to avoid code duplication, and to improve readability of the code. The latter is extra important since the GHA "language" is very limited, needs a lot of quirks and workarounds, and is probably not well known by many OpenJDK developers. I've strived to find useful layers of abstraction to make the expressions as clear as possible.
> 
> Unfortunately, the Workflow/Action YAML language is quite limited. There are two ways to avoid duplication, "local composite actions" and "callable workflows". They both have several limitations:
> 
>  * "Callable workflows" can only be used in a single redirection. They are (apparently) inlined into the "calling workflow" at run time, and as such, they are present without having to check out the source code. (Which is a lengthy process.)
> 
>  * "Local composite actions" can use other actions, but you must start by checking out the repo.
> 
> To use the strength of both kinds of sub-modules, I'm using "callable workflows" from `main.yml` to call `build-<platform>.yml` and `test.yml`. It is not allowed to mix "strategies" (that is, the method of automatically creating a test matrix) when calling callable workflows, so I needed to have some amount of duplication in `main.yml` that could have been avoided otherwise.
> 
> All the callable workflows need to check out the source code anyway, so there is no real additional cost of using "local composite actions" for abstraction of these workflows. (A bit of a lucky break.) I've created "high level" actions, corresponding to something like a function call. The goal here was both to avoid duplication, and to improve readability of the workflows.
> 
> The four `build-<platform>.yml` files are very similar. But in the end of the day, only like 50% of the source code is shared, and the platform specific changes permeate the files. So I decided to keep them separately, since mixing them all into one would have made a mess, due to the lack of proper abstraction mechanisms. But that also mean that if we change platform independent code in building, we need to remember to update it in all four places.
> 
> In the strictest sense, this is a "refactoring" in that the functionality should be equal to the old `submit.yml`. The same platforms should build, with the same arguments, and the same tests should run. When I look at the code now, I see lots of potential for improvement here, by rethinking what we do run. But let's save that discussion for the next PR.
> 
> There is one major change, though. Windows is no longer running on Cygwin, but on MSYS2. This was not really triggered by the recurring build issues on Cygwin (though that certainly did help me in thinking I made the right choice), but the sheer impossibility of getting Cygwin to behave as a normal unix shell on GHA Windows hosts. I spent countless hours trying to work out limitations, by setting `SHELLOPTS=igncr`, by running `set +x posix` to turn of the POSIX compliance mode that kept turning on by itself and made bash choke on several of our scripts, by playing tricks with the `PATH`, but in the end to no avail. There were no single combination of hacks and workarounds that could get us past the entire chain from configure, to build, to testing. (The old solution user PowerShell instead to get around these limitations.) I'm happy to report that I have had absolutely zero issues with MSYS2 since I made the switch (and understood how to set the PATH properly), and I'm seriously co
 nsidering switching stance to recommend using MSYS2 instead of Cygwin as the primary winenv for building the JDK.
> 
> ### Example run
> 
> A good example on how a run looks like with the new GHA system is [the run for this PR](https://github.com/magicus/jdk/actions/runs/2454577164).
> 
> ### New features
> 
> While the primary focus was to convert the old system to a new framework, more accommodating to development, and to wait with further enhancements for the future, I have made a few additional features already in this PR. Most of them are related to needs that arose during development of this PR.
> 
> * A build failure summary, similar to the recently added test failure summary, is added when the build step fails
> 
> * The test reporting has been extended to all platforms, including Windows
> 
> * Test reporting has been improved slightly, and gotten multiple bug fixes
> 
> * All artifacts are now available for individual download. This includes:
> 
>   * The build bundles, per platform
>   * The test results, per platform and test suite
>   * Build failure logs, in case of build failure
> 
>   The build bundles have a retention period of 24 h, but the rest uses GitHub's default retention period (currently 90 days). The idea is that you can use GHA to download builds for platforms you might not have access to, but after that, conserving the builds does not make sense. GitHub currently provides free, unlimited storage (within the retention period) for artifacts, so we can afford this.
> 
> * The GHA process starts up much faster, which mean that e.g. a build failure on an exotic platform will show up earlier. This will not really affect the overall run time though, since it is bounded by variables such as queuing for workers, and waiting on tests with somewhat arbitrarily run times to finish.
> 
> ### Additional changes outside GHA
> 
> I also needed to make a few tweaks to the build system to play nice with the new GHA code.
> 
> * The build failure summary is now stored in build/$BUILD/make-support/failure-summary.log
> 
> * The configure summary now indicates what devkit or sysroot is used, if any
> 
> * The --with-sysroot argument is now properly normalized
> 
> ### Test failures
> 
> A handful of tests, which relies on shell behavior, turned out to fail on Windows when running under MSYS2. I have filed separate bugs, and submitted PRs, to get these fixed:
> 
> * https://bugs.openjdk.org/browse/JDK-8287902
> 
> * https://bugs.openjdk.org/browse/JDK-8287895

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - Merge branch 'master' into gha-refactor
 - Clean up apt architecture handling, inspired by suggestions in code review
 - https instead of http
 - Clean up cross compilation according to code review
 - Use MSYS2 as name as consistently as possible
 - Fix test failure regex
 - Apparently that was not a legal reference to actions/checkout. Try another way.
 - Use Java 11 to build jtreg. Also temporarily switch out jtreg source ref to PR that fixes build on msys2. (This will be updated once the fix is in an official jtreg release.)
 - Build JTReg from source instead of downloading pre-built binary
 - 8287906: Rewrite of GitHub Actions (GHA) sanity tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9063/files
  - new: https://git.openjdk.org/jdk/pull/9063/files/2ebeee99..463f8862

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9063&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9063&range=07-08

  Stats: 1839 lines in 93 files changed: 1186 ins; 242 del; 411 mod
  Patch: https://git.openjdk.org/jdk/pull/9063.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9063/head:pull/9063

PR: https://git.openjdk.org/jdk/pull/9063


From ihse at openjdk.java.net  Fri Jun 10 20:36:00 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 10 Jun 2022 20:36:00 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v10]
In-Reply-To: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
Message-ID: <jKQ_gSmPGQQJFLDl436wGvLr3v5d5F7kYXQYhRI79fE=.170cf395-497a-41ff-8c63-aabaf8d90283@github.com>

> With project Skara, the ability to run a set of sanity build and test jobs on selected platforms was added. This functionality was driven by `.github/workflows/submit.yml`. This file unfortunately lacks any real structure, and contains a lot of code duplication and redundancy. This has made it hard to add functionality, and new platforms to test, and it has made it even harder to debug issues. (This is hard enough as it is, since we have no direct access to the platforms that GHA runs on.)
> 
> Since the GHA tests are important for a large subset of the community, we need to do better. 
> 
> ## GitHub Actions framework rewrite
>  
> This is a complete overhaul of the GHA testing framework. I started out trying to just tease the old `submit.yml` apart, trying to de-duplicate code, but I soon realized a much more thorough rework was needed.
> 
> ### Design description
> 
> The principle for the new design was to avoid code duplication, and to improve readability of the code. The latter is extra important since the GHA "language" is very limited, needs a lot of quirks and workarounds, and is probably not well known by many OpenJDK developers. I've strived to find useful layers of abstraction to make the expressions as clear as possible.
> 
> Unfortunately, the Workflow/Action YAML language is quite limited. There are two ways to avoid duplication, "local composite actions" and "callable workflows". They both have several limitations:
> 
>  * "Callable workflows" can only be used in a single redirection. They are (apparently) inlined into the "calling workflow" at run time, and as such, they are present without having to check out the source code. (Which is a lengthy process.)
> 
>  * "Local composite actions" can use other actions, but you must start by checking out the repo.
> 
> To use the strength of both kinds of sub-modules, I'm using "callable workflows" from `main.yml` to call `build-<platform>.yml` and `test.yml`. It is not allowed to mix "strategies" (that is, the method of automatically creating a test matrix) when calling callable workflows, so I needed to have some amount of duplication in `main.yml` that could have been avoided otherwise.
> 
> All the callable workflows need to check out the source code anyway, so there is no real additional cost of using "local composite actions" for abstraction of these workflows. (A bit of a lucky break.) I've created "high level" actions, corresponding to something like a function call. The goal here was both to avoid duplication, and to improve readability of the workflows.
> 
> The four `build-<platform>.yml` files are very similar. But in the end of the day, only like 50% of the source code is shared, and the platform specific changes permeate the files. So I decided to keep them separately, since mixing them all into one would have made a mess, due to the lack of proper abstraction mechanisms. But that also mean that if we change platform independent code in building, we need to remember to update it in all four places.
> 
> In the strictest sense, this is a "refactoring" in that the functionality should be equal to the old `submit.yml`. The same platforms should build, with the same arguments, and the same tests should run. When I look at the code now, I see lots of potential for improvement here, by rethinking what we do run. But let's save that discussion for the next PR.
> 
> There is one major change, though. Windows is no longer running on Cygwin, but on MSYS2. This was not really triggered by the recurring build issues on Cygwin (though that certainly did help me in thinking I made the right choice), but the sheer impossibility of getting Cygwin to behave as a normal unix shell on GHA Windows hosts. I spent countless hours trying to work out limitations, by setting `SHELLOPTS=igncr`, by running `set +x posix` to turn of the POSIX compliance mode that kept turning on by itself and made bash choke on several of our scripts, by playing tricks with the `PATH`, but in the end to no avail. There were no single combination of hacks and workarounds that could get us past the entire chain from configure, to build, to testing. (The old solution user PowerShell instead to get around these limitations.) I'm happy to report that I have had absolutely zero issues with MSYS2 since I made the switch (and understood how to set the PATH properly), and I'm seriously co
 nsidering switching stance to recommend using MSYS2 instead of Cygwin as the primary winenv for building the JDK.
> 
> ### Example run
> 
> A good example on how a run looks like with the new GHA system is [the run for this PR](https://github.com/magicus/jdk/actions/runs/2454577164).
> 
> ### New features
> 
> While the primary focus was to convert the old system to a new framework, more accommodating to development, and to wait with further enhancements for the future, I have made a few additional features already in this PR. Most of them are related to needs that arose during development of this PR.
> 
> * A build failure summary, similar to the recently added test failure summary, is added when the build step fails
> 
> * The test reporting has been extended to all platforms, including Windows
> 
> * Test reporting has been improved slightly, and gotten multiple bug fixes
> 
> * All artifacts are now available for individual download. This includes:
> 
>   * The build bundles, per platform
>   * The test results, per platform and test suite
>   * Build failure logs, in case of build failure
> 
>   The build bundles have a retention period of 24 h, but the rest uses GitHub's default retention period (currently 90 days). The idea is that you can use GHA to download builds for platforms you might not have access to, but after that, conserving the builds does not make sense. GitHub currently provides free, unlimited storage (within the retention period) for artifacts, so we can afford this.
> 
> * The GHA process starts up much faster, which mean that e.g. a build failure on an exotic platform will show up earlier. This will not really affect the overall run time though, since it is bounded by variables such as queuing for workers, and waiting on tests with somewhat arbitrarily run times to finish.
> 
> ### Additional changes outside GHA
> 
> I also needed to make a few tweaks to the build system to play nice with the new GHA code.
> 
> * The build failure summary is now stored in build/$BUILD/make-support/failure-summary.log
> 
> * The configure summary now indicates what devkit or sysroot is used, if any
> 
> * The --with-sysroot argument is now properly normalized
> 
> ### Test failures
> 
> A handful of tests, which relies on shell behavior, turned out to fail on Windows when running under MSYS2. I have filed separate bugs, and submitted PRs, to get these fixed:
> 
> * https://bugs.openjdk.org/browse/JDK-8287902
> 
> * https://bugs.openjdk.org/browse/JDK-8287895

Magnus Ihse Bursie 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 11 additional commits since the last revision:

 - Merge branch 'master' into gha-refactor
 - Merge branch 'master' into gha-refactor
 - Clean up apt architecture handling, inspired by suggestions in code review
 - https instead of http
 - Clean up cross compilation according to code review
 - Use MSYS2 as name as consistently as possible
 - Fix test failure regex
 - Apparently that was not a legal reference to actions/checkout. Try another way.
 - Use Java 11 to build jtreg. Also temporarily switch out jtreg source ref to PR that fixes build on msys2. (This will be updated once the fix is in an official jtreg release.)
 - Build JTReg from source instead of downloading pre-built binary
 - ... and 1 more: https://git.openjdk.org/jdk/compare/836b39c5...34b5514b

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9063/files
  - new: https://git.openjdk.org/jdk/pull/9063/files/463f8862..34b5514b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9063&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9063&range=08-09

  Stats: 10618 lines in 225 files changed: 9052 ins; 491 del; 1075 mod
  Patch: https://git.openjdk.org/jdk/pull/9063.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9063/head:pull/9063

PR: https://git.openjdk.org/jdk/pull/9063


From ihse at openjdk.java.net  Fri Jun 10 20:36:04 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 10 Jun 2022 20:36:04 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v4]
In-Reply-To: <1tumB9d27f6IoTicUyMNbGlYGjomWoQ_nL2R1LgqfFA=.7bcb0c2c-54db-47cf-b471-e46e0da74f87@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
 <zkK7RAg7izSW-Rg0g37Snuj8ucIZ6WnN6WMtgrlbig0=.9836fc74-86e6-423a-b7d7-6ce6136f24cf@github.com>
 <1tumB9d27f6IoTicUyMNbGlYGjomWoQ_nL2R1LgqfFA=.7bcb0c2c-54db-47cf-b471-e46e0da74f87@github.com>
Message-ID: <L31BXo7PRGhK8UaE5wswZsFZJ3kF1ugg6S2i90UPOrk=.83e0ac4d-01ea-4584-8a5a-debd14d5f924@github.com>

On Fri, 10 Jun 2022 07:29:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apparently that was not a legal reference to actions/checkout. Try another way.
>
> This all looks very nice. I have a few inline comments.
> 
> The general one is that we need to make sure:
>  - jtreg needs to be built from its mainline at a given tag;
>  - tests need to pass (I assume you are waiting for test fixes to land first);

@shipilev JDK-8287902 and JDK-8287895 are now fixed, and with that, all msys2-related test problems should be resolved.

-------------

PR: https://git.openjdk.org/jdk/pull/9063


From mcimadamore at openjdk.java.net  Fri Jun 10 21:55:46 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 10 Jun 2022 21:55:46 GMT
Subject: RFR: 8288114: Update JIRA link in vcs.xml
In-Reply-To: <kUYuV5md8sfEcVrehSWXg2g9ddAyK8Z-__C1eGv6KiY=.93b555b6-102d-4b19-a617-c775c4fa06e1@github.com>
References: <kUYuV5md8sfEcVrehSWXg2g9ddAyK8Z-__C1eGv6KiY=.93b555b6-102d-4b19-a617-c775c4fa06e1@github.com>
Message-ID: <KVyuHXQz6rkK4kTTRaV6SzXJNJkIy_eU8vjq_K2opC4=.7b105217-20b6-4659-b1f9-e31ae602582e@github.com>

On Fri, 10 Jun 2022 17:11:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Update the link to JBS in `vcs.xml` template to https://bugs.openjdk.org/
> 
> It will affect newly generated project files only.  
> Edit `vcs.xml` manually or in UI to update in existing projects.

Looks good - thanks!

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9130


From ihse at openjdk.java.net  Fri Jun 10 22:54:59 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 10 Jun 2022 22:54:59 GMT
Subject: RFR: 8288114: Update JIRA link in vcs.xml
In-Reply-To: <kUYuV5md8sfEcVrehSWXg2g9ddAyK8Z-__C1eGv6KiY=.93b555b6-102d-4b19-a617-c775c4fa06e1@github.com>
References: <kUYuV5md8sfEcVrehSWXg2g9ddAyK8Z-__C1eGv6KiY=.93b555b6-102d-4b19-a617-c775c4fa06e1@github.com>
Message-ID: <GFFkXhSEMhV17yhkOUdVsVZP1HWB79nR8yIAJ9lNmtU=.97f3d494-1e3f-44e8-864a-9043e9669073@github.com>

On Fri, 10 Jun 2022 17:11:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Update the link to JBS in `vcs.xml` template to https://bugs.openjdk.org/
> 
> It will affect newly generated project files only.  
> Edit `vcs.xml` manually or in UI to update in existing projects.

Marked as reviewed by ihse (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9130


From ihse at openjdk.java.net  Sat Jun 11 10:16:35 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Sat, 11 Jun 2022 10:16:35 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v11]
In-Reply-To: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
Message-ID: <xO4hHloJMaaqWY1IvK79rjSEGCG-U_T-MKeRsBYoFvI=.bab77a11-bed7-4290-bfb5-512759b226ab@github.com>

> With project Skara, the ability to run a set of sanity build and test jobs on selected platforms was added. This functionality was driven by `.github/workflows/submit.yml`. This file unfortunately lacks any real structure, and contains a lot of code duplication and redundancy. This has made it hard to add functionality, and new platforms to test, and it has made it even harder to debug issues. (This is hard enough as it is, since we have no direct access to the platforms that GHA runs on.)
> 
> Since the GHA tests are important for a large subset of the community, we need to do better. 
> 
> ## GitHub Actions framework rewrite
>  
> This is a complete overhaul of the GHA testing framework. I started out trying to just tease the old `submit.yml` apart, trying to de-duplicate code, but I soon realized a much more thorough rework was needed.
> 
> ### Design description
> 
> The principle for the new design was to avoid code duplication, and to improve readability of the code. The latter is extra important since the GHA "language" is very limited, needs a lot of quirks and workarounds, and is probably not well known by many OpenJDK developers. I've strived to find useful layers of abstraction to make the expressions as clear as possible.
> 
> Unfortunately, the Workflow/Action YAML language is quite limited. There are two ways to avoid duplication, "local composite actions" and "callable workflows". They both have several limitations:
> 
>  * "Callable workflows" can only be used in a single redirection. They are (apparently) inlined into the "calling workflow" at run time, and as such, they are present without having to check out the source code. (Which is a lengthy process.)
> 
>  * "Local composite actions" can use other actions, but you must start by checking out the repo.
> 
> To use the strength of both kinds of sub-modules, I'm using "callable workflows" from `main.yml` to call `build-<platform>.yml` and `test.yml`. It is not allowed to mix "strategies" (that is, the method of automatically creating a test matrix) when calling callable workflows, so I needed to have some amount of duplication in `main.yml` that could have been avoided otherwise.
> 
> All the callable workflows need to check out the source code anyway, so there is no real additional cost of using "local composite actions" for abstraction of these workflows. (A bit of a lucky break.) I've created "high level" actions, corresponding to something like a function call. The goal here was both to avoid duplication, and to improve readability of the workflows.
> 
> The four `build-<platform>.yml` files are very similar. But in the end of the day, only like 50% of the source code is shared, and the platform specific changes permeate the files. So I decided to keep them separately, since mixing them all into one would have made a mess, due to the lack of proper abstraction mechanisms. But that also mean that if we change platform independent code in building, we need to remember to update it in all four places.
> 
> In the strictest sense, this is a "refactoring" in that the functionality should be equal to the old `submit.yml`. The same platforms should build, with the same arguments, and the same tests should run. When I look at the code now, I see lots of potential for improvement here, by rethinking what we do run. But let's save that discussion for the next PR.
> 
> There is one major change, though. Windows is no longer running on Cygwin, but on MSYS2. This was not really triggered by the recurring build issues on Cygwin (though that certainly did help me in thinking I made the right choice), but the sheer impossibility of getting Cygwin to behave as a normal unix shell on GHA Windows hosts. I spent countless hours trying to work out limitations, by setting `SHELLOPTS=igncr`, by running `set +x posix` to turn of the POSIX compliance mode that kept turning on by itself and made bash choke on several of our scripts, by playing tricks with the `PATH`, but in the end to no avail. There were no single combination of hacks and workarounds that could get us past the entire chain from configure, to build, to testing. (The old solution user PowerShell instead to get around these limitations.) I'm happy to report that I have had absolutely zero issues with MSYS2 since I made the switch (and understood how to set the PATH properly), and I'm seriously co
 nsidering switching stance to recommend using MSYS2 instead of Cygwin as the primary winenv for building the JDK.
> 
> ### Example run
> 
> A good example on how a run looks like with the new GHA system is [the run for this PR](https://github.com/magicus/jdk/actions/runs/2454577164).
> 
> ### New features
> 
> While the primary focus was to convert the old system to a new framework, more accommodating to development, and to wait with further enhancements for the future, I have made a few additional features already in this PR. Most of them are related to needs that arose during development of this PR.
> 
> * A build failure summary, similar to the recently added test failure summary, is added when the build step fails
> 
> * The test reporting has been extended to all platforms, including Windows
> 
> * Test reporting has been improved slightly, and gotten multiple bug fixes
> 
> * All artifacts are now available for individual download. This includes:
> 
>   * The build bundles, per platform
>   * The test results, per platform and test suite
>   * Build failure logs, in case of build failure
> 
>   The build bundles have a retention period of 24 h, but the rest uses GitHub's default retention period (currently 90 days). The idea is that you can use GHA to download builds for platforms you might not have access to, but after that, conserving the builds does not make sense. GitHub currently provides free, unlimited storage (within the retention period) for artifacts, so we can afford this.
> 
> * The GHA process starts up much faster, which mean that e.g. a build failure on an exotic platform will show up earlier. This will not really affect the overall run time though, since it is bounded by variables such as queuing for workers, and waiting on tests with somewhat arbitrarily run times to finish.
> 
> ### Additional changes outside GHA
> 
> I also needed to make a few tweaks to the build system to play nice with the new GHA code.
> 
> * The build failure summary is now stored in build/$BUILD/make-support/failure-summary.log
> 
> * The configure summary now indicates what devkit or sysroot is used, if any
> 
> * The --with-sysroot argument is now properly normalized
> 
> ### Test failures
> 
> A handful of tests, which relies on shell behavior, turned out to fail on Windows when running under MSYS2. I have filed separate bugs, and submitted PRs, to get these fixed:
> 
> * https://bugs.openjdk.org/browse/JDK-8287902
> 
> * https://bugs.openjdk.org/browse/JDK-8287895

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Use jtreg 6.1+2 now that it is available

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9063/files
  - new: https://git.openjdk.org/jdk/pull/9063/files/34b5514b..385bbd72

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9063&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9063&range=09-10

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9063.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9063/head:pull/9063

PR: https://git.openjdk.org/jdk/pull/9063


From ihse at openjdk.java.net  Mon Jun 13 06:45:49 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 13 Jun 2022 06:45:49 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v12]
In-Reply-To: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
Message-ID: <8-SlvyGCEzz8OqurYiFYC5QUGThLrFvJ51SHkgihx-M=.924d4ba9-615c-4bcf-afda-1fd4db264b6f@github.com>

> With project Skara, the ability to run a set of sanity build and test jobs on selected platforms was added. This functionality was driven by `.github/workflows/submit.yml`. This file unfortunately lacks any real structure, and contains a lot of code duplication and redundancy. This has made it hard to add functionality, and new platforms to test, and it has made it even harder to debug issues. (This is hard enough as it is, since we have no direct access to the platforms that GHA runs on.)
> 
> Since the GHA tests are important for a large subset of the community, we need to do better. 
> 
> ## GitHub Actions framework rewrite
>  
> This is a complete overhaul of the GHA testing framework. I started out trying to just tease the old `submit.yml` apart, trying to de-duplicate code, but I soon realized a much more thorough rework was needed.
> 
> ### Design description
> 
> The principle for the new design was to avoid code duplication, and to improve readability of the code. The latter is extra important since the GHA "language" is very limited, needs a lot of quirks and workarounds, and is probably not well known by many OpenJDK developers. I've strived to find useful layers of abstraction to make the expressions as clear as possible.
> 
> Unfortunately, the Workflow/Action YAML language is quite limited. There are two ways to avoid duplication, "local composite actions" and "callable workflows". They both have several limitations:
> 
>  * "Callable workflows" can only be used in a single redirection. They are (apparently) inlined into the "calling workflow" at run time, and as such, they are present without having to check out the source code. (Which is a lengthy process.)
> 
>  * "Local composite actions" can use other actions, but you must start by checking out the repo.
> 
> To use the strength of both kinds of sub-modules, I'm using "callable workflows" from `main.yml` to call `build-<platform>.yml` and `test.yml`. It is not allowed to mix "strategies" (that is, the method of automatically creating a test matrix) when calling callable workflows, so I needed to have some amount of duplication in `main.yml` that could have been avoided otherwise.
> 
> All the callable workflows need to check out the source code anyway, so there is no real additional cost of using "local composite actions" for abstraction of these workflows. (A bit of a lucky break.) I've created "high level" actions, corresponding to something like a function call. The goal here was both to avoid duplication, and to improve readability of the workflows.
> 
> The four `build-<platform>.yml` files are very similar. But in the end of the day, only like 50% of the source code is shared, and the platform specific changes permeate the files. So I decided to keep them separately, since mixing them all into one would have made a mess, due to the lack of proper abstraction mechanisms. But that also mean that if we change platform independent code in building, we need to remember to update it in all four places.
> 
> In the strictest sense, this is a "refactoring" in that the functionality should be equal to the old `submit.yml`. The same platforms should build, with the same arguments, and the same tests should run. When I look at the code now, I see lots of potential for improvement here, by rethinking what we do run. But let's save that discussion for the next PR.
> 
> There is one major change, though. Windows is no longer running on Cygwin, but on MSYS2. This was not really triggered by the recurring build issues on Cygwin (though that certainly did help me in thinking I made the right choice), but the sheer impossibility of getting Cygwin to behave as a normal unix shell on GHA Windows hosts. I spent countless hours trying to work out limitations, by setting `SHELLOPTS=igncr`, by running `set +x posix` to turn of the POSIX compliance mode that kept turning on by itself and made bash choke on several of our scripts, by playing tricks with the `PATH`, but in the end to no avail. There were no single combination of hacks and workarounds that could get us past the entire chain from configure, to build, to testing. (The old solution user PowerShell instead to get around these limitations.) I'm happy to report that I have had absolutely zero issues with MSYS2 since I made the switch (and understood how to set the PATH properly), and I'm seriously co
 nsidering switching stance to recommend using MSYS2 instead of Cygwin as the primary winenv for building the JDK.
> 
> ### Example run
> 
> A good example on how a run looks like with the new GHA system is [the run for this PR](https://github.com/magicus/jdk/actions/runs/2454577164).
> 
> ### New features
> 
> While the primary focus was to convert the old system to a new framework, more accommodating to development, and to wait with further enhancements for the future, I have made a few additional features already in this PR. Most of them are related to needs that arose during development of this PR.
> 
> * A build failure summary, similar to the recently added test failure summary, is added when the build step fails
> 
> * The test reporting has been extended to all platforms, including Windows
> 
> * Test reporting has been improved slightly, and gotten multiple bug fixes
> 
> * All artifacts are now available for individual download. This includes:
> 
>   * The build bundles, per platform
>   * The test results, per platform and test suite
>   * Build failure logs, in case of build failure
> 
>   The build bundles have a retention period of 24 h, but the rest uses GitHub's default retention period (currently 90 days). The idea is that you can use GHA to download builds for platforms you might not have access to, but after that, conserving the builds does not make sense. GitHub currently provides free, unlimited storage (within the retention period) for artifacts, so we can afford this.
> 
> * The GHA process starts up much faster, which mean that e.g. a build failure on an exotic platform will show up earlier. This will not really affect the overall run time though, since it is bounded by variables such as queuing for workers, and waiting on tests with somewhat arbitrarily run times to finish.
> 
> ### Additional changes outside GHA
> 
> I also needed to make a few tweaks to the build system to play nice with the new GHA code.
> 
> * The build failure summary is now stored in build/$BUILD/make-support/failure-summary.log
> 
> * The configure summary now indicates what devkit or sysroot is used, if any
> 
> * The --with-sysroot argument is now properly normalized
> 
> ### Test failures
> 
> A handful of tests, which relies on shell behavior, turned out to fail on Windows when running under MSYS2. I have filed separate bugs, and submitted PRs, to get these fixed:
> 
> * https://bugs.openjdk.org/browse/JDK-8287902
> 
> * https://bugs.openjdk.org/browse/JDK-8287895

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Remove bundle artifacts

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9063/files
  - new: https://git.openjdk.org/jdk/pull/9063/files/385bbd72..c0f9bb1e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9063&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9063&range=10-11

  Stats: 47 lines in 1 file changed: 47 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9063.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9063/head:pull/9063

PR: https://git.openjdk.org/jdk/pull/9063


From ihse at openjdk.java.net  Mon Jun 13 06:53:08 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 13 Jun 2022 06:53:08 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v12]
In-Reply-To: <8-SlvyGCEzz8OqurYiFYC5QUGThLrFvJ51SHkgihx-M=.924d4ba9-615c-4bcf-afda-1fd4db264b6f@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
 <8-SlvyGCEzz8OqurYiFYC5QUGThLrFvJ51SHkgihx-M=.924d4ba9-615c-4bcf-afda-1fd4db264b6f@github.com>
Message-ID: <7CQOASm3byYd_g1By_3s7g0kd6K4aCE6GVFoiLe6EGM=.498446e8-3dc1-4ed8-86c1-db4542e442ef@github.com>

On Mon, 13 Jun 2022 06:45:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> With project Skara, the ability to run a set of sanity build and test jobs on selected platforms was added. This functionality was driven by `.github/workflows/submit.yml`. This file unfortunately lacks any real structure, and contains a lot of code duplication and redundancy. This has made it hard to add functionality, and new platforms to test, and it has made it even harder to debug issues. (This is hard enough as it is, since we have no direct access to the platforms that GHA runs on.)
>> 
>> Since the GHA tests are important for a large subset of the community, we need to do better. 
>> 
>> ## GitHub Actions framework rewrite
>>  
>> This is a complete overhaul of the GHA testing framework. I started out trying to just tease the old `submit.yml` apart, trying to de-duplicate code, but I soon realized a much more thorough rework was needed.
>> 
>> ### Design description
>> 
>> The principle for the new design was to avoid code duplication, and to improve readability of the code. The latter is extra important since the GHA "language" is very limited, needs a lot of quirks and workarounds, and is probably not well known by many OpenJDK developers. I've strived to find useful layers of abstraction to make the expressions as clear as possible.
>> 
>> Unfortunately, the Workflow/Action YAML language is quite limited. There are two ways to avoid duplication, "local composite actions" and "callable workflows". They both have several limitations:
>> 
>>  * "Callable workflows" can only be used in a single redirection. They are (apparently) inlined into the "calling workflow" at run time, and as such, they are present without having to check out the source code. (Which is a lengthy process.)
>> 
>>  * "Local composite actions" can use other actions, but you must start by checking out the repo.
>> 
>> To use the strength of both kinds of sub-modules, I'm using "callable workflows" from `main.yml` to call `build-<platform>.yml` and `test.yml`. It is not allowed to mix "strategies" (that is, the method of automatically creating a test matrix) when calling callable workflows, so I needed to have some amount of duplication in `main.yml` that could have been avoided otherwise.
>> 
>> All the callable workflows need to check out the source code anyway, so there is no real additional cost of using "local composite actions" for abstraction of these workflows. (A bit of a lucky break.) I've created "high level" actions, corresponding to something like a function call. The goal here was both to avoid duplication, and to improve readability of the workflows.
>> 
>> The four `build-<platform>.yml` files are very similar. But in the end of the day, only like 50% of the source code is shared, and the platform specific changes permeate the files. So I decided to keep them separately, since mixing them all into one would have made a mess, due to the lack of proper abstraction mechanisms. But that also mean that if we change platform independent code in building, we need to remember to update it in all four places.
>> 
>> In the strictest sense, this is a "refactoring" in that the functionality should be equal to the old `submit.yml`. The same platforms should build, with the same arguments, and the same tests should run. When I look at the code now, I see lots of potential for improvement here, by rethinking what we do run. But let's save that discussion for the next PR.
>> 
>> There is one major change, though. Windows is no longer running on Cygwin, but on MSYS2. This was not really triggered by the recurring build issues on Cygwin (though that certainly did help me in thinking I made the right choice), but the sheer impossibility of getting Cygwin to behave as a normal unix shell on GHA Windows hosts. I spent countless hours trying to work out limitations, by setting `SHELLOPTS=igncr`, by running `set +x posix` to turn of the POSIX compliance mode that kept turning on by itself and made bash choke on several of our scripts, by playing tricks with the `PATH`, but in the end to no avail. There were no single combination of hacks and workarounds that could get us past the entire chain from configure, to build, to testing. (The old solution user PowerShell instead to get around these limitations.) I'm happy to report that I have had absolutely zero issues with MSYS2 since I made the switch (and understood how to set the PATH properly), and I'm seriously c
 onsidering switching stance to recommend using MSYS2 instead of Cygwin as the primary winenv for building the JDK.
>> 
>> ### Example run
>> 
>> A good example on how a run looks like with the new GHA system is [the run for this PR](https://github.com/magicus/jdk/actions/runs/2454577164).
>> 
>> ### New features
>> 
>> While the primary focus was to convert the old system to a new framework, more accommodating to development, and to wait with further enhancements for the future, I have made a few additional features already in this PR. Most of them are related to needs that arose during development of this PR.
>> 
>> * A build failure summary, similar to the recently added test failure summary, is added when the build step fails
>> 
>> * The test reporting has been extended to all platforms, including Windows
>> 
>> * Test reporting has been improved slightly, and gotten multiple bug fixes
>> 
>> * All artifacts are now available for individual download. This includes:
>> 
>>   * The build bundles, per platform
>>   * The test results, per platform and test suite
>>   * Build failure logs, in case of build failure
>> 
>>   The build bundles have a retention period of 24 h, but the rest uses GitHub's default retention period (currently 90 days). The idea is that you can use GHA to download builds for platforms you might not have access to, but after that, conserving the builds does not make sense. GitHub currently provides free, unlimited storage (within the retention period) for artifacts, so we can afford this.
>> 
>> * The GHA process starts up much faster, which mean that e.g. a build failure on an exotic platform will show up earlier. This will not really affect the overall run time though, since it is bounded by variables such as queuing for workers, and waiting on tests with somewhat arbitrarily run times to finish.
>> 
>> ### Additional changes outside GHA
>> 
>> I also needed to make a few tweaks to the build system to play nice with the new GHA code.
>> 
>> * The build failure summary is now stored in build/$BUILD/make-support/failure-summary.log
>> 
>> * The configure summary now indicates what devkit or sysroot is used, if any
>> 
>> * The --with-sysroot argument is now properly normalized
>> 
>> ### Test failures
>> 
>> A handful of tests, which relies on shell behavior, turned out to fail on Windows when running under MSYS2. I have filed separate bugs, and submitted PRs, to get these fixed:
>> 
>> * https://bugs.openjdk.org/browse/JDK-8287902
>> 
>> * https://bugs.openjdk.org/browse/JDK-8287895
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove bundle artifacts

I'm restoring the old "functionality" of removing the newly built bundles from the set of artifacts. Even though the GHA runs in the users' personal forks, and the artifacts expire in 24 h, some of my co-workers felt this could be misconstrued as a binary distribution from the JDK project, which we are not in the business of doing. (If anyone disagrees with this interpretation, please save that discussion for a separate time. It is easy to restore the functionality if need be.)

-------------

PR: https://git.openjdk.org/jdk/pull/9063


From duke at openjdk.java.net  Mon Jun 13 06:54:06 2022
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Mon, 13 Jun 2022 06:54:06 GMT
Subject: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default
In-Reply-To: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
References: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
Message-ID: <XOvpFs3L_qkUSrCztK_3ZYF2yiCoVaLvd9xd9JRDi48=.7934314d-782d-4cc6-8997-9e48c9627410@github.com>

On Wed, 8 Jun 2022 07:47:24 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

> At default configuration, SOURCE_DATE_EPOCH is exported as environment variable in SetupReproducibleBuild. Then, gcc is affected of SOURCE_DATE_EPOCH environment variable. This value is used only to set SOURCE_DATE_ISO_8601 (except below), so I removed "export" for SOURCE_DATE_EPOCH in SetupReproducibleBuild. And, at building ct.sym, SOURCE_DATE_EPOCH environment variable is needed. So I added setting routine if SOURCE_DATE_EPOCH is not set.
> 
> This fix works fine. With default configuration shows -Xinternalversion output same as Windows, and with --with-source-date configuration shows -Xinternalversion output specified timestamp. Would you please review this fix?

Thank you for your comments.
I understood the goal of reproducible build. But now, ENABLE_REPRODUCIBLE_BUILD is set to false in default configuration.
Then I think minimize the effort of SOURCE_DATE_EPOCH when reproducible build is disabled. I wonder why build time information is different from Windows and Linux.

-------------

PR: https://git.openjdk.org/jdk/pull/9081


From ihse at openjdk.java.net  Mon Jun 13 07:17:53 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 13 Jun 2022 07:17:53 GMT
Subject: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default
In-Reply-To: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
References: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
Message-ID: <faW2AaIxj_dpfar5Aah90IehCsdATzePzFWUvZMdc78=.0c1716f0-7f65-41e1-9ff5-f8df99dd45a4@github.com>

On Wed, 8 Jun 2022 07:47:24 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

> At default configuration, SOURCE_DATE_EPOCH is exported as environment variable in SetupReproducibleBuild. Then, gcc is affected of SOURCE_DATE_EPOCH environment variable. This value is used only to set SOURCE_DATE_ISO_8601 (except below), so I removed "export" for SOURCE_DATE_EPOCH in SetupReproducibleBuild. And, at building ct.sym, SOURCE_DATE_EPOCH environment variable is needed. So I added setting routine if SOURCE_DATE_EPOCH is not set.
> 
> This fix works fine. With default configuration shows -Xinternalversion output same as Windows, and with --with-source-date configuration shows -Xinternalversion output specified timestamp. Would you please review this fix?

What do you mean by "build time information"?

-------------

PR: https://git.openjdk.org/jdk/pull/9081


From erikj at openjdk.java.net  Mon Jun 13 08:43:09 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 13 Jun 2022 08:43:09 GMT
Subject: RFR: 8288114: Update JIRA link in vcs.xml
In-Reply-To: <kUYuV5md8sfEcVrehSWXg2g9ddAyK8Z-__C1eGv6KiY=.93b555b6-102d-4b19-a617-c775c4fa06e1@github.com>
References: <kUYuV5md8sfEcVrehSWXg2g9ddAyK8Z-__C1eGv6KiY=.93b555b6-102d-4b19-a617-c775c4fa06e1@github.com>
Message-ID: <0N84qD7K3VWX5L2b37EYvaqPWeDRkghc6b66Or-YoUE=.9b088bb6-bb35-45d5-803a-ea0a5cf1510f@github.com>

On Fri, 10 Jun 2022 17:11:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Update the link to JBS in `vcs.xml` template to https://bugs.openjdk.org/
> 
> It will affect newly generated project files only.  
> Edit `vcs.xml` manually or in UI to update in existing projects.

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9130


From erikj at openjdk.java.net  Mon Jun 13 09:48:52 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 13 Jun 2022 09:48:52 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v12]
In-Reply-To: <8-SlvyGCEzz8OqurYiFYC5QUGThLrFvJ51SHkgihx-M=.924d4ba9-615c-4bcf-afda-1fd4db264b6f@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
 <8-SlvyGCEzz8OqurYiFYC5QUGThLrFvJ51SHkgihx-M=.924d4ba9-615c-4bcf-afda-1fd4db264b6f@github.com>
Message-ID: <oRhmR5RsP0Kh4UXyOFK0R5teAvwxXeag-XfYh3ef8pw=.bc38396a-49b3-4c64-ba9f-fcc03ac412e7@github.com>

On Mon, 13 Jun 2022 06:45:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> With project Skara, the ability to run a set of sanity build and test jobs on selected platforms was added. This functionality was driven by `.github/workflows/submit.yml`. This file unfortunately lacks any real structure, and contains a lot of code duplication and redundancy. This has made it hard to add functionality, and new platforms to test, and it has made it even harder to debug issues. (This is hard enough as it is, since we have no direct access to the platforms that GHA runs on.)
>> 
>> Since the GHA tests are important for a large subset of the community, we need to do better. 
>> 
>> ## GitHub Actions framework rewrite
>>  
>> This is a complete overhaul of the GHA testing framework. I started out trying to just tease the old `submit.yml` apart, trying to de-duplicate code, but I soon realized a much more thorough rework was needed.
>> 
>> ### Design description
>> 
>> The principle for the new design was to avoid code duplication, and to improve readability of the code. The latter is extra important since the GHA "language" is very limited, needs a lot of quirks and workarounds, and is probably not well known by many OpenJDK developers. I've strived to find useful layers of abstraction to make the expressions as clear as possible.
>> 
>> Unfortunately, the Workflow/Action YAML language is quite limited. There are two ways to avoid duplication, "local composite actions" and "callable workflows". They both have several limitations:
>> 
>>  * "Callable workflows" can only be used in a single redirection. They are (apparently) inlined into the "calling workflow" at run time, and as such, they are present without having to check out the source code. (Which is a lengthy process.)
>> 
>>  * "Local composite actions" can use other actions, but you must start by checking out the repo.
>> 
>> To use the strength of both kinds of sub-modules, I'm using "callable workflows" from `main.yml` to call `build-<platform>.yml` and `test.yml`. It is not allowed to mix "strategies" (that is, the method of automatically creating a test matrix) when calling callable workflows, so I needed to have some amount of duplication in `main.yml` that could have been avoided otherwise.
>> 
>> All the callable workflows need to check out the source code anyway, so there is no real additional cost of using "local composite actions" for abstraction of these workflows. (A bit of a lucky break.) I've created "high level" actions, corresponding to something like a function call. The goal here was both to avoid duplication, and to improve readability of the workflows.
>> 
>> The four `build-<platform>.yml` files are very similar. But in the end of the day, only like 50% of the source code is shared, and the platform specific changes permeate the files. So I decided to keep them separately, since mixing them all into one would have made a mess, due to the lack of proper abstraction mechanisms. But that also mean that if we change platform independent code in building, we need to remember to update it in all four places.
>> 
>> In the strictest sense, this is a "refactoring" in that the functionality should be equal to the old `submit.yml`. The same platforms should build, with the same arguments, and the same tests should run. When I look at the code now, I see lots of potential for improvement here, by rethinking what we do run. But let's save that discussion for the next PR.
>> 
>> There is one major change, though. Windows is no longer running on Cygwin, but on MSYS2. This was not really triggered by the recurring build issues on Cygwin (though that certainly did help me in thinking I made the right choice), but the sheer impossibility of getting Cygwin to behave as a normal unix shell on GHA Windows hosts. I spent countless hours trying to work out limitations, by setting `SHELLOPTS=igncr`, by running `set +x posix` to turn of the POSIX compliance mode that kept turning on by itself and made bash choke on several of our scripts, by playing tricks with the `PATH`, but in the end to no avail. There were no single combination of hacks and workarounds that could get us past the entire chain from configure, to build, to testing. (The old solution user PowerShell instead to get around these limitations.) I'm happy to report that I have had absolutely zero issues with MSYS2 since I made the switch (and understood how to set the PATH properly), and I'm seriously c
 onsidering switching stance to recommend using MSYS2 instead of Cygwin as the primary winenv for building the JDK.
>> 
>> ### Example run
>> 
>> A good example on how a run looks like with the new GHA system is [the run for this PR](https://github.com/magicus/jdk/actions/runs/2454577164).
>> 
>> ### New features
>> 
>> While the primary focus was to convert the old system to a new framework, more accommodating to development, and to wait with further enhancements for the future, I have made a few additional features already in this PR. Most of them are related to needs that arose during development of this PR.
>> 
>> * A build failure summary, similar to the recently added test failure summary, is added when the build step fails
>> 
>> * The test reporting has been extended to all platforms, including Windows
>> 
>> * Test reporting has been improved slightly, and gotten multiple bug fixes
>> 
>> * All artifacts are now available for individual download. This includes:
>> 
>>   * The build bundles, per platform
>>   * The test results, per platform and test suite
>>   * Build failure logs, in case of build failure
>> 
>>   The build bundles have a retention period of 24 h, but the rest uses GitHub's default retention period (currently 90 days). The idea is that you can use GHA to download builds for platforms you might not have access to, but after that, conserving the builds does not make sense. GitHub currently provides free, unlimited storage (within the retention period) for artifacts, so we can afford this.
>> 
>> * The GHA process starts up much faster, which mean that e.g. a build failure on an exotic platform will show up earlier. This will not really affect the overall run time though, since it is bounded by variables such as queuing for workers, and waiting on tests with somewhat arbitrarily run times to finish.
>> 
>> ### Additional changes outside GHA
>> 
>> I also needed to make a few tweaks to the build system to play nice with the new GHA code.
>> 
>> * The build failure summary is now stored in build/$BUILD/make-support/failure-summary.log
>> 
>> * The configure summary now indicates what devkit or sysroot is used, if any
>> 
>> * The --with-sysroot argument is now properly normalized
>> 
>> ### Test failures
>> 
>> A handful of tests, which relies on shell behavior, turned out to fail on Windows when running under MSYS2. I have filed separate bugs, and submitted PRs, to get these fixed:
>> 
>> * https://bugs.openjdk.org/browse/JDK-8287902
>> 
>> * https://bugs.openjdk.org/browse/JDK-8287895
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove bundle artifacts

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9063


From sgehwolf at openjdk.java.net  Mon Jun 13 09:51:00 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 13 Jun 2022 09:51:00 GMT
Subject: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default
In-Reply-To: <faW2AaIxj_dpfar5Aah90IehCsdATzePzFWUvZMdc78=.0c1716f0-7f65-41e1-9ff5-f8df99dd45a4@github.com>
References: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
 <faW2AaIxj_dpfar5Aah90IehCsdATzePzFWUvZMdc78=.0c1716f0-7f65-41e1-9ff5-f8df99dd45a4@github.com>
Message-ID: <IrrVrkrSEoNCqWxzCdp1r1i4x-lZtxfkUpedxysLUdw=.35b62496-24e2-4450-8eec-26d68234d1a9@github.com>

On Mon, 13 Jun 2022 07:14:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> At default configuration, SOURCE_DATE_EPOCH is exported as environment variable in SetupReproducibleBuild. Then, gcc is affected of SOURCE_DATE_EPOCH environment variable. This value is used only to set SOURCE_DATE_ISO_8601 (except below), so I removed "export" for SOURCE_DATE_EPOCH in SetupReproducibleBuild. And, at building ct.sym, SOURCE_DATE_EPOCH environment variable is needed. So I added setting routine if SOURCE_DATE_EPOCH is not set.
>> 
>> This fix works fine. With default configuration shows -Xinternalversion output same as Windows, and with --with-source-date configuration shows -Xinternalversion output specified timestamp. Would you please review this fix?
>
> What do you mean by "build time information"?

@magicus I think it's `-Xinternalversion` which has different output between Windows and Linux of the same build. But to me that's a feature not a bug. From the PR description:

> With default configuration shows `-Xinternalversion` output same as Windows, [...]

-------------

PR: https://git.openjdk.org/jdk/pull/9081


From aivanov at openjdk.java.net  Mon Jun 13 12:15:08 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 13 Jun 2022 12:15:08 GMT
Subject: RFR: 8288114: Update JIRA link in vcs.xml
In-Reply-To: <kUYuV5md8sfEcVrehSWXg2g9ddAyK8Z-__C1eGv6KiY=.93b555b6-102d-4b19-a617-c775c4fa06e1@github.com>
References: <kUYuV5md8sfEcVrehSWXg2g9ddAyK8Z-__C1eGv6KiY=.93b555b6-102d-4b19-a617-c775c4fa06e1@github.com>
Message-ID: <zYQyMJ-lLh2wScL4AAF1_KbjI-SEZRG9YbqidQvJiyo=.4dd09d84-aa52-4e55-90d5-9d7e4ce9f076@github.com>

On Fri, 10 Jun 2022 17:11:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Update the link to JBS in `vcs.xml` template to https://bugs.openjdk.org/
> 
> It will affect newly generated project files only.  
> Edit `vcs.xml` manually or in UI to update in existing projects.

Bot, wake up! Will it help?

-------------

PR: https://git.openjdk.org/jdk/pull/9130


From aivanov at openjdk.java.net  Mon Jun 13 14:53:54 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 13 Jun 2022 14:53:54 GMT
Subject: Integrated: 8288114: Update JIRA link in vcs.xml
In-Reply-To: <kUYuV5md8sfEcVrehSWXg2g9ddAyK8Z-__C1eGv6KiY=.93b555b6-102d-4b19-a617-c775c4fa06e1@github.com>
References: <kUYuV5md8sfEcVrehSWXg2g9ddAyK8Z-__C1eGv6KiY=.93b555b6-102d-4b19-a617-c775c4fa06e1@github.com>
Message-ID: <uj71NExt1vyuQh-6xREFECm-XhpqEZUKweuEh2UlGck=.6e9a66a5-9bfb-4dff-bd4c-7e243ed6cdca@github.com>

On Fri, 10 Jun 2022 17:11:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Update the link to JBS in `vcs.xml` template to https://bugs.openjdk.org/
> 
> It will affect newly generated project files only.  
> Edit `vcs.xml` manually or in UI to update in existing projects.

This pull request has now been integrated.

Changeset: b97a4f6c
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b97a4f6cdcd5e497ab901e68923666e493414825
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8288114: Update JIRA link in vcs.xml

Reviewed-by: mcimadamore, ihse, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/9130


From cstein at openjdk.java.net  Mon Jun 13 15:04:08 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Mon, 13 Jun 2022 15:04:08 GMT
Subject: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v12]
In-Reply-To: <8-SlvyGCEzz8OqurYiFYC5QUGThLrFvJ51SHkgihx-M=.924d4ba9-615c-4bcf-afda-1fd4db264b6f@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
 <8-SlvyGCEzz8OqurYiFYC5QUGThLrFvJ51SHkgihx-M=.924d4ba9-615c-4bcf-afda-1fd4db264b6f@github.com>
Message-ID: <1wjW8GKb8FhGn7Di9rC_JIKo6-2VPZcr8Lna5rBPk-8=.023ed586-6756-4be4-9a0f-753616508c6f@github.com>

On Mon, 13 Jun 2022 06:45:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> With project Skara, the ability to run a set of sanity build and test jobs on selected platforms was added. This functionality was driven by `.github/workflows/submit.yml`. This file unfortunately lacks any real structure, and contains a lot of code duplication and redundancy. This has made it hard to add functionality, and new platforms to test, and it has made it even harder to debug issues. (This is hard enough as it is, since we have no direct access to the platforms that GHA runs on.)
>> 
>> Since the GHA tests are important for a large subset of the community, we need to do better. 
>> 
>> ## GitHub Actions framework rewrite
>>  
>> This is a complete overhaul of the GHA testing framework. I started out trying to just tease the old `submit.yml` apart, trying to de-duplicate code, but I soon realized a much more thorough rework was needed.
>> 
>> ### Design description
>> 
>> The principle for the new design was to avoid code duplication, and to improve readability of the code. The latter is extra important since the GHA "language" is very limited, needs a lot of quirks and workarounds, and is probably not well known by many OpenJDK developers. I've strived to find useful layers of abstraction to make the expressions as clear as possible.
>> 
>> Unfortunately, the Workflow/Action YAML language is quite limited. There are two ways to avoid duplication, "local composite actions" and "callable workflows". They both have several limitations:
>> 
>>  * "Callable workflows" can only be used in a single redirection. They are (apparently) inlined into the "calling workflow" at run time, and as such, they are present without having to check out the source code. (Which is a lengthy process.)
>> 
>>  * "Local composite actions" can use other actions, but you must start by checking out the repo.
>> 
>> To use the strength of both kinds of sub-modules, I'm using "callable workflows" from `main.yml` to call `build-<platform>.yml` and `test.yml`. It is not allowed to mix "strategies" (that is, the method of automatically creating a test matrix) when calling callable workflows, so I needed to have some amount of duplication in `main.yml` that could have been avoided otherwise.
>> 
>> All the callable workflows need to check out the source code anyway, so there is no real additional cost of using "local composite actions" for abstraction of these workflows. (A bit of a lucky break.) I've created "high level" actions, corresponding to something like a function call. The goal here was both to avoid duplication, and to improve readability of the workflows.
>> 
>> The four `build-<platform>.yml` files are very similar. But in the end of the day, only like 50% of the source code is shared, and the platform specific changes permeate the files. So I decided to keep them separately, since mixing them all into one would have made a mess, due to the lack of proper abstraction mechanisms. But that also mean that if we change platform independent code in building, we need to remember to update it in all four places.
>> 
>> In the strictest sense, this is a "refactoring" in that the functionality should be equal to the old `submit.yml`. The same platforms should build, with the same arguments, and the same tests should run. When I look at the code now, I see lots of potential for improvement here, by rethinking what we do run. But let's save that discussion for the next PR.
>> 
>> There is one major change, though. Windows is no longer running on Cygwin, but on MSYS2. This was not really triggered by the recurring build issues on Cygwin (though that certainly did help me in thinking I made the right choice), but the sheer impossibility of getting Cygwin to behave as a normal unix shell on GHA Windows hosts. I spent countless hours trying to work out limitations, by setting `SHELLOPTS=igncr`, by running `set +x posix` to turn of the POSIX compliance mode that kept turning on by itself and made bash choke on several of our scripts, by playing tricks with the `PATH`, but in the end to no avail. There were no single combination of hacks and workarounds that could get us past the entire chain from configure, to build, to testing. (The old solution user PowerShell instead to get around these limitations.) I'm happy to report that I have had absolutely zero issues with MSYS2 since I made the switch (and understood how to set the PATH properly), and I'm seriously c
 onsidering switching stance to recommend using MSYS2 instead of Cygwin as the primary winenv for building the JDK.
>> 
>> ### Example run
>> 
>> A good example on how a run looks like with the new GHA system is [the run for this PR](https://github.com/magicus/jdk/actions/runs/2454577164).
>> 
>> ### New features
>> 
>> While the primary focus was to convert the old system to a new framework, more accommodating to development, and to wait with further enhancements for the future, I have made a few additional features already in this PR. Most of them are related to needs that arose during development of this PR.
>> 
>> * A build failure summary, similar to the recently added test failure summary, is added when the build step fails
>> 
>> * The test reporting has been extended to all platforms, including Windows
>> 
>> * Test reporting has been improved slightly, and gotten multiple bug fixes
>> 
>> * All artifacts are now available for individual download. This includes:
>> 
>>   * The build bundles, per platform
>>   * The test results, per platform and test suite
>>   * Build failure logs, in case of build failure
>> 
>>   The build bundles have a retention period of 24 h, but the rest uses GitHub's default retention period (currently 90 days). The idea is that you can use GHA to download builds for platforms you might not have access to, but after that, conserving the builds does not make sense. GitHub currently provides free, unlimited storage (within the retention period) for artifacts, so we can afford this.
>> 
>> * The GHA process starts up much faster, which mean that e.g. a build failure on an exotic platform will show up earlier. This will not really affect the overall run time though, since it is bounded by variables such as queuing for workers, and waiting on tests with somewhat arbitrarily run times to finish.
>> 
>> ### Additional changes outside GHA
>> 
>> I also needed to make a few tweaks to the build system to play nice with the new GHA code.
>> 
>> * The build failure summary is now stored in build/$BUILD/make-support/failure-summary.log
>> 
>> * The configure summary now indicates what devkit or sysroot is used, if any
>> 
>> * The --with-sysroot argument is now properly normalized
>> 
>> ### Test failures
>> 
>> A handful of tests, which relies on shell behavior, turned out to fail on Windows when running under MSYS2. I have filed separate bugs, and submitted PRs, to get these fixed:
>> 
>> * https://bugs.openjdk.org/browse/JDK-8287902
>> 
>> * https://bugs.openjdk.org/browse/JDK-8287895
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove bundle artifacts

Splitting logic into smaller actions, scripts and workflow definition is great!
`jtreg`-related changes look good to me.

-------------

Marked as reviewed by cstein (Author).

PR: https://git.openjdk.org/jdk/pull/9063


From bradford.wetmore at oracle.com  Tue Jun 14 00:01:04 2022
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Mon, 13 Jun 2022 17:01:04 -0700
Subject: Warning about git from 'make test' on Windows
In-Reply-To: <PAXPR02MB7799A7161D75D758C535D04D8AA19@PAXPR02MB7799.eurprd02.prod.outlook.com>
References: <CAF+DQ5fxyDtf4X5vXXeL-8TQEoZupecp_9O4KQsNSSwN2pOLJg@mail.gmail.com>
 <cefd3097-41e8-3d2f-1c42-3d31005169be@oracle.com>
 <PAXPR02MB7799A7161D75D758C535D04D8AA19@PAXPR02MB7799.eurprd02.prod.outlook.com>
Message-ID: <9c3dc89a-4d93-18aa-b98a-b52767026c88@oracle.com>

Andrey/Christoph,

This may be a little late, but...

> Maybe this gives a hint on how to fix it?

I (and others in my group) typically use the root c:/cygwin and avoid 
this whole issue.

Brad



On 6/3/2022 12:09 AM, Langer, Christoph wrote:
> Hi,
> 
> I see the same on my windows build. I verified that 8.3 filenames are enabled.
> 
> I took a little closer look. In my PATH env in Cygwin I have: ...:/cygdrive/c/Program Files/Git/cmd:...
> 
> The git path is resolved via UTIL_LOOKUP_PROGS(GIT, git) in basic_tools.m4. UTIL_LOOKUP_PROGS, defined in util_paths.m4 must somehow not be capable to correctly resolve the path with spaces. The output in configure is:
> 
> checking for git...  Files/Git/cmd/git
> 
> Maybe this gives a hint on how to fix it? I guess I can configure my path to use the 8.3 notation. But maybe UTIL_LOOKUP_PROGS could be improved?
> 
> Cheers
> Christoph
> 
>> -----Original Message-----
>> From: build-dev <build-dev-retn at openjdk.java.net> On Behalf Of Magnus Ihse
>> Bursie
>> Sent: Freitag, 3. Juni 2022 01:10
>> To: Andrey Turbanov <turbanoff at gmail.com>; build-dev at openjdk.java.net
>> Subject: Re: Warning about git from 'make test' on Windows
>>
>>
>> On 2022-06-02 21:26, Andrey Turbanov wrote:
>>> Hello.
>>> I noticed strange warnings produced by 'make test' recently on my
>>> Win11 installation. For example:
>>>
>>> $ make test TEST="tier1"
>>> Building target 'test' in configuration 'windows-x86_64-server-release'
>>> /usr/bin/bash: Files/Git/cmd/git: No such file or directory
>>> /usr/bin/bash: Files/Git/cmd/git: No such file or directory Test
>>> selection 'tier1', will run:
>>>
>>>
>>> Also found this in
>>> build\windows-x86_64-server-release\configure-support\config.log
>>>
>>> configure:29274: checking for git
>>> configure:29502: result:  Files/Git/cmd/git
>>>
>>> Seems like space in git path is incorrectly handled.
>>> Is it a known issue or is it a limitation of autoconf?
>> Spaces in paths is always tricky and is best avoided. That being said, we try to
>> make autoconf robust for tools in directories with space in them.
>>
>> Are you running in Cygwin?
>>
>> Can you verify that your C: drive can use short paths. See
>> https://openjdk.java.net/groups/build/doc/building.html#spaces-in-path
>>
>> /Magnus
>>>
>>> Andrey Turbanov
> 


From ihse at openjdk.java.net  Tue Jun 14 07:45:00 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 14 Jun 2022 07:45:00 GMT
Subject: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default
In-Reply-To: <IrrVrkrSEoNCqWxzCdp1r1i4x-lZtxfkUpedxysLUdw=.35b62496-24e2-4450-8eec-26d68234d1a9@github.com>
References: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
 <faW2AaIxj_dpfar5Aah90IehCsdATzePzFWUvZMdc78=.0c1716f0-7f65-41e1-9ff5-f8df99dd45a4@github.com>
 <IrrVrkrSEoNCqWxzCdp1r1i4x-lZtxfkUpedxysLUdw=.35b62496-24e2-4450-8eec-26d68234d1a9@github.com>
Message-ID: <AkG3jzrCOMcPm5_CFyvGU1LKJETUtKl4bOY1erWpSuI=.ea4b3a09-14cc-4dfc-a1e9-c371d5d04681@github.com>

On Mon, 13 Jun 2022 09:47:48 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> What do you mean by "build time information"?
>
> @magicus I think it's `-Xinternalversion` which has different output between Windows and Linux of the same build. But to me that's a feature not a bug. From the PR description:
> 
>> With default configuration shows `-Xinternalversion` output same as Windows, [...]

@jerboaa I agree. If anything, this PR makes me want to remove the option to *not* build reproducible. That way, there will be no discrepancies between platforms.

-------------

PR: https://git.openjdk.org/jdk/pull/9081


From ihse at openjdk.java.net  Tue Jun 14 07:53:25 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 14 Jun 2022 07:53:25 GMT
Subject: Integrated: 8287906: Rewrite of GitHub Actions (GHA) sanity tests
In-Reply-To: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
References: <AclcOI_tFsDdVMZBF4senDKoFkJ4HO8tCfCcd0pLbvk=.20d6c186-da6e-4bc7-b0fd-b983ee91c0eb@github.com>
Message-ID: <bjsMm-HxaM3x-i-U-OXQ6LJxmdo2-u5wU-SeMjSquTU=.3f0d8110-f5a9-4a61-bcc7-7954a9b238ba@github.com>

On Tue, 7 Jun 2022 13:05:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> With project Skara, the ability to run a set of sanity build and test jobs on selected platforms was added. This functionality was driven by `.github/workflows/submit.yml`. This file unfortunately lacks any real structure, and contains a lot of code duplication and redundancy. This has made it hard to add functionality, and new platforms to test, and it has made it even harder to debug issues. (This is hard enough as it is, since we have no direct access to the platforms that GHA runs on.)
> 
> Since the GHA tests are important for a large subset of the community, we need to do better. 
> 
> ## GitHub Actions framework rewrite
>  
> This is a complete overhaul of the GHA testing framework. I started out trying to just tease the old `submit.yml` apart, trying to de-duplicate code, but I soon realized a much more thorough rework was needed.
> 
> ### Design description
> 
> The principle for the new design was to avoid code duplication, and to improve readability of the code. The latter is extra important since the GHA "language" is very limited, needs a lot of quirks and workarounds, and is probably not well known by many OpenJDK developers. I've strived to find useful layers of abstraction to make the expressions as clear as possible.
> 
> Unfortunately, the Workflow/Action YAML language is quite limited. There are two ways to avoid duplication, "local composite actions" and "callable workflows". They both have several limitations:
> 
>  * "Callable workflows" can only be used in a single redirection. They are (apparently) inlined into the "calling workflow" at run time, and as such, they are present without having to check out the source code. (Which is a lengthy process.)
> 
>  * "Local composite actions" can use other actions, but you must start by checking out the repo.
> 
> To use the strength of both kinds of sub-modules, I'm using "callable workflows" from `main.yml` to call `build-<platform>.yml` and `test.yml`. It is not allowed to mix "strategies" (that is, the method of automatically creating a test matrix) when calling callable workflows, so I needed to have some amount of duplication in `main.yml` that could have been avoided otherwise.
> 
> All the callable workflows need to check out the source code anyway, so there is no real additional cost of using "local composite actions" for abstraction of these workflows. (A bit of a lucky break.) I've created "high level" actions, corresponding to something like a function call. The goal here was both to avoid duplication, and to improve readability of the workflows.
> 
> The four `build-<platform>.yml` files are very similar. But in the end of the day, only like 50% of the source code is shared, and the platform specific changes permeate the files. So I decided to keep them separately, since mixing them all into one would have made a mess, due to the lack of proper abstraction mechanisms. But that also mean that if we change platform independent code in building, we need to remember to update it in all four places.
> 
> In the strictest sense, this is a "refactoring" in that the functionality should be equal to the old `submit.yml`. The same platforms should build, with the same arguments, and the same tests should run. When I look at the code now, I see lots of potential for improvement here, by rethinking what we do run. But let's save that discussion for the next PR.
> 
> There is one major change, though. Windows is no longer running on Cygwin, but on MSYS2. This was not really triggered by the recurring build issues on Cygwin (though that certainly did help me in thinking I made the right choice), but the sheer impossibility of getting Cygwin to behave as a normal unix shell on GHA Windows hosts. I spent countless hours trying to work out limitations, by setting `SHELLOPTS=igncr`, by running `set +x posix` to turn of the POSIX compliance mode that kept turning on by itself and made bash choke on several of our scripts, by playing tricks with the `PATH`, but in the end to no avail. There were no single combination of hacks and workarounds that could get us past the entire chain from configure, to build, to testing. (The old solution user PowerShell instead to get around these limitations.) I'm happy to report that I have had absolutely zero issues with MSYS2 since I made the switch (and understood how to set the PATH properly), and I'm seriously co
 nsidering switching stance to recommend using MSYS2 instead of Cygwin as the primary winenv for building the JDK.
> 
> ### Example run
> 
> A good example on how a run looks like with the new GHA system is [the run for this PR](https://github.com/magicus/jdk/actions/runs/2454577164).
> 
> ### New features
> 
> While the primary focus was to convert the old system to a new framework, more accommodating to development, and to wait with further enhancements for the future, I have made a few additional features already in this PR. Most of them are related to needs that arose during development of this PR.
> 
> * A build failure summary, similar to the recently added test failure summary, is added when the build step fails
> 
> * The test reporting has been extended to all platforms, including Windows
> 
> * Test reporting has been improved slightly, and gotten multiple bug fixes
> 
> * All artifacts are now available for individual download. This includes:
> 
>   * The build bundles, per platform
>   * The test results, per platform and test suite
>   * Build failure logs, in case of build failure
> 
>   The build bundles have a retention period of 24 h, but the rest uses GitHub's default retention period (currently 90 days). The idea is that you can use GHA to download builds for platforms you might not have access to, but after that, conserving the builds does not make sense. GitHub currently provides free, unlimited storage (within the retention period) for artifacts, so we can afford this.
> 
> * The GHA process starts up much faster, which mean that e.g. a build failure on an exotic platform will show up earlier. This will not really affect the overall run time though, since it is bounded by variables such as queuing for workers, and waiting on tests with somewhat arbitrarily run times to finish.
> 
> ### Additional changes outside GHA
> 
> I also needed to make a few tweaks to the build system to play nice with the new GHA code.
> 
> * The build failure summary is now stored in build/$BUILD/make-support/failure-summary.log
> 
> * The configure summary now indicates what devkit or sysroot is used, if any
> 
> * The --with-sysroot argument is now properly normalized
> 
> ### Test failures
> 
> A handful of tests, which relies on shell behavior, turned out to fail on Windows when running under MSYS2. I have filed separate bugs, and submitted PRs, to get these fixed:
> 
> * https://bugs.openjdk.org/browse/JDK-8287902
> 
> * https://bugs.openjdk.org/browse/JDK-8287895

This pull request has now been integrated.

Changeset: 1a653322
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1a6533225d8f4b9c5d21e236eaa9f827f096fa5d
Stats:     3994 lines in 20 files changed: 1911 ins; 2083 del; 0 mod

8287906: Rewrite of GitHub Actions (GHA) sanity tests

Reviewed-by: shade, erikj, cstein

-------------

PR: https://git.openjdk.org/jdk/pull/9063


From erikj at openjdk.java.net  Tue Jun 14 09:00:51 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 14 Jun 2022 09:00:51 GMT
Subject: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default
In-Reply-To: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
References: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
Message-ID: <p6ULnQnrZW_CElUlCe3m2TvI5f4UJjZUpD5m-bLNsx0=.7194efbe-827b-44e5-ba14-4b98c719ba82@github.com>

On Wed, 8 Jun 2022 07:47:24 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

> At default configuration, SOURCE_DATE_EPOCH is exported as environment variable in SetupReproducibleBuild. Then, gcc is affected of SOURCE_DATE_EPOCH environment variable. This value is used only to set SOURCE_DATE_ISO_8601 (except below), so I removed "export" for SOURCE_DATE_EPOCH in SetupReproducibleBuild. And, at building ct.sym, SOURCE_DATE_EPOCH environment variable is needed. So I added setting routine if SOURCE_DATE_EPOCH is not set.
> 
> This fix works fine. With default configuration shows -Xinternalversion output same as Windows, and with --with-source-date configuration shows -Xinternalversion output specified timestamp. Would you please review this fix?

Is the problem that on Windows we get -Xinternalversion in local timezone but on Linux we get UTC? That's a difference that may warrant fixing, but I don't think this is the way to do it. 

I don't think it makes a practical difference if the timestamp is taken at the start of the build or when a certain src file is compiled.

-------------

PR: https://git.openjdk.org/jdk/pull/9081


From ihse at openjdk.java.net  Tue Jun 14 09:54:44 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 14 Jun 2022 09:54:44 GMT
Subject: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default
In-Reply-To: <XOvpFs3L_qkUSrCztK_3ZYF2yiCoVaLvd9xd9JRDi48=.7934314d-782d-4cc6-8997-9e48c9627410@github.com>
References: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
 <XOvpFs3L_qkUSrCztK_3ZYF2yiCoVaLvd9xd9JRDi48=.7934314d-782d-4cc6-8997-9e48c9627410@github.com>
Message-ID: <s90ZHWiCJSzvHHeEUGACyP2851dTKt33JQL3q6iNK_w=.76c5f198-da40-4064-ac2a-c0844f1167dc@github.com>

On Mon, 13 Jun 2022 06:50:54 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

>> At default configuration, SOURCE_DATE_EPOCH is exported as environment variable in SetupReproducibleBuild. Then, gcc is affected of SOURCE_DATE_EPOCH environment variable. This value is used only to set SOURCE_DATE_ISO_8601 (except below), so I removed "export" for SOURCE_DATE_EPOCH in SetupReproducibleBuild. And, at building ct.sym, SOURCE_DATE_EPOCH environment variable is needed. So I added setting routine if SOURCE_DATE_EPOCH is not set.
>> 
>> This fix works fine. With default configuration shows -Xinternalversion output same as Windows, and with --with-source-date configuration shows -Xinternalversion output specified timestamp. Would you please review this fix?
>
> Thank you for your comments.
> I understood the goal of reproducible build. But now, ENABLE_REPRODUCIBLE_BUILD is set to false in default configuration.
> Then I think minimize the effort of SOURCE_DATE_EPOCH when reproducible build is disabled. I wonder why build time information is different from Windows and Linux.

@tkiriyama I have created https://bugs.openjdk.org/browse/JDK-8288396 for the approach I championed above, i.e. to always build reproducible instead. As part of this, the `-Xinternalversion` time stamp should be of the same format for all platforms, given the same set of options to `configure`.

The associated PR is https://github.com/openjdk/jdk/pull/9152. Can you verify if this solves your issues, and if so, close this bug?

-------------

PR: https://git.openjdk.org/jdk/pull/9081


From ihse at openjdk.java.net  Tue Jun 14 09:59:05 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 14 Jun 2022 09:59:05 GMT
Subject: RFR: 8288396: Always create reproducible builds
Message-ID: <ckkR5_LGhD3Q10LqP84yyapjrO6_RVFwcHGLsMiVZno=.8359d6b6-9510-4309-8cf5-10ee85706107@github.com>

When we started introducing some possibly more intrusive compiler flags and functionality for reproducible builds, we also introduced a flag to turn this off  out of an abundance of caution. But we have been been using this configuration for a year or so internally within Oracle, with no issues. So there's really no reason to be able to turn this off. (If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one.)

With this fix, all randomness should be gone from our builds, at least on linux and windows. There are no more `__DATE__` and `__TIME__` macros in the source code.

-------------

Commit messages:
 - 8288396: Always create reproducible builds

Changes: https://git.openjdk.org/jdk/pull/9152/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9152&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288396
  Stats: 94 lines in 15 files changed: 11 ins; 63 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/9152.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9152/head:pull/9152

PR: https://git.openjdk.org/jdk/pull/9152


From ihse at openjdk.java.net  Tue Jun 14 09:59:06 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 14 Jun 2022 09:59:06 GMT
Subject: RFR: 8288396: Always create reproducible builds
In-Reply-To: <ckkR5_LGhD3Q10LqP84yyapjrO6_RVFwcHGLsMiVZno=.8359d6b6-9510-4309-8cf5-10ee85706107@github.com>
References: <ckkR5_LGhD3Q10LqP84yyapjrO6_RVFwcHGLsMiVZno=.8359d6b6-9510-4309-8cf5-10ee85706107@github.com>
Message-ID: <sX_L8kUHlO_pv08Hsq34TRMlJQICyB5XBK9sDqFFTBQ=.0b85e579-c43a-42b3-b7a7-5eb3a4b1637f@github.com>

On Tue, 14 Jun 2022 09:48:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> When we started introducing some possibly more intrusive compiler flags and functionality for reproducible builds, we also introduced a flag to turn this off  out of an abundance of caution. But we have been been using this configuration for a year or so internally within Oracle, with no issues. So there's really no reason to be able to turn this off. (If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one.)
> 
> With this fix, all randomness should be gone from our builds, at least on linux and windows. There are no more `__DATE__` and `__TIME__` macros in the source code.

This PR also include a more "radical" version of JDK-8287894, which probably should have been adopted by JDK-8287894 in the first place. There is no need to include the build date in the assert strings for shmem on Windows.

-------------

PR: https://git.openjdk.org/jdk/pull/9152


From ihse at openjdk.java.net  Tue Jun 14 10:09:37 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 14 Jun 2022 10:09:37 GMT
Subject: RFR: 8288396: Always create reproducible builds [v2]
In-Reply-To: <ckkR5_LGhD3Q10LqP84yyapjrO6_RVFwcHGLsMiVZno=.8359d6b6-9510-4309-8cf5-10ee85706107@github.com>
References: <ckkR5_LGhD3Q10LqP84yyapjrO6_RVFwcHGLsMiVZno=.8359d6b6-9510-4309-8cf5-10ee85706107@github.com>
Message-ID: <WaK1CYepb_F0uwQ-8EGGszBcZkxsYUNsgJE5EKci8rU=.46ed1126-d015-47e5-a384-e8e6936540f2@github.com>

> When we started introducing some possibly more intrusive compiler flags and functionality for reproducible builds, we also introduced a flag to turn this off  out of an abundance of caution. But we have been been using this configuration for a year or so internally within Oracle, with no issues. So there's really no reason to be able to turn this off. (If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one.)
> 
> With this fix, all randomness should be gone from our builds, at least on linux and windows. There are no more `__DATE__` and `__TIME__` macros in the source code.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix exitTransportWithError signature

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9152/files
  - new: https://git.openjdk.org/jdk/pull/9152/files/8bc40ddb..e2f5fc05

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9152&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9152&range=00-01

  Stats: 33 lines in 5 files changed: 0 ins; 27 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/9152.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9152/head:pull/9152

PR: https://git.openjdk.org/jdk/pull/9152


From ihse at openjdk.java.net  Tue Jun 14 10:37:49 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 14 Jun 2022 10:37:49 GMT
Subject: RFR: 8288396: Always create reproducible builds [v2]
In-Reply-To: <WaK1CYepb_F0uwQ-8EGGszBcZkxsYUNsgJE5EKci8rU=.46ed1126-d015-47e5-a384-e8e6936540f2@github.com>
References: <ckkR5_LGhD3Q10LqP84yyapjrO6_RVFwcHGLsMiVZno=.8359d6b6-9510-4309-8cf5-10ee85706107@github.com>
 <WaK1CYepb_F0uwQ-8EGGszBcZkxsYUNsgJE5EKci8rU=.46ed1126-d015-47e5-a384-e8e6936540f2@github.com>
Message-ID: <nGnRVjmkrfVtHyLnCSKNdvRxMUxKvKgbmG4Oes2P0EI=.d3a4fdfd-32e9-491c-bf52-6d8fafafa3fb@github.com>

On Tue, 14 Jun 2022 10:09:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> When we started introducing some possibly more intrusive compiler flags and functionality for reproducible builds, we also introduced a flag to turn this off  out of an abundance of caution. But we have been been using this configuration for a year or so internally within Oracle, with no issues. So there's really no reason to be able to turn this off. (If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one.)
>> 
>> With this fix, all randomness should be gone from our builds, at least on linux and windows. There are no more `__DATE__` and `__TIME__` macros in the source code.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix exitTransportWithError signature

I made some additional cleanup associated with shmem. I think that `sysAssert` can (and probably should) be replaced with `SHMEM_ASSERT`. I can fix that as well, if someone from serviceability says that I should do it.

-------------

PR: https://git.openjdk.org/jdk/pull/9152


From erikj at openjdk.java.net  Tue Jun 14 12:02:01 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 14 Jun 2022 12:02:01 GMT
Subject: RFR: 8288396: Always create reproducible builds [v2]
In-Reply-To: <WaK1CYepb_F0uwQ-8EGGszBcZkxsYUNsgJE5EKci8rU=.46ed1126-d015-47e5-a384-e8e6936540f2@github.com>
References: <ckkR5_LGhD3Q10LqP84yyapjrO6_RVFwcHGLsMiVZno=.8359d6b6-9510-4309-8cf5-10ee85706107@github.com>
 <WaK1CYepb_F0uwQ-8EGGszBcZkxsYUNsgJE5EKci8rU=.46ed1126-d015-47e5-a384-e8e6936540f2@github.com>
Message-ID: <qnNiR3uk1tFvAoU-7ZjRmgz-_5Oec21f8EQEN8AwjpU=.7aafd8af-ca5d-4928-bd66-68b98f3aad03@github.com>

On Tue, 14 Jun 2022 10:09:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> When we started introducing some possibly more intrusive compiler flags and functionality for reproducible builds, we also introduced a flag to turn this off  out of an abundance of caution. But we have been been using this configuration for a year or so internally within Oracle, with no issues. So there's really no reason to be able to turn this off. (If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one.)
>> 
>> With this fix, all randomness should be gone from our builds, at least on linux and windows. There are no more `__DATE__` and `__TIME__` macros in the source code.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix exitTransportWithError signature

make/autoconf/flags-ldflags.m4 line 132:

> 130: 
> 131:   if test "x$TOOLCHAIN_TYPE" = xmicrosoft; then
> 132:     REPRODUCIBLE_LDFLAGS="-experimental:deterministic"

For the cflag, we check that the compiler supports it, but for the linker flag you are just setting it without a check. Before this patch, if we got here and ENABLE_REPRODUCIBLE_BUILD was true, it meant that the test had passed for the compiler, from which we could assume it would also work for the linker, but that is no longer the case.

-------------

PR: https://git.openjdk.org/jdk/pull/9152


From ihse at openjdk.java.net  Tue Jun 14 12:31:04 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 14 Jun 2022 12:31:04 GMT
Subject: RFR: 8288396: Always create reproducible builds [v2]
In-Reply-To: <qnNiR3uk1tFvAoU-7ZjRmgz-_5Oec21f8EQEN8AwjpU=.7aafd8af-ca5d-4928-bd66-68b98f3aad03@github.com>
References: <ckkR5_LGhD3Q10LqP84yyapjrO6_RVFwcHGLsMiVZno=.8359d6b6-9510-4309-8cf5-10ee85706107@github.com>
 <WaK1CYepb_F0uwQ-8EGGszBcZkxsYUNsgJE5EKci8rU=.46ed1126-d015-47e5-a384-e8e6936540f2@github.com>
 <qnNiR3uk1tFvAoU-7ZjRmgz-_5Oec21f8EQEN8AwjpU=.7aafd8af-ca5d-4928-bd66-68b98f3aad03@github.com>
Message-ID: <FvgWabi6pwwQKk2Bpu8_n92D1gsqcv3Sw51Gq1-Zyzo=.7a351ed1-81d7-42b6-94ef-23261da817ed@github.com>

On Tue, 14 Jun 2022 11:54:40 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix exitTransportWithError signature
>
> make/autoconf/flags-ldflags.m4 line 132:
> 
>> 130: 
>> 131:   if test "x$TOOLCHAIN_TYPE" = xmicrosoft; then
>> 132:     REPRODUCIBLE_LDFLAGS="-experimental:deterministic"
> 
> For the cflag, we check that the compiler supports it, but for the linker flag you are just setting it without a check. Before this patch, if we got here and ENABLE_REPRODUCIBLE_BUILD was true, it meant that the test had passed for the compiler, from which we could assume it would also work for the linker, but that is no longer the case.

Good point.

-------------

PR: https://git.openjdk.org/jdk/pull/9152


From chagedorn at openjdk.java.net  Tue Jun 14 16:03:19 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 14 Jun 2022 16:03:19 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v12]
In-Reply-To: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
Message-ID: <4Eha34Wka66ssPeJb4oEPphesBlxVrXmElPboudLK4s=.faa049f4-3c53-485c-812a-f36ae6d5c32c@github.com>

> When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method:
> 
> Stack: [0x00007f6e01739000,0x00007f6e0183a000],  sp=0x00007f6e01838110,  free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64
> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec
> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899
> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df
> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69
> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d
> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167
> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180
> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f
> 
> This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method.
> 
> This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)):
> 
> Stack: [0x00007f34fca18000,0x00007f34fcb19000],  sp=0x00007f34fcb17110,  free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64  (c1_Compilation.cpp:607)
> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec  (c1_Compiler.cpp:250)
> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899  (compileBroker.cpp:2291)
> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df  (compileBroker.cpp:1966)
> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69  (compilerThread.cpp:59)
> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d  (thread.cpp:1297)
> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167  (thread.cpp:1280)
> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180  (thread.cpp:358)
> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f  (os_linux.cpp:705)
> 
> For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. 
> 
> The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf
> I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. 
> 
> The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability.
> 
> Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. 
> 
> **Testing:**
> Apart from manual testing, I've added two kinds of tests:
> - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers.
> - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename.
> 
> On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation.
> 
> To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional  `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number.
> 
> I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user).
> 
> Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`!
>  
> Thanks,
> Christian

Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 68 commits:

 - Exclude TestDwarf.java when run with product because TraceDwarf is a develop flag
 - Merge branch 'master' into JDK-8242181
 - Merge branch 'master' into JDK-8242181
 - Fix TestDwarf for older GCC versions
 - Change logging from UL to tty based with new TraceDwarfLevel develop flag
 - Add support to parse the .debug_line section in DWARF 2 as emitted by GCC 8, add some comments
 - Merge branch 'master' into JDK-8242181
 - Merge branch 'master' into JDK-8242181
 - Merge branch 'master' into JDK-8242181
 - Fix build, add GCC flag gdwarf-4 to exclude DWARF 5, add assertions
 - ... and 58 more: https://git.openjdk.org/jdk/compare/c2ccf4ca...cb030f10

-------------

Changes: https://git.openjdk.org/jdk/pull/7126/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7126&range=11
  Stats: 2781 lines in 18 files changed: 2684 ins; 41 del; 56 mod
  Patch: https://git.openjdk.org/jdk/pull/7126.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7126/head:pull/7126

PR: https://git.openjdk.org/jdk/pull/7126


From amenkov at openjdk.java.net  Tue Jun 14 23:06:37 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 14 Jun 2022 23:06:37 GMT
Subject: RFR: 8288396: Always create reproducible builds [v2]
In-Reply-To: <FvgWabi6pwwQKk2Bpu8_n92D1gsqcv3Sw51Gq1-Zyzo=.7a351ed1-81d7-42b6-94ef-23261da817ed@github.com>
References: <ckkR5_LGhD3Q10LqP84yyapjrO6_RVFwcHGLsMiVZno=.8359d6b6-9510-4309-8cf5-10ee85706107@github.com>
 <WaK1CYepb_F0uwQ-8EGGszBcZkxsYUNsgJE5EKci8rU=.46ed1126-d015-47e5-a384-e8e6936540f2@github.com>
 <qnNiR3uk1tFvAoU-7ZjRmgz-_5Oec21f8EQEN8AwjpU=.7aafd8af-ca5d-4928-bd66-68b98f3aad03@github.com>
 <FvgWabi6pwwQKk2Bpu8_n92D1gsqcv3Sw51Gq1-Zyzo=.7a351ed1-81d7-42b6-94ef-23261da817ed@github.com>
Message-ID: <8c8eYBUKp4-nZsS7eIxdbBohIOd0BRzRchSfHL8wE5s=.883d27bd-7e38-4829-80a4-71a8378876c8@github.com>

On Tue, 14 Jun 2022 12:27:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/autoconf/flags-ldflags.m4 line 132:
>> 
>>> 130: 
>>> 131:   if test "x$TOOLCHAIN_TYPE" = xmicrosoft; then
>>> 132:     REPRODUCIBLE_LDFLAGS="-experimental:deterministic"
>> 
>> For the cflag, we check that the compiler supports it, but for the linker flag you are just setting it without a check. Before this patch, if we got here and ENABLE_REPRODUCIBLE_BUILD was true, it meant that the test had passed for the compiler, from which we could assume it would also work for the linker, but that is no longer the case.
>
> Good point.

> I made some additional cleanup associated with shmem. I think that sysAssert can (and probably should)
> be replaced with SHMEM_ASSERT. I can fix that as well, if someone from serviceability says that I should do it.

Please do it.
There is no reason to keep 2 identical defines.

-------------

PR: https://git.openjdk.org/jdk/pull/9152


From aleonard at openjdk.java.net  Wed Jun 15 10:18:23 2022
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 15 Jun 2022 10:18:23 GMT
Subject: RFR: 8288399: MacOS debug symbol files not always deterministic in
 reproducible builds
Message-ID: <RrTz-SX4c51wc-9hpoHnyJVnUwtko8YkmJS_5rMTZXk=.31775c35-9ad6-4dc4-b661-5374c87a9200@github.com>

MacOS builds built with ENABLE_REPRODUCIBLE_BUILD enabled still contain full build paths in the
debug symbol information. Linux gcc reproducible builds already uses -fdebug-prefix-map to make these deterministic,
clang supports the same option, and testing with this for clang shows correct mapping.
Similiarly for reproducible builds assembly source file debug declarations need to be relative, as is for Linux gcc. 

The compiler generated unique function symbols contain a random generated part, which if not deterministically
seeded will be random. -frandom-seed provides a deterministic seed solution.

Signed-off-by: Andrew Leonard <anleonar at redhat.com>

-------------

Commit messages:
 - 8288399: MacOS debug symbol files not always deterministic in reproducible builds

Changes: https://git.openjdk.org/jdk/pull/9166/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9166&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288399
  Stats: 17 lines in 2 files changed: 13 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9166.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9166/head:pull/9166

PR: https://git.openjdk.org/jdk/pull/9166


From erikj at openjdk.java.net  Wed Jun 15 11:05:39 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 15 Jun 2022 11:05:39 GMT
Subject: RFR: 8288399: MacOS debug symbol files not always deterministic in
 reproducible builds
In-Reply-To: <RrTz-SX4c51wc-9hpoHnyJVnUwtko8YkmJS_5rMTZXk=.31775c35-9ad6-4dc4-b661-5374c87a9200@github.com>
References: <RrTz-SX4c51wc-9hpoHnyJVnUwtko8YkmJS_5rMTZXk=.31775c35-9ad6-4dc4-b661-5374c87a9200@github.com>
Message-ID: <zXF7z1W-6kMjtmtkgWKFVzwYEW3tLDkUJm93eFUb3oI=.f46ade08-1383-4d1f-b1a7-c8f33fc85cf3@github.com>

On Wed, 15 Jun 2022 10:10:26 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> MacOS builds built with ENABLE_REPRODUCIBLE_BUILD enabled still contain full build paths in the
> debug symbol information. Linux gcc reproducible builds already uses -fdebug-prefix-map to make these deterministic,
> clang supports the same option, and testing with this for clang shows correct mapping.
> Similiarly for reproducible builds assembly source file debug declarations need to be relative, as is for Linux gcc. 
> 
> The compiler generated unique function symbols contain a random generated part, which if not deterministically
> seeded will be random. -frandom-seed provides a deterministic seed solution.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9166


From aleonard at openjdk.java.net  Wed Jun 15 13:15:57 2022
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 15 Jun 2022 13:15:57 GMT
Subject: RFR: 8288399: MacOS debug symbol files not always deterministic in
 reproducible builds
In-Reply-To: <zXF7z1W-6kMjtmtkgWKFVzwYEW3tLDkUJm93eFUb3oI=.f46ade08-1383-4d1f-b1a7-c8f33fc85cf3@github.com>
References: <RrTz-SX4c51wc-9hpoHnyJVnUwtko8YkmJS_5rMTZXk=.31775c35-9ad6-4dc4-b661-5374c87a9200@github.com>
 <zXF7z1W-6kMjtmtkgWKFVzwYEW3tLDkUJm93eFUb3oI=.f46ade08-1383-4d1f-b1a7-c8f33fc85cf3@github.com>
Message-ID: <8QJjIXTU6S6AlMeLVBq4mn03Vy4sUkG2hy0-2C8BAXs=.94971e15-8da9-458e-a333-3279fa0cd1c4@github.com>

On Wed, 15 Jun 2022 11:03:36 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> MacOS builds built with ENABLE_REPRODUCIBLE_BUILD enabled still contain full build paths in the
>> debug symbol information. Linux gcc reproducible builds already uses -fdebug-prefix-map to make these deterministic,
>> clang supports the same option, and testing with this for clang shows correct mapping.
>> Similiarly for reproducible builds assembly source file debug declarations need to be relative, as is for Linux gcc. 
>> 
>> The compiler generated unique function symbols contain a random generated part, which if not deterministically
>> seeded will be random. -frandom-seed provides a deterministic seed solution.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Marked as reviewed by erikj (Reviewer).

thanks @erikj79

-------------

PR: https://git.openjdk.org/jdk/pull/9166


From aleonard at openjdk.java.net  Wed Jun 15 14:02:55 2022
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 15 Jun 2022 14:02:55 GMT
Subject: Integrated: 8288399: MacOS debug symbol files not always deterministic
 in reproducible builds
In-Reply-To: <RrTz-SX4c51wc-9hpoHnyJVnUwtko8YkmJS_5rMTZXk=.31775c35-9ad6-4dc4-b661-5374c87a9200@github.com>
References: <RrTz-SX4c51wc-9hpoHnyJVnUwtko8YkmJS_5rMTZXk=.31775c35-9ad6-4dc4-b661-5374c87a9200@github.com>
Message-ID: <8BKxLpVahCgDtqIYlrjysHM6HXW12L7m4mdA0MRN8Gw=.8c376b56-3106-4d79-bbd1-ab41cee777ba@github.com>

On Wed, 15 Jun 2022 10:10:26 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> MacOS builds built with ENABLE_REPRODUCIBLE_BUILD enabled still contain full build paths in the
> debug symbol information. Linux gcc reproducible builds already uses -fdebug-prefix-map to make these deterministic,
> clang supports the same option, and testing with this for clang shows correct mapping.
> Similiarly for reproducible builds assembly source file debug declarations need to be relative, as is for Linux gcc. 
> 
> The compiler generated unique function symbols contain a random generated part, which if not deterministically
> seeded will be random. -frandom-seed provides a deterministic seed solution.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

This pull request has now been integrated.

Changeset: 6633855c
Author:    Andrew Leonard <aleonard at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6633855ca78ff0f5f1213a2a1424436678a30e55
Stats:     17 lines in 2 files changed: 13 ins; 0 del; 4 mod

8288399: MacOS debug symbol files not always deterministic in reproducible builds

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/jdk/pull/9166


From ihse at openjdk.java.net  Wed Jun 15 14:13:43 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 15 Jun 2022 14:13:43 GMT
Subject: RFR: 8288396: Always create reproducible builds [v3]
In-Reply-To: <ckkR5_LGhD3Q10LqP84yyapjrO6_RVFwcHGLsMiVZno=.8359d6b6-9510-4309-8cf5-10ee85706107@github.com>
References: <ckkR5_LGhD3Q10LqP84yyapjrO6_RVFwcHGLsMiVZno=.8359d6b6-9510-4309-8cf5-10ee85706107@github.com>
Message-ID: <EXMzQ7PH7UY3IcfYdxFFssScHeChY2TsiFEKhnyl014=.cf642c77-28d5-45ad-bf33-612335d248fc@github.com>

> When we started introducing some possibly more intrusive compiler flags and functionality for reproducible builds, we also introduced a flag to turn this off  out of an abundance of caution. But we have been been using this configuration for a year or so internally within Oracle, with no issues. So there's really no reason to be able to turn this off. (If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one.)
> 
> With this fix, all randomness should be gone from our builds, at least on linux and windows. There are no more `__DATE__` and `__TIME__` macros in the source code.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Replace sysAssert with SHMEM_ASSERT

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9152/files
  - new: https://git.openjdk.org/jdk/pull/9152/files/e2f5fc05..0421abc3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9152&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9152&range=01-02

  Stats: 30 lines in 1 file changed: 0 ins; 12 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/9152.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9152/head:pull/9152

PR: https://git.openjdk.org/jdk/pull/9152


From ihse at openjdk.java.net  Wed Jun 15 14:19:34 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 15 Jun 2022 14:19:34 GMT
Subject: RFR: 8288396: Always create reproducible builds [v4]
In-Reply-To: <ckkR5_LGhD3Q10LqP84yyapjrO6_RVFwcHGLsMiVZno=.8359d6b6-9510-4309-8cf5-10ee85706107@github.com>
References: <ckkR5_LGhD3Q10LqP84yyapjrO6_RVFwcHGLsMiVZno=.8359d6b6-9510-4309-8cf5-10ee85706107@github.com>
Message-ID: <7PVfQ1OxfSkOxdkxxNH9NrakgUCXHjhzLpY0mwHh-F0=.a793fa2f-7115-4f04-9d60-8409989d802b@github.com>

> When we started introducing some possibly more intrusive compiler flags and functionality for reproducible builds, we also introduced a flag to turn this off  out of an abundance of caution. But we have been been using this configuration for a year or so internally within Oracle, with no issues. So there's really no reason to be able to turn this off. (If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one.)
> 
> With this fix, all randomness should be gone from our builds, at least on linux and windows. There are no more `__DATE__` and `__TIME__` macros in the source code.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' into full-reproducibility
 - Replace sysAssert with SHMEM_ASSERT
 - Fix exitTransportWithError signature
 - 8288396: Always create reproducible builds

-------------

Changes: https://git.openjdk.org/jdk/pull/9152/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9152&range=03
  Stats: 155 lines in 18 files changed: 11 ins; 102 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/9152.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9152/head:pull/9152

PR: https://git.openjdk.org/jdk/pull/9152


From ihse at openjdk.java.net  Wed Jun 15 15:18:04 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 15 Jun 2022 15:18:04 GMT
Subject: RFR: 8288396: Always create reproducible builds [v5]
In-Reply-To: <ckkR5_LGhD3Q10LqP84yyapjrO6_RVFwcHGLsMiVZno=.8359d6b6-9510-4309-8cf5-10ee85706107@github.com>
References: <ckkR5_LGhD3Q10LqP84yyapjrO6_RVFwcHGLsMiVZno=.8359d6b6-9510-4309-8cf5-10ee85706107@github.com>
Message-ID: <Rbf9agwOfJ9hcxnAuRVTAV__47bh83C8U6SmbG2yyHg=.92ff9026-6bdf-4b40-bde8-c29b985f9996@github.com>

> When we started introducing some possibly more intrusive compiler flags and functionality for reproducible builds, we also introduced a flag to turn this off  out of an abundance of caution. But we have been been using this configuration for a year or so internally within Oracle, with no issues. So there's really no reason to be able to turn this off. (If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one.)
> 
> With this fix, all randomness should be gone from our builds, at least on linux and windows. There are no more `__DATE__` and `__TIME__` macros in the source code.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Remove incorrect argument
 - Test if linker can accept the flag

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9152/files
  - new: https://git.openjdk.org/jdk/pull/9152/files/adc0bbcb..6c45fa5b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9152&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9152&range=03-04

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9152.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9152/head:pull/9152

PR: https://git.openjdk.org/jdk/pull/9152


From ihse at openjdk.java.net  Wed Jun 15 15:28:41 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 15 Jun 2022 15:28:41 GMT
Subject: RFR: 8288499: Restore cancel-in-progress in GHA
Message-ID: <vEiq8Sl3xpNOE4sPkIo69688yo_aeD7i8KanTpP4xJQ=.128f07f0-4df0-41ba-bec7-ba360f9fb833@github.com>

I accidentally changed the behavior in GHA wrt multiple runs from the same branch. The old solution used `cancel-in-progress: true` which means that an old batch was cancelled when a new commit was pushed to the branch.

I think this is a good behavior, since it minimizes wait times for GHA results, and wastes less GHA resources.

I changed this to `false` while developing the new GHA framework, and intended to change it back before pushing, but forgot about it.

-------------

Commit messages:
 - 8288499: Restore cancel-in-progress in GHA

Changes: https://git.openjdk.org/jdk/pull/9170/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9170&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288499
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9170.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9170/head:pull/9170

PR: https://git.openjdk.org/jdk/pull/9170


From erikj at openjdk.java.net  Wed Jun 15 15:47:58 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 15 Jun 2022 15:47:58 GMT
Subject: RFR: 8288499: Restore cancel-in-progress in GHA
In-Reply-To: <vEiq8Sl3xpNOE4sPkIo69688yo_aeD7i8KanTpP4xJQ=.128f07f0-4df0-41ba-bec7-ba360f9fb833@github.com>
References: <vEiq8Sl3xpNOE4sPkIo69688yo_aeD7i8KanTpP4xJQ=.128f07f0-4df0-41ba-bec7-ba360f9fb833@github.com>
Message-ID: <iL4cFYvqeXNTtmA_gO6hBlQD9LguiuYWcH0pC3Fu-dc=.d04b22a3-6b8f-40e1-88cf-257f2415f455@github.com>

On Wed, 15 Jun 2022 15:20:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I accidentally changed the behavior in GHA wrt multiple runs from the same branch. The old solution used `cancel-in-progress: true` which means that an old batch was cancelled when a new commit was pushed to the branch.
> 
> I think this is a good behavior, since it minimizes wait times for GHA results, and wastes less GHA resources.
> 
> I changed this to `false` while developing the new GHA framework, and intended to change it back before pushing, but forgot about it.

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9170


From shade at openjdk.java.net  Wed Jun 15 15:52:02 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 15 Jun 2022 15:52:02 GMT
Subject: RFR: 8288499: Restore cancel-in-progress in GHA
In-Reply-To: <vEiq8Sl3xpNOE4sPkIo69688yo_aeD7i8KanTpP4xJQ=.128f07f0-4df0-41ba-bec7-ba360f9fb833@github.com>
References: <vEiq8Sl3xpNOE4sPkIo69688yo_aeD7i8KanTpP4xJQ=.128f07f0-4df0-41ba-bec7-ba360f9fb833@github.com>
Message-ID: <zXFL961ZvuEK2i5B9SsI2fRR90XgYkedipZ71zDMYQ4=.5c335964-0c08-419e-8c06-bc1badc0b5e9@github.com>

On Wed, 15 Jun 2022 15:20:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I accidentally changed the behavior in GHA wrt multiple runs from the same branch. The old solution used `cancel-in-progress: true` which means that an old batch was cancelled when a new commit was pushed to the branch.
> 
> I think this is a good behavior, since it minimizes wait times for GHA results, and wastes less GHA resources.
> 
> I changed this to `false` while developing the new GHA framework, and intended to change it back before pushing, but forgot about it.

Whoops. Looks good.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9170


From ihse at openjdk.java.net  Wed Jun 15 17:41:03 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 15 Jun 2022 17:41:03 GMT
Subject: Integrated: 8288499: Restore cancel-in-progress in GHA
In-Reply-To: <vEiq8Sl3xpNOE4sPkIo69688yo_aeD7i8KanTpP4xJQ=.128f07f0-4df0-41ba-bec7-ba360f9fb833@github.com>
References: <vEiq8Sl3xpNOE4sPkIo69688yo_aeD7i8KanTpP4xJQ=.128f07f0-4df0-41ba-bec7-ba360f9fb833@github.com>
Message-ID: <Cr9f8mA46F6L4AQq_q0SFulqwzDP1FemND15CrsPCiU=.705b7513-ad7f-42fe-ba84-2039de425903@github.com>

On Wed, 15 Jun 2022 15:20:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I accidentally changed the behavior in GHA wrt multiple runs from the same branch. The old solution used `cancel-in-progress: true` which means that an old batch was cancelled when a new commit was pushed to the branch.
> 
> I think this is a good behavior, since it minimizes wait times for GHA results, and wastes less GHA resources.
> 
> I changed this to `false` while developing the new GHA framework, and intended to change it back before pushing, but forgot about it.

This pull request has now been integrated.

Changeset: cb5ef3da
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cb5ef3da1904e6639130c601db9644895807b4d6
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8288499: Restore cancel-in-progress in GHA

Reviewed-by: erikj, shade

-------------

PR: https://git.openjdk.org/jdk/pull/9170


From amenkov at openjdk.java.net  Wed Jun 15 21:23:04 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 15 Jun 2022 21:23:04 GMT
Subject: RFR: 8288396: Always create reproducible builds [v5]
In-Reply-To: <Rbf9agwOfJ9hcxnAuRVTAV__47bh83C8U6SmbG2yyHg=.92ff9026-6bdf-4b40-bde8-c29b985f9996@github.com>
References: <ckkR5_LGhD3Q10LqP84yyapjrO6_RVFwcHGLsMiVZno=.8359d6b6-9510-4309-8cf5-10ee85706107@github.com>
 <Rbf9agwOfJ9hcxnAuRVTAV__47bh83C8U6SmbG2yyHg=.92ff9026-6bdf-4b40-bde8-c29b985f9996@github.com>
Message-ID: <EFVznghot7yu_KZTNkXK60E3QwQ2YdfeXixKL_n_I1A=.a130b896-ab82-4350-836e-0e92523d1e86@github.com>

On Wed, 15 Jun 2022 15:18:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> When we started introducing some possibly more intrusive compiler flags and functionality for reproducible builds, we also introduced a flag to turn this off  out of an abundance of caution. But we have been been using this configuration for a year or so internally within Oracle, with no issues. So there's really no reason to be able to turn this off. (If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one.)
>> 
>> With this fix, all randomness should be gone from our builds, at least on linux and windows. There are no more `__DATE__` and `__TIME__` macros in the source code.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove incorrect argument
>  - Test if linker can accept the flag

JDI changes look good

-------------

Marked as reviewed by amenkov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9152


From duke at openjdk.java.net  Thu Jun 16 06:42:03 2022
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Thu, 16 Jun 2022 06:42:03 GMT
Subject: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default
In-Reply-To: <s90ZHWiCJSzvHHeEUGACyP2851dTKt33JQL3q6iNK_w=.76c5f198-da40-4064-ac2a-c0844f1167dc@github.com>
References: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
 <XOvpFs3L_qkUSrCztK_3ZYF2yiCoVaLvd9xd9JRDi48=.7934314d-782d-4cc6-8997-9e48c9627410@github.com>
 <s90ZHWiCJSzvHHeEUGACyP2851dTKt33JQL3q6iNK_w=.76c5f198-da40-4064-ac2a-c0844f1167dc@github.com>
Message-ID: <gnT9X1ZZU0XyviDF-mHP_m3YLSRBnHJYXZW_f-A7BXU=.cdb40d23-50a9-44cc-a79e-45b8c38efa4f@github.com>

On Tue, 14 Jun 2022 09:50:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Thank you for your comments.
>> I understood the goal of reproducible build. But now, ENABLE_REPRODUCIBLE_BUILD is set to false in default configuration.
>> Then I think minimize the effort of SOURCE_DATE_EPOCH when reproducible build is disabled. I wonder why build time information is different from Windows and Linux.
>
> @tkiriyama I have created https://bugs.openjdk.org/browse/JDK-8288396 for the approach I championed above, i.e. to always build reproducible instead. As part of this, the `-Xinternalversion` time stamp should be of the same format for all platforms, given the same set of options to `configure`.
> 
> The associated PR is https://github.com/openjdk/jdk/pull/9152. Can you verify if this solves your issues, and if so, close this bug?

@magicus 
Thank you. I will check it.

-------------

PR: https://git.openjdk.org/jdk/pull/9081


From asotona at openjdk.org  Thu Jun 16 13:59:07 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 16 Jun 2022 13:59:07 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v11]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <E4j45zg2e_METAHDCb8VB7vBVN3OBZMV9r7kuSY_Ud0=.80634e26-7c57-40c3-b424-104af94c2591@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge branch 'openjdk:master' into JDK-8244681
 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module
 - Added man-page line about lossy-conversion lint
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   re-enabled warnings for java.base, java.rmi and java.smartcardio
 - Merge branch 'openjdk:master' into JDK-8244681
 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base
   new case appeared in java.base by moving jdk.incubator.foreign code under java.base
 - Merge remote-tracking branch 'upstream/master' into JDK-8244681
   
   # Conflicts:
   #	make/test/BuildMicrobenchmark.gmk
 - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr
 - Merge branch 'openjdk:master' into JDK-8244681
 - ... and 5 more: https://git.openjdk.org/jdk/compare/cf4a4966...3314423d

-------------

Changes: https://git.openjdk.org/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=10
  Stats: 442 lines in 17 files changed: 440 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.org/jdk/pull/8599


From browseria at hotmail.com  Thu Jun 16 14:43:39 2022
From: browseria at hotmail.com (Browser)
Date: Thu, 16 Jun 2022 14:43:39 +0000
Subject: assembler_x86.cpp:11128:38: error: 'this' pointer is null
Message-ID: <CY5P223MB049042CC6C9FBBDD7F57CEA1ABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>

I am trying to build jdk18u on RHEL9 using GCC 11.3.1.
I am able to build it with no problems on RHEL8 using GCC 8.3.1.
I am able to build it with no problems on Fedora 29 using GCC 8.3.1.
But on RHEL9/Fedora 34/Fedora 36 using GCC 11.3.1/12.1.1 (the default for these distros) I get the following error:

```
cat build/linux-x86_64-server-release/build.log
Building target 'images' in configuration 'linux-x86_64-server-release'
Compiling 1 files for BUILD_TOOLS_HOTSPOT
Compiling 8 files for BUILD_TOOLS_LANGTOOLS
Creating hotspot/variant-server/tools/adlc/adlc from 13 file(s)
Compiling 2 files for BUILD_JVMTI_TOOLS
Parsing 2 properties into enum-like class for jdk.compiler
Compiling 13 properties into resource bundles for jdk.javadoc
Compiling 16 properties into resource bundles for jdk.compiler
Compiling 12 properties into resource bundles for jdk.jdeps
Compiling 7 properties into resource bundles for jdk.jshell
Compiling 127 files for BUILD_java.compiler.interim
Compiling 403 files for BUILD_jdk.compiler.interim
Compiling 238 files for BUILD_jdk.javadoc.interim
Creating support/modules_libs/java.base/server/libjvm.so from 1081 file(s)
Compiling 31 files for BUILD_JRTFS
Creating support/modules_libs/java.base/jrt-fs.jar
Compiling 186 files for BUILD_TOOLS_JDK
Compiling 2 files for COMPILE_DEPEND
Compiling 1 properties into resource bundles for jdk.httpserver
Compiling 11 properties into resource bundles for jdk.jartool
Compiling 71 files for COMPILE_CREATE_SYMBOLS
Compiling 11 properties into resource bundles for jdk.management.agent
Compiling 3 properties into resource bundles for jdk.jdi
Compiling 5 properties into resource bundles for jdk.jlink
Compiling 3 properties into resource bundles for jdk.jlink
Compiling 1 properties into resource bundles for jdk.jlink
Compiling 224 properties into resource bundles for jdk.localedata
/usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp: In member function 'void Assembler::evprord(XMMRegister, KRegister, XMMRegister, int, bool, int)':
/usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp:11128:38: error: 'this' pointer is null [-Werror=nonnull]
11128 |   int encode = vex_prefix_and_encode(xmm0->encoding(), dst->encoding(), src->encoding(), VEX_SIMD_66, VEX_OPCODE_0F, &attributes);
      |                                      ^~~~
In file included from /usr/src/jdk18u/src/hotspot/share/asm/register.hpp:59,
                 from /usr/src/jdk18u/src/hotspot/share/asm/assembler.hpp:29,
                 from /usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp:26:
/usr/src/jdk18u/src/hotspot/cpu/x86/register_x86.hpp:160:9: note: in a call to non-static member function 'int XMMRegisterImpl::encoding() const'
  160 |   int   encoding() const                          { assert(is_valid(), "invalid register (%d)", (int)(intptr_t)this ); return (intptr_t)this; }
      |         ^~~~~~~~
/usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp: In member function 'void Assembler::evprorq(XMMRegister, KRegister, XMMRegister, int, bool, int)':
/usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp:11140:38: error: 'this' pointer is null [-Werror=nonnull]
11140 |   int encode = vex_prefix_and_encode(xmm0->encoding(), dst->encoding(), src->encoding(), VEX_SIMD_66, VEX_OPCODE_0F, &attributes);
      |                                      ^~~~
In file included from /usr/src/jdk18u/src/hotspot/share/asm/register.hpp:59,
                 from /usr/src/jdk18u/src/hotspot/share/asm/assembler.hpp:29,
                 from /usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp:26:
/usr/src/jdk18u/src/hotspot/cpu/x86/register_x86.hpp:160:9: note: in a call to non-static member function 'int XMMRegisterImpl::encoding() const'
  160 |   int   encoding() const                          { assert(is_valid(), "invalid register (%d)", (int)(intptr_t)this ); return (intptr_t)this; }
      |         ^~~~~~~~
Compiling 11 properties into resource bundles for java.base
cc1plus: all warnings being treated as errors
gmake[3]: *** [lib/CompileJvm.gmk:143: /usr/src/jdk18u/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/assembler_x86.o] Error 1
gmake[3]: *** Waiting for unfinished jobs....
Compiling 6 properties into resource bundles for java.base
gmake[2]: *** [make/Main.gmk:252: hotspot-server-libs] Error 2
gmake[2]: *** Waiting for unfinished jobs....

ERROR: Build failed for target 'images' in configuration 'linux-x86_64-server-release' (exit code 2)
```


```
cat /usr/src/jdk18u/build/linux-x86_64-server-release/make-support/failure-logs/*
/usr/bin/g++ -MMD -MF /usr/src/jdk18u/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/assembler_x86.d.tmp -I/usr/src/jdk18u/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/precompiled -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -D_GNU_SOURCE -D_REENTRANT -pipe -fno-rtti -fno-exceptions -fvisibility=hidden -fno-strict-aliasing -fno-omit-frame-pointer -fcheck-new -fstack-protector -std=c++14 -DLIBC=gnu -DLINUX -Wall -Wextra -Wformat=2 -Wpointer-arith -Wsign-compare -Wunused-function -Wundef -Wunused-value -Wreturn-type -Wtrampolines -Woverloaded-virtual -Wreorder -fPIC -fmacro-prefix-map=/usr/src/jdk18u/= -DVM_LITTLE_ENDIAN -D_LP64=1 -fno-delete-null-pointer-checks -fno-lifetime-dse -Wno-format-zero-length -Wtype-limits -Wuninitialized -m64 -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_linux -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_gcc -DTARGET_COMPILER_gcc -DAMD64 -DHOTSPOT_LIB_ARCH='"amd64"' -DCOMPILER1 -DCOMPILER2 -I/usr/src/jdk18u/build/linux-x86_64-server-release/hotspot/variant-server/gensrc/adfiles -I/usr/src/jdk18u/src/hotspot/share -I/usr/src/jdk18u/src/hotspot/os/linux -I/usr/src/jdk18u/src/hotspot/os/posix -I/usr/src/jdk18u/src/hotspot/cpu/x86 -I/usr/src/jdk18u/src/hotspot/os_cpu/linux_x86 -I/usr/src/jdk18u/build/linux-x86_64-server-release/hotspot/variant-server/gensrc -I/usr/src/jdk18u/src/hotspot/share/precompiled -I/usr/src/jdk18u/src/hotspot/share/include -I/usr/src/jdk18u/src/hotspot/os/posix/include -I/usr/src/jdk18u/build/linux-x86_64-server-release/support/modules_include/java.base -I/usr/src/jdk18u/build/linux-x86_64-server-release/support/modules_include/java.base/linux -I/usr/src/jdk18u/src/java.base/share/native/libjimage -m64 -I/usr/src/jdk18u/build/linux-x86_64-server-release/hotspot/variant-server/gensrc/adfiles -I/usr/src/jdk18u/src/hotspot/share -I/usr/src/jdk18u/src/hotspot/os/linux -I/usr/src/jdk18u/src/hotspot/os/posix -I/usr/src/jdk18u/src/hotspot/cpu/x86 -I/usr/src/jdk18u/src/hotspot/os_cpu/linux_x86 -I/usr/src/jdk18u/build/linux-x86_64-server-release/hotspot/variant-server/gensrc -Wno-unused-parameter -Wno-unused -Wno-parentheses -Wno-comment -Wno-unknown-pragmas -Wno-address -Wno-delete-non-virtual-dtor -Wno-char-subscripts -Wno-array-bounds -Wno-int-in-bool-context -Wno-ignored-qualifiers -Wno-missing-field-initializers -Wno-implicit-fallthrough -Wno-empty-body -Wno-strict-overflow -Wno-sequence-point -Wno-maybe-uninitialized -Wno-misleading-indentation -Wno-cast-function-type -Wno-shift-negative-value -Werror -O3 -Wno-maybe-uninitialized -c -o /usr/src/jdk18u/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/assembler_x86.o /usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp
/usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp: In member function 'void Assembler::evprord(XMMRegister, KRegister, XMMRegister, int, bool, int)':
/usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp:11128:38: error: 'this' pointer is null [-Werror=nonnull]
11128 |   int encode = vex_prefix_and_encode(xmm0->encoding(), dst->encoding(), src->encoding(), VEX_SIMD_66, VEX_OPCODE_0F, &attributes);
      |                                      ^~~~
In file included from /usr/src/jdk18u/src/hotspot/share/asm/register.hpp:59,
                 from /usr/src/jdk18u/src/hotspot/share/asm/assembler.hpp:29,
                 from /usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp:26:
/usr/src/jdk18u/src/hotspot/cpu/x86/register_x86.hpp:160:9: note: in a call to non-static member function 'int XMMRegisterImpl::encoding() const'
  160 |   int   encoding() const                          { assert(is_valid(), "invalid register (%d)", (int)(intptr_t)this ); return (intptr_t)this; }
      |         ^~~~~~~~
/usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp: In member function 'void Assembler::evprorq(XMMRegister, KRegister, XMMRegister, int, bool, int)':
/usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp:11140:38: error: 'this' pointer is null [-Werror=nonnull]
11140 |   int encode = vex_prefix_and_encode(xmm0->encoding(), dst->encoding(), src->encoding(), VEX_SIMD_66, VEX_OPCODE_0F, &attributes);
      |                                      ^~~~
In file included from /usr/src/jdk18u/src/hotspot/share/asm/register.hpp:59,
                 from /usr/src/jdk18u/src/hotspot/share/asm/assembler.hpp:29,
                 from /usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp:26:
/usr/src/jdk18u/src/hotspot/cpu/x86/register_x86.hpp:160:9: note: in a call to non-static member function 'int XMMRegisterImpl::encoding() const'
  160 |   int   encoding() const                          { assert(is_valid(), "invalid register (%d)", (int)(intptr_t)this ); return (intptr_t)this; }
      |         ^~~~~~~~
cc1plus: all warnings being treated as errors
```

Has anyone tried compiling this on RHEL9 or Fedora >= 34 / GCC >= 11.3.1?
Does anyone know of a workaround to get this to compile on these platforms/with these compilers?



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20220616/c25bd53c/attachment.htm>

From maxim.kartashev at jetbrains.com  Thu Jun 16 14:50:24 2022
From: maxim.kartashev at jetbrains.com (Maxim Kartashev)
Date: Thu, 16 Jun 2022 17:50:24 +0300
Subject: assembler_x86.cpp:11128:38: error: 'this' pointer is null
In-Reply-To: <CY5P223MB049042CC6C9FBBDD7F57CEA1ABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
References: <CY5P223MB049042CC6C9FBBDD7F57CEA1ABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
Message-ID: <CAG0Tb0gx3TyAmNaURvR5RxvXyQZYB+cP=pB1D+1fxXTgfeMerA@mail.gmail.com>

A workaround would be to configure with --disable-warnings-as-errors
option. Perhaps gcc 11.3 has become much smarter in its dataflow analysis,
hence the warning. If the warning is legitimate, it needs to be dealt with
properly by making changes to the code or at least silencing the warning
(unfortunately, the code is full of situations where the 'this' pointer is
NULL at times).

On Thu, Jun 16, 2022 at 5:44 PM Browser <browseria at hotmail.com> wrote:

> I am trying to build jdk18u on RHEL9 using GCC 11.3.1.
> I am able to build it with no problems on RHEL8 using GCC 8.3.1.
> I am able to build it with no problems on Fedora 29 using GCC 8.3.1.
> But on RHEL9/Fedora 34/Fedora 36 using GCC 11.3.1/12.1.1 (the default for
> these distros) I get the following error:
>
> ```
> cat build/linux-x86_64-server-release/build.log
> Building target 'images' in configuration 'linux-x86_64-server-release'
> Compiling 1 files for BUILD_TOOLS_HOTSPOT
> Compiling 8 files for BUILD_TOOLS_LANGTOOLS
> Creating hotspot/variant-server/tools/adlc/adlc from 13 file(s)
> Compiling 2 files for BUILD_JVMTI_TOOLS
> Parsing 2 properties into enum-like class for jdk.compiler
> Compiling 13 properties into resource bundles for jdk.javadoc
> Compiling 16 properties into resource bundles for jdk.compiler
> Compiling 12 properties into resource bundles for jdk.jdeps
> Compiling 7 properties into resource bundles for jdk.jshell
> Compiling 127 files for BUILD_java.compiler.interim
> Compiling 403 files for BUILD_jdk.compiler.interim
> Compiling 238 files for BUILD_jdk.javadoc.interim
> Creating support/modules_libs/java.base/server/libjvm.so from 1081 file(s)
> Compiling 31 files for BUILD_JRTFS
> Creating support/modules_libs/java.base/jrt-fs.jar
> Compiling 186 files for BUILD_TOOLS_JDK
> Compiling 2 files for COMPILE_DEPEND
> Compiling 1 properties into resource bundles for jdk.httpserver
> Compiling 11 properties into resource bundles for jdk.jartool
> Compiling 71 files for COMPILE_CREATE_SYMBOLS
> Compiling 11 properties into resource bundles for jdk.management.agent
> Compiling 3 properties into resource bundles for jdk.jdi
> Compiling 5 properties into resource bundles for jdk.jlink
> Compiling 3 properties into resource bundles for jdk.jlink
> Compiling 1 properties into resource bundles for jdk.jlink
> Compiling 224 properties into resource bundles for jdk.localedata
> /usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp: In member function
> 'void Assembler::evprord(XMMRegister, KRegister, XMMRegister, int, bool,
> int)':
> /usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp:11128:38: error:
> 'this' pointer is null [-Werror=nonnull]
> 11128 |   int encode = vex_prefix_and_encode(xmm0->encoding(),
> dst->encoding(), src->encoding(), VEX_SIMD_66, VEX_OPCODE_0F, &attributes);
>       |                                      ^~~~
> In file included from
> /usr/src/jdk18u/src/hotspot/share/asm/register.hpp:59,
>                  from
> /usr/src/jdk18u/src/hotspot/share/asm/assembler.hpp:29,
>                  from
> /usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp:26:
> /usr/src/jdk18u/src/hotspot/cpu/x86/register_x86.hpp:160:9: note: in a
> call to non-static member function 'int XMMRegisterImpl::encoding() const'
>   160 |   int   encoding() const                          {
> assert(is_valid(), "invalid register (%d)", (int)(intptr_t)this ); return
> (intptr_t)this; }
>       |         ^~~~~~~~
> /usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp: In member function
> 'void Assembler::evprorq(XMMRegister, KRegister, XMMRegister, int, bool,
> int)':
> /usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp:11140:38: error:
> 'this' pointer is null [-Werror=nonnull]
> 11140 |   int encode = vex_prefix_and_encode(xmm0->encoding(),
> dst->encoding(), src->encoding(), VEX_SIMD_66, VEX_OPCODE_0F, &attributes);
>       |                                      ^~~~
> In file included from
> /usr/src/jdk18u/src/hotspot/share/asm/register.hpp:59,
>                  from
> /usr/src/jdk18u/src/hotspot/share/asm/assembler.hpp:29,
>                  from
> /usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp:26:
> /usr/src/jdk18u/src/hotspot/cpu/x86/register_x86.hpp:160:9: note: in a
> call to non-static member function 'int XMMRegisterImpl::encoding() const'
>   160 |   int   encoding() const                          {
> assert(is_valid(), "invalid register (%d)", (int)(intptr_t)this ); return
> (intptr_t)this; }
>       |         ^~~~~~~~
> Compiling 11 properties into resource bundles for java.base
> cc1plus: all warnings being treated as errors
> gmake[3]: *** [lib/CompileJvm.gmk:143:
> /usr/src/jdk18u/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/assembler_x86.o]
> Error 1
> gmake[3]: *** Waiting for unfinished jobs....
> Compiling 6 properties into resource bundles for java.base
> gmake[2]: *** [make/Main.gmk:252: hotspot-server-libs] Error 2
> gmake[2]: *** Waiting for unfinished jobs....
>
> ERROR: Build failed for target 'images' in configuration
> 'linux-x86_64-server-release' (exit code 2)
> ```
>
>
> ```
> cat
> /usr/src/jdk18u/build/linux-x86_64-server-release/make-support/failure-logs/*
> /usr/bin/g++ -MMD -MF
> /usr/src/jdk18u/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/assembler_x86.d.tmp
> -I/usr/src/jdk18u/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/precompiled
> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
> -D_GNU_SOURCE -D_REENTRANT -pipe -fno-rtti -fno-exceptions
> -fvisibility=hidden -fno-strict-aliasing -fno-omit-frame-pointer
> -fcheck-new -fstack-protector -std=c++14 -DLIBC=gnu -DLINUX -Wall -Wextra
> -Wformat=2 -Wpointer-arith -Wsign-compare -Wunused-function -Wundef
> -Wunused-value -Wreturn-type -Wtrampolines -Woverloaded-virtual -Wreorder
> -fPIC -fmacro-prefix-map=/usr/src/jdk18u/= -DVM_LITTLE_ENDIAN -D_LP64=1
> -fno-delete-null-pointer-checks -fno-lifetime-dse -Wno-format-zero-length
> -Wtype-limits -Wuninitialized -m64 -DPRODUCT -DTARGET_ARCH_x86
> -DINCLUDE_SUFFIX_OS=_linux -DINCLUDE_SUFFIX_CPU=_x86
> -DINCLUDE_SUFFIX_COMPILER=_gcc -DTARGET_COMPILER_gcc -DAMD64
> -DHOTSPOT_LIB_ARCH='"amd64"' -DCOMPILER1 -DCOMPILER2
> -I/usr/src/jdk18u/build/linux-x86_64-server-release/hotspot/variant-server/gensrc/adfiles
> -I/usr/src/jdk18u/src/hotspot/share -I/usr/src/jdk18u/src/hotspot/os/linux
> -I/usr/src/jdk18u/src/hotspot/os/posix
> -I/usr/src/jdk18u/src/hotspot/cpu/x86
> -I/usr/src/jdk18u/src/hotspot/os_cpu/linux_x86
> -I/usr/src/jdk18u/build/linux-x86_64-server-release/hotspot/variant-server/gensrc
> -I/usr/src/jdk18u/src/hotspot/share/precompiled
> -I/usr/src/jdk18u/src/hotspot/share/include
> -I/usr/src/jdk18u/src/hotspot/os/posix/include
> -I/usr/src/jdk18u/build/linux-x86_64-server-release/support/modules_include/java.base
> -I/usr/src/jdk18u/build/linux-x86_64-server-release/support/modules_include/java.base/linux
> -I/usr/src/jdk18u/src/java.base/share/native/libjimage -m64
> -I/usr/src/jdk18u/build/linux-x86_64-server-release/hotspot/variant-server/gensrc/adfiles
> -I/usr/src/jdk18u/src/hotspot/share -I/usr/src/jdk18u/src/hotspot/os/linux
> -I/usr/src/jdk18u/src/hotspot/os/posix
> -I/usr/src/jdk18u/src/hotspot/cpu/x86
> -I/usr/src/jdk18u/src/hotspot/os_cpu/linux_x86
> -I/usr/src/jdk18u/build/linux-x86_64-server-release/hotspot/variant-server/gensrc
> -Wno-unused-parameter -Wno-unused -Wno-parentheses -Wno-comment
> -Wno-unknown-pragmas -Wno-address -Wno-delete-non-virtual-dtor
> -Wno-char-subscripts -Wno-array-bounds -Wno-int-in-bool-context
> -Wno-ignored-qualifiers -Wno-missing-field-initializers
> -Wno-implicit-fallthrough -Wno-empty-body -Wno-strict-overflow
> -Wno-sequence-point -Wno-maybe-uninitialized -Wno-misleading-indentation
> -Wno-cast-function-type -Wno-shift-negative-value -Werror -O3
> -Wno-maybe-uninitialized -c -o
> /usr/src/jdk18u/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/assembler_x86.o
> /usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp
> /usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp: In member function
> 'void Assembler::evprord(XMMRegister, KRegister, XMMRegister, int, bool,
> int)':
> /usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp:11128:38: error:
> 'this' pointer is null [-Werror=nonnull]
> 11128 |   int encode = vex_prefix_and_encode(xmm0->encoding(),
> dst->encoding(), src->encoding(), VEX_SIMD_66, VEX_OPCODE_0F, &attributes);
>       |                                      ^~~~
> In file included from
> /usr/src/jdk18u/src/hotspot/share/asm/register.hpp:59,
>                  from
> /usr/src/jdk18u/src/hotspot/share/asm/assembler.hpp:29,
>                  from
> /usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp:26:
> /usr/src/jdk18u/src/hotspot/cpu/x86/register_x86.hpp:160:9: note: in a
> call to non-static member function 'int XMMRegisterImpl::encoding() const'
>   160 |   int   encoding() const                          {
> assert(is_valid(), "invalid register (%d)", (int)(intptr_t)this ); return
> (intptr_t)this; }
>       |         ^~~~~~~~
> /usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp: In member function
> 'void Assembler::evprorq(XMMRegister, KRegister, XMMRegister, int, bool,
> int)':
> /usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp:11140:38: error:
> 'this' pointer is null [-Werror=nonnull]
> 11140 |   int encode = vex_prefix_and_encode(xmm0->encoding(),
> dst->encoding(), src->encoding(), VEX_SIMD_66, VEX_OPCODE_0F, &attributes);
>       |                                      ^~~~
> In file included from
> /usr/src/jdk18u/src/hotspot/share/asm/register.hpp:59,
>                  from
> /usr/src/jdk18u/src/hotspot/share/asm/assembler.hpp:29,
>                  from
> /usr/src/jdk18u/src/hotspot/cpu/x86/assembler_x86.cpp:26:
> /usr/src/jdk18u/src/hotspot/cpu/x86/register_x86.hpp:160:9: note: in a
> call to non-static member function 'int XMMRegisterImpl::encoding() const'
>   160 |   int   encoding() const                          {
> assert(is_valid(), "invalid register (%d)", (int)(intptr_t)this ); return
> (intptr_t)this; }
>       |         ^~~~~~~~
> cc1plus: all warnings being treated as errors
> ```
>
> Has anyone tried compiling this on RHEL9 or Fedora >= 34 / GCC >= 11.3.1?
> Does anyone know of a workaround to get this to compile on these
> platforms/with these compilers?
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20220616/32feba02/attachment.htm>

From shade at redhat.com  Thu Jun 16 15:28:01 2022
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 16 Jun 2022 17:28:01 +0200
Subject: assembler_x86.cpp:11128:38: error: 'this' pointer is null
In-Reply-To: <CY5P223MB049042CC6C9FBBDD7F57CEA1ABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
References: <CY5P223MB049042CC6C9FBBDD7F57CEA1ABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
Message-ID: <1ec8068a-8097-2519-da53-74dd4943e17f@redhat.com>

On 6/16/22 16:43, Browser wrote:
> Has anyone tried compiling this on RHEL9 or Fedora >= 34 / GCC >= 11.3.1?
> Does anyone know of a workaround to get this to compile on these platforms/with these compilers?

That seems to be:
   https://bugs.openjdk.org/browse/JDK-8278525

If so, it is fixed in mainline, and just needs a backport to 18u and other releases.

-- 
Thanks,
-Aleksey



From shade at redhat.com  Thu Jun 16 15:36:58 2022
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 16 Jun 2022 17:36:58 +0200
Subject: assembler_x86.cpp:11128:38: error: 'this' pointer is null
In-Reply-To: <1ec8068a-8097-2519-da53-74dd4943e17f@redhat.com>
References: <CY5P223MB049042CC6C9FBBDD7F57CEA1ABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
 <1ec8068a-8097-2519-da53-74dd4943e17f@redhat.com>
Message-ID: <39d85c1d-c5ce-5e75-7b57-69af9385cb18@redhat.com>

On 6/16/22 17:28, Aleksey Shipilev wrote:
> On 6/16/22 16:43, Browser wrote:
>> Has anyone tried compiling this on RHEL9 or Fedora >= 34 / GCC >= 11.3.1?
>> Does anyone know of a workaround to get this to compile on these platforms/with these compilers?
> 
> That seems to be:
>     https://bugs.openjdk.org/browse/JDK-8278525
> 
> If so, it is fixed in mainline, and just needs a backport to 18u and other releases.

18u backport:
   https://urldefense.com/v3/__https://github.com/openjdk/jdk18u/pull/152__;!!ACWV5N9M2RV99hQ!J3iXeiC73Jo1UNcrQj0wnVoV19B9POOu1k0nIsw2MF3BaLiEDOm452TkF-MaDE8_fjjQHTsDbt3H2PSJ$ 

You might want to try and test that on your GCC 11 box. (There are instructions how to get the PR 
branch from Git).

-- 
Thanks,
-Aleksey



From browseria at hotmail.com  Thu Jun 16 15:56:16 2022
From: browseria at hotmail.com (Browser)
Date: Thu, 16 Jun 2022 15:56:16 +0000
Subject: assembler_x86.cpp:11128:38: error: 'this' pointer is null
In-Reply-To: <39d85c1d-c5ce-5e75-7b57-69af9385cb18@redhat.com>
References: <CY5P223MB049042CC6C9FBBDD7F57CEA1ABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
 <1ec8068a-8097-2519-da53-74dd4943e17f@redhat.com>
 <39d85c1d-c5ce-5e75-7b57-69af9385cb18@redhat.com>
Message-ID: <CY5P223MB0490AE97668D1F228481A02EABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>

Thank you for pointing me in the right direction! I tried the backport in pull 152. Unfortunately, it doesn't take care of this problem ?

I will keep a watch on this, however.
________________________________
From: Aleksey Shipilev <shade at redhat.com>
Sent: Thursday, June 16, 2022 10:36 AM
To: Browser <browseria at hotmail.com>; build-dev at openjdk.org <build-dev at openjdk.org>
Subject: Re: assembler_x86.cpp:11128:38: error: 'this' pointer is null

On 6/16/22 17:28, Aleksey Shipilev wrote:
> On 6/16/22 16:43, Browser wrote:
>> Has anyone tried compiling this on RHEL9 or Fedora >= 34 / GCC >= 11.3.1?
>> Does anyone know of a workaround to get this to compile on these platforms/with these compilers?
>
> That seems to be:
>     https://bugs.openjdk.org/browse/JDK-8278525
>
> If so, it is fixed in mainline, and just needs a backport to 18u and other releases.

18u backport:
   https://urldefense.com/v3/__https://github.com/openjdk/jdk18u/pull/152__;!!ACWV5N9M2RV99hQ!MmIfKPxNEvMe_Zc1IVbxZEHsyLKf7A6sa-37z_MGCk8BeSy-wXBYZh3VGylC_LN3puRKkun_9hMlKrUgI1ASd-k$ 

You might want to try and test that on your GCC 11 box. (There are instructions how to get the PR
branch from Git).

--
Thanks,
-Aleksey

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20220616/04463444/attachment.htm>

From shade at redhat.com  Thu Jun 16 17:02:27 2022
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 16 Jun 2022 19:02:27 +0200
Subject: assembler_x86.cpp:11128:38: error: 'this' pointer is null
In-Reply-To: <CY5P223MB0490AE97668D1F228481A02EABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
References: <CY5P223MB049042CC6C9FBBDD7F57CEA1ABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
 <1ec8068a-8097-2519-da53-74dd4943e17f@redhat.com>
 <39d85c1d-c5ce-5e75-7b57-69af9385cb18@redhat.com>
 <CY5P223MB0490AE97668D1F228481A02EABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
Message-ID: <13b3d4d3-3137-8fcf-9e00-e8908c282590@redhat.com>

On 6/16/22 17:56, Browser wrote:
> Thank you for pointing me in the right direction! I tried the backport in pull 152. Unfortunately, 
> it doesn't take care of this problem ?

Are you seeing the same failure?

I just built the jdk18u on Fedora 36 / GCC 12 and it failed as you described. Then I built jdk18u 
with my backport, and it now fails further down the line:

* For target hotspot_variant-server_libjvm_objs_zReferenceProcessor.o:
/home/test/shipilev-jdk18u/src/hotspot/share/gc/z/zReferenceProcessor.cpp: In member function 
'oopDesc* ZReferenceProcessor::drop(oop, ReferenceType)':
/home/test/shipilev-jdk18u/src/hotspot/share/gc/z/zReferenceProcessor.cpp:270:22: error: '%s' 
directive argument is null [-Werror=format-overflow=]
   270 |   log_trace(gc, ref)("Dropped Reference: " PTR_FORMAT " (%s)", p2i(reference), 
reference_type_name(type));
       |                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

That one I'll chalk up to not-yet-resolved issue with GCC 12. Mainline does not seem to fail GCC 12 
the same way, but it does fail too.

Pleasing the newer compiler version is always something in progress. Meanwhile, as usual, 
configuring with --disable-warnings-as-errors helps to demote these warnings to just warnings.

-- 
Thanks,
-Aleksey



From asotona at openjdk.org  Thu Jun 16 17:05:17 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 16 Jun 2022 17:05:17 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v12]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <3FVbsCyO8Uhv_P47AQJRdjzXy-Vrd3bD1-ReNIZ7jBI=.f4b29583-4211-4027-90b1-f7e133ff56ea@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module
 - Added man-page line about lossy-conversion lint
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   re-enabled warnings for java.base, java.rmi and java.smartcardio
 - Merge branch 'openjdk:master' into JDK-8244681
 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base
   new case appeared in java.base by moving jdk.incubator.foreign code under java.base
 - Merge remote-tracking branch 'upstream/master' into JDK-8244681
   
   # Conflicts:
   #	make/test/BuildMicrobenchmark.gmk
 - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr
 - ... and 6 more: https://git.openjdk.org/jdk/compare/e7d52e25...1b2d663d

-------------

Changes: https://git.openjdk.org/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=11
  Stats: 442 lines in 17 files changed: 440 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.org/jdk/pull/8599


From browseria at hotmail.com  Thu Jun 16 18:00:56 2022
From: browseria at hotmail.com (Browser)
Date: Thu, 16 Jun 2022 18:00:56 +0000
Subject: assembler_x86.cpp:11128:38: error: 'this' pointer is null
In-Reply-To: <13b3d4d3-3137-8fcf-9e00-e8908c282590@redhat.com>
References: <CY5P223MB049042CC6C9FBBDD7F57CEA1ABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
 <1ec8068a-8097-2519-da53-74dd4943e17f@redhat.com>
 <39d85c1d-c5ce-5e75-7b57-69af9385cb18@redhat.com>
 <CY5P223MB0490AE97668D1F228481A02EABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
 <13b3d4d3-3137-8fcf-9e00-e8908c282590@redhat.com>
Message-ID: <CY5P223MB04900BF2A51873504A66F94DABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>

Yes, that is the exact same error I get with the backport. I also tried disabling all errors, but I got even more null pointer and use after free warnings. It did result in a runable `./build/linux-x86_64-server-release/images/jdk/bin/java` / JDK, however I no longer have confidence in the JDK generated. null pointers make me nervous, use-after-free warnings also make me nervous! Is this something I need to worry about? Or is the JDK still good?
________________________________
From: Aleksey Shipilev <shade at redhat.com>
Sent: Thursday, June 16, 2022 12:02 PM
To: Browser <browseria at hotmail.com>; build-dev at openjdk.org <build-dev at openjdk.org>
Subject: Re: assembler_x86.cpp:11128:38: error: 'this' pointer is null

On 6/16/22 17:56, Browser wrote:
> Thank you for pointing me in the right direction! I tried the backport in pull 152. Unfortunately,
> it doesn't take care of this problem ?

Are you seeing the same failure?

I just built the jdk18u on Fedora 36 / GCC 12 and it failed as you described. Then I built jdk18u
with my backport, and it now fails further down the line:

* For target hotspot_variant-server_libjvm_objs_zReferenceProcessor.o:
/home/test/shipilev-jdk18u/src/hotspot/share/gc/z/zReferenceProcessor.cpp: In member function
'oopDesc* ZReferenceProcessor::drop(oop, ReferenceType)':
/home/test/shipilev-jdk18u/src/hotspot/share/gc/z/zReferenceProcessor.cpp:270:22: error: '%s'
directive argument is null [-Werror=format-overflow=]
   270 |   log_trace(gc, ref)("Dropped Reference: " PTR_FORMAT " (%s)", p2i(reference),
reference_type_name(type));
       |                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

That one I'll chalk up to not-yet-resolved issue with GCC 12. Mainline does not seem to fail GCC 12
the same way, but it does fail too.

Pleasing the newer compiler version is always something in progress. Meanwhile, as usual,
configuring with --disable-warnings-as-errors helps to demote these warnings to just warnings.

--
Thanks,
-Aleksey

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20220616/a373ad49/attachment.htm>

From aph-open at littlepinkcloud.com  Fri Jun 17 07:36:54 2022
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Fri, 17 Jun 2022 08:36:54 +0100
Subject: assembler_x86.cpp:11128:38: error: 'this' pointer is null
In-Reply-To: <CY5P223MB04900BF2A51873504A66F94DABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
References: <CY5P223MB049042CC6C9FBBDD7F57CEA1ABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
 <1ec8068a-8097-2519-da53-74dd4943e17f@redhat.com>
 <39d85c1d-c5ce-5e75-7b57-69af9385cb18@redhat.com>
 <CY5P223MB0490AE97668D1F228481A02EABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
 <13b3d4d3-3137-8fcf-9e00-e8908c282590@redhat.com>
 <CY5P223MB04900BF2A51873504A66F94DABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
Message-ID: <1360de29-8066-5506-0bd8-63088a3751aa@littlepinkcloud.com>

On 6/16/22 19:00, Browser wrote:
 > That one I'll chalk up to not-yet-resolved issue with GCC 12. Mainline does not seem to fail GCC 12
 > the same way, but it does fail too.

 > shade at redhat.com:

 >> Pleasing the newer compiler version is always something in
 >> progress. Meanwhile, as usual, configuring with
 >> --disable-warnings-as-errors helps to demote these warnings to just
 >> warnings.

This is the Undefined Behaviour bug that I fixed for AArch64 in
8276563, Undefined Behaviour in class Assembler. Compilers get
smarter, and IMO this is an evil hack from decades ago that we should
fix.

The problem is that all instances of type Register exhibit UB in the
form of wild pointer (including null pointer) dereferences. It isn't
very hard to fix: we should make Registers pointers to something
rather than aliases of small integers.

I'd like to apply the same fix to x86, so we never hear of this bug
again. What do you think?

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://urldefense.com/v3/__https://www.redhat.com__;!!ACWV5N9M2RV99hQ!OtbRk3IjtkZWG0t0Bpsa66EfBsaQMGoFlzSIyRDF9W1_eN7GogdN6wA4buYUnsub7-H2sS_NCqzQlBGmP6sZrrD86Wq7$ >
https://urldefense.com/v3/__https://keybase.io/andrewhaley__;!!ACWV5N9M2RV99hQ!OtbRk3IjtkZWG0t0Bpsa66EfBsaQMGoFlzSIyRDF9W1_eN7GogdN6wA4buYUnsub7-H2sS_NCqzQlBGmP6sZrnHbC_Pi$ 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From ihse at openjdk.org  Fri Jun 17 13:59:09 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 17 Jun 2022 13:59:09 GMT
Subject: RFR: 8288396: Always create reproducible builds [v5]
In-Reply-To: <Rbf9agwOfJ9hcxnAuRVTAV__47bh83C8U6SmbG2yyHg=.92ff9026-6bdf-4b40-bde8-c29b985f9996@github.com>
References: <ckkR5_LGhD3Q10LqP84yyapjrO6_RVFwcHGLsMiVZno=.8359d6b6-9510-4309-8cf5-10ee85706107@github.com>
 <Rbf9agwOfJ9hcxnAuRVTAV__47bh83C8U6SmbG2yyHg=.92ff9026-6bdf-4b40-bde8-c29b985f9996@github.com>
Message-ID: <5dvZCp5zW56RrXU6QPhglJP2dT0fk3g71L8peDgELiY=.857d2783-3a5e-442b-9921-29c8074c3c2b@github.com>

On Wed, 15 Jun 2022 15:18:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> When we started introducing some possibly more intrusive compiler flags and functionality for reproducible builds, we also introduced a flag to turn this off  out of an abundance of caution. But we have been been using this configuration for a year or so internally within Oracle, with no issues. So there's really no reason to be able to turn this off. (If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one.)
>> 
>> With this fix, all randomness should be gone from our builds, at least on linux and windows. There are no more `__DATE__` and `__TIME__` macros in the source code.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove incorrect argument
>  - Test if linker can accept the flag

Anyone from Hotspot caring to review the Hotspot changes?

-------------

PR: https://git.openjdk.org/jdk/pull/9152


From serb at openjdk.org  Fri Jun 17 23:14:53 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 17 Jun 2022 23:14:53 GMT
Subject: RFR: 8286623: Bundle zlib by default with JDK on macos aarch64
In-Reply-To: <eg6oa0mM1gHJ1Z8On__L6JoO5xe6Rd_6zXtV-POrgGU=.16037f2f-8574-4e44-b63a-caa1bffb49d0@github.com>
References: <yXDeNXPyOXPSwn7yHh1tehQj4lUejjLLolmWasKtCIg=.d33792fb-a743-488d-94c2-01957e52dbbf@github.com>
 <eg6oa0mM1gHJ1Z8On__L6JoO5xe6Rd_6zXtV-POrgGU=.16037f2f-8574-4e44-b63a-caa1bffb49d0@github.com>
Message-ID: <nQ7yJdmcRUB23SBr9X9xSzQacsMsgtaN18iC99B02uo=.4767fb7e-46dc-441b-a6c1-50aef550e868@github.com>

On Fri, 13 May 2022 01:54:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change to the build system which now makes bundled zlib as the default for macos aarch64 systems? 
>> 
>> We have been running into various intermittent failures on macos aarch64 systems for several months now. After investigation we have been able to ascertain that the root cause of the issue lies within the zlib that's shipped on macos aarch64 systems. The complete details about that issue is available at https://bugs.openjdk.java.net/browse/JDK-8282954. 
>> We have filed a bug with Apple for their inputs on what we can do to fix it in that shipped library. Given the nature of that issue, we don't have a timeline on when/if the solution for that will be available. Until that time, at least, the proposal is to use bundled zlib (which doesn't reproduce those failures) by default on macos aarch64.
>
> Thank you everyone for the reviews.

@jaikiran Do you have a plan to backport this fix to the 17 and below?

-------------

PR: https://git.openjdk.org/jdk/pull/8675


From shade at redhat.com  Mon Jun 20 08:55:27 2022
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 20 Jun 2022 10:55:27 +0200
Subject: assembler_x86.cpp:11128:38: error: 'this' pointer is null
In-Reply-To: <1360de29-8066-5506-0bd8-63088a3751aa@littlepinkcloud.com>
References: <CY5P223MB049042CC6C9FBBDD7F57CEA1ABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
 <1ec8068a-8097-2519-da53-74dd4943e17f@redhat.com>
 <39d85c1d-c5ce-5e75-7b57-69af9385cb18@redhat.com>
 <CY5P223MB0490AE97668D1F228481A02EABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
 <13b3d4d3-3137-8fcf-9e00-e8908c282590@redhat.com>
 <CY5P223MB04900BF2A51873504A66F94DABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
 <1360de29-8066-5506-0bd8-63088a3751aa@littlepinkcloud.com>
Message-ID: <33838a36-732b-4947-91eb-a76d2cd2e839@redhat.com>

On 6/17/22 09:36, Andrew Haley wrote:
> On 6/16/22 19:00, Browser wrote:
>   > That one I'll chalk up to not-yet-resolved issue with GCC 12. Mainline does not seem to fail GCC 12
>   > the same way, but it does fail too.
> 
>   > shade at redhat.com:
> 
>   >> Pleasing the newer compiler version is always something in
>   >> progress. Meanwhile, as usual, configuring with
>   >> --disable-warnings-as-errors helps to demote these warnings to just
>   >> warnings.
> 
> This is the Undefined Behaviour bug that I fixed for AArch64 in
> 8276563, Undefined Behaviour in class Assembler. Compilers get
> smarter, and IMO this is an evil hack from decades ago that we should
> fix.
> 
> The problem is that all instances of type Register exhibit UB in the
> form of wild pointer (including null pointer) dereferences. It isn't
> very hard to fix: we should make Registers pointers to something
> rather than aliases of small integers.
> 
> I'd like to apply the same fix to x86, so we never hear of this bug
> again. What do you think?

Yes, please. I think I am seeing this now in mainline JDK with GCC 11:

* For target hotspot_variant-server_libjvm_objs_sharedRuntime_x86_32.o:
/home/buildbot/worker/build-jdkX-debian12/build/src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp: In 
static member function 'static OopMap* RegisterSaver::save_live_registers(MacroAssembler*, int, 
int*, bool, bool)':
/home/buildbot/worker/build-jdkX-debian12/build/src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp:260:48: 
error: 'this' pointer is null [-Werror=nonnull]
   260 |   map->set_callee_saved(STACK_OFFSET(rax_off), rax->as_VMReg());
       |                                                ^~~
In file included from 
/home/buildbot/worker/build-jdkX-debian12/build/src/hotspot/share/code/vmreg.inline.hpp:31,
                  from 
/home/buildbot/worker/build-jdkX-debian12/build/src/hotspot/cpu/x86/macroAssembler_x86.hpp:30,
                  from 
/home/buildbot/worker/build-jdkX-debian12/build/src/hotspot/share/asm/macroAssembler.hpp:31,
                  from 
/home/buildbot/worker/build-jdkX-debian12/build/src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp:26:


-- 
Thanks,
-Aleksey



From shade at redhat.com  Mon Jun 20 09:51:56 2022
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 20 Jun 2022 11:51:56 +0200
Subject: assembler_x86.cpp:11128:38: error: 'this' pointer is null
In-Reply-To: <CY5P223MB04900BF2A51873504A66F94DABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
References: <CY5P223MB049042CC6C9FBBDD7F57CEA1ABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
 <1ec8068a-8097-2519-da53-74dd4943e17f@redhat.com>
 <39d85c1d-c5ce-5e75-7b57-69af9385cb18@redhat.com>
 <CY5P223MB0490AE97668D1F228481A02EABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
 <13b3d4d3-3137-8fcf-9e00-e8908c282590@redhat.com>
 <CY5P223MB04900BF2A51873504A66F94DABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
Message-ID: <3712d119-702c-51ef-bd74-72d9096c15ce@redhat.com>

On 6/16/22 20:00, Browser wrote:
> ... It did result in a runable `./build/linux-x86_64-server-release/images/jdk/bin/java` / JDK, 
> however I no longer have confidence in the JDK generated. null pointers make me nervous, 
> use-after-free warnings also make me nervous! Is this something I need to worry about? Or is the
> JDK still good?
Depends on your current worldview, to be honest.

Optimistic view: OpenJDK builds already disable a whole lot of compiler warnings. Newer toolchains 
routinely come with new warnings that are either fixed in code, or added to global ignore lists, or 
disabled per code spot. The OpenJDK build faces this more often because it builds with 
warnings-as-errors by default. As long as your built OpenJDK passes testing, it is probably fine.

Pessimistic view: compiler warnings are real, the bugs they signify are real, the products that 
build with warnings are probably subtly broken, no reasonable amount of testing would cover 
everything, things fall apart, centre cannot hold, mere anarchy is loosed upon the world, he comes 
he comes his unholy radiance destroying all enlightenment all is lost all is lost...

I believe many people normally oscillate between these two.

We should strive to get the cleanest builds by default, of course, by examining each warning and 
ballparking its risks. Your case only highlights that is the ongoing struggle.

-- 
Thanks,
-Aleksey



From jpai at openjdk.org  Mon Jun 20 11:51:54 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 20 Jun 2022 11:51:54 GMT
Subject: RFR: 8286623: Bundle zlib by default with JDK on macos aarch64
In-Reply-To: <yXDeNXPyOXPSwn7yHh1tehQj4lUejjLLolmWasKtCIg=.d33792fb-a743-488d-94c2-01957e52dbbf@github.com>
References: <yXDeNXPyOXPSwn7yHh1tehQj4lUejjLLolmWasKtCIg=.d33792fb-a743-488d-94c2-01957e52dbbf@github.com>
Message-ID: <rQQuysKlPnrqvAw_2ctpuvhtQI2Tq7A0xehLa2N4fGw=.52ff545e-9c81-4a54-ad6f-644165159fa9@github.com>

On Thu, 12 May 2022 08:43:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change to the build system which now makes bundled zlib as the default for macos aarch64 systems? 
> 
> We have been running into various intermittent failures on macos aarch64 systems for several months now. After investigation we have been able to ascertain that the root cause of the issue lies within the zlib that's shipped on macos aarch64 systems. The complete details about that issue is available at https://bugs.openjdk.java.net/browse/JDK-8282954. 
> We have filed a bug with Apple for their inputs on what we can do to fix it in that shipped library. Given the nature of that issue, we don't have a timeline on when/if the solution for that will be available. Until that time, at least, the proposal is to use bundled zlib (which doesn't reproduce those failures) by default on macos aarch64.

Hello Sergey, there's currently no plan to backport this. We are hoping to hear back from Apple for the root cause issue that we have filed.

-------------

PR: https://git.openjdk.org/jdk/pull/8675


From jwaters at openjdk.org  Mon Jun 20 13:09:16 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 20 Jun 2022 13:09:16 GMT
Subject: RFR: JDK-8288740: Change incorrect documentation for sjavac flag
Message-ID: <M2swnyXWBH-9NPaYUdZ3sKj2t1mb2NXkEgw1EIbfCBw=.02751813-c843-466c-9e8c-3c210c4c9bd0@github.com>

The documentation for build performance currently points to the non-existent --enable-sjavac flag to enable sjavac, the correct one is actually --enable-javac-server (Finally seem to have gotten pandoc working, hopefully the html is correct this time)

-------------

Commit messages:
 - Correct sjavac documentation in build docs

Changes: https://git.openjdk.org/jdk/pull/9215/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9215&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288740
  Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9215.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9215/head:pull/9215

PR: https://git.openjdk.org/jdk/pull/9215


From jwilhelm at openjdk.org  Mon Jun 20 18:28:50 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 20 Jun 2022 18:28:50 GMT
Subject: RFR: Merge jdk19
Message-ID: <cvtpd9RoksS7fxFHaBb5gLifLOq1ICRq871yeUA3LKg=.b796dace-c0c5-416b-9e70-bed600da4cd8@github.com>

Forwardport JDK 19 -> JDK 20

-------------

Commit messages:
 - Merge
 - 8288527: broken link in java.base/java/util/zip/package-summary.html
 - 8288741: JFR: Change package name of snippet files
 - 8288663: JFR: Disabling the JfrThreadSampler commits only a partially disabled state
 - 8287800: JFR: Incorrect error message when starting recording with missing .jfc file
 - 8288485: jni/nullCaller/NullCallerTest.java failing (ppc64)
 - 8288564: C2: LShiftLNode::Ideal produces wrong result after JDK-8278114
 - 8288397: AArch64: Fix register issues in SVE backend match rules
 - 8288692: jdk/javadoc/doclet/testTagMisuse/TestTagMisuse.java fails after JDK-8288545
 - 8268398: 15% increase in JFR footprint in Noop-Base
 - ... and 1 more: https://git.openjdk.org/jdk/compare/302a6c06...6efc7e9e

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9220&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9220&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9220/files
  Stats: 752 lines in 36 files changed: 538 ins; 58 del; 156 mod
  Patch: https://git.openjdk.org/jdk/pull/9220.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9220/head:pull/9220

PR: https://git.openjdk.org/jdk/pull/9220


From jwilhelm at openjdk.org  Mon Jun 20 19:44:19 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 20 Jun 2022 19:44:19 GMT
Subject: RFR: Merge jdk19 [v2]
In-Reply-To: <cvtpd9RoksS7fxFHaBb5gLifLOq1ICRq871yeUA3LKg=.b796dace-c0c5-416b-9e70-bed600da4cd8@github.com>
References: <cvtpd9RoksS7fxFHaBb5gLifLOq1ICRq871yeUA3LKg=.b796dace-c0c5-416b-9e70-bed600da4cd8@github.com>
Message-ID: <wOC-cOnunQe0dlkf1uVHOn0PrafZajxmhFD_Rg6cwuI=.072a626a-5ae7-4ed5-a0a6-d3eeacd89c8b@github.com>

> Forwardport JDK 19 -> JDK 20

Jesper Wilhelmsson 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 96 additional commits since the last revision:

 - Merge
 - 8287801: Fix test-bugs related to stress flags
   
   Reviewed-by: chagedorn, thartmann
 - 8288663: JFR: Disabling the JfrThreadSampler commits only a partially disabled state
   
   Reviewed-by: jbachorik, egahlin
 - 8287771: Remove useless G1 After GC summary refinement and sampling thread times
   
   Reviewed-by: tschatzl, kbarrett
 - 8288011: StringConcatFactory: Split application of stringifiers
   
   Reviewed-by: jvernee, mchung
 - 8288685: JFR: Use static methods for Active Recording and Active Setting events
   
   Reviewed-by: mgronlun
 - 8288673: Reduce runtime of java.time microbenchmarks
   
   Reviewed-by: jvernee
 - 8288667: Reduce runtime of java.text microbenchmarks
   
   Reviewed-by: jvernee
 - 8284672: Collapse identical catch branches in java.desktop
   
   Reviewed-by: prr, aivanov, serb
 - 8288329: Avoid redundant TreeMap.containsKey call in PolicyParser.read
   
   Reviewed-by: mullan
 - ... and 86 more: https://git.openjdk.org/jdk/compare/cb2201b4...6efc7e9e

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9220/files
  - new: https://git.openjdk.org/jdk/pull/9220/files/6efc7e9e..6efc7e9e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9220&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9220&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9220.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9220/head:pull/9220

PR: https://git.openjdk.org/jdk/pull/9220


From jwilhelm at openjdk.org  Mon Jun 20 19:44:19 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 20 Jun 2022 19:44:19 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <cvtpd9RoksS7fxFHaBb5gLifLOq1ICRq871yeUA3LKg=.b796dace-c0c5-416b-9e70-bed600da4cd8@github.com>
References: <cvtpd9RoksS7fxFHaBb5gLifLOq1ICRq871yeUA3LKg=.b796dace-c0c5-416b-9e70-bed600da4cd8@github.com>
Message-ID: <99J0-7NZyn_B1qAUt-E3RDXhVlOBpw5q0y_7OfkWqNU=.c9779d47-1137-44ca-8b97-bd31716fbc11@github.com>

On Mon, 20 Jun 2022 18:20:21 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 7039c661
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7039c6616ad1b67320f08e7ea4763e8ff4977430
Stats:     752 lines in 36 files changed: 538 ins; 58 del; 156 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/9220


From duke at openjdk.org  Tue Jun 21 06:29:44 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Tue, 21 Jun 2022 06:29:44 GMT
Subject: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default
In-Reply-To: <s90ZHWiCJSzvHHeEUGACyP2851dTKt33JQL3q6iNK_w=.76c5f198-da40-4064-ac2a-c0844f1167dc@github.com>
References: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
 <XOvpFs3L_qkUSrCztK_3ZYF2yiCoVaLvd9xd9JRDi48=.7934314d-782d-4cc6-8997-9e48c9627410@github.com>
 <s90ZHWiCJSzvHHeEUGACyP2851dTKt33JQL3q6iNK_w=.76c5f198-da40-4064-ac2a-c0844f1167dc@github.com>
Message-ID: <0mVNgmpMBfN6cAe10CMInds_yHF3CCFSnSfFOJm1lus=.33d4e0e3-58f7-4d53-9feb-09282093e1c1@github.com>

On Tue, 14 Jun 2022 09:50:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Thank you for your comments.
>> I understood the goal of reproducible build. But now, ENABLE_REPRODUCIBLE_BUILD is set to false in default configuration.
>> Then I think minimize the effort of SOURCE_DATE_EPOCH when reproducible build is disabled. I wonder why build time information is different from Windows and Linux.
>
> @tkiriyama I have created https://bugs.openjdk.org/browse/JDK-8288396 for the approach I championed above, i.e. to always build reproducible instead. As part of this, the `-Xinternalversion` time stamp should be of the same format for all platforms, given the same set of options to `configure`.
> 
> The associated PR is https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9152__;!!ACWV5N9M2RV99hQ!P-ih1KOsqxjOgH-nLhQAe7l_x-qYC9MdAqnWBJMvuCAPBq_5RFQoQMLPMjvRCGZ83WhCSEDBwTuVgZl-EA$ . Can you verify if this solves your issues, and if so, close this bug?

@magicus Thank you for your action. I tried to build above PR branch, and I could get same build information between Windows and Linux
with ISO8601 format. I would close this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/9081


From duke at openjdk.org  Tue Jun 21 06:29:44 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Tue, 21 Jun 2022 06:29:44 GMT
Subject: Withdrawn: 8288001: SOURCE_DATE_EPOCH should not be set by default
In-Reply-To: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
References: <tTvTLFWWdTPfrxk5a5Dc4AVcTOCLb2FexkK42V_lids=.2dba47ae-e286-4875-bf52-0eddd5a73046@github.com>
Message-ID: <OPPVg_LUW23L_qUwsgKtg4HdKFgJfi_HYmSikxBKAtQ=.ddb646e8-2fd1-4507-abc1-0022cb26fc1b@github.com>

On Wed, 8 Jun 2022 07:47:24 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> At default configuration, SOURCE_DATE_EPOCH is exported as environment variable in SetupReproducibleBuild. Then, gcc is affected of SOURCE_DATE_EPOCH environment variable. This value is used only to set SOURCE_DATE_ISO_8601 (except below), so I removed "export" for SOURCE_DATE_EPOCH in SetupReproducibleBuild. And, at building ct.sym, SOURCE_DATE_EPOCH environment variable is needed. So I added setting routine if SOURCE_DATE_EPOCH is not set.
> 
> This fix works fine. With default configuration shows -Xinternalversion output same as Windows, and with --with-source-date configuration shows -Xinternalversion output specified timestamp. Would you please review this fix?

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/9081


From aph-open at littlepinkcloud.com  Tue Jun 21 09:07:31 2022
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Tue, 21 Jun 2022 10:07:31 +0100
Subject: assembler_x86.cpp:11128:38: error: 'this' pointer is null
In-Reply-To: <33838a36-732b-4947-91eb-a76d2cd2e839@redhat.com>
References: <CY5P223MB049042CC6C9FBBDD7F57CEA1ABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
 <1ec8068a-8097-2519-da53-74dd4943e17f@redhat.com>
 <39d85c1d-c5ce-5e75-7b57-69af9385cb18@redhat.com>
 <CY5P223MB0490AE97668D1F228481A02EABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
 <13b3d4d3-3137-8fcf-9e00-e8908c282590@redhat.com>
 <CY5P223MB04900BF2A51873504A66F94DABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
 <1360de29-8066-5506-0bd8-63088a3751aa@littlepinkcloud.com>
 <33838a36-732b-4947-91eb-a76d2cd2e839@redhat.com>
Message-ID: <723cb8ea-2489-2793-3a6e-d204e0b83e5d@littlepinkcloud.com>

On 6/20/22 09:55, Aleksey Shipilev wrote:
> Yes, please. I think I am seeing this now in mainline JDK with GCC 11:
> 
> * For target hotspot_variant-server_libjvm_objs_sharedRuntime_x86_32.o:
> /home/buildbot/worker/build-jdkX-debian12/build/src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp: In
> static member function 'static OopMap* RegisterSaver::save_live_registers(MacroAssembler*, int,
> int*, bool, bool)':
> /home/buildbot/worker/build-jdkX-debian12/build/src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp:260:48:
> error: 'this' pointer is null [-Werror=nonnull]

Please test with that warning diabled, and let me know how you get on.

Thanks,

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://urldefense.com/v3/__https://www.redhat.com__;!!ACWV5N9M2RV99hQ!MulKzlihq43T1sPs-W08TRZXylpYLvnm5d6PBrmBZ7f5D-tWv1IelKqS8BV1aHFAMWKDSgNM8j-HaQT0O-fSqqB0ZUtw$ >
https://urldefense.com/v3/__https://keybase.io/andrewhaley__;!!ACWV5N9M2RV99hQ!MulKzlihq43T1sPs-W08TRZXylpYLvnm5d6PBrmBZ7f5D-tWv1IelKqS8BV1aHFAMWKDSgNM8j-HaQT0O-fSqlIIECkz$ 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From aph-open at littlepinkcloud.com  Tue Jun 21 09:39:43 2022
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Tue, 21 Jun 2022 10:39:43 +0100
Subject: assembler_x86.cpp:11128:38: error: 'this' pointer is null
In-Reply-To: <CY5P223MB04900BF2A51873504A66F94DABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
References: <CY5P223MB049042CC6C9FBBDD7F57CEA1ABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
 <1ec8068a-8097-2519-da53-74dd4943e17f@redhat.com>
 <39d85c1d-c5ce-5e75-7b57-69af9385cb18@redhat.com>
 <CY5P223MB0490AE97668D1F228481A02EABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
 <13b3d4d3-3137-8fcf-9e00-e8908c282590@redhat.com>
 <CY5P223MB04900BF2A51873504A66F94DABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
Message-ID: <52a517fd-da1e-5168-f9db-cfa3107a21de@littlepinkcloud.com>

On 6/16/22 19:00, Browser wrote:
> Yes, that is the exact same error I get with the backport. I also tried disabling all errors, but I got even more null pointer and use after free warnings. It did result in a runable `./build/linux-x86_64-server-release/images/jdk/bin/java` / JDK, however I no longer have confidence in the JDK generated. null pointers make me nervous, use-after-free warnings also make me nervous! Is this something I need to worry about? Or is the JDK still good?

I think so, yes, because of the compiler options that we use to disable some
of GCC's optimizations. A better fix is on the way, I promise.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://urldefense.com/v3/__https://www.redhat.com__;!!ACWV5N9M2RV99hQ!Oz1Ll2hpKPTlsavALMxhVl5deB43BVS2oGsKZCQ_HgV9dSr4TPYP38bH44OSZN-JeX8MuUsa5bej6ltBMURcAZCwjinB$ >
https://urldefense.com/v3/__https://keybase.io/andrewhaley__;!!ACWV5N9M2RV99hQ!Oz1Ll2hpKPTlsavALMxhVl5deB43BVS2oGsKZCQ_HgV9dSr4TPYP38bH44OSZN-JeX8MuUsa5bej6ltBMURcAR5WVPGf$ 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From shade at redhat.com  Tue Jun 21 13:12:50 2022
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 21 Jun 2022 15:12:50 +0200
Subject: assembler_x86.cpp:11128:38: error: 'this' pointer is null
In-Reply-To: <723cb8ea-2489-2793-3a6e-d204e0b83e5d@littlepinkcloud.com>
References: <CY5P223MB049042CC6C9FBBDD7F57CEA1ABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
 <1ec8068a-8097-2519-da53-74dd4943e17f@redhat.com>
 <39d85c1d-c5ce-5e75-7b57-69af9385cb18@redhat.com>
 <CY5P223MB0490AE97668D1F228481A02EABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
 <13b3d4d3-3137-8fcf-9e00-e8908c282590@redhat.com>
 <CY5P223MB04900BF2A51873504A66F94DABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
 <1360de29-8066-5506-0bd8-63088a3751aa@littlepinkcloud.com>
 <33838a36-732b-4947-91eb-a76d2cd2e839@redhat.com>
 <723cb8ea-2489-2793-3a6e-d204e0b83e5d@littlepinkcloud.com>
Message-ID: <2efe9a53-1854-7b57-63e8-909b8e6057da@redhat.com>

On 6/21/22 11:07, Andrew Haley wrote:
> On 6/20/22 09:55, Aleksey Shipilev wrote:
>> Yes, please. I think I am seeing this now in mainline JDK with GCC 11:
>>
>> * For target hotspot_variant-server_libjvm_objs_sharedRuntime_x86_32.o:
>> /home/buildbot/worker/build-jdkX-debian12/build/src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp: In
>> static member function 'static OopMap* RegisterSaver::save_live_registers(MacroAssembler*, int,
>> int*, bool, bool)':
>> /home/buildbot/worker/build-jdkX-debian12/build/src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp:260:48:
>> error: 'this' pointer is null [-Werror=nonnull]
> 
> Please test with that warning diabled, and let me know how you get on.

linux-x86-server-release builds fine with "./configure --with-extra-cflags=-Wno-nonnull".

-- 
Thanks,
-Aleksey



From ihse at openjdk.org  Wed Jun 22 09:15:42 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 22 Jun 2022 09:15:42 GMT
Subject: RFR: JDK-8288740: Change incorrect documentation for sjavac flag
In-Reply-To: <M2swnyXWBH-9NPaYUdZ3sKj2t1mb2NXkEgw1EIbfCBw=.02751813-c843-466c-9e8c-3c210c4c9bd0@github.com>
References: <M2swnyXWBH-9NPaYUdZ3sKj2t1mb2NXkEgw1EIbfCBw=.02751813-c843-466c-9e8c-3c210c4c9bd0@github.com>
Message-ID: <4WCcnbxrJ6mQO0BhvDL4eT9zzPGCZhSeDEF6mD33aJY=.83fd1103-7d47-4fc6-8087-c77df87e09bc@github.com>

On Mon, 20 Jun 2022 13:01:40 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> The documentation for build performance currently points to the non-existent --enable-sjavac flag to enable sjavac, the correct one is actually --enable-javac-server (Finally seem to have gotten pandoc working, hopefully the html is correct this time)

Marked as reviewed by ihse (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9215


From djelinski at openjdk.org  Wed Jun 22 14:41:07 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 22 Jun 2022 14:41:07 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time
Message-ID: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>

This PR improves the performance of deduplication done by ResourceBundleGenerator.

The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.

The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
The files generated before and after this change have the same size.

-------------

Commit messages:
 - Speed up CLDR deduplication

Changes: https://git.openjdk.org/jdk/pull/9243/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9243&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288979
  Stats: 101 lines in 1 file changed: 56 ins; 27 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/9243.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9243/head:pull/9243

PR: https://git.openjdk.org/jdk/pull/9243


From rriggs at openjdk.org  Wed Jun 22 16:22:15 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 22 Jun 2022 16:22:15 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time
In-Reply-To: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
Message-ID: <wz124fKQn2-5D4UClkQio8OWjodF7UPigEXztfANbI0=.60573b34-dd4a-4764-a243-005859bac43a@github.com>

On Wed, 22 Jun 2022 14:24:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This PR improves the performance of deduplication done by ResourceBundleGenerator.
> 
> The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.
> 
> The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
> The files generated before and after this change have the same size.

make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java line 146:

> 144:             // generic reduction of duplicated values
> 145:             Map<String, Object> newMap = new HashMap<>(map);
> 146:             Map<BundleEntryValue, BundleEntryValue> dedup = new HashMap<>(map.size());

LinkedHashMap could be used to retain the iteration order.
Or TreeMap if some deterministic order was desirable.

make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java line 157:

> 155:                             fmt = new Formatter();
> 156:                         }
> 157:                         String metaVal = oldEntry.metaKey();

The new instanceof pattern matching could be used avoid the cast below.

make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java line 270:

> 268:                 if (value instanceof String s) {
> 269:                     return s.equals(entry.value);
> 270:                 } else if (!(entry.value instanceof String[])) {

Could be re-written to use instanceof pattern and save a cast.

-------------

PR: https://git.openjdk.org/jdk/pull/9243


From djelinski at openjdk.org  Wed Jun 22 17:10:55 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 22 Jun 2022 17:10:55 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time
In-Reply-To: <wz124fKQn2-5D4UClkQio8OWjodF7UPigEXztfANbI0=.60573b34-dd4a-4764-a243-005859bac43a@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <wz124fKQn2-5D4UClkQio8OWjodF7UPigEXztfANbI0=.60573b34-dd4a-4764-a243-005859bac43a@github.com>
Message-ID: <8GdQ3xogOEjYUEYyOu1ryPXvYL9hiqxSBQ_vQmqyRE0=.ed513d11-9b3c-4256-8d59-3be410f6735c@github.com>

On Wed, 22 Jun 2022 16:11:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This PR improves the performance of deduplication done by ResourceBundleGenerator.
>> 
>> The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.
>> 
>> The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
>> The files generated before and after this change have the same size.
>
> make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java line 146:
> 
>> 144:             // generic reduction of duplicated values
>> 145:             Map<String, Object> newMap = new HashMap<>(map);
>> 146:             Map<BundleEntryValue, BundleEntryValue> dedup = new HashMap<>(map.size());
> 
> LinkedHashMap could be used to retain the iteration order.
> Or TreeMap if some deterministic order was desirable.

True. Which raises the question: do we need any arbitrary order? The original code used a hashmap too. It preserved the original order only when no duplicates were detected.

-------------

PR: https://git.openjdk.org/jdk/pull/9243


From djelinski at openjdk.org  Wed Jun 22 17:30:48 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 22 Jun 2022 17:30:48 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time [v2]
In-Reply-To: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
Message-ID: <GNbRMZG2qKz5mTOajQDN5D2irerbicTPIuDUch-sh0Y=.f2543f76-a773-4219-8268-e43b2c0452a8@github.com>

> This PR improves the performance of deduplication done by ResourceBundleGenerator.
> 
> The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.
> 
> The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
> The files generated before and after this change have the same size.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Use instanceof pattern matching

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9243/files
  - new: https://git.openjdk.org/jdk/pull/9243/files/c3743d18..6cb47724

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9243&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9243&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9243.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9243/head:pull/9243

PR: https://git.openjdk.org/jdk/pull/9243


From rriggs at openjdk.org  Wed Jun 22 17:30:51 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 22 Jun 2022 17:30:51 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time [v2]
In-Reply-To: <8GdQ3xogOEjYUEYyOu1ryPXvYL9hiqxSBQ_vQmqyRE0=.ed513d11-9b3c-4256-8d59-3be410f6735c@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <wz124fKQn2-5D4UClkQio8OWjodF7UPigEXztfANbI0=.60573b34-dd4a-4764-a243-005859bac43a@github.com>
 <8GdQ3xogOEjYUEYyOu1ryPXvYL9hiqxSBQ_vQmqyRE0=.ed513d11-9b3c-4256-8d59-3be410f6735c@github.com>
Message-ID: <aIfWDx0KtZvFhOf8Jw_NeMtlkZ6WtWlxJKeNoIaKNxI=.450d721b-48d5-4dc3-b4b6-fa4b86d0de6c@github.com>

On Wed, 22 Jun 2022 17:07:11 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java line 146:
>> 
>>> 144:             // generic reduction of duplicated values
>>> 145:             Map<String, Object> newMap = new HashMap<>(map);
>>> 146:             Map<BundleEntryValue, BundleEntryValue> dedup = new HashMap<>(map.size());
>> 
>> LinkedHashMap could be used to retain the iteration order.
>> Or TreeMap if some deterministic order was desirable.
>
> True. Which raises the question: do we need any arbitrary order? The original code used a hashmap too. It preserved the original order only when no duplicates were detected.

A stable order is useful when comparing between builds (by a human). 
It also supports the goal of reproducible builds.
@naotoj  What do you think?

-------------

PR: https://git.openjdk.org/jdk/pull/9243


From naoto at openjdk.org  Wed Jun 22 18:02:07 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 Jun 2022 18:02:07 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time [v2]
In-Reply-To: <aIfWDx0KtZvFhOf8Jw_NeMtlkZ6WtWlxJKeNoIaKNxI=.450d721b-48d5-4dc3-b4b6-fa4b86d0de6c@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <wz124fKQn2-5D4UClkQio8OWjodF7UPigEXztfANbI0=.60573b34-dd4a-4764-a243-005859bac43a@github.com>
 <8GdQ3xogOEjYUEYyOu1ryPXvYL9hiqxSBQ_vQmqyRE0=.ed513d11-9b3c-4256-8d59-3be410f6735c@github.com>
 <aIfWDx0KtZvFhOf8Jw_NeMtlkZ6WtWlxJKeNoIaKNxI=.450d721b-48d5-4dc3-b4b6-fa4b86d0de6c@github.com>
Message-ID: <VgTYYO5SaGu-KSu5HuM8oILkBReE0isNi3GVP3HvhaU=.6ad95bbf-ac98-4983-b09a-acdbee20beab@github.com>

On Wed, 22 Jun 2022 17:27:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> True. Which raises the question: do we need any arbitrary order? The original code used a hashmap too. It preserved the original order only when no duplicates were detected.
>
> A stable order is useful when comparing between builds (by a human). 
> It also supports the goal of reproducible builds.
> @naotoj  What do you think?

IIUC, once this fix makes it to the repository, the build will be reproducible. Making it to be sorted is a welcome enhancement (I compare the generated bundles manually from time to time), but it may be costly so it could defy the performance improvement?

-------------

PR: https://git.openjdk.org/jdk/pull/9243


From jwilhelm at openjdk.org  Wed Jun 22 21:32:40 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 22 Jun 2022 21:32:40 GMT
Subject: RFR: Merge jdk19
Message-ID: <3-PLWroZbcfL-LaQ2_R6PTYsuJi7TzLIx15dVCOdNU8=.76b664a2-58e8-4356-bdae-e39242872744@github.com>

Forwardport JDK 19 -> JDK 20

-------------

Commit messages:
 - Merge
 - 8288988: ProblemList serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java in -Xcomp mode
 - 8288846: misc tests fail "assert(ms < 1000) failed: Un-interruptable sleep, short time use only"
 - 8288840: StructureViolationException should not link to fork method
 - 8287982: Concurrent implicit attach from native threads crashes VM
 - 8288529: broken link in java.xml

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9251&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9251&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9251/files
  Stats: 434 lines in 12 files changed: 379 ins; 22 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/9251.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9251/head:pull/9251

PR: https://git.openjdk.org/jdk/pull/9251


From naoto at openjdk.org  Wed Jun 22 21:51:42 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 Jun 2022 21:51:42 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time [v2]
In-Reply-To: <GNbRMZG2qKz5mTOajQDN5D2irerbicTPIuDUch-sh0Y=.f2543f76-a773-4219-8268-e43b2c0452a8@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <GNbRMZG2qKz5mTOajQDN5D2irerbicTPIuDUch-sh0Y=.f2543f76-a773-4219-8268-e43b2c0452a8@github.com>
Message-ID: <3wfGl3xjVGdG52MQJnW48OogCIctlTpQkySX_oKx95c=.8ddb037c-a37b-4284-9e0d-dea038b2fc10@github.com>

On Wed, 22 Jun 2022 17:30:48 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This PR improves the performance of deduplication done by ResourceBundleGenerator.
>> 
>> The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.
>> 
>> The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
>> The files generated before and after this change have the same size.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use instanceof pattern matching

Thanks for the refactoring Daniel. Removing the leftover `List` was a bonus.

-------------

PR: https://git.openjdk.org/jdk/pull/9243


From naoto at openjdk.org  Wed Jun 22 21:51:42 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 Jun 2022 21:51:42 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time [v2]
In-Reply-To: <VgTYYO5SaGu-KSu5HuM8oILkBReE0isNi3GVP3HvhaU=.6ad95bbf-ac98-4983-b09a-acdbee20beab@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <wz124fKQn2-5D4UClkQio8OWjodF7UPigEXztfANbI0=.60573b34-dd4a-4764-a243-005859bac43a@github.com>
 <8GdQ3xogOEjYUEYyOu1ryPXvYL9hiqxSBQ_vQmqyRE0=.ed513d11-9b3c-4256-8d59-3be410f6735c@github.com>
 <aIfWDx0KtZvFhOf8Jw_NeMtlkZ6WtWlxJKeNoIaKNxI=.450d721b-48d5-4dc3-b4b6-fa4b86d0de6c@github.com>
 <VgTYYO5SaGu-KSu5HuM8oILkBReE0isNi3GVP3HvhaU=.6ad95bbf-ac98-4983-b09a-acdbee20beab@github.com>
Message-ID: <1lhu9rBdV8kgUcXp7M366TsqQn6ZTycWd7UsgEnVopM=.b04c2c39-8482-492f-af0a-bff7a28ba428@github.com>

On Wed, 22 Jun 2022 17:57:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> A stable order is useful when comparing between builds (by a human). 
>> It also supports the goal of reproducible builds.
>> @naotoj  What do you think?
>
> IIUC, once this fix makes it to the repository, the build will be reproducible. Making it to be sorted is a welcome enhancement (I compare the generated bundles manually from time to time), but it may be costly so it could defy the performance improvement?

BTW, this can utilize the new `HashMap.newHashMap()`, although I don't think resizing would be occurring in this case.

-------------

PR: https://git.openjdk.org/jdk/pull/9243


From jwilhelm at openjdk.org  Wed Jun 22 23:25:41 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 22 Jun 2022 23:25:41 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <3-PLWroZbcfL-LaQ2_R6PTYsuJi7TzLIx15dVCOdNU8=.76b664a2-58e8-4356-bdae-e39242872744@github.com>
References: <3-PLWroZbcfL-LaQ2_R6PTYsuJi7TzLIx15dVCOdNU8=.76b664a2-58e8-4356-bdae-e39242872744@github.com>
Message-ID: <Y-N-9WAVC9A6tS4Kgxx4DHaaecrZEeC2mTF0J29hW54=.cd126033-4a8d-4c41-8f3f-a5953dc51a92@github.com>

On Wed, 22 Jun 2022 21:25:07 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 5b583e47
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5b583e4792b1d59891495a4a050fcdd4d38dfee1
Stats:     434 lines in 12 files changed: 379 ins; 22 del; 33 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/9251


From djelinski at openjdk.org  Thu Jun 23 08:53:37 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 23 Jun 2022 08:53:37 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time [v3]
In-Reply-To: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
Message-ID: <0X50hfiZvQw-sJ8MWg7cjv-NZYo888__IIODZOGei5w=.34de9317-50c9-4dd2-a60d-9fd44fbf4c68@github.com>

> This PR improves the performance of deduplication done by ResourceBundleGenerator.
> 
> The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.
> 
> The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
> The files generated before and after this change have the same size.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Sort output

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9243/files
  - new: https://git.openjdk.org/jdk/pull/9243/files/6cb47724..8d26e537

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9243&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9243&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/9243


From djelinski at openjdk.org  Thu Jun 23 08:59:41 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 23 Jun 2022 08:59:41 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time [v3]
In-Reply-To: <1lhu9rBdV8kgUcXp7M366TsqQn6ZTycWd7UsgEnVopM=.b04c2c39-8482-492f-af0a-bff7a28ba428@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <wz124fKQn2-5D4UClkQio8OWjodF7UPigEXztfANbI0=.60573b34-dd4a-4764-a243-005859bac43a@github.com>
 <8GdQ3xogOEjYUEYyOu1ryPXvYL9hiqxSBQ_vQmqyRE0=.ed513d11-9b3c-4256-8d59-3be410f6735c@github.com>
 <aIfWDx0KtZvFhOf8Jw_NeMtlkZ6WtWlxJKeNoIaKNxI=.450d721b-48d5-4dc3-b4b6-fa4b86d0de6c@github.com>
 <VgTYYO5SaGu-KSu5HuM8oILkBReE0isNi3GVP3HvhaU=.6ad95bbf-ac98-4983-b09a-acdbee20beab@github.com>
 <1lhu9rBdV8kgUcXp7M366TsqQn6ZTycWd7UsgEnVopM=.b04c2c39-8482-492f-af0a-bff7a28ba428@github.com>
Message-ID: <Q4tqgNMy885ng7J5zMyZTySXn2Vl3DXVFhAJ14svPck=.68d2eae1-2d6b-4a71-9a12-24db60253304@github.com>

On Wed, 22 Jun 2022 21:45:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> IIUC, once this fix makes it to the repository, the build will be reproducible. Making it to be sorted is a welcome enhancement (I compare the generated bundles manually from time to time), but it may be costly so it could defy the performance improvement?
>
> BTW, this can utilize the new `HashMap.newHashMap()`, although I don't think resizing would be occurring in this case.

> once this fix makes it to the repository, the build will be reproducible

Yes, we always produce the same source code. Given the same order of modifications, a hashmap will produce the same iteration order.

> LinkedHashMap could be used to retain the iteration order.

Just added. The input maps were always sorted in some order (they were either LinkedHashMaps or TreeMaps), and now we preserve that order.
This means a lot of changes in the generated output files now, but hopefully in the future the changes will be much easier to review.

TIL: `put` / `putIfAbsent` on an existing entry does not change the iteration order of a `LinkedHashMap` unless `accessOrder` is true.

-------------

PR: https://git.openjdk.org/jdk/pull/9243


From djelinski at openjdk.org  Thu Jun 23 09:04:41 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 23 Jun 2022 09:04:41 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time [v3]
In-Reply-To: <Q4tqgNMy885ng7J5zMyZTySXn2Vl3DXVFhAJ14svPck=.68d2eae1-2d6b-4a71-9a12-24db60253304@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <wz124fKQn2-5D4UClkQio8OWjodF7UPigEXztfANbI0=.60573b34-dd4a-4764-a243-005859bac43a@github.com>
 <8GdQ3xogOEjYUEYyOu1ryPXvYL9hiqxSBQ_vQmqyRE0=.ed513d11-9b3c-4256-8d59-3be410f6735c@github.com>
 <aIfWDx0KtZvFhOf8Jw_NeMtlkZ6WtWlxJKeNoIaKNxI=.450d721b-48d5-4dc3-b4b6-fa4b86d0de6c@github.com>
 <VgTYYO5SaGu-KSu5HuM8oILkBReE0isNi3GVP3HvhaU=.6ad95bbf-ac98-4983-b09a-acdbee20beab@github.com>
 <1lhu9rBdV8kgUcXp7M366TsqQn6ZTycWd7UsgEnVopM=.b04c2c39-8482-492f-af0a-bff7a28ba428@github.com>
 <Q4tqgNMy885ng7J5zMyZTySXn2Vl3DXVFhAJ14svPck=.68d2eae1-2d6b-4a71-9a12-24db60253304@github.com>
Message-ID: <Sxyc5_9-pgmZWN-TjJ5MAcplaRfbFxDE8LKw6_7-Ors=.89d59d50-909e-4022-beac-b3fd517495c0@github.com>

On Thu, 23 Jun 2022 08:56:08 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> BTW, this can utilize the new `HashMap.newHashMap()`, although I don't think resizing would be occurring in this case.
>
>> once this fix makes it to the repository, the build will be reproducible
> 
> Yes, we always produce the same source code. Given the same order of modifications, a hashmap will produce the same iteration order.
> 
>> LinkedHashMap could be used to retain the iteration order.
> 
> Just added. The input maps were always sorted in some order (they were either LinkedHashMaps or TreeMaps), and now we preserve that order.
> This means a lot of changes in the generated output files now, but hopefully in the future the changes will be much easier to review.
> 
> TIL: `put` / `putIfAbsent` on an existing entry does not change the iteration order of a `LinkedHashMap` unless `accessOrder` is true.

> BTW, this can utilize the new `HashMap.newHashMap()`, although I don't think resizing would be occurring in this case.

It may occur if there are very few duplicates. Still, the performance impact of proper sizing is minimal here.

-------------

PR: https://git.openjdk.org/jdk/pull/9243


From rriggs at openjdk.org  Thu Jun 23 14:12:45 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 23 Jun 2022 14:12:45 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time [v3]
In-Reply-To: <0X50hfiZvQw-sJ8MWg7cjv-NZYo888__IIODZOGei5w=.34de9317-50c9-4dd2-a60d-9fd44fbf4c68@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <0X50hfiZvQw-sJ8MWg7cjv-NZYo888__IIODZOGei5w=.34de9317-50c9-4dd2-a60d-9fd44fbf4c68@github.com>
Message-ID: <d3675Rh7ela5uoRkzdhFeolJTba62VmXd5YzRdHI8iU=.a7141101-6612-4def-a203-81a409f7968e@github.com>

On Thu, 23 Jun 2022 08:53:37 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This PR improves the performance of deduplication done by ResourceBundleGenerator.
>> 
>> The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.
>> 
>> The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
>> The files generated before and after this change have the same size.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sort output

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9243


From jwaters at openjdk.org  Thu Jun 23 14:23:40 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 23 Jun 2022 14:23:40 GMT
Subject: Integrated: JDK-8288740: Change incorrect documentation for sjavac
 flag
In-Reply-To: <M2swnyXWBH-9NPaYUdZ3sKj2t1mb2NXkEgw1EIbfCBw=.02751813-c843-466c-9e8c-3c210c4c9bd0@github.com>
References: <M2swnyXWBH-9NPaYUdZ3sKj2t1mb2NXkEgw1EIbfCBw=.02751813-c843-466c-9e8c-3c210c4c9bd0@github.com>
Message-ID: <S6ETIxclf6PD4w5ZWKK6UvmqLsgmGbNtgd_VxLn2-2w=.45c74428-fc9e-475e-93b5-957545f5d21a@github.com>

On Mon, 20 Jun 2022 13:01:40 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> The documentation for build performance currently points to the non-existent --enable-sjavac flag to enable sjavac, the correct one is actually --enable-javac-server (Finally seem to have gotten pandoc working, hopefully the html is correct this time)

This pull request has now been integrated.

Changeset: d579916a
Author:    Julian Waters <jwaters at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d579916a6b93577519b095e5fbf07377963dcec6
Stats:     5 lines in 2 files changed: 2 ins; 0 del; 3 mod

8288740: Change incorrect documentation for sjavac flag

Reviewed-by: ihse

-------------

PR: https://git.openjdk.org/jdk/pull/9215


From naoto at openjdk.org  Thu Jun 23 18:10:03 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 23 Jun 2022 18:10:03 GMT
Subject: RFR: 8288979: Improve CLDRConverter run time [v3]
In-Reply-To: <0X50hfiZvQw-sJ8MWg7cjv-NZYo888__IIODZOGei5w=.34de9317-50c9-4dd2-a60d-9fd44fbf4c68@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <0X50hfiZvQw-sJ8MWg7cjv-NZYo888__IIODZOGei5w=.34de9317-50c9-4dd2-a60d-9fd44fbf4c68@github.com>
Message-ID: <LMsVhWm07B08Ez1wuH5CO7PkHmmZ8U5GxYGakB4tuVA=.a3e42979-71d8-4159-acc2-229b6c173e4c@github.com>

On Thu, 23 Jun 2022 08:53:37 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This PR improves the performance of deduplication done by ResourceBundleGenerator.
>> 
>> The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.
>> 
>> The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
>> The files generated before and after this change have the same size.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sort output

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9243


From djelinski at openjdk.org  Thu Jun 23 18:49:37 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 23 Jun 2022 18:49:37 GMT
Subject: Integrated: 8288979: Improve CLDRConverter run time
In-Reply-To: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
Message-ID: <WnG_9rwqqvOULJk3UsgLKos5VRGF7GBxFMx54yxuqK8=.84b5fb49-b93e-484b-9ae7-3bddb2a5b823@github.com>

On Wed, 22 Jun 2022 14:24:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This PR improves the performance of deduplication done by ResourceBundleGenerator.
> 
> The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.
> 
> The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
> The files generated before and after this change have the same size.

This pull request has now been integrated.

Changeset: c8cc94a3
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c8cc94a38423c0cef597986fb51938a26dc20b51
Stats:     100 lines in 1 file changed: 55 ins; 27 del; 18 mod

8288979: Improve CLDRConverter run time

Reviewed-by: naoto, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/9243


From aph-open at littlepinkcloud.com  Fri Jun 24 15:59:03 2022
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Fri, 24 Jun 2022 16:59:03 +0100
Subject: assembler_x86.cpp:11128:38: error: 'this' pointer is null
In-Reply-To: <2efe9a53-1854-7b57-63e8-909b8e6057da@redhat.com>
References: <CY5P223MB049042CC6C9FBBDD7F57CEA1ABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
 <1ec8068a-8097-2519-da53-74dd4943e17f@redhat.com>
 <39d85c1d-c5ce-5e75-7b57-69af9385cb18@redhat.com>
 <CY5P223MB0490AE97668D1F228481A02EABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
 <13b3d4d3-3137-8fcf-9e00-e8908c282590@redhat.com>
 <CY5P223MB04900BF2A51873504A66F94DABAC9@CY5P223MB0490.NAMP223.PROD.OUTLOOK.COM>
 <1360de29-8066-5506-0bd8-63088a3751aa@littlepinkcloud.com>
 <33838a36-732b-4947-91eb-a76d2cd2e839@redhat.com>
 <723cb8ea-2489-2793-3a6e-d204e0b83e5d@littlepinkcloud.com>
 <2efe9a53-1854-7b57-63e8-909b8e6057da@redhat.com>
Message-ID: <26750607-a73a-4cf3-65dc-5cc8c7349047@littlepinkcloud.com>

On 6/21/22 14:12, Aleksey Shipilev wrote:
> On 6/21/22 11:07, Andrew Haley wrote:
>> On 6/20/22 09:55, Aleksey Shipilev wrote:
>>> Yes, please. I think I am seeing this now in mainline JDK with GCC 11:
>>>
>>> * For target hotspot_variant-server_libjvm_objs_sharedRuntime_x86_32.o:
>>> /home/buildbot/worker/build-jdkX-debian12/build/src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp: In
>>> static member function 'static OopMap* RegisterSaver::save_live_registers(MacroAssembler*, int,
>>> int*, bool, bool)':
>>> /home/buildbot/worker/build-jdkX-debian12/build/src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp:260:48:
>>> error: 'this' pointer is null [-Werror=nonnull]
>>
>> Please test with that warning diabled, and let me know how you get on.
> 
> linux-x86-server-release builds fine with "./configure --with-extra-cflags=-Wno-nonnull".

https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9261__;!!ACWV5N9M2RV99hQ!J3uY1fTn8pUuCuvYdSbpPraeumNlt4QSm-DGEHmReLxb7SyILvoXm-KGq53sckDMtdtXceCfn2gPgGtzMKcCVZ4XTcvG$  and https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9276__;!!ACWV5N9M2RV99hQ!J3uY1fTn8pUuCuvYdSbpPraeumNlt4QSm-DGEHmReLxb7SyILvoXm-KGq53sckDMtdtXceCfn2gPgGtzMKcCVb4r24B2$ 
should be enough.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://urldefense.com/v3/__https://www.redhat.com__;!!ACWV5N9M2RV99hQ!J3uY1fTn8pUuCuvYdSbpPraeumNlt4QSm-DGEHmReLxb7SyILvoXm-KGq53sckDMtdtXceCfn2gPgGtzMKcCVQFwtACE$ >
https://urldefense.com/v3/__https://keybase.io/andrewhaley__;!!ACWV5N9M2RV99hQ!J3uY1fTn8pUuCuvYdSbpPraeumNlt4QSm-DGEHmReLxb7SyILvoXm-KGq53sckDMtdtXceCfn2gPgGtzMKcCVZlhOfYc$ 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From duke at openjdk.org  Sun Jun 26 12:39:35 2022
From: duke at openjdk.org (Nikita Gubarkov)
Date: Sun, 26 Jun 2022 12:39:35 GMT
Subject: RFR: 8289189: Configure fails on WSL1
Message-ID: <5b5npslmm6Hmf6rRtQvHy6Q6HLwIRv0Bdf9j5PNawUc=.df61881a-1df1-4d71-bc21-8dae9d82586a@github.com>

Use temp directory for autoconf on both WSL1 and WSL2

-------------

Commit messages:
 - 8289189: Configure fails on WSL1

Changes: https://git.openjdk.org/jdk/pull/9289/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9289&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289189
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9289.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9289/head:pull/9289

PR: https://git.openjdk.org/jdk/pull/9289


From asotona at openjdk.org  Mon Jun 27 08:53:01 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Jun 2022 08:53:01 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v13]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <TYFZimuHBQWcdrZsDq3i-o6gLmjjC0Ca8R8BdDsGX3Y=.5bf9fe73-3a01-4b5c-ad3d-dc8d81093d0a@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - Merge branch 'openjdk:master' into JDK-8244681
 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module
 - Added man-page line about lossy-conversion lint
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   re-enabled warnings for java.base, java.rmi and java.smartcardio
 - Merge branch 'openjdk:master' into JDK-8244681
 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base
   new case appeared in java.base by moving jdk.incubator.foreign code under java.base
 - Merge remote-tracking branch 'upstream/master' into JDK-8244681
   
   # Conflicts:
   #	make/test/BuildMicrobenchmark.gmk
 - ... and 7 more: https://git.openjdk.org/jdk/compare/7905788e...cab6ce59

-------------

Changes: https://git.openjdk.org/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=12
  Stats: 442 lines in 17 files changed: 440 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.org/jdk/pull/8599


From asotona at openjdk.org  Mon Jun 27 09:25:58 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Jun 2022 09:25:58 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v14]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <cg1cvzaYh2RZByrgkAI6sPvZ1J0B4JAOiqVe4ib_e34=.9ec074a6-f3c0-4226-8b8c-8064fefd393b@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8599/files
  - new: https://git.openjdk.org/jdk/pull/8599/files/cab6ce59..6f32938d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=12-13

  Stats: 3 lines in 3 files changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.org/jdk/pull/8599


From ehelin at openjdk.org  Mon Jun 27 11:47:45 2022
From: ehelin at openjdk.org (Erik Helin)
Date: Mon, 27 Jun 2022 11:47:45 GMT
Subject: RFR: 8288396: Always create reproducible builds [v5]
In-Reply-To: <Rbf9agwOfJ9hcxnAuRVTAV__47bh83C8U6SmbG2yyHg=.92ff9026-6bdf-4b40-bde8-c29b985f9996@github.com>
References: <ckkR5_LGhD3Q10LqP84yyapjrO6_RVFwcHGLsMiVZno=.8359d6b6-9510-4309-8cf5-10ee85706107@github.com>
 <Rbf9agwOfJ9hcxnAuRVTAV__47bh83C8U6SmbG2yyHg=.92ff9026-6bdf-4b40-bde8-c29b985f9996@github.com>
Message-ID: <PRV05ciinhIoZo8wvDG5e-AqelsSDS-XqOeWaxchnn4=.ba49641b-ee26-4f0b-b551-93b5ad0ecb99@github.com>

On Wed, 15 Jun 2022 15:18:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> When we started introducing some possibly more intrusive compiler flags and functionality for reproducible builds, we also introduced a flag to turn this off  out of an abundance of caution. But we have been been using this configuration for a year or so internally within Oracle, with no issues. So there's really no reason to be able to turn this off. (If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one.)
>> 
>> With this fix, all randomness should be gone from our builds, at least on linux and windows. There are no more `__DATE__` and `__TIME__` macros in the source code.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove incorrect argument
>  - Test if linker can accept the flag

The HotSpot changes looks good to me.

The only problem I can think of is if some program is parsing the version string and relies on `__DATE__` having the form `Mmm dd yyyy` (as mandated by the C++ spec) and now it will have ISO 8601 format, but I don't think that issue should prevent this change. Those programs will just have to be updated ?

-------------

Marked as reviewed by ehelin (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9152


From lkorinth at openjdk.org  Mon Jun 27 14:27:36 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 27 Jun 2022 14:27:36 GMT
Subject: RFR: 8287828: Fix so that one can select jtreg test case by ID
 from make [v6]
In-Reply-To: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
References: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
Message-ID: <t9dke1oorlYhdumfDEFrkC99QJYhi7fdElyCVyHxgEA=.50ec4158-9006-49a2-a2d7-cfd0d5b5b064@github.com>

> One can select a testcase by ID when running a jtreg test case directly from jtreg (using the testcase.java#testID syntax). However, this has not been possible to do when launching jtreg indirectly from make.
> 
> This fix attempts to address this issue. I have not tested this thoroughly yet, I wanted to show the code to get feedback first. The idea is to *not* emulated destructive imperative assignments through the use of eval. I instead try to handle it in a functional style without reassigning variables. I have tried to make the change as small as possible.
> 
> I am not used to change the build system, so I would appreciate thorough review.
> 
> `IfAppend` and `IfPrepend` are general purpose functions. If similar functions exists elsewhere inside the code base or in make itself I should probably use those instead. If they do not exist, they might be useful elsewhere and maybe should be placed in a common make file instead of the RunTests.gmk file.

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  remove one unnessesary $(subst)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9028/files
  - new: https://git.openjdk.org/jdk/pull/9028/files/a6d51c2a..95d507bf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9028&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9028&range=04-05

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

PR: https://git.openjdk.org/jdk/pull/9028


From cito at openjdk.org  Tue Jun 28 06:36:18 2022
From: cito at openjdk.org (Chihiro Ito)
Date: Tue, 28 Jun 2022 06:36:18 GMT
Subject: RFR: 8288783: JFR: Error messages are confusing when options conflict
 in -XX:StartFlightRecording
Message-ID: <87hLVKwlIH1L9Bdvb_gK0kA6fu_jSBhcRxOfqodha-o=.72705b7b-2db2-41ce-b23c-5ca4b266d20b@github.com>

Could I have a review of PR that fixes incorrect error messages regarding of recording.

The current message is very confusing. If a user types jcmd <pid> JFR.start name=abc name=def or java --XX:StartFlightRecording=name=abc,name=def,  the error message says "Duplicates in diagnostic command arguments", but doesn't know what options are duplicated.
Furthermore, if a user specifies two or three duplicate parameters, the same logs will be output.

It should say follows,
Option name can only be specified once with starting flight recording
Options name and disk can only be specified once with starting flight recording
Options name, disk and maxage can only be specified once with starting flight recording
This problem affects --XX:StartFlightRecording, jcmd JFR.start, JFR.stop, JFR.dump, JFR.check, and MBean.

For other than start, the output is as follows, (example of dump)
Option name can only be specified once with dumping flight recording

Testing: jdk/jdk/jfr

Thanks
Chihiro

-------------

Commit messages:
 - modify whitespace from windows to linux
 - modify copyright
 - Modify log message and test case
 - JDK-8288783 Initial

Changes: https://git.openjdk.org/jdk/pull/9302/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9302&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288783
  Stats: 442 lines in 10 files changed: 431 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/9302.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9302/head:pull/9302

PR: https://git.openjdk.org/jdk/pull/9302


From lkorinth at openjdk.org  Tue Jun 28 08:31:44 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 28 Jun 2022 08:31:44 GMT
Subject: RFR: 8287828: Fix so that one can select jtreg test case by ID
 from make [v6]
In-Reply-To: <t9dke1oorlYhdumfDEFrkC99QJYhi7fdElyCVyHxgEA=.50ec4158-9006-49a2-a2d7-cfd0d5b5b064@github.com>
References: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
 <t9dke1oorlYhdumfDEFrkC99QJYhi7fdElyCVyHxgEA=.50ec4158-9006-49a2-a2d7-cfd0d5b5b064@github.com>
Message-ID: <T05r42OXXLaQXwtGr17Rx69OOU9h0Wv97HFKz5HAYm4=.3d93d10d-1a05-48a0-9855-fd39769b1bfe@github.com>

On Mon, 27 Jun 2022 14:27:36 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> One can select a testcase by ID when running a jtreg test case directly from jtreg (using the testcase.java#testID syntax). However, this has not been possible to do when launching jtreg indirectly from make.
>> 
>> This fix attempts to address this issue. I have not tested this thoroughly yet, I wanted to show the code to get feedback first. The idea is to *not* emulated destructive imperative assignments through the use of eval. I instead try to handle it in a functional style without reassigning variables. I have tried to make the change as small as possible.
>> 
>> I am not used to change the build system, so I would appreciate thorough review.
>> 
>> `IfAppend` and `IfPrepend` are general purpose functions. If similar functions exists elsewhere inside the code base or in make itself I should probably use those instead. If they do not exist, they might be useful elsewhere and maybe should be placed in a common make file instead of the RunTests.gmk file.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove one unnessesary $(subst)

I removed one unnecessary `$(subst)`, I think it was a leftover from an early version that striped the hash character from the id.

-------------

PR: https://git.openjdk.org/jdk/pull/9028


From ihse at openjdk.org  Tue Jun 28 09:02:44 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 28 Jun 2022 09:02:44 GMT
Subject: RFR: 8287828: Fix so that one can select jtreg test case by ID
 from make [v6]
In-Reply-To: <t9dke1oorlYhdumfDEFrkC99QJYhi7fdElyCVyHxgEA=.50ec4158-9006-49a2-a2d7-cfd0d5b5b064@github.com>
References: <yTtzG7mvq1iF5Xlyl1638smjnJ6upF0hh6S6hFyf5gk=.fc9882f3-46be-423e-ad6e-69a85588babe@github.com>
 <t9dke1oorlYhdumfDEFrkC99QJYhi7fdElyCVyHxgEA=.50ec4158-9006-49a2-a2d7-cfd0d5b5b064@github.com>
Message-ID: <9A7Mlnz1Qfw4_GIgonXKjKy2f2SntS0EbZ5YkWr-TnM=.774e1eca-f96e-49c4-8f81-6e31740e5473@github.com>

On Mon, 27 Jun 2022 14:27:36 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> One can select a testcase by ID when running a jtreg test case directly from jtreg (using the testcase.java#testID syntax). However, this has not been possible to do when launching jtreg indirectly from make.
>> 
>> This fix attempts to address this issue. I have not tested this thoroughly yet, I wanted to show the code to get feedback first. The idea is to *not* emulated destructive imperative assignments through the use of eval. I instead try to handle it in a functional style without reassigning variables. I have tried to make the change as small as possible.
>> 
>> I am not used to change the build system, so I would appreciate thorough review.
>> 
>> `IfAppend` and `IfPrepend` are general purpose functions. If similar functions exists elsewhere inside the code base or in make itself I should probably use those instead. If they do not exist, they might be useful elsewhere and maybe should be placed in a common make file instead of the RunTests.gmk file.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove one unnessesary $(subst)

Marked as reviewed by ihse (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9028


From ihse at openjdk.org  Tue Jun 28 09:04:44 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 28 Jun 2022 09:04:44 GMT
Subject: Integrated: 8288396: Always create reproducible builds
In-Reply-To: <ckkR5_LGhD3Q10LqP84yyapjrO6_RVFwcHGLsMiVZno=.8359d6b6-9510-4309-8cf5-10ee85706107@github.com>
References: <ckkR5_LGhD3Q10LqP84yyapjrO6_RVFwcHGLsMiVZno=.8359d6b6-9510-4309-8cf5-10ee85706107@github.com>
Message-ID: <kORnEbpfamlg1WWIRGJVlcmCQ-qGqCkRpEkbQP55emk=.2083d915-a726-4f45-a4b2-967f721ffe3a@github.com>

On Tue, 14 Jun 2022 09:48:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> When we started introducing some possibly more intrusive compiler flags and functionality for reproducible builds, we also introduced a flag to turn this off  out of an abundance of caution. But we have been been using this configuration for a year or so internally within Oracle, with no issues. So there's really no reason to be able to turn this off. (If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one.)
> 
> With this fix, all randomness should be gone from our builds, at least on linux and windows. There are no more `__DATE__` and `__TIME__` macros in the source code.

This pull request has now been integrated.

Changeset: b4ab5fe1
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b4ab5fe1daf22a543e1bd973bcd34322360054b4
Stats:     158 lines in 18 files changed: 14 ins; 100 del; 44 mod

8288396: Always create reproducible builds

Reviewed-by: amenkov, ehelin

-------------

PR: https://git.openjdk.org/jdk/pull/9152


From ihse at openjdk.org  Tue Jun 28 09:25:39 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 28 Jun 2022 09:25:39 GMT
Subject: RFR: 8289189: Configure fails on WSL1
In-Reply-To: <5b5npslmm6Hmf6rRtQvHy6Q6HLwIRv0Bdf9j5PNawUc=.df61881a-1df1-4d71-bc21-8dae9d82586a@github.com>
References: <5b5npslmm6Hmf6rRtQvHy6Q6HLwIRv0Bdf9j5PNawUc=.df61881a-1df1-4d71-bc21-8dae9d82586a@github.com>
Message-ID: <mpP3uRLZqKm8ENPwZ_MN9TdkyMiYVok0ldraBMlLn7w=.030c71cd-06e0-4749-84a0-7dfd158ef2a1@github.com>

On Sun, 26 Jun 2022 12:31:22 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

> Use temp directory for autoconf on both WSL1 and WSL2

I'm not sure this is correct. There is a difference between WSL1 and WSL2 in that files we generate needs to be in a Windows or WSL directory. I think it was important that the temp dir was in the WSL place for WSL1 and in a Windows location for WSL2, or if it was the other way around. I'm currently on vacation and I don't remember the full details, but this PR sounds a lot of alarm bells for me.

I'm also curious as to why the current solution do not work for you. There is no real information in the bug report on why the failure occurs or why this helps.

-------------

PR: https://git.openjdk.org/jdk/pull/9289


From alanb at openjdk.org  Tue Jun 28 14:19:13 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Jun 2022 14:19:13 GMT
Subject: RFR: 8289284: jdk.tracePinnedThreads output confusing when pinned due
 to native frame
Message-ID: <n6SWBjly4XYojVFuvl46L09-JjRRYrAMC_naGTNBWQM=.fd82fd8f-27fa-4bab-a2b7-fad2fb66ca83@github.com>

The system property jdk.tracePinnedThreads triggers a stack trace to be printed when a virtual thread parks while pinned. If a virtual thread is pinned due to a native frame there is a spurious " <== monitors:0" added to line for the native method.

A secondary issue is that there is no stack trace when there is Panama downcall as there isn't a native method in the stack trace. A future change may annotate the downcalls, for now the entire stack trace is printed (no filtering) so there is at least some output when pinned due to a call through native code

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/9308/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9308&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289284
  Stats: 114 lines in 4 files changed: 91 ins; 7 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/9308.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9308/head:pull/9308

PR: https://git.openjdk.org/jdk/pull/9308