Re: RFR: 8284772: GHA: Use GCC Major Version Dependencies Only
On Tue, 22 Aug 2023 02:14:54 GMT, Andrew John Hughes wrote: > GHA regularly breaks because we specify a very explicit GCC version, even > down to the release versioning of the Ubuntu package. In just this last > week, it has caused issues with the testing of PRs on 11u > (https://github.com/openjdk/jdk11u-dev/pull/2084) and 17u > (https://github.com/openjdk/jdk17u-dev/pull/1672) > > Rather than bumping this yet again like > [JDK-8313428](https://bugs.openjdk.org/browse/JDK-8313428), this PR suggests > dropping the specific version as we did some time ago in 8u and have now done > in 11u (https://github.com/openjdk/jdk11u-dev/pull/2087). The requirement > still specifies a specific major version of GCC. It just means the dependency > isn't broken every time Ubuntu bumps to a new minor release or even just > makes a minor change to the package alone. > > Note that the current setup does not guarantee sticking with an exact version > of GCC anyway, because - as seen by recent GHA breakage - older versions get > removed from the package repository. All we get from this exact version > requirement is sporadic breakage of testing and developer time wasted fixing > & reviewing (and, in the case of backport trees, approving). If we truly want > a static version of GCC, we need to provide our own - or maybe even a full > devkit - as we do with the JDK. Thanks for all the reviews. I'll integrate now it's been open >24 hours. - PR Comment: https://git.openjdk.org/jdk/pull/15374#issuecomment-1689224965
Integrated: 8284772: GHA: Use GCC Major Version Dependencies Only
On Tue, 22 Aug 2023 02:14:54 GMT, Andrew John Hughes wrote: > GHA regularly breaks because we specify a very explicit GCC version, even > down to the release versioning of the Ubuntu package. In just this last > week, it has caused issues with the testing of PRs on 11u > (https://github.com/openjdk/jdk11u-dev/pull/2084) and 17u > (https://github.com/openjdk/jdk17u-dev/pull/1672) > > Rather than bumping this yet again like > [JDK-8313428](https://bugs.openjdk.org/browse/JDK-8313428), this PR suggests > dropping the specific version as we did some time ago in 8u and have now done > in 11u (https://github.com/openjdk/jdk11u-dev/pull/2087). The requirement > still specifies a specific major version of GCC. It just means the dependency > isn't broken every time Ubuntu bumps to a new minor release or even just > makes a minor change to the package alone. > > Note that the current setup does not guarantee sticking with an exact version > of GCC anyway, because - as seen by recent GHA breakage - older versions get > removed from the package repository. All we get from this exact version > requirement is sporadic breakage of testing and developer time wasted fixing > & reviewing (and, in the case of backport trees, approving). If we truly want > a static version of GCC, we need to provide our own - or maybe even a full > devkit - as we do with the JDK. This pull request has now been integrated. Changeset: 7e843c22 Author:Andrew John Hughes URL: https://git.openjdk.org/jdk/commit/7e843c22e718ad17e0ea7223f10a26fb62477157 Stats: 23 lines in 3 files changed: 0 ins; 18 del; 5 mod 8284772: GHA: Use GCC Major Version Dependencies Only Reviewed-by: jwaters, shade, stuefe, erikj, serb Backport-of: 62defc3dfc4b9ba5adfe3189f34fe8b3f59b94a0 - PR: https://git.openjdk.org/jdk/pull/15374
RFR: 8314555: Build with mawk fails on Windows
Building JDK with mawk on windows fails due to regular expression. I use WSL Debian. Debian has mawk as the default awk implementation. $ awk Usage: mawk [Options] [Program] [file ...] $ make images Building target 'images' in configuration 'windows-x86_64-server-fastdebug' ... nawk: line 1: regular expression compile failed (missing operand) ??_7.*@@6B@ The meta character '?' is not escaped, so the error occurs. I added an escape sequence prefix to it. Incidentally, this doesn't happen if we use gawk instead of mawk. Gawk works fine with or without the prefix. ### Check I've built JDK with both awk and they are successful. Additionally, I checked the result of both awk executions. I saved each result to a file during the build. $(JVM_OUTPUTDIR)/symbols-objects: $(BUILD_LIBJVM_ALL_OBJS) $(call LogInfo, Generating symbol list from object files) $(CD) $(JVM_OUTPUTDIR)/objs && \ $(DUMP_SYMBOLS_CMD) | $(AWK) $(FILTER_SYMBOLS_AWK_SCRIPT) | $(SORT) -u > [FILE] The file from gawk before applying this PR, the file from mawk after applying this PR and the file from gawk after applying this PR were the same. ### Note Only the windows build uses this regular expression. I also tried to look for non-escaped meta characters in the make directory, but there were none. - Commit messages: - Update copyright - Escape the meta character Changes: https://git.openjdk.org/jdk/pull/15357/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15357&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314555 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15357/head:pull/15357 PR: https://git.openjdk.org/jdk/pull/15357
Re: RFR: 8284772: GHA: Use GCC Major Version Dependencies Only
On Tue, 22 Aug 2023 02:14:54 GMT, Andrew John Hughes wrote: > GHA regularly breaks because we specify a very explicit GCC version, even > down to the release versioning of the Ubuntu package. In just this last > week, it has caused issues with the testing of PRs on 11u > (https://github.com/openjdk/jdk11u-dev/pull/2084) and 17u > (https://github.com/openjdk/jdk17u-dev/pull/1672) > > Rather than bumping this yet again like > [JDK-8313428](https://bugs.openjdk.org/browse/JDK-8313428), this PR suggests > dropping the specific version as we did some time ago in 8u and have now done > in 11u (https://github.com/openjdk/jdk11u-dev/pull/2087). The requirement > still specifies a specific major version of GCC. It just means the dependency > isn't broken every time Ubuntu bumps to a new minor release or even just > makes a minor change to the package alone. > > Note that the current setup does not guarantee sticking with an exact version > of GCC anyway, because - as seen by recent GHA breakage - older versions get > removed from the package repository. All we get from this exact version > requirement is sporadic breakage of testing and developer time wasted fixing > & reviewing (and, in the case of backport trees, approving). If we truly want > a static version of GCC, we need to provide our own - or maybe even a full > devkit - as we do with the JDK. That is great! - Marked as reviewed by serb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15374#pullrequestreview-1590376725
Re: RFR: 8314730: GHA: Drop libfreetype6-dev transitional package in favor of libfreetype-dev
On Tue, 22 Aug 2023 13:01:03 GMT, Erik Joelsson wrote: > > I did notice that this is set for the riscv64 build in > > `make/conf/jib-profiles.js` > > This configuration only exists to verify that the build works. We don't > currently use the binaries for anything. Using "bundled" made devkit creation > and maintenance simpler. > > For GHA, I think the builds should be configured the way we expect most users > to configure them. On Linux, I think linking to a system installed freetype > is more common and desired. I agree, though I have wondered in the past if we should have a build-only run that tests out the non-default options for these (mostly `--with-x=system`, freetype is the exception). - PR Comment: https://git.openjdk.org/jdk/pull/15378#issuecomment-1688946046
Re: RFR: 8314644: Change "Rvalue references and move semantics" into an accepted feature
On Tue, 22 Aug 2023 12:16:49 GMT, Johan Sjölen wrote: > Hi, > > I'd like to propose that rvalue references and move semantics are now > considered permitted in the style guide. This change would allow for move > constructors to be written. This enables more performant code, if the move > ctr is less expensive than the copy ctr, but also more correct code. For the > latter part, look at "8314571: GrowableArray should move its old data and not > copy it". Here we can avoid using copy assignment, instead using move > constructors, which more accurately reflects what is happening: The old > elements are in fact moved, and not copied. > > Two useful std functions will become available to us with this change: > > 1. `std::move`, for explicitly moving a value. This is a slightly more > powerful `static_cast(T)`, in that it also handles `T&` corectly. > 2. `std::forward`, which simplifies the usage of perfect forwarding. Perfect > forwarding is a technique where in copying is minimized. To quote Scott > Meyers ( > https://cppandbeyond.com/2011/04/25/session-announcement-adventures-in-perfect-forwarding/ > ): > >> Perfecting forwarding is an important C++0x technique built atop rvalue >> references. It allows move semantics to be automatically applied, even when >> the source and the destination of a move are separated by intervening >> function calls. Common examples include constructors and setter functions >> that forward arguments they receive to the data members of the class they >> are initializing or setting, as well as standard library functions like >> make_shared, which “perfect-forwards” its arguments to the class constructor >> of whatever object the to-be-created shared_ptr is to point to. > > Looking forward to your feedback, thank you. > Johan After internal discussion I have come to the conclusion that this probably won't move forward, but if we have any external contributors who would like to voice their opinion I am happy to hear them. - PR Comment: https://git.openjdk.org/jdk/pull/15386#issuecomment-1688892278
Re: RFR: 8313961: Enhance identification of special serialization methods [v2]
On Mon, 21 Aug 2023 16:57:57 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/java/io/ObjectStreamClass.java line 1670:
>>
>>> 1668: ObjectStreamField[] serialPersistentFields = null;
>>> 1669: try {
>>> 1670: Field f = getDeclaredField(cl, ObjectStreamField[].class,
>>> "serialPersistentFields");
>>
>> This can technically be a breaking change, as it was supported for the field
>> to have a declared type that is assignable from `ObjectStreamField[]`, as
>> long as it held an `ObjectStreamField[]` instance at runtime, even if it
>> wasn’t officially supported.
>>
>>
>> class Example implements Serializable {
>> // This used to work before this patch in OpenJDK
>> private static final Object serialPersistentFields = new
>> ObjectStreamField[] {
>> // ...
>> };
>>
>> // ...
>> }
>
> True.
>
> On the other hand, what about a .class file that includes all of (pseudo-Java)
>
>
> private static final Object serialPersistentFields = new
> ObjectStreamField[0];
> private static final Cloneable serialPersistentFields = new
> ObjectStreamField[0];
> private static final SerializableserialPersistentFields = new
> ObjectStreamField[0];
> private static final ObjectStreamField[] serialPersistentFields = new
> SubclassOfObjectStreamField[0];
>
>
> Which one is the "preferred" field?
>
> Perhaps the Java Object Serialization Specification should simply prohibit
> multiple `serialPersistentFields`.
> This can technically be a breaking change, as it was supported for the field
> to have a declared type that is assignable from `ObjectStreamField[]`, as
> long as it held an `ObjectStreamField[]` instance at runtime, even if it
> wasn’t officially supported.
>
> ```java
> class Example implements Serializable {
> // This used to work before this patch in OpenJDK
> private static final Object serialPersistentFields = new
> ObjectStreamField[] {
> // ...
> };
>
> // ...
> }
> ```
That sort of behavior change would require a CSR; marking the PR accordingly.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15364#discussion_r1302070033
Re: RFR: 8284772: GHA: Use GCC Major Version Dependencies Only
On Tue, 22 Aug 2023 13:35:18 GMT, Volker Simonis wrote: > Maybe we could use > [devkits](https://github.com/openjdk/jdk/blob/master/doc/building.md#cross-compiling-the-easy-way-with-openjdk-devkits) > to pin the compiler version? I'm not sure how feasible that is in the GHA > context. It might have a negative performance impact? That would be preferable to me, but the main problem I see is hosting of the devkits. I can't publish such binaries. My understanding is that OpenJDK doesn't have the legal framework for hosting binaries publicly. Building them dynamically for each GHA run is definitely not feasible. - PR Comment: https://git.openjdk.org/jdk/pull/15374#issuecomment-1688613327
Re: RFR: 8284772: GHA: Use GCC Major Version Dependencies Only
On Tue, 22 Aug 2023 13:35:18 GMT, Volker Simonis wrote: > In principle I very much prefer locking down dependency versions to keep the > build as reliable as possible. Unfortunately, as we have experienced so far, > this isn't possible with GHA because the exact package versions aren't kept > available for very long. I suppose it would be possible with very diligent > watching for new versions and manually testing and updating before the old > version disappears, but that doesn't seem feasible in practice. On the other > hand, I don't think we have actually seen any problems when bumping the > versions so far, so I'm now inclined to agree with this change. Thanks Erik. For the record, I would prefer the build environment was as stable as possible as well. I just don't think the current setup is actually achieving that, because we don't have control of these packages. As I mentioned in the PR description, if we really want that to work, we likely need to build our own compiler - or maybe even a full devkit - and provide it to the build as we do with the JDK. My experience of working with these shifting build environments in Fedora & RHEL over the years is that versions within the same major version tend to be stable, and we've experienced all kinds of weird & wonderful breakage when Fedora brings in some new major version of GCC. I believe this is why Ubuntu has the versioned GCC packages like `gcc-10` and I can't recall a GCC issue on RHEL, despite the GCC team providing updated builds of the same major version. If one was to occur, then it would seem preferable to catch it early in GHA and such a failure would be useful to us. I don't think the current missing package failures we're seeing are useful and they are a particular pain in the update releases where - for good reason - it takes more work to get a change in and there is less visibility. - PR Comment: https://git.openjdk.org/jdk/pull/15374#issuecomment-1688619129
Re: RFR: 8314753: Remove support for @beaninfo, @ToDo, @since.unbundled, and @Note [v2]
On Tue, 22 Aug 2023 14:55:18 GMT, Pavel Rappo wrote: >> Please review this trivial PR. > > Pavel Rappo has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' into 8314753 > - Initial commit Thanks for reviewing it. > Looks trivial only after reviewing the issue and knowing the background. > The PR description could be a bit more complete and save a bunch of clicking > around. Fair enough. For the benefit of other reviewers, I'll copy the JBS description here and additionally note that tags in question are absent in the mainline doc comments and are also disabled during `make docs`. JBS: Those tags seem to have been effectively decommissioned, but their remnants are still there and when seen, raise needless questions. - `@beaninfo` seems to relate to UI: - [JDK-7179078](https://bugs.openjdk.org/browse/JDK-7179078) - [JDK-4763438](https://bugs.openjdk.org/browse/JDK-4763438) - [JDK-8051548](https://bugs.openjdk.org/browse/JDK-8051548) - `@ToDo` and `@since.unbundled` hasn't been used since the initial load (2007). - `@Note` seems to relate to UI: - [JDK-8285686](https://bugs.openjdk.org/browse/JDK-8285686) - [JDK-8227324](https://bugs.openjdk.org/browse/JDK-8227324) - [JDK-8222362](https://bugs.openjdk.org/browse/JDK-8222362) - PR Comment: https://git.openjdk.org/jdk/pull/15385#issuecomment-1688367797
Re: RFR: 8314753: Remove support for @beaninfo, @ToDo, @since.unbundled, and @Note [v2]
On Tue, 22 Aug 2023 14:55:18 GMT, Pavel Rappo wrote: >> Please review this trivial PR. > > Pavel Rappo has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' into 8314753 > - Initial commit Looks trivial only after reviewing the issue and knowing the background. The PR description could be a bit more complete and save a bunch of clicking around. - Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15385#pullrequestreview-1589653044
Re: RFR: 8314753: Remove support for @beaninfo, @ToDo, @since.unbundled, and @Note [v2]
> Please review this trivial PR. Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into 8314753 - Initial commit - Changes: https://git.openjdk.org/jdk/pull/15385/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15385&range=01 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15385.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15385/head:pull/15385 PR: https://git.openjdk.org/jdk/pull/15385
Re: RFR: 8314656: GHA: No need for Debian ports keyring installation after JDK-8313701 [v3]
> There is no need for keyring installation after > [JDK-8313701](https://bugs.openjdk.org/browse/JDK-8313701). We can simplify > that part to reduce the difference between different JDK releases. > > Additional testing: > - [ ] GHA Aleksey Shipilev 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 two additional commits since the last revision: - Merge branch 'master' into JDK-8314656-gha-nokeyring - Fix - Changes: - all: https://git.openjdk.org/jdk/pull/15362/files - new: https://git.openjdk.org/jdk/pull/15362/files/f364f61e..e41d8eb9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15362&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15362&range=01-02 Stats: 269 lines in 44 files changed: 94 ins; 142 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/15362.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15362/head:pull/15362 PR: https://git.openjdk.org/jdk/pull/15362
Integrated: 8314730: GHA: Drop libfreetype6-dev transitional package in favor of libfreetype-dev
On Tue, 22 Aug 2023 06:49:21 GMT, Aleksey Shipilev wrote: > Current GHA bootstraps fail for some arches with the incompatibility between > libfreetype-dev and libfreetype6-dev. Current RISC-V GHA bootstrap fails due > to this conflict. > > In both sid, bullseye, jammy, libfreetype6-dev is a transitional package, the > alias to libfreetype-dev: > https://packages.debian.org/bullseye/libfreetype6-dev > https://packages.debian.org/sid/libfreetype6-dev > https://packages.ubuntu.com/jammy/libfreetype6-dev > > There is therefore no reason to ask for libfreetype6-dev instead of > libfreetype-dev. > > Additional testing: > - [x] GHA This pull request has now been integrated. Changeset: 69d900d2 Author:Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/69d900d2ce97e5479020cff9a63c471d07e39989 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8314730: GHA: Drop libfreetype6-dev transitional package in favor of libfreetype-dev Reviewed-by: andrew, erikj - PR: https://git.openjdk.org/jdk/pull/15378
Re: RFR: 8314730: GHA: Drop libfreetype6-dev transitional package in favor of libfreetype-dev
On Tue, 22 Aug 2023 06:49:21 GMT, Aleksey Shipilev wrote: > Current GHA bootstraps fail for some arches with the incompatibility between > libfreetype-dev and libfreetype6-dev. Current RISC-V GHA bootstrap fails due > to this conflict. > > In both sid, bullseye, jammy, libfreetype6-dev is a transitional package, the > alias to libfreetype-dev: > https://packages.debian.org/bullseye/libfreetype6-dev > https://packages.debian.org/sid/libfreetype6-dev > https://packages.ubuntu.com/jammy/libfreetype6-dev > > There is therefore no reason to ask for libfreetype6-dev instead of > libfreetype-dev. > > Additional testing: > - [x] GHA Integrating to unbreak GHA. - PR Comment: https://git.openjdk.org/jdk/pull/15378#issuecomment-1688205974
Re: RFR: 8284772: GHA: Use GCC Major Version Dependencies Only
On Tue, 22 Aug 2023 13:09:21 GMT, Erik Joelsson wrote: > In principle I very much prefer locking down dependency versions to keep the > build as reliable as possible. Unfortunately, as we have experienced so far, > this isn't possible with GHA because the exact package versions aren't kept > available for very long. I suppose it would be possible with very diligent > watching for new versions and manually testing and updating before the old > version disappears, but that doesn't seem feasible in practice. On the other > hand, I don't think we have actually seen any problems when bumping the > versions so far, so I'm now inclined to agree with this change. Maybe we could use [devkits](https://github.com/openjdk/jdk/blob/master/doc/building.md#cross-compiling-the-easy-way-with-openjdk-devkits) to pin the compiler version? I'm not sure how feasible that is in the GHA context. It might have a negative performance impact? - PR Comment: https://git.openjdk.org/jdk/pull/15374#issuecomment-1688203379
Re: RFR: 8284772: GHA: Use GCC Major Version Dependencies Only
On Tue, 22 Aug 2023 02:14:54 GMT, Andrew John Hughes wrote: > GHA regularly breaks because we specify a very explicit GCC version, even > down to the release versioning of the Ubuntu package. In just this last > week, it has caused issues with the testing of PRs on 11u > (https://github.com/openjdk/jdk11u-dev/pull/2084) and 17u > (https://github.com/openjdk/jdk17u-dev/pull/1672) > > Rather than bumping this yet again like > [JDK-8313428](https://bugs.openjdk.org/browse/JDK-8313428), this PR suggests > dropping the specific version as we did some time ago in 8u and have now done > in 11u (https://github.com/openjdk/jdk11u-dev/pull/2087). The requirement > still specifies a specific major version of GCC. It just means the dependency > isn't broken every time Ubuntu bumps to a new minor release or even just > makes a minor change to the package alone. > > Note that the current setup does not guarantee sticking with an exact version > of GCC anyway, because - as seen by recent GHA breakage - older versions get > removed from the package repository. All we get from this exact version > requirement is sporadic breakage of testing and developer time wasted fixing > & reviewing (and, in the case of backport trees, approving). If we truly want > a static version of GCC, we need to provide our own - or maybe even a full > devkit - as we do with the JDK. In principle I very much prefer locking down dependency versions to keep the build as reliable as possible. Unfortunately, as we have experienced so far, this isn't possible with GHA because the exact package versions aren't kept available for very long. I suppose it would be possible with very diligent watching for new versions and manually testing and updating before the old version disappears, but that doesn't seem feasible in practice. On the other hand, I don't think we have actually seen any problems when bumping the versions so far, so I'm now inclined to agree with this change. - Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15374#pullrequestreview-1589406551
Re: RFR: 8314730: GHA: Drop libfreetype6-dev transitional package in favor of libfreetype-dev
On Tue, 22 Aug 2023 12:08:46 GMT, Andrew John Hughes wrote: > I did notice that this is set for the riscv64 build in > `make/conf/jib-profiles.js` This configuration only exists to verify that the build works. We don't currently use the binaries for anything. Using "bundled" made devkit creation and maintenance simpler. For GHA, I think the builds should be configured the way we expect most users to configure them. On Linux, I think linking to a system installed freetype is more common and desired. - PR Comment: https://git.openjdk.org/jdk/pull/15378#issuecomment-1688143834
Integrated: 8314738: Remove all occurrences of and support for @revised
On Tue, 22 Aug 2023 08:42:32 GMT, Pavel Rappo wrote: > Please review this simple PR. This pull request has now been integrated. Changeset: f39fc0aa Author:Pavel Rappo URL: https://git.openjdk.org/jdk/commit/f39fc0aa2de19332fa51af605ece0660891d8c7a Stats: 124 lines in 28 files changed: 0 ins; 116 del; 8 mod 8314738: Remove all occurrences of and support for @revised Reviewed-by: mr - PR: https://git.openjdk.org/jdk/pull/15382
Re: RFR: 8314730: GHA: Drop libfreetype6-dev transitional package in favor of libfreetype-dev
On Tue, 22 Aug 2023 06:49:21 GMT, Aleksey Shipilev wrote: > Current GHA bootstraps fail for some arches with the incompatibility between > libfreetype-dev and libfreetype6-dev. Current RISC-V GHA bootstrap fails due > to this conflict. > > In both sid and bullseye, libfreetype6-dev is a transitional package, the > alias to libfreetype-dev: > https://packages.debian.org/bullseye/libfreetype6-dev > https://packages.debian.org/sid/libfreetype6-dev > > There is therefore no reason to ask for libfreetype6-dev instead of > libfreetype-dev. > > Additional testing: > - [x] GHA Marked as reviewed by erikj (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/15378#pullrequestreview-1589379141
Re: RFR: 8314738: Remove all occurrences of and support for @revised
On Tue, 22 Aug 2023 08:42:32 GMT, Pavel Rappo wrote: > Please review this simple PR. You can leave the copyright years as-is. - PR Comment: https://git.openjdk.org/jdk/pull/15382#issuecomment-1688104170
Re: RFR: 8314738: Remove all occurrences of and support for @revised
On Tue, 22 Aug 2023 08:42:32 GMT, Pavel Rappo wrote: > Please review this simple PR. Removing `@revised` tags is not a substantive change, so I wouldn’t update the copyright year as you have in some of these files. Otherwise, this looks fine. - Marked as reviewed by mr (Lead). PR Review: https://git.openjdk.org/jdk/pull/15382#pullrequestreview-1589309922
Re: RFR: 8314738: Remove all occurrences of and support for @revised
On Tue, 22 Aug 2023 12:23:18 GMT, Mark Reinhold wrote: > I wouldn’t update the copyright year as you have in some of these files. I was taught to do it every time when I change a file. Would you like me to revert those changes to copyright years in this case? - PR Comment: https://git.openjdk.org/jdk/pull/15382#issuecomment-1688086627
RFR: 8314762: Make {@Incubating} conventional
Please review this trivial PR. - Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/15387/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15387&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314762 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/15387.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15387/head:pull/15387 PR: https://git.openjdk.org/jdk/pull/15387
RFR: 8314644: Change "Rvalue references and move semantics" into an accepted feature
Hi, I'd like to propose that rvalue references and move semantics are now considered permitted in the style guide. This change would allow for move constructors to be written. This enables more performant code, if the move ctr is less expensive than the copy ctr, but also more correct code. For the latter part, look at "8314571: GrowableArray should move its old data and not copy it". Here we can avoid using copy assignment, instead using move constructors, which more accurately reflects what is happening: The old elements are in fact moved, and not copied. Two useful std functions will become available to us with this change: 1. `std::move`, for explicitly moving a value. This is a slightly more powerful `static_cast(T)`, in that it also handles `T&` corectly. 2. `std::forward`, which simplifies the usage of perfect forwarding. Perfect forwarding is a technique where in copying is minimized. To quote Scott Meyers ( https://cppandbeyond.com/2011/04/25/session-announcement-adventures-in-perfect-forwarding/ ): > Perfecting forwarding is an important C++0x technique built atop rvalue > references. It allows move semantics to be automatically applied, even when > the source and the destination of a move are separated by intervening > function calls. Common examples include constructors and setter functions > that forward arguments they receive to the data members of the class they are > initializing or setting, as well as standard library functions like > make_shared, which “perfect-forwards” its arguments to the class constructor > of whatever object the to-be-created shared_ptr is to point to. Looking forward to your feedback, thank you. Johan - Commit messages: - Also update html - Move over Rvalue references and move semantics to permitted features Changes: https://git.openjdk.org/jdk/pull/15386/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15386&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314644 Stats: 8 lines in 2 files changed: 5 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15386.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15386/head:pull/15386 PR: https://git.openjdk.org/jdk/pull/15386
Re: RFR: 8284772: GHA: Use GCC Major Version Dependencies Only
On Tue, 22 Aug 2023 07:30:15 GMT, Aleksey Shipilev wrote: > This looks okay. > Thanks. > That said, it is rather unnatural to forward-port the patches. Next time, I > would like to see a clean mainline RFE, which would then be cleanly > backported to each of the JDK updates trees. Agreed. I think we must have been in a rush to unbreak GHA in 8u originally and expected more pushback from trunk. No excuse though really. - PR Comment: https://git.openjdk.org/jdk/pull/15374#issuecomment-1688064677
Re: RFR: 8314730: GHA: Drop libfreetype6-dev transitional package in favor of libfreetype-dev
On Tue, 22 Aug 2023 06:49:21 GMT, Aleksey Shipilev wrote: > Current GHA bootstraps fail for some arches with the incompatibility between > libfreetype-dev and libfreetype6-dev. libfreetype6-dev. Current RISC-V GHA > bootstrap fails due to this conflict. > > In both sid and bullseye and sid, libfreetype6-dev is a transitional package: > https://packages.debian.org/bullseye/libfreetype6-dev > https://packages.debian.org/sid/libfreetype6-dev > > There is therefore no reason to ask for libfreetype6-dev instead of > libfreetype-dev. > > Additional testing: > - [ ] GHA Fix for the issue looks good and tests pass. As to removing FreeType as a dependency altogether, I think you'd need to pass `--with-freetype=bundled` to the `configure` in `build-cross-compile.yml` as well. By default, it is set to `system` on Linux. >From `make/autoconf/lib-freetype.m4`: ~~~ FREETYPE_TO_USE=bundled if test "x$OPENJDK_TARGET_OS" != "xwindows" && \ test "x$OPENJDK_TARGET_OS" != "xmacosx" && \ test "x$OPENJDK_TARGET_OS" != "xaix"; then FREETYPE_TO_USE=system fi ~~~ I did notice that this is set for the riscv64 build in `make/conf/jib-profiles.js` - Marked as reviewed by andrew (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15378#pullrequestreview-1589283336
Re: RFR: 8284772: GHA: Use GCC Major Version Dependencies Only
Aleksey Shipilev schrieb am Di., 22. Aug. 2023, 09:33: > On Tue, 22 Aug 2023 02:14:54 GMT, Andrew John Hughes > wrote: > > > GHA regularly breaks because we specify a very explicit GCC version, > even down to the release versioning of the Ubuntu package. In just this > last week, it has caused issues with the testing of PRs on 11u ( > https://github.com/openjdk/jdk11u-dev/pull/2084) and 17u ( > https://github.com/openjdk/jdk17u-dev/pull/1672) > > > > Rather than bumping this yet again like [JDK-8313428]( > https://bugs.openjdk.org/browse/JDK-8313428), this PR suggests dropping > the specific version as we did some time ago in 8u and have now done in 11u > (https://github.com/openjdk/jdk11u-dev/pull/2087). The requirement still > specifies a specific major version of GCC. It just means the dependency > isn't broken every time Ubuntu bumps to a new minor release or even just > makes a minor change to the package alone. > > > > Note that the current setup does not guarantee sticking with an exact > version of GCC anyway, because - as seen by recent GHA breakage - older > versions get removed from the package repository. All we get from this > exact version requirement is sporadic breakage of testing and developer > time wasted fixing & reviewing (and, in the case of backport trees, > approving). If we truly want a static version of GCC, we need to provide > our own - or maybe even a full devkit - as we do with the JDK. > > This looks okay. > > That said, it is rather unnatural to forward-port the patches. Next time, > I would like to see a clean mainline RFE, which would then be cleanly > backported to each of the JDK updates trees. > I think this is kind of an exceptional case because we were in a hurry to fix the 11u-dev GHA in order to push the fix for the ZIP64 issue introduced by the last security update. > - > > Marked as reviewed by shade (Reviewer). > > PR Review: > https://git.openjdk.org/jdk/pull/15374#pullrequestreview-1588655871 >
Re: RFR: 8314753: Remove support for @beaninfo, @ToDo, @since.unbundled, and @Note
On Tue, 22 Aug 2023 11:09:39 GMT, Pavel Rappo wrote: > Please review this trivial PR. CC'ing client-libs-dev because @beaninfo and @Note and jmx-dev because of @since.unbundled, which might've been used for JMX before 2007. - PR Comment: https://git.openjdk.org/jdk/pull/15385#issuecomment-1688004264
Re: RFR: 8314753: Remove support for @beaninfo, @ToDo, @since.unbundled, and @Note
On Tue, 22 Aug 2023 11:09:39 GMT, Pavel Rappo wrote: > Please review this trivial PR. CC'ing core-libs-dev whose members might also have some recollection on tags in question. - PR Comment: https://git.openjdk.org/jdk/pull/15385#issuecomment-1687995105
Re: RFR: 8314753: Remove support for @beaninfo, @ToDo, @since.unbundled, and @Note
On Tue, 22 Aug 2023 11:09:39 GMT, Pavel Rappo wrote: > Please review this trivial PR. CC'ing client-libs-dev because `@beaninfo` and `@Note` and jmx-dev because of `@since.unbundled`, which might've been used for JMX before 2007. - PR Comment: https://git.openjdk.org/jdk/pull/15385#issuecomment-1687990983
RFR: 8314753: Remove support for @beaninfo, @ToDo, @since.unbundled, and @Note
Please review this trivial PR. - Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/15385/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15385&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314753 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15385.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15385/head:pull/15385 PR: https://git.openjdk.org/jdk/pull/15385
RFR: 8314730: GHA: Drop libfreetype6-dev transitional package in favor of libfreetype-dev
Current GHA bootstraps fail for some arches with the incompatibility between libfreetype-dev and libfreetype6-dev. libfreetype6-dev. Current RISC-V GHA bootstrap fails due to this conflict. In both sid and bullseye and sid, libfreetype6-dev is a transitional package: https://packages.debian.org/bullseye/libfreetype6-dev https://packages.debian.org/sid/libfreetype6-dev There is therefore no reason to ask for libfreetype6-dev instead of libfreetype-dev. Additional testing: - [ ] GHA - Commit messages: - Actually, cannot build without freetype: cross-compiled builds look into sysroots for it - Drop freetype completely, as we ship one in JDK - Fix Changes: https://git.openjdk.org/jdk/pull/15378/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15378&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314730 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15378.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15378/head:pull/15378 PR: https://git.openjdk.org/jdk/pull/15378
Re: RFR: 8284772: GHA: Use GCC Major Version Dependencies Only
On Tue, 22 Aug 2023 08:47:32 GMT, Thomas Stuefe wrote: > Looks good. > > Anyone knows whats up with riscv64, though? It worked on my GHA run from this > morning > https://github.com/openjdk/jdk/pull/15041/checks?check_run_id=16096790652 It's #15378, manifests in official Debian repository. - PR Comment: https://git.openjdk.org/jdk/pull/15374#issuecomment-1687947641
Re: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4]
On Wed, 28 Jun 2023 18:53:12 GMT, Tim Prinzing wrote: >> The socket read/write JFR events currently use instrumentation of java.base >> code using templates in the jdk.jfr modules. This results in some java.base >> code residing in the jdk.jfr module which is undesirable. >> >> JDK19 added static support for event classes. The old instrumentor classes >> should be replaced with mirror events using the static support. >> >> In the java.base module: >> Added two new events, jdk.internal.event.SocketReadEvent and >> jdk.internal.event.SocketWriteEvent. >> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of >> the new events. >> >> In the jdk.jfr module: >> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were >> changed to be mirror events. >> In the package jdk.jfr.internal.instrument, the classes >> SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and >> SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated >> to reflect all of those changes. >> >> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the >> new implementation: >> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java >> Passed: jdk/jfr/event/io/TestSocketEvents.java >> >> I added a micro benchmark which measures the overhead of handling the jfr >> socket events. >> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. >> It needs access the jdk.internal.event package, which is done at runtime >> with annotations that add the extra arguments. >> At compile time the build arguments had to be augmented in >> make/test/BuildMicrobenchmark.gmk > > Tim Prinzing has updated the pull request incrementally with one additional > commit since the last revision: > > less exception filtering when fetching socket read timeout One other thing is that the comments in Socket.SocketInputStream and Socket.SocketOutputStream where it has "This class is instrumented by Java Flight Recorder (JFR) to get socket I/O events" can be removed now. - PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1687765868
Re: RFR: 8284772: GHA: Use GCC Major Version Dependencies Only
On Tue, 22 Aug 2023 02:14:54 GMT, Andrew John Hughes wrote: > GHA regularly breaks because we specify a very explicit GCC version, even > down to the release versioning of the Ubuntu package. In just this last > week, it has caused issues with the testing of PRs on 11u > (https://github.com/openjdk/jdk11u-dev/pull/2084) and 17u > (https://github.com/openjdk/jdk17u-dev/pull/1672) > > Rather than bumping this yet again like > [JDK-8313428](https://bugs.openjdk.org/browse/JDK-8313428), this PR suggests > dropping the specific version as we did some time ago in 8u and have now done > in 11u (https://github.com/openjdk/jdk11u-dev/pull/2087). The requirement > still specifies a specific major version of GCC. It just means the dependency > isn't broken every time Ubuntu bumps to a new minor release or even just > makes a minor change to the package alone. > > Note that the current setup does not guarantee sticking with an exact version > of GCC anyway, because - as seen by recent GHA breakage - older versions get > removed from the package repository. All we get from this exact version > requirement is sporadic breakage of testing and developer time wasted fixing > & reviewing (and, in the case of backport trees, approving). If we truly want > a static version of GCC, we need to provide our own - or maybe even a full > devkit - as we do with the JDK. Looks good. Anyone knows whats up with riscv64, though? It worked on my GHA run from this morning https://github.com/openjdk/jdk/pull/15041/checks?check_run_id=16096790652 - Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15374#pullrequestreview-1588851136
RFR: 8314738: Remove all occurrences of and support for @revised
Please review this simple PR. - Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/15382/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15382&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314738 Stats: 124 lines in 28 files changed: 0 ins; 116 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/15382.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15382/head:pull/15382 PR: https://git.openjdk.org/jdk/pull/15382
Re: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4]
On Wed, 28 Jun 2023 18:53:12 GMT, Tim Prinzing wrote: >> The socket read/write JFR events currently use instrumentation of java.base >> code using templates in the jdk.jfr modules. This results in some java.base >> code residing in the jdk.jfr module which is undesirable. >> >> JDK19 added static support for event classes. The old instrumentor classes >> should be replaced with mirror events using the static support. >> >> In the java.base module: >> Added two new events, jdk.internal.event.SocketReadEvent and >> jdk.internal.event.SocketWriteEvent. >> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of >> the new events. >> >> In the jdk.jfr module: >> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were >> changed to be mirror events. >> In the package jdk.jfr.internal.instrument, the classes >> SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and >> SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated >> to reflect all of those changes. >> >> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the >> new implementation: >> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java >> Passed: jdk/jfr/event/io/TestSocketEvents.java >> >> I added a micro benchmark which measures the overhead of handling the jfr >> socket events. >> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. >> It needs access the jdk.internal.event package, which is done at runtime >> with annotations that add the extra arguments. >> At compile time the build arguments had to be augmented in >> make/test/BuildMicrobenchmark.gmk > > Tim Prinzing has updated the pull request incrementally with one additional > commit since the last revision: > > less exception filtering when fetching socket read timeout The stack trace will start in the incorrect method, i.e checkForCommit, when a utility method is used. This is probably something we will have to fix anyway. I filed an issue for that: https://bugs.openjdk.org/browse/JDK-8314745 - PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1687749717
Re: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4]
On Tue, 27 Jun 2023 18:29:45 GMT, Tim Prinzing wrote:
>> src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 408:
>>
>>> 406: @Override
>>> 407: public int read(ByteBuffer buf) throws IOException {
>>> 408: if (!SocketReadEvent.enabled()) {
>>
>> The read/write with sun.nio.ch.SocketInputStream and SocketOutputStream does
>> not go through SC.read/write so I think SocketAdaptor read/write will need
>> attention, maybe a future PR as there are other code paths that aren't
>> covered in this PR.
>
> I've created https://bugs.openjdk.org/browse/JDK-8310978 to drive the future
> PR to support the missing code paths
Thanks, it's a reminder that the existing SocketXXX events are incomplete
and/or not much I/O done with the socket adaptors.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1301143720
Re: RFR: 8308995: Update Network IO JFR events to be static mirror events [v3]
On Wed, 28 Jun 2023 06:09:14 GMT, Alan Bateman wrote:
>> Tim Prinzing has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains ten commits:
>>
>> - remove unused SOCKET_READ and SOCKET_WRITE configurations.
>> - Merge branch 'master' into JDK-8308995
>>
>># Conflicts:
>># src/jdk.jfr/share/classes/jdk/jfr/events/EventConfigurations.java
>> - Avoid exceptions getting address/timeout for jfr event. Remove unused
>>EventConiguration fields SOCKET_READ and SOCKET_WRITE. Remove spurious
>>whitespace.
>> - some changes from review.
>>
>>read0() to implRead()
>>write0() to implWrite()
>>trailing whitespace
>> - fix copyright date
>> - Added micro benchmark to measure socket event overhead.
>> - Some changes from review.
>>
>>Append a 0 to method names being wrapped. Use getHostString to avoid
>>a reverse lookup when fetching the hostname of the remote address.
>> - remove unnecessary cast
>> - 8308995: Update Network IO JFR events to be static mirror events
>
> src/java.base/share/classes/java/net/Socket.java line 1133:
>
>> 1131: return parent.getSoTimeout();
>> 1132: } catch (Throwable t) {
>> 1133: // ignored - avoiding exceptions in jfr event data
>> gathering
>
> This should be SocketException, not Throwable. That said, I think it would be
> useful to know why the SocketReadEvent includes the timeout. Is this used to
> see If read durations are close to the timeout? I assume once this code is
> fixed to deal with the exceptional case that the need to include the timeout
> for the success case will mostly go away.
Were you able to find out what the timeout is used for?
-
PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1301136108
Re: RFR: 8308995: Update Network IO JFR events to be static mirror events
On Thu, 22 Jun 2023 13:39:51 GMT, Erik Gahlin wrote: > An exception event will be emitted. The event is disabled by default, but > there is ongoing work on a throttling mechanism, so it can be always-on. Good, I think the exception cases are probably the most interesting for this area when it comes to troubleshooting. - PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1687636801
Re: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4]
On Wed, 28 Jun 2023 18:53:12 GMT, Tim Prinzing wrote:
>> The socket read/write JFR events currently use instrumentation of java.base
>> code using templates in the jdk.jfr modules. This results in some java.base
>> code residing in the jdk.jfr module which is undesirable.
>>
>> JDK19 added static support for event classes. The old instrumentor classes
>> should be replaced with mirror events using the static support.
>>
>> In the java.base module:
>> Added two new events, jdk.internal.event.SocketReadEvent and
>> jdk.internal.event.SocketWriteEvent.
>> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of
>> the new events.
>>
>> In the jdk.jfr module:
>> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were
>> changed to be mirror events.
>> In the package jdk.jfr.internal.instrument, the classes
>> SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and
>> SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated
>> to reflect all of those changes.
>>
>> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the
>> new implementation:
>> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
>> Passed: jdk/jfr/event/io/TestSocketEvents.java
>>
>> I added a micro benchmark which measures the overhead of handling the jfr
>> socket events.
>> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
>> It needs access the jdk.internal.event package, which is done at runtime
>> with annotations that add the extra arguments.
>> At compile time the build arguments had to be augmented in
>> make/test/BuildMicrobenchmark.gmk
>
> Tim Prinzing has updated the pull request incrementally with one additional
> commit since the last revision:
>
> less exception filtering when fetching socket read timeout
Overall, it's good to move away from the "faraway instrumentation". Looks
forward to the next steps to get to a more complete solution.
src/java.base/share/classes/java/net/Socket.java line 44:
> 42: import java.util.Collections;
> 43:
> 44:
Minor nit, I assume this additional blank line is left over from a previous
iteration.
src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 465:
> 463: public long read(ByteBuffer[] dsts, int offset, int length)
> 464: throws IOException
> 465: {
The supporting methods for read (beginRead, endRead, throwConnectionReset, ...)
are declared before the read methods. It's probably best to put the implRead
before the read too so that all the supporting methods are together. Same thing
with the write methods.
-
Marked as reviewed by alanb (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/14342#pullrequestreview-1588627786
PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1301134829
PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1301144638
Re: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4]
On Wed, 2 Aug 2023 20:09:39 GMT, Alan Bateman wrote: > https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling > https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event > generation https://bugs.openjdk.org/browse/JDK-8310994 - non-blocking, event > for select ops Do you have a sense yet on events when the channel is configured non-blocking? I realise the threshold is 20ms so they are probably not recorded today but I wonder if these code paths will eventually include `|| !blocking` or if it useful to record data on all socket read/write ops. - PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1687630491
Re: RFR: 8284772: GHA: Use GCC Major Version Dependencies Only
On Tue, 22 Aug 2023 02:14:54 GMT, Andrew John Hughes wrote: > GHA regularly breaks because we specify a very explicit GCC version, even > down to the release versioning of the Ubuntu package. In just this last > week, it has caused issues with the testing of PRs on 11u > (https://github.com/openjdk/jdk11u-dev/pull/2084) and 17u > (https://github.com/openjdk/jdk17u-dev/pull/1672) > > Rather than bumping this yet again like > [JDK-8313428](https://bugs.openjdk.org/browse/JDK-8313428), this PR suggests > dropping the specific version as we did some time ago in 8u and have now done > in 11u (https://github.com/openjdk/jdk11u-dev/pull/2087). The requirement > still specifies a specific major version of GCC. It just means the dependency > isn't broken every time Ubuntu bumps to a new minor release or even just > makes a minor change to the package alone. > > Note that the current setup does not guarantee sticking with an exact version > of GCC anyway, because - as seen by recent GHA breakage - older versions get > removed from the package repository. All we get from this exact version > requirement is sporadic breakage of testing and developer time wasted fixing > & reviewing (and, in the case of backport trees, approving). If we truly want > a static version of GCC, we need to provide our own - or maybe even a full > devkit - as we do with the JDK. This looks okay. That said, it is rather unnatural to forward-port the patches. Next time, I would like to see a clean mainline RFE, which would then be cleanly backported to each of the JDK updates trees. - Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15374#pullrequestreview-1588655871
