Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]
On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > Joe Darcy has updated the pull request incrementally with one additional > commit since the last revision: > > Respond to review feedback. 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 [v2]
On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > Joe Darcy has updated the pull request incrementally with one additional > commit since the last revision: > > Respond to review feedback. Marked as reviewed by kcr (Author). - PR: https://git.openjdk.java.net/jdk/pull/8236
Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]
On Thu, 26 May 2022 22:38:12 GMT, David Holmes wrote: >> Joe Darcy has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Respond to review feedback. > > src/java.base/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java line > 312: > >> 310: int V18 = 0 << 16 | 62; >> 311: int V19 = 0 << 16 | 63; >> 312: int V20 = 0 << 17 | 64; > > 17 ?? > > Though why do we even bother with this when the minor version is zero? Simple > assignment works. Doh! Will fix in the next pushed. - PR: https://git.openjdk.java.net/jdk/pull/8236
Re: RFR: JDK-8284858: Start of release updates for JDK 20
On Thu, 26 May 2022 22:40:59 GMT, Kevin Rushforth wrote: > You also need to change the JBS version from 19 to 20 in > [`.jcheck/conf`](https://github.com/openjdk/jdk/blob/6a33974a6b8a629744c6d76c3b4fa1f772e52ac8/.jcheck/conf#L4): Acknowledged; will fix in the next push. Thanks. - PR: https://git.openjdk.java.net/jdk/pull/8236
Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]
> Time to start getting ready for JDK 20... Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. - Changes: - all: https://git.openjdk.java.net/jdk/pull/8236/files - new: https://git.openjdk.java.net/jdk/pull/8236/files/49c871d9..96be1787 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8236=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8236=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 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: JDK-8284858: Start of release updates for JDK 20
On Thu, 14 Apr 2022 05:09:14 GMT, Joe Darcy wrote: > Time to start getting ready for JDK 20... You also need to change the JBS version from 19 to 20 in [`.jcheck/conf`](https://github.com/openjdk/jdk/blob/6a33974a6b8a629744c6d76c3b4fa1f772e52ac8/.jcheck/conf#L4): - PR: https://git.openjdk.java.net/jdk/pull/8236
Re: RFR: JDK-8284858: Start of release updates for JDK 20
On Thu, 14 Apr 2022 05:09:14 GMT, Joe Darcy wrote: > Time to start getting ready for JDK 20... One comment below. I ignored the sym files. Everything else appears okay. Thanks. src/java.base/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java line 312: > 310: int V18 = 0 << 16 | 62; > 311: int V19 = 0 << 16 | 63; > 312: int V20 = 0 << 17 | 64; 17 ?? Though why do we even bother with this when the minor version is zero? Simple assignment works. - Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8236
RFR: JDK-8284858: Start of release updates for JDK 20
Time to start getting ready for JDK 20... - Commit messages: - 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. - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - ... and 23 more: https://git.openjdk.java.net/jdk/compare/295be6f1...49c871d9 Changes: https://git.openjdk.java.net/jdk/pull/8236/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8236=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284858 Stats: 6210 lines in 67 files changed: 6166 ins; 0 del; 44 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: JDK-8284858: Start of release updates for JDK 20
On Thu, 14 Apr 2022 05:09:14 GMT, Joe Darcy wrote: > Time to start getting ready for JDK 20... The expected kinds of updates to start up JDK 20. - PR: https://git.openjdk.java.net/jdk/pull/8236
Re: RFR: 8286562: GCC 12 reports some compiler warnings [v10]
On Thu, 26 May 2022 10:55:28 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 >> on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should >> separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * >> src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned >> char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at >> /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at >> /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* >> BytecodeConstantPool::create_constant_pool(JavaThread*) const' at >> /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one > additional commit since the last revision: > > Fix comments Marked as reviewed by kbarrett (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8646
RFR: 8287378: GHA: Update cygwin to fix issues in langtools tests on Windows
This fixes the Windows GHA test failures that popped up short time ago, e.g. [these](https://github.com/RealCLanger/jdk/runs/6598399845) Failing tests: tools/javac/Paths/MineField.sh tools/javac/Paths/wcMineField.sh I've debugged it and it comes down to calls to javac/java in the test through env are failing with RC 127. E.g. here: https://github.com/openjdk/jdk/blob/e44465d4d6eaddebfc5a1b149223aa8332affa8b/test/langtools/tools/javac/Paths/MineField.sh#L218 Don't know why but I figured that the test failure goes away with current cygwin. It should be ok to update cygwin now because the bug that made JDK-8276854 necessary seems to be fixed. - Commit messages: - JDK-8287378 Changes: https://git.openjdk.java.net/jdk/pull/8903/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8903=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287378 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8903.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8903/head:pull/8903 PR: https://git.openjdk.java.net/jdk/pull/8903
Integrated: 8287336: GHA: Workflows break on patch versions
On Wed, 25 May 2022 17:17:12 GMT, Christoph Langer wrote: > This fixes the issue on GHA when the branch contains a patch version. > > Here you can see the problem: > https://github.com/openjdk-bots/jdk18u/actions/runs/2385040187 > And here you see how it looks if it's fixed: > https://github.com/RealCLanger/jdk18u/actions/runs/2384983103 > > I plan to backport this fix to 18u, where the problem currently occurs, > immediately. This pull request has now been integrated. Changeset: e44465d4 Author:Christoph Langer URL: https://git.openjdk.java.net/jdk/commit/e44465d4d6eaddebfc5a1b149223aa8332affa8b Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod 8287336: GHA: Workflows break on patch versions Reviewed-by: shade - PR: https://git.openjdk.java.net/jdk/pull/
Re: RFR: 8287336: GHA: Workflows break on patch versions
On Wed, 25 May 2022 17:50:29 GMT, Aleksey Shipilev wrote: >> This fixes the issue on GHA when the branch contains a patch version. >> >> Here you can see the problem: >> https://github.com/openjdk-bots/jdk18u/actions/runs/2385040187 >> And here you see how it looks if it's fixed: >> https://github.com/RealCLanger/jdk18u/actions/runs/2384983103 >> >> I plan to backport this fix to 18u, where the problem currently occurs, >> immediately. > > Ah yes. Looks good! Thanks @shipilev for the review. - PR: https://git.openjdk.java.net/jdk/pull/
Integrated: 8287187: Utilize HashMap.newHashMap() in CLDRConverter
On Wed, 25 May 2022 16:43:59 GMT, Naoto Sato wrote: > Refactoring the leftover self-calculations of the optimized `HashMap` initial > value with `newHashMap()` method. Also replaced some string literals using > text blocks for better readability. Confirmed that the output resource bundle > sources are effectively (sans indentation) the same as the original ones. This pull request has now been integrated. Changeset: c10749a6 Author:Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/c10749a6a70977fbd6cd33b298410d212276fcf1 Stats: 65 lines in 1 file changed: 8 ins; 1 del; 56 mod 8287187: Utilize HashMap.newHashMap() in CLDRConverter Reviewed-by: joehw - PR: https://git.openjdk.java.net/jdk/pull/8887
RFR: 8287366: Improve test failure reporting in GHA
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. - Commit messages: - Extra commit to re-trigger the GHA - 8287366: Improve test failure reporting in GHA Changes: https://git.openjdk.java.net/jdk/pull/8901/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8901=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287366 Stats: 285 lines in 1 file changed: 264 ins; 0 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/8901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8901/head:pull/8901 PR: https://git.openjdk.java.net/jdk/pull/8901
Re: RFR: 8286562: GCC 12 reports some compiler warnings [v10]
> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on > Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should > separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * > src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned > char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at > /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at > /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* > BytecodeConstantPool::create_constant_pool(JavaThread*) const' at > /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Fix comments - Changes: - all: https://git.openjdk.java.net/jdk/pull/8646/files - new: https://git.openjdk.java.net/jdk/pull/8646/files/17cda224..851279ae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8646=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8646=08-09 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646
Re: RFR: 8286562: GCC 12 reports some compiler warnings [v9]
On Thu, 26 May 2022 03:48:31 GMT, Kim Barrett wrote:
>> Yasumasa Suenaga has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Change Array::data() implementation
>> - Avoid stringop-overflow warning in jfrTraceIdBits.inline.hpp
>
> src/java.base/unix/native/libjli/java_md_common.c line 133:
>
>> 131:
>> 132: snprintf_result = JLI_Snprintf(name, sizeof(name), "%s%c%s", indir,
>> FILE_SEPARATOR, cmd);
>> 133: if ((snprintf_result < 0) && (snprintf_result >=
>> (int)sizeof(name))) {
>
> That should be `||` rather than `&&`.
Good catch! I fixed it in new commit.
> src/java.base/unix/native/libjli/java_md_common.c line 135:
>
>> 133: if ((snprintf_result < 0) && (snprintf_result >=
>> (int)sizeof(name))) {
>> 134: return 0;
>> 135: }
>
> Pre-existing: It seems odd that this returns `0` above and below, rather than
> returning `NULL`. I think there are one or two other places in this file
> that are similarly using literal `0` for a null pointer, though others are
> using `NULL`. Something to report and clean up separately from this change.
I was wondering about that too.
I use `NULL` at L134, and have filed it as
[JDK-8287363](https://bugs.openjdk.java.net/browse/JDK-8287363). I will work
for it after this issue.
-
PR: https://git.openjdk.java.net/jdk/pull/8646
