Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v6]
On Thu, 9 Jun 2022 01:03:47 GMT, Joe Darcy 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
Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v6]
> 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=8236=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8236=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
Re: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v2]
> 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-.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-.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 >
Re: RFR: 8287828: Fix so that one can select jtreg test case by ID from make [v5]
On Tue, 7 Jun 2022 18:15:30 GMT, Leo Korinth 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
Integrated: 8287894: Use fixed timestamp as an alternative of __DATE__ macro in jdk.jdi to make Windows build reproducible
On Tue, 7 Jun 2022 19:57:48 GMT, Alexey Pavlyutkin 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 Committer: Yuri Nesterenko 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
Re: RFR: 8287894: Use fixed timestamp as an alternative of __DATE__ macro in jdk.jdi to make Windows build reproducible
On Tue, 7 Jun 2022 19:57:48 GMT, Alexey Pavlyutkin 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
Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v5]
On Thu, 2 Jun 2022 17:00:35 GMT, Joe Darcy 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
Re: RFR: 8287894: Use fixed timestamp as an alternative of __DATE__ macro in jdk.jdi to make Windows build reproducible
On Tue, 7 Jun 2022 19:57:48 GMT, Alexey Pavlyutkin 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
Re: RFR: 8287828: Fix so that one can select jtreg test case by ID from make [v5]
On Tue, 7 Jun 2022 18:15:30 GMT, Leo Korinth 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
Re: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default
On Wed, 8 Jun 2022 07:47:24 GMT, KIRIYAMA Takuya 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
Re: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default
On Wed, 8 Jun 2022 07:47:24 GMT, KIRIYAMA Takuya 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
RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default
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=9081=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
