From weijun at openjdk.org  Sat Oct  1 15:02:04 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 1 Oct 2022 15:02:04 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <RAPey5BSjlbfy8WMa3N39QofovAuJ1wnJdx9xm-lvJw=.12e7b645-4668-4810-a24f-4c6fc20cd9ed@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
 <eM7WMgB7uVvIw-lqL8AzCf6zG-Xz6UUQQPibY5hRn6A=.80c398cb-9d26-4b94-b73c-50c85e438730@github.com>
 <RAPey5BSjlbfy8WMa3N39QofovAuJ1wnJdx9xm-lvJw=.12e7b645-4668-4810-a24f-4c6fc20cd9ed@github.com>
Message-ID: <azol0p7osOA4BoEFm_2HZT1U9GmKrrF4_vMq3o35hVE=.7e936b3f-a0fa-41e8-bf82-66f977688fd8@github.com>

On Fri, 30 Sep 2022 17:38:54 GMT, Phil Race <prr at openjdk.org> wrote:

>> Why do we need to link to a URL? Why not `../../bridge/AccessBridgeCalls.c`?
>
> This is correct.
> AccessBridge.h is published with the include/header files of the JDK and anyone reading it there can't exactly make use of "../"

Thanks @prrace. And yes, git link is better.

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

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


From darcy at openjdk.org  Sun Oct  2 22:06:20 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 2 Oct 2022 22:06:20 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK
In-Reply-To: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
Message-ID: <pCQ2BQu90c5Y1unot4E9spU79ReaV4hRXafN0Cfwsjw=.dce5abe4-ef72-412a-874d-dcda57317b6e@github.com>

On Thu, 29 Sep 2022 13:11:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.

Marked as reviewed by darcy (Reviewer).

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

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


From erik.joelsson at oracle.com  Mon Oct  3 14:33:49 2022
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Mon, 3 Oct 2022 07:33:49 -0700
Subject: references to hg
In-Reply-To: <AM9PR02MB6770EA47A4DBBBAD65677CF893549@AM9PR02MB6770.eurprd02.prod.outlook.com>
References: <AM9PR02MB6770EA47A4DBBBAD65677CF893549@AM9PR02MB6770.eurprd02.prod.outlook.com>
Message-ID: <be080b75-f5a9-1e0d-ffcb-78d10dfbd0b6@oracle.com>


On 9/28/22 06:28, Baesken, Matthias wrote:
>
> Hello, I noticed still a few references to hg in current openjdk 
> subtree make, I wonder should we remove?/ replace ?them ?
>
> Some of those :
>
> make/autoconf/basic.m4
>
> AC_MSG_ERROR([Bad file permissions on src files. This is usually 
> caused by cloning the repositories with a non cygwin hg in a directory 
> not created in cygwin.])
>
> Is this still an issue ?at all with git ?
>
I'm not sure if this is reproducible with Git on Windows/Cygwin. The 
reference to hg should be fixed though.
>
> make/autoconf/spec.gmk.in
>
> 772 HG:=@HG@
>
> make/autoconf/basic_tools.m4
>
> 345 UTIL_LOOKUP_PROGS(HG, hg)
>
Those are certainly not needed anymore.
>
> make/scripts/update_copyright_year.sh has also quite a few references 
> to hg, but I am not very familiar with the script.
>
I would leave this script alone unless you intend to really fix it. I 
never used it myself, but having it around for reference may be best for 
now.

/Erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20221003/aaa3b775/attachment.htm>

From erikj at openjdk.org  Mon Oct  3 14:48:22 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 3 Oct 2022 14:48:22 GMT
Subject: RFR: 8294549: configure script should detect unsupported path
In-Reply-To: <ClmMLq3SfuUgMs0U99KlBCzSCYxg49viIMeULKZTZz8=.2d692956-840c-492f-9039-1db587c8808e@github.com>
References: <INSePlc55Rszv4HetLtZS6-BnsZ2irY5hSeNTiipxwE=.55a00ecc-3f61-4615-96fd-7198a7b4ac63@github.com>
 <cA13ef5JKDjVikhOh4eZdO_a0DZOXrQI741zPh5VORE=.7cb034c3-ee6b-4048-9af6-773ebbc4361a@github.com>
 <ClmMLq3SfuUgMs0U99KlBCzSCYxg49viIMeULKZTZz8=.2d692956-840c-492f-9039-1db587c8808e@github.com>
Message-ID: <tVDRduyr_qveFkVPNzVJ5qkKg-yYm_rjCKF0XjJWSJo=.6e10acf2-f554-4a26-9d09-ad6d71d53204@github.com>

On Thu, 29 Sep 2022 04:03:39 GMT, Mike Duigou <mduigou at openjdk.org> wrote:

>> configure line 29:
>> 
>>> 27: 
>>> 28: # Get an absolute path to this script, since that determines the top-level directory.
>>> 29: source_path="${BASH_SOURCE[0]:-$0}"
>> 
>> Can we (do we want to) rely the shell running this script itself supporting BASH_SOURCE and/or other potential bash-isms?
>
> It is explicitly a bash script so I believe it is OK to use bash-isms. I usually write pure POSIX scripts because of the issues with MacOS compatibility (they use a very old GPLv2 version of BASH) and compatibility with other shells but didn't feel it was an issue here.

This script is just a very thin wrapper of the script in `make/autoconf/configure`. That script is explicitly called with `bash` so using bash-isms there (and in the rest of the configure script and build system) is fine. In this wrapper however, I think it's better to stick with compatible shell as much as possible. The shebang in this file isn't really relevant as we can't make files executable. I suspect plenty of users are still running this as `sh configure` out of habit.

I would recommend moving the space check to `make/autoconf/configure` instead.

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

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


From darcy at openjdk.org  Mon Oct  3 17:20:53 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 17:20:53 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <xtCGcSpiMRaJNEOP0fgvF56wVK2gaB_x8Qym-i_lnZU=.33efcb67-350a-4b6d-8a0d-ffb13d5a6a4e@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <eCjWYSRQB0sC2mcoavSzqTGOt7Tw5GdAKAqnDRmq07A=.f8403857-eb3a-4069-940a-a4414a8b83e8@github.com>
 <xtCGcSpiMRaJNEOP0fgvF56wVK2gaB_x8Qym-i_lnZU=.33efcb67-350a-4b6d-8a0d-ffb13d5a6a4e@github.com>
Message-ID: <H7mN4EfTvxE72FBcCrQ3MDstHI5Sm0u0fhH6o8YJRfU=.e61230a2-0413-4262-9142-76126c181725@github.com>

On Fri, 30 Sep 2022 20:25:28 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Also, FWIW, there are 100+ hits in `test` as well. But that is so many it might warrant a separate PR..?

Filed a few follow-up bugs:

JDK-8294724: Update openjdk.java.net => openjdk.org in tests (umbrella)
JDK-8294725: Update openjdk.java.net => openjdk.org in java command man page

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

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


From darcy at openjdk.org  Mon Oct  3 17:25:30 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 17:25:30 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v6]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <_UYUckHSBcJizYd7JBVbr6evdOrHu9h2MopGUlzrLR8=.b5c6d747-800b-462b-a19a-73a0f5096e3e@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Update doc directory files.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/fbaf3d4c..6bf7bf61

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=04-05

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

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


From darcy at openjdk.org  Mon Oct  3 17:29:45 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 17:29:45 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v7]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <-_gZsyDFTlHjj-7UiLaIjMBikGCJU8M2Kz9D7dm-20I=.7eacd8cd-6f3c-4a9d-9bbb-18291146b58e@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Update make directory.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/6bf7bf61..224ed7a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=05-06

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

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


From darcy at openjdk.org  Mon Oct  3 17:38:14 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 17:38:14 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <H7mN4EfTvxE72FBcCrQ3MDstHI5Sm0u0fhH6o8YJRfU=.e61230a2-0413-4262-9142-76126c181725@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <eCjWYSRQB0sC2mcoavSzqTGOt7Tw5GdAKAqnDRmq07A=.f8403857-eb3a-4069-940a-a4414a8b83e8@github.com>
 <xtCGcSpiMRaJNEOP0fgvF56wVK2gaB_x8Qym-i_lnZU=.33efcb67-350a-4b6d-8a0d-ffb13d5a6a4e@github.com>
 <H7mN4EfTvxE72FBcCrQ3MDstHI5Sm0u0fhH6o8YJRfU=.e61230a2-0413-4262-9142-76126c181725@github.com>
Message-ID: <w8oqOHIlJyGizESmriPdGYTsVqpLZya2cPRL-2FjHWE=.8730e026-5e1c-4b3f-9543-a8f3eb4a8c3c@github.com>

On Mon, 3 Oct 2022 17:17:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > Also, FWIW, there are 100+ hits in `test` as well. But that is so many it might warrant a separate PR..?
> 
> Filed a few follow-up bugs:
> 
> JDK-8294724: Update openjdk.java.net => openjdk.org in tests (umbrella) JDK-8294725: Update openjdk.java.net => openjdk.org in java command man page

And also filed

JDK-8294728: Update openjdk.java.net => openjdk.org in hotspot unit test docs

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

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


From prr at openjdk.org  Mon Oct  3 20:08:19 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 3 Oct 2022 20:08:19 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v7]
In-Reply-To: <-_gZsyDFTlHjj-7UiLaIjMBikGCJU8M2Kz9D7dm-20I=.7eacd8cd-6f3c-4a9d-9bbb-18291146b58e@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <-_gZsyDFTlHjj-7UiLaIjMBikGCJU8M2Kz9D7dm-20I=.7eacd8cd-6f3c-4a9d-9bbb-18291146b58e@github.com>
Message-ID: <RJ23ZyPLKtf2O6dWE_xNJZ8m11z66OmIB24BuZ3lAXA=.39b0cdf3-bb6e-4d9a-a6ec-6efb20f1ebee@github.com>

On Mon, 3 Oct 2022 17:29:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update make directory.

src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 36:

> 34:  * https://git.openjdk.org/jdk/blob/master/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c
> 35:  *
> 36:  * Also note that the API is used in the jaccessinspector and jaccesswalker tools.

The problem with this is, is that anyone who gets JDK 20 (or 21 the LTS) will be forever more then pointed at the OpenJDK "tip" and if we made an incompatible ABI change, that would be a problem.
At this point I'd prefer that this be updated to point to JDK 17, as in
https://github.com/openjdk/jdk17/blob/master/src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp
So it is a defined, known, compatible version.

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

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


From darcy at openjdk.org  Mon Oct  3 20:37:11 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 20:37:11 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v8]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <IOhGRORrJpR6DLUZUsSzM6WleiMFX-IWLfdFSQeDD8Q=.e7433c0f-ddec-43a7-a1f5-19c30c50cc0b@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

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 11 additional commits since the last revision:

 - Update accessibility URLs.
 - Merge branch 'master' into JDK-8294618
 - Update make directory.
 - Update doc directory files.
 - Update hg URLs to git.
 - Merge branch 'master' into JDK-8294618
 - http -> https
 - Undo manpage update.
 - Update copyright.
 - Revert unintended update to binary file.
 - ... and 1 more: https://git.openjdk.org/jdk/compare/7a8d31f3...4055f1a6

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/224ed7a0..4055f1a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=06-07

  Stats: 5510 lines in 75 files changed: 3554 ins; 1669 del; 287 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

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


From darcy at openjdk.org  Mon Oct  3 20:37:14 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 20:37:14 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v7]
In-Reply-To: <RJ23ZyPLKtf2O6dWE_xNJZ8m11z66OmIB24BuZ3lAXA=.39b0cdf3-bb6e-4d9a-a6ec-6efb20f1ebee@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <-_gZsyDFTlHjj-7UiLaIjMBikGCJU8M2Kz9D7dm-20I=.7eacd8cd-6f3c-4a9d-9bbb-18291146b58e@github.com>
 <RJ23ZyPLKtf2O6dWE_xNJZ8m11z66OmIB24BuZ3lAXA=.39b0cdf3-bb6e-4d9a-a6ec-6efb20f1ebee@github.com>
Message-ID: <hGRiPhKIV8XCNGN7oJ010i5zPMJJlaYU7XzaP-c0vjM=.dee8d1ca-3312-4540-9f43-879aeffe7431@github.com>

On Mon, 3 Oct 2022 20:04:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update make directory.
>
> src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 36:
> 
>> 34:  * https://git.openjdk.org/jdk/blob/master/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c
>> 35:  *
>> 36:  * Also note that the API is used in the jaccessinspector and jaccesswalker tools.
> 
> The problem with this is, is that anyone who gets JDK 20 (or 21 the LTS) will be forever more then pointed at the OpenJDK "tip" and if we made an incompatible ABI change, that would be a problem.
> At this point I'd prefer that this be updated to point to JDK 17, as in
> https://github.com/openjdk/jdk17/blob/master/src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp
> So it is a defined, known, compatible version.

Updated to refer to JDK 17 specifically.

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

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


From matthias.baesken at sap.com  Tue Oct  4 07:32:42 2022
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 4 Oct 2022 07:32:42 +0000
Subject: references to hg
In-Reply-To: <be080b75-f5a9-1e0d-ffcb-78d10dfbd0b6@oracle.com>
References: <AM9PR02MB6770EA47A4DBBBAD65677CF893549@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <be080b75-f5a9-1e0d-ffcb-78d10dfbd0b6@oracle.com>
Message-ID: <AM9PR02MB67708275BB78FB57E7F17697935A9@AM9PR02MB6770.eurprd02.prod.outlook.com>

Hi Erik, thanks for the feedback.
I created :

https://bugs.openjdk.org/browse/JDK-8294748
8294748 : Cleanup unneeded references to hg

Best regards, Matthias


--------------- snip ---------------------------------------------

make/autoconf/spec.gmk.in

772 HG:=@HG@

make/autoconf/basic_tools.m4

345   UTIL_LOOKUP_PROGS(HG, hg)

>Those are certainly not needed anymore.


make/scripts/update_copyright_year.sh  has also quite a few references to hg, but I am not very familiar with the script.


>I would leave this script alone unless you intend to really fix it. I never used it myself, but having it around for reference may be best for now.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20221004/5166ccf4/attachment.htm>

From mbaesken at openjdk.org  Tue Oct  4 12:38:00 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 4 Oct 2022 12:38:00 GMT
Subject: RFR: JDK-8294748: Cleanup unneeded references to hg
Message-ID: <lGvvphJNxGegwEkf5p-psv5oxB7w1i7bHSMgkV3j4jY=.e308ee82-dba8-47fd-a2c8-04171e93ae7a@github.com>

There are still a number of unneeded references to hg, for example

make/autoconf/spec.gmk.in
 
772 HG:=@HG@
 
make/autoconf/basic_tools.m4
 
345 UTIL_LOOKUP_PROGS(HG, hg)

Those can be cleaned up.

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

Commit messages:
 - JDK-8294748

Changes: https://git.openjdk.org/jdk/pull/10554/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10554&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294748
  Stats: 17 lines in 7 files changed: 0 ins; 9 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/10554.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10554/head:pull/10554

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


From mbaesken at openjdk.org  Tue Oct  4 13:08:37 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 4 Oct 2022 13:08:37 GMT
Subject: RFR: JDK-8294748: Cleanup unneeded references to hg [v2]
In-Reply-To: <lGvvphJNxGegwEkf5p-psv5oxB7w1i7bHSMgkV3j4jY=.e308ee82-dba8-47fd-a2c8-04171e93ae7a@github.com>
References: <lGvvphJNxGegwEkf5p-psv5oxB7w1i7bHSMgkV3j4jY=.e308ee82-dba8-47fd-a2c8-04171e93ae7a@github.com>
Message-ID: <zzF5lW7iKBiCUF_KXVwRoYzmM1-Bn_BC1DtTqMJqPiU=.9862a189-236f-433d-bc90-ec5a2d4085a6@github.com>

> There are still a number of unneeded references to hg, for example
> 
> make/autoconf/spec.gmk.in
>  
> 772 HG:=@HG@
>  
> make/autoconf/basic_tools.m4
>  
> 345 UTIL_LOOKUP_PROGS(HG, hg)
> 
> Those can be cleaned up.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  remove hg related line from MakeBase.gmk

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10554/files
  - new: https://git.openjdk.org/jdk/pull/10554/files/d37ade88..8fa4e57a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10554&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10554&range=00-01

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

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


From erikj at openjdk.org  Tue Oct  4 13:08:37 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 4 Oct 2022 13:08:37 GMT
Subject: RFR: JDK-8294748: Cleanup unneeded references to hg [v2]
In-Reply-To: <zzF5lW7iKBiCUF_KXVwRoYzmM1-Bn_BC1DtTqMJqPiU=.9862a189-236f-433d-bc90-ec5a2d4085a6@github.com>
References: <lGvvphJNxGegwEkf5p-psv5oxB7w1i7bHSMgkV3j4jY=.e308ee82-dba8-47fd-a2c8-04171e93ae7a@github.com>
 <zzF5lW7iKBiCUF_KXVwRoYzmM1-Bn_BC1DtTqMJqPiU=.9862a189-236f-433d-bc90-ec5a2d4085a6@github.com>
Message-ID: <lIoGGU2XH4mdPWs5oPY37VPMcfoCj28JFjWR6hc4bU8=.ee3d1839-2b4c-450b-8c3f-d800e3e06583@github.com>

On Tue, 4 Oct 2022 13:03:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are still a number of unneeded references to hg, for example
>> 
>> make/autoconf/spec.gmk.in
>>  
>> 772 HG:=@HG@
>>  
>> make/autoconf/basic_tools.m4
>>  
>> 345 UTIL_LOOKUP_PROGS(HG, hg)
>> 
>> Those can be cleaned up.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove hg related line from MakeBase.gmk

make/common/MakeBase.gmk line 133:

> 131: FindAllReposAbs = \
> 132:     $(strip $(sort $(dir $(filter-out $(TOPDIR)/build/%, $(wildcard \
> 133:         $(addprefix $(TOPDIR)/, .hg */.hg */*/.hg */*/*/.hg */*/*/*/.hg) \

This line should be possible to remove as well.

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

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


From mbaesken at openjdk.org  Tue Oct  4 13:08:37 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 4 Oct 2022 13:08:37 GMT
Subject: RFR: JDK-8294748: Cleanup unneeded references to hg [v2]
In-Reply-To: <lIoGGU2XH4mdPWs5oPY37VPMcfoCj28JFjWR6hc4bU8=.ee3d1839-2b4c-450b-8c3f-d800e3e06583@github.com>
References: <lGvvphJNxGegwEkf5p-psv5oxB7w1i7bHSMgkV3j4jY=.e308ee82-dba8-47fd-a2c8-04171e93ae7a@github.com>
 <zzF5lW7iKBiCUF_KXVwRoYzmM1-Bn_BC1DtTqMJqPiU=.9862a189-236f-433d-bc90-ec5a2d4085a6@github.com>
 <lIoGGU2XH4mdPWs5oPY37VPMcfoCj28JFjWR6hc4bU8=.ee3d1839-2b4c-450b-8c3f-d800e3e06583@github.com>
Message-ID: <ebmGHNxAymIUamcGizNUkTLBhC_T1QYLdtcfocy78Pk=.7595a545-8336-4e2a-a930-3dcbfd668f89@github.com>

On Tue, 4 Oct 2022 12:59:29 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove hg related line from MakeBase.gmk
>
> make/common/MakeBase.gmk line 133:
> 
>> 131: FindAllReposAbs = \
>> 132:     $(strip $(sort $(dir $(filter-out $(TOPDIR)/build/%, $(wildcard \
>> 133:         $(addprefix $(TOPDIR)/, .hg */.hg */*/.hg */*/*/.hg */*/*/*/.hg) \
> 
> This line should be possible to remove as well.

Hi Erik, thanks for the remark. I removed the line.

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

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


From erikj at openjdk.org  Tue Oct  4 13:20:09 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 4 Oct 2022 13:20:09 GMT
Subject: RFR: JDK-8294748: Cleanup unneeded references to hg [v2]
In-Reply-To: <zzF5lW7iKBiCUF_KXVwRoYzmM1-Bn_BC1DtTqMJqPiU=.9862a189-236f-433d-bc90-ec5a2d4085a6@github.com>
References: <lGvvphJNxGegwEkf5p-psv5oxB7w1i7bHSMgkV3j4jY=.e308ee82-dba8-47fd-a2c8-04171e93ae7a@github.com>
 <zzF5lW7iKBiCUF_KXVwRoYzmM1-Bn_BC1DtTqMJqPiU=.9862a189-236f-433d-bc90-ec5a2d4085a6@github.com>
Message-ID: <55DCVC_lYPPTAYCzXtWmTkWuK0QQcwIiKBwgWXZiQb8=.74a802e7-e365-466d-95a6-43a292b91bd0@github.com>

On Tue, 4 Oct 2022 13:08:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are still a number of unneeded references to hg, for example
>> 
>> make/autoconf/spec.gmk.in
>>  
>> 772 HG:=@HG@
>>  
>> make/autoconf/basic_tools.m4
>>  
>> 345 UTIL_LOOKUP_PROGS(HG, hg)
>> 
>> Those can be cleaned up.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove hg related line from MakeBase.gmk

Marked as reviewed by erikj (Reviewer).

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

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


From mbaesken at openjdk.org  Tue Oct  4 13:30:09 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 4 Oct 2022 13:30:09 GMT
Subject: RFR: JDK-8294748: Cleanup unneeded references to hg [v2]
In-Reply-To: <zzF5lW7iKBiCUF_KXVwRoYzmM1-Bn_BC1DtTqMJqPiU=.9862a189-236f-433d-bc90-ec5a2d4085a6@github.com>
References: <lGvvphJNxGegwEkf5p-psv5oxB7w1i7bHSMgkV3j4jY=.e308ee82-dba8-47fd-a2c8-04171e93ae7a@github.com>
 <zzF5lW7iKBiCUF_KXVwRoYzmM1-Bn_BC1DtTqMJqPiU=.9862a189-236f-433d-bc90-ec5a2d4085a6@github.com>
Message-ID: <vVSxsWfuvTsPNab8fltqf6Ug47Xe9J7PnkU1Mn3gruY=.ff9a1eeb-91b3-411b-9dd6-d6fc687074f9@github.com>

On Tue, 4 Oct 2022 13:08:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are still a number of unneeded references to hg, for example
>> 
>> make/autoconf/spec.gmk.in
>>  
>> 772 HG:=@HG@
>>  
>> make/autoconf/basic_tools.m4
>>  
>> 345 UTIL_LOOKUP_PROGS(HG, hg)
>> 
>> Those can be cleaned up.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove hg related line from MakeBase.gmk

Hi Erik, thanks for approving ;  do we need a second review or is it sufficient now ?
Best regards, Matthias

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

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


From jvernee at openjdk.org  Tue Oct  4 17:33:05 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 4 Oct 2022 17:33:05 GMT
Subject: RFR: 8294368: Java incremental builds broken on Windows after
 JDK-8293116
Message-ID: <BA9OChWzSnvuH0ylymaHLYmarFFlJCFL1mQ1dZ-Kmac=.495b9204-60d1-4b99-966a-070ef08f2d88@github.com>

This patch fixes incremental builds on Windows.

There are 2 parts to this:
1. the build system needs to run the paths in the modified file list through fixpath. I've added a `convert` mode to `fixpath.sh` for that. There's an extra target for generating the file with fixed paths. On non-windows platforms this is just a simple `cp` of the file.
2. the dependency plugin of `javac` was using string-based path comparison. But, the paths fed by the build system and the paths used internally by javac could be in slightly different formats, meaning that files were not detected properly as changed. I switched to `Path`-based comparison instead and that fixes the issue.

Testing:
tested this manually by doing the following:
1. `make clean`
2. `make images`
3. put garbage in one of the files in `java.base`
4. `make images` (incremental)
5. verify that the build reported an error
6. verify the contents of `<build>\jdk\modules\java.base_the.java.base_batch.modfiles.fixed`
7. revert the changes of 3, and do the same for another file
8. `make images` (incremental)
9. verify that the build reported an error
10. verify the contents of `<build>\jdk\modules\java.base_the.java.base_batch.modfiles.fixed`
11. remove garbage from file modified by 9 again
12. `make images` (incremental)
13. verify that build succeeds as in 2

I've tested the build on Windows and Linux (WSL) using the above steps.

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

Commit messages:
 - review comments
 - tweak comment in fixpath
 - fix windows incremental builds

Changes: https://git.openjdk.org/jdk/pull/10560/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10560&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294368
  Stats: 47 lines in 4 files changed: 39 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/10560.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10560/head:pull/10560

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


From erikj at openjdk.org  Tue Oct  4 17:33:10 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 4 Oct 2022 17:33:10 GMT
Subject: RFR: 8294368: Java incremental builds broken on Windows after
 JDK-8293116
In-Reply-To: <BA9OChWzSnvuH0ylymaHLYmarFFlJCFL1mQ1dZ-Kmac=.495b9204-60d1-4b99-966a-070ef08f2d88@github.com>
References: <BA9OChWzSnvuH0ylymaHLYmarFFlJCFL1mQ1dZ-Kmac=.495b9204-60d1-4b99-966a-070ef08f2d88@github.com>
Message-ID: <jS1QwNmTgI-bbmmTKTQZMSpmRqLGhabj6N1xQzr5H4g=.1507220a-8362-4991-b9ee-f2faa0e4bce0@github.com>

On Tue, 4 Oct 2022 16:19:24 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch fixes incremental builds on Windows.
> 
> There are 2 parts to this:
> 1. the build system needs to run the paths in the modified file list through fixpath. I've added a `convert` mode to `fixpath.sh` for that. There's an extra target for generating the file with fixed paths. On non-windows platforms this is just a simple `cp` of the file.
> 2. the dependency plugin of `javac` was using string-based path comparison. But, the paths fed by the build system and the paths used internally by javac could be in slightly different formats, meaning that files were not detected properly as changed. I switched to `Path`-based comparison instead and that fixes the issue.
> 
> Testing:
> tested this manually by doing the following:
> 1. `make clean`
> 2. `make images`
> 3. put garbage in one of the files in `java.base`
> 4. `make images` (incremental)
> 5. verify that the build reported an error
> 6. verify the contents of `<build>\jdk\modules\java.base_the.java.base_batch.modfiles.fixed`
> 7. revert the changes of 3, and do the same for another file
> 8. `make images` (incremental)
> 9. verify that the build reported an error
> 10. verify the contents of `<build>\jdk\modules\java.base_the.java.base_batch.modfiles.fixed`
> 11. remove garbage from file modified by 9 again
> 12. `make images` (incremental)
> 13. verify that build succeeds as in 2
> 
> I've tested the build on Windows and Linux (WSL) using the above steps.

This looks like a good fix. I would probably have done it slightly differently to avoid the redundant copy when it's not needed, but I think this is good enough. Thanks for fixing it!

make/common/JavaCompilation.gmk line 473:

> 471: 		$$(eval $$(call ListPathsSafely, $1_MODFILES, $$($1_MODFILELIST)))
> 472: 
> 473:     $$($1_MODFILELIST_FIXED): $$($1_MODFILELIST)

Could you add a comment about why this is needed?

make/common/MakeBase.gmk line 449:

> 447:   FixPath = \
> 448:     $(strip $(subst \,\\, $(shell $(FIXPATH_BASE) print $(patsubst $(FIXPATH), , $1))))
> 449:   FixPathFile = \

Could you add a comment on what FixPathFile does exactly?

make/scripts/fixpath.sh line 361:

> 359:   outfile="$2"
> 360:   if [[ -e $outfile ]] ; then
> 361: 	rm $outfile

Please try to match indent length with the rest of the file.

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

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


From jvernee at openjdk.org  Tue Oct  4 17:33:11 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 4 Oct 2022 17:33:11 GMT
Subject: RFR: 8294368: Java incremental builds broken on Windows after
 JDK-8293116
In-Reply-To: <BA9OChWzSnvuH0ylymaHLYmarFFlJCFL1mQ1dZ-Kmac=.495b9204-60d1-4b99-966a-070ef08f2d88@github.com>
References: <BA9OChWzSnvuH0ylymaHLYmarFFlJCFL1mQ1dZ-Kmac=.495b9204-60d1-4b99-966a-070ef08f2d88@github.com>
Message-ID: <mR6lVXfL9GtUV166P3pZ3fUGTFZxDNdtWfbHX5CTBnU=.069a2550-8185-486f-86bd-f805b47b0ccc@github.com>

On Tue, 4 Oct 2022 16:19:24 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch fixes incremental builds on Windows.
> 
> There are 2 parts to this:
> 1. the build system needs to run the paths in the modified file list through fixpath. I've added a `convert` mode to `fixpath.sh` for that. There's an extra target for generating the file with fixed paths. On non-windows platforms this is just a simple `cp` of the file.
> 2. the dependency plugin of `javac` was using string-based path comparison. But, the paths fed by the build system and the paths used internally by javac could be in slightly different formats, meaning that files were not detected properly as changed. I switched to `Path`-based comparison instead and that fixes the issue.
> 
> Testing:
> tested this manually by doing the following:
> 1. `make clean`
> 2. `make images`
> 3. put garbage in one of the files in `java.base`
> 4. `make images` (incremental)
> 5. verify that the build reported an error
> 6. verify the contents of `<build>\jdk\modules\java.base_the.java.base_batch.modfiles.fixed`
> 7. revert the changes of 3, and do the same for another file
> 8. `make images` (incremental)
> 9. verify that the build reported an error
> 10. verify the contents of `<build>\jdk\modules\java.base_the.java.base_batch.modfiles.fixed`
> 11. remove garbage from file modified by 9 again
> 12. `make images` (incremental)
> 13. verify that build succeeds as in 2
> 
> I've tested the build on Windows and Linux (WSL) using the above steps.

Thanks for the review, I've address your comments (https://github.com/openjdk/jdk/pull/10560/commits/35cc2269be8d69841f5641396cece5a1b0c1b2a3).

WRT the redundant copy. I wanted to avoid the use site having to have some `if` that checks whether we're running on Windows to decide which file `$1_COMPILE_TARGET` should depend on. Copying allows always depending on the fixed file.

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

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


From jvernee at openjdk.org  Tue Oct  4 17:33:13 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 4 Oct 2022 17:33:13 GMT
Subject: RFR: 8294368: Java incremental builds broken on Windows after
 JDK-8293116
In-Reply-To: <jS1QwNmTgI-bbmmTKTQZMSpmRqLGhabj6N1xQzr5H4g=.1507220a-8362-4991-b9ee-f2faa0e4bce0@github.com>
References: <BA9OChWzSnvuH0ylymaHLYmarFFlJCFL1mQ1dZ-Kmac=.495b9204-60d1-4b99-966a-070ef08f2d88@github.com>
 <jS1QwNmTgI-bbmmTKTQZMSpmRqLGhabj6N1xQzr5H4g=.1507220a-8362-4991-b9ee-f2faa0e4bce0@github.com>
Message-ID: <ef6MzqAOtFv1fYx2hG2VUqLZF0NTejo4o8qfPBqYXuA=.2e3088e0-42aa-4d16-8489-b5b97ede0ab9@github.com>

On Tue, 4 Oct 2022 16:56:52 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> This patch fixes incremental builds on Windows.
>> 
>> There are 2 parts to this:
>> 1. the build system needs to run the paths in the modified file list through fixpath. I've added a `convert` mode to `fixpath.sh` for that. There's an extra target for generating the file with fixed paths. On non-windows platforms this is just a simple `cp` of the file.
>> 2. the dependency plugin of `javac` was using string-based path comparison. But, the paths fed by the build system and the paths used internally by javac could be in slightly different formats, meaning that files were not detected properly as changed. I switched to `Path`-based comparison instead and that fixes the issue.
>> 
>> Testing:
>> tested this manually by doing the following:
>> 1. `make clean`
>> 2. `make images`
>> 3. put garbage in one of the files in `java.base`
>> 4. `make images` (incremental)
>> 5. verify that the build reported an error
>> 6. verify the contents of `<build>\jdk\modules\java.base_the.java.base_batch.modfiles.fixed`
>> 7. revert the changes of 3, and do the same for another file
>> 8. `make images` (incremental)
>> 9. verify that the build reported an error
>> 10. verify the contents of `<build>\jdk\modules\java.base_the.java.base_batch.modfiles.fixed`
>> 11. remove garbage from file modified by 9 again
>> 12. `make images` (incremental)
>> 13. verify that build succeeds as in 2
>> 
>> I've tested the build on Windows and Linux (WSL) using the above steps.
>
> make/scripts/fixpath.sh line 361:
> 
>> 359:   outfile="$2"
>> 360:   if [[ -e $outfile ]] ; then
>> 361: 	rm $outfile
> 
> Please try to match indent length with the rest of the file.

Looks like some tabs snuck in. Fixed now

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

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


From erikj at openjdk.org  Tue Oct  4 17:58:32 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 4 Oct 2022 17:58:32 GMT
Subject: RFR: 8294368: Java incremental builds broken on Windows after
 JDK-8293116
In-Reply-To: <BA9OChWzSnvuH0ylymaHLYmarFFlJCFL1mQ1dZ-Kmac=.495b9204-60d1-4b99-966a-070ef08f2d88@github.com>
References: <BA9OChWzSnvuH0ylymaHLYmarFFlJCFL1mQ1dZ-Kmac=.495b9204-60d1-4b99-966a-070ef08f2d88@github.com>
Message-ID: <zg0wdaU6Dqae-bk8duyeQgNIKKvGYxZTNqY1uxmPj9A=.28a0e85e-59a1-4f9d-abf5-e6a113956c33@github.com>

On Tue, 4 Oct 2022 16:19:24 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch fixes incremental builds on Windows.
> 
> There are 2 parts to this:
> 1. the build system needs to run the paths in the modified file list through fixpath. I've added a `convert` mode to `fixpath.sh` for that. There's an extra target for generating the file with fixed paths. On non-windows platforms this is just a simple `cp` of the file.
> 2. the dependency plugin of `javac` was using string-based path comparison. But, the paths fed by the build system and the paths used internally by javac could be in slightly different formats, meaning that files were not detected properly as changed. I switched to `Path`-based comparison instead and that fixes the issue.
> 
> Testing:
> tested this manually by doing the following:
> 1. `make clean`
> 2. `make images`
> 3. put garbage in one of the files in `java.base`
> 4. `make images` (incremental)
> 5. verify that the build reported an error
> 6. verify the contents of `<build>\jdk\modules\java.base_the.java.base_batch.modfiles.fixed`
> 7. revert the changes of 3, and do the same for another file
> 8. `make images` (incremental)
> 9. verify that the build reported an error
> 10. verify the contents of `<build>\jdk\modules\java.base_the.java.base_batch.modfiles.fixed`
> 11. remove garbage from file modified by 9 again
> 12. `make images` (incremental)
> 13. verify that build succeeds as in 2
> 
> I've tested the build on Windows and Linux (WSL) using the above steps.

Marked as reviewed by erikj (Reviewer).

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

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


From erikj at openjdk.org  Tue Oct  4 17:58:33 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 4 Oct 2022 17:58:33 GMT
Subject: RFR: 8294368: Java incremental builds broken on Windows after
 JDK-8293116
In-Reply-To: <mR6lVXfL9GtUV166P3pZ3fUGTFZxDNdtWfbHX5CTBnU=.069a2550-8185-486f-86bd-f805b47b0ccc@github.com>
References: <BA9OChWzSnvuH0ylymaHLYmarFFlJCFL1mQ1dZ-Kmac=.495b9204-60d1-4b99-966a-070ef08f2d88@github.com>
 <mR6lVXfL9GtUV166P3pZ3fUGTFZxDNdtWfbHX5CTBnU=.069a2550-8185-486f-86bd-f805b47b0ccc@github.com>
Message-ID: <Yk6OG3iB1ACDYSSxj7nTK8dv7UThVkbcz7NnaQr-BE8=.3cf122fa-42f1-4e60-8acc-b4b5ea409e70@github.com>

On Tue, 4 Oct 2022 17:25:07 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> WRT the redundant copy. I wanted to avoid the use site having to have some `if` that checks whether we're running on Windows to decide which file `$1_COMPILE_TARGET` should depend on. Copying allows always depending on the fixed file.

You are indeed correct and having a single code path is also a desirable attribute. Had this been in a more performance sensitive location, I would have still preferred to avoid the copy, but I think once per Java compilation unit is rare enough to not be an issue, especially since it's just unnecessary on non-windows.

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

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


From prr at openjdk.org  Tue Oct  4 18:42:44 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 4 Oct 2022 18:42:44 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v8]
In-Reply-To: <IOhGRORrJpR6DLUZUsSzM6WleiMFX-IWLfdFSQeDD8Q=.e7433c0f-ddec-43a7-a1f5-19c30c50cc0b@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <IOhGRORrJpR6DLUZUsSzM6WleiMFX-IWLfdFSQeDD8Q=.e7433c0f-ddec-43a7-a1f5-19c30c50cc0b@github.com>
Message-ID: <sHOtl2OQ9-SEwkAbYNVq8gBaJMrW-my-5CBX2s1avkI=.8c95a200-f440-4e98-907f-2060e620c5b6@github.com>

On Mon, 3 Oct 2022 20:37:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> 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 11 additional commits since the last revision:
> 
>  - Update accessibility URLs.
>  - Merge branch 'master' into JDK-8294618
>  - Update make directory.
>  - Update doc directory files.
>  - Update hg URLs to git.
>  - Merge branch 'master' into JDK-8294618
>  - http -> https
>  - Undo manpage update.
>  - Update copyright.
>  - Revert unintended update to binary file.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/571e4932...4055f1a6

Marked as reviewed by prr (Reviewer).

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

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


From clanger at openjdk.org  Wed Oct  5 05:56:07 2022
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 5 Oct 2022 05:56:07 GMT
Subject: RFR: JDK-8294748: Cleanup unneeded references to hg [v2]
In-Reply-To: <zzF5lW7iKBiCUF_KXVwRoYzmM1-Bn_BC1DtTqMJqPiU=.9862a189-236f-433d-bc90-ec5a2d4085a6@github.com>
References: <lGvvphJNxGegwEkf5p-psv5oxB7w1i7bHSMgkV3j4jY=.e308ee82-dba8-47fd-a2c8-04171e93ae7a@github.com>
 <zzF5lW7iKBiCUF_KXVwRoYzmM1-Bn_BC1DtTqMJqPiU=.9862a189-236f-433d-bc90-ec5a2d4085a6@github.com>
Message-ID: <8duDFpnEYfsWQI_cIACl9c2VPpzWo8k9q6P6BJeg9R8=.fb6f5695-f8a9-4aa2-a1e7-33f823f21d60@github.com>

On Tue, 4 Oct 2022 13:08:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are still a number of unneeded references to hg, for example
>> 
>> make/autoconf/spec.gmk.in
>>  
>> 772 HG:=@HG@
>>  
>> make/autoconf/basic_tools.m4
>>  
>> 345 UTIL_LOOKUP_PROGS(HG, hg)
>> 
>> Those can be cleaned up.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove hg related line from MakeBase.gmk

Looks good. Thanks for the cleanup.

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

Marked as reviewed by clanger (Reviewer).

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


From ihse at openjdk.org  Wed Oct  5 05:59:48 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 5 Oct 2022 05:59:48 GMT
Subject: Integrated: 8294376: Minimize disabled warnings in java.base
In-Reply-To: <R7_lfTjzEBkN-TAZxMd75nnuJ2_ZwAJfcqq-Z1Erhk0=.2aa5ecbd-14bb-4808-9087-21d084c77f8a@github.com>
References: <R7_lfTjzEBkN-TAZxMd75nnuJ2_ZwAJfcqq-Z1Erhk0=.2aa5ecbd-14bb-4808-9087-21d084c77f8a@github.com>
Message-ID: <g68lvrSZDEifvYshvevs8EE828noJh7g86tkfUdmMPg=.652cd9d2-3de0-4b30-ba9b-b28477881329@github.com>

On Mon, 26 Sep 2022 15:31:53 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.base native libraries.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.

This pull request has now been integrated.

Changeset: 755958e5
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/755958e5ee40f83f3deb5c922d51e425e3bd412c
Stats:     26 lines in 2 files changed: 8 ins; 4 del; 14 mod

8294376: Minimize disabled warnings in java.base

Reviewed-by: erikj

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

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


From mbaesken at openjdk.org  Wed Oct  5 07:28:26 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 5 Oct 2022 07:28:26 GMT
Subject: Integrated: JDK-8294748: Cleanup unneeded references to hg
In-Reply-To: <lGvvphJNxGegwEkf5p-psv5oxB7w1i7bHSMgkV3j4jY=.e308ee82-dba8-47fd-a2c8-04171e93ae7a@github.com>
References: <lGvvphJNxGegwEkf5p-psv5oxB7w1i7bHSMgkV3j4jY=.e308ee82-dba8-47fd-a2c8-04171e93ae7a@github.com>
Message-ID: <l1XSl3qSPkyR-HBFU5D5vo5OJdqc23qLzzlDouInbAM=.6f01f2b6-4dc0-4cb7-a71d-29e8fb2a6d81@github.com>

On Tue, 4 Oct 2022 12:22:24 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are still a number of unneeded references to hg, for example
> 
> make/autoconf/spec.gmk.in
>  
> 772 HG:=@HG@
>  
> make/autoconf/basic_tools.m4
>  
> 345 UTIL_LOOKUP_PROGS(HG, hg)
> 
> Those can be cleaned up.

This pull request has now been integrated.

Changeset: be82cff6
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/be82cff625c919e332da0879e2be0002485f1d1c
Stats:     18 lines in 7 files changed: 0 ins; 10 del; 8 mod

8294748: Cleanup unneeded references to hg

Reviewed-by: erikj, clanger

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

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


From ihse at openjdk.org  Wed Oct  5 07:43:19 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 5 Oct 2022 07:43:19 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v8]
In-Reply-To: <IOhGRORrJpR6DLUZUsSzM6WleiMFX-IWLfdFSQeDD8Q=.e7433c0f-ddec-43a7-a1f5-19c30c50cc0b@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <IOhGRORrJpR6DLUZUsSzM6WleiMFX-IWLfdFSQeDD8Q=.e7433c0f-ddec-43a7-a1f5-19c30c50cc0b@github.com>
Message-ID: <VwPBSkgS79Le2mS0S-MK5Zsm49GZ3eIHj-M-yyHovZg=.219c7fcd-da16-4b54-b50f-6b203107fde2@github.com>

On Mon, 3 Oct 2022 20:37:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> 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 11 additional commits since the last revision:
> 
>  - Update accessibility URLs.
>  - Merge branch 'master' into JDK-8294618
>  - Update make directory.
>  - Update doc directory files.
>  - Update hg URLs to git.
>  - Merge branch 'master' into JDK-8294618
>  - http -> https
>  - Undo manpage update.
>  - Update copyright.
>  - Revert unintended update to binary file.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/72d7bf5d...4055f1a6

Marked as reviewed by ihse (Reviewer).

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

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


From djelinski at openjdk.org  Wed Oct  5 07:49:25 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 5 Oct 2022 07:49:25 GMT
Subject: RFR: 8294368: Java incremental builds broken on Windows after
 JDK-8293116
In-Reply-To: <BA9OChWzSnvuH0ylymaHLYmarFFlJCFL1mQ1dZ-Kmac=.495b9204-60d1-4b99-966a-070ef08f2d88@github.com>
References: <BA9OChWzSnvuH0ylymaHLYmarFFlJCFL1mQ1dZ-Kmac=.495b9204-60d1-4b99-966a-070ef08f2d88@github.com>
Message-ID: <2cA71Zn88pojIuGyFBshPY0wL9RiNs9djzy_KMvkNdc=.491ddeb4-b3f0-432d-856a-2069603329a4@github.com>

On Tue, 4 Oct 2022 16:19:24 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch fixes incremental builds on Windows.
> 
> There are 2 parts to this:
> 1. the build system needs to run the paths in the modified file list through fixpath. I've added a `convert` mode to `fixpath.sh` for that. There's an extra target for generating the file with fixed paths. On non-windows platforms this is just a simple `cp` of the file.
> 2. the dependency plugin of `javac` was using string-based path comparison. But, the paths fed by the build system and the paths used internally by javac could be in slightly different formats, meaning that files were not detected properly as changed. I switched to `Path`-based comparison instead and that fixes the issue.
> 
> Testing:
> tested this manually by doing the following:
> 1. `make clean`
> 2. `make images`
> 3. put garbage in one of the files in `java.base`
> 4. `make images` (incremental)
> 5. verify that the build reported an error
> 6. verify the contents of `<build>\jdk\modules\java.base_the.java.base_batch.modfiles.fixed`
> 7. revert the changes of 3, and do the same for another file
> 8. `make images` (incremental)
> 9. verify that the build reported an error
> 10. verify the contents of `<build>\jdk\modules\java.base_the.java.base_batch.modfiles.fixed`
> 11. remove garbage from file modified by 9 again
> 12. `make images` (incremental)
> 13. verify that build succeeds as in 2
> 
> I've tested the build on Windows and Linux (WSL) using the above steps.

Also verified that:
- changes to public interface trigger full recompilation
- changes that do not affect public interface cause minimal recompilation.

This was on Cygwin. LGTM!

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

Marked as reviewed by djelinski (Committer).

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


From rgiulietti at openjdk.org  Wed Oct  5 10:02:49 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 5 Oct 2022 10:02:49 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK [v2]
In-Reply-To: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
Message-ID: <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>

> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.

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

 - 8294456: Fix misleading-indentation warnings in JDK
   
   Merge branch 'master' into JDK-8294456
 - 8294456: Fix misleading-indentation warnings in JDK

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

Changes: https://git.openjdk.org/jdk/pull/10487/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10487&range=01
  Stats: 9 lines in 4 files changed: 1 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/10487.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10487/head:pull/10487

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


From rgiulietti at openjdk.org  Wed Oct  5 10:08:31 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 5 Oct 2022 10:08:31 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK [v2]
In-Reply-To: <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
Message-ID: <56bmZbja-KHTjSDqWCsX7s2RwGkpyWIDwGLBua1d5FA=.063111f6-4ad4-4508-9ae1-7e55a9810261@github.com>

On Wed, 5 Oct 2022 10:02:49 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - 8294456: Fix misleading-indentation warnings in JDK
>    
>    Merge branch 'master' into JDK-8294456
>  - 8294456: Fix misleading-indentation warnings in JDK

I had to solve a merge conflict after https://github.com/openjdk/jdk/pull/10426 was integrated.
I think my changes need another review on the conflicting file.

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

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


From jlahoda at openjdk.org  Wed Oct  5 10:13:16 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 5 Oct 2022 10:13:16 GMT
Subject: RFR: 8294368: Java incremental builds broken on Windows after
 JDK-8293116
In-Reply-To: <BA9OChWzSnvuH0ylymaHLYmarFFlJCFL1mQ1dZ-Kmac=.495b9204-60d1-4b99-966a-070ef08f2d88@github.com>
References: <BA9OChWzSnvuH0ylymaHLYmarFFlJCFL1mQ1dZ-Kmac=.495b9204-60d1-4b99-966a-070ef08f2d88@github.com>
Message-ID: <YrKugd1EvgluXdLcrjzmI8YiTNCrsIU4EizVOFfttgg=.d075502d-7eda-44d4-b2a3-586e81d0ae80@github.com>

On Tue, 4 Oct 2022 16:19:24 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch fixes incremental builds on Windows.
> 
> There are 2 parts to this:
> 1. the build system needs to run the paths in the modified file list through fixpath. I've added a `convert` mode to `fixpath.sh` for that. There's an extra target for generating the file with fixed paths. On non-windows platforms this is just a simple `cp` of the file.
> 2. the dependency plugin of `javac` was using string-based path comparison. But, the paths fed by the build system and the paths used internally by javac could be in slightly different formats, meaning that files were not detected properly as changed. I switched to `Path`-based comparison instead and that fixes the issue.
> 
> Testing:
> tested this manually by doing the following:
> 1. `make clean`
> 2. `make images`
> 3. put garbage in one of the files in `java.base`
> 4. `make images` (incremental)
> 5. verify that the build reported an error
> 6. verify the contents of `<build>\jdk\modules\java.base_the.java.base_batch.modfiles.fixed`
> 7. revert the changes of 3, and do the same for another file
> 8. `make images` (incremental)
> 9. verify that the build reported an error
> 10. verify the contents of `<build>\jdk\modules\java.base_the.java.base_batch.modfiles.fixed`
> 11. remove garbage from file modified by 9 again
> 12. `make images` (incremental)
> 13. verify that build succeeds as in 2
> 
> I've tested the build on Windows and Linux (WSL) using the above steps.

Thanks a lot for fixing this, and sorry for trouble!

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

Marked as reviewed by jlahoda (Reviewer).

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


From shade at openjdk.org  Wed Oct  5 10:20:33 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 5 Oct 2022 10:20:33 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK [v2]
In-Reply-To: <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
Message-ID: <LhmYvUkg786sWFBhYRIew2felVmcThp2M1tAfsQENtQ=.a4ea41ea-8f6a-4eb4-8d8f-7cb03807a306@github.com>

On Wed, 5 Oct 2022 10:02:49 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - 8294456: Fix misleading-indentation warnings in JDK
>    
>    Merge branch 'master' into JDK-8294456
>  - 8294456: Fix misleading-indentation warnings in JDK

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 298:

> 296:     HEADERS_FROM_SRC := $(LIBLCMS_HEADERS_FROM_SRC), \
> 297:     DISABLED_WARNINGS_gcc := format-nonliteral type-limits \
> 298:         undef unused-function stringop-truncation, \

Ok, let's not touch this global warning and rename the issue to "Fix misleading-indentation warnings in core JDK libraries". Leave the Awt2d change to another day.

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

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


From jvernee at openjdk.org  Wed Oct  5 10:29:30 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 5 Oct 2022 10:29:30 GMT
Subject: Integrated: 8294368: Java incremental builds broken on Windows after
 JDK-8293116
In-Reply-To: <BA9OChWzSnvuH0ylymaHLYmarFFlJCFL1mQ1dZ-Kmac=.495b9204-60d1-4b99-966a-070ef08f2d88@github.com>
References: <BA9OChWzSnvuH0ylymaHLYmarFFlJCFL1mQ1dZ-Kmac=.495b9204-60d1-4b99-966a-070ef08f2d88@github.com>
Message-ID: <MiRxucTeAbTSqu25vHmfmgLcGf7U-en15lGmHpLJtHo=.a1708bb5-6bea-426e-b272-2225a2521499@github.com>

On Tue, 4 Oct 2022 16:19:24 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch fixes incremental builds on Windows.
> 
> There are 2 parts to this:
> 1. the build system needs to run the paths in the modified file list through fixpath. I've added a `convert` mode to `fixpath.sh` for that. There's an extra target for generating the file with fixed paths. On non-windows platforms this is just a simple `cp` of the file.
> 2. the dependency plugin of `javac` was using string-based path comparison. But, the paths fed by the build system and the paths used internally by javac could be in slightly different formats, meaning that files were not detected properly as changed. I switched to `Path`-based comparison instead and that fixes the issue.
> 
> Testing:
> tested this manually by doing the following:
> 1. `make clean`
> 2. `make images`
> 3. put garbage in one of the files in `java.base`
> 4. `make images` (incremental)
> 5. verify that the build reported an error
> 6. verify the contents of `<build>\jdk\modules\java.base_the.java.base_batch.modfiles.fixed`
> 7. revert the changes of 3, and do the same for another file
> 8. `make images` (incremental)
> 9. verify that the build reported an error
> 10. verify the contents of `<build>\jdk\modules\java.base_the.java.base_batch.modfiles.fixed`
> 11. remove garbage from file modified by 9 again
> 12. `make images` (incremental)
> 13. verify that build succeeds as in 2
> 
> I've tested the build on Windows and Linux (WSL) using the above steps.

This pull request has now been integrated.

Changeset: 8ebebbce
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8ebebbce32c7021cc0983dece4bb2644c79e64aa
Stats:     47 lines in 4 files changed: 39 ins; 0 del; 8 mod

8294368: Java incremental builds broken on Windows after JDK-8293116

Reviewed-by: erikj, djelinski, jlahoda

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

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


From duke at openjdk.org  Wed Oct  5 11:35:24 2022
From: duke at openjdk.org (Sacha Coppey)
Date: Wed, 5 Oct 2022 11:35:24 GMT
Subject: RFR: 8290154: [JVMCI] partially implement JVMCI for RISC-V [v10]
In-Reply-To: <01N2Slfoz83bKVvbH3Ja0O0cOI-rcagrV6jeIdi3dws=.4cce1f7e-2223-4013-bb11-8319aef46444@github.com>
References: <Fo5zR0zWrySO82DNETw8MfSKJrPHNc7WI13We85rRTE=.a0691f98-9a15-453a-ad4a-67a9e1d490ca@github.com>
 <01N2Slfoz83bKVvbH3Ja0O0cOI-rcagrV6jeIdi3dws=.4cce1f7e-2223-4013-bb11-8319aef46444@github.com>
Message-ID: <fY-DJipWPTG2ZvunzFEuTUUSGH1iy1dUzPCLyNdhJQc=.ad6a9b2b-8ca6-4233-bb8d-6651f8e7d7be@github.com>

On Wed, 14 Sep 2022 09:39:07 GMT, Sacha Coppey <duke at openjdk.org> wrote:

>> This patch adds a partial JVMCI implementation for RISC-V, to allow using the GraalVM Native Image RISC-V LLVM backend, which does not use JVMCI for code emission.
>> It creates the jdk.vm.ci.riscv64 and jdk.vm.ci.hotspot.riscv64 packages, as well as implements a part of jvmciCodeInstaller_riscv64.cpp. To check for correctness, it enables JVMCI code installation tests on RISC-V. More testing is performed in Native Image.
>
> Sacha Coppey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove noinline attribute by fixing sign extended value

Hello, this PR has been stuck for some time now. What should I do to proceed?

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

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


From rgiulietti at openjdk.org  Wed Oct  5 12:03:22 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 5 Oct 2022 12:03:22 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK [v2]
In-Reply-To: <LhmYvUkg786sWFBhYRIew2felVmcThp2M1tAfsQENtQ=.a4ea41ea-8f6a-4eb4-8d8f-7cb03807a306@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
 <LhmYvUkg786sWFBhYRIew2felVmcThp2M1tAfsQENtQ=.a4ea41ea-8f6a-4eb4-8d8f-7cb03807a306@github.com>
Message-ID: <1UQyX79zIVU7mGxkOTSULe7S7DZNDUjOy6NPnSP8V1c=.ddb4d2f9-f784-4fe2-9eb1-bb29349ecb55@github.com>

On Wed, 5 Oct 2022 10:16:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - 8294456: Fix misleading-indentation warnings in JDK
>>    
>>    Merge branch 'master' into JDK-8294456
>>  - 8294456: Fix misleading-indentation warnings in JDK
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 298:
> 
>> 296:     HEADERS_FROM_SRC := $(LIBLCMS_HEADERS_FROM_SRC), \
>> 297:     DISABLED_WARNINGS_gcc := format-nonliteral type-limits \
>> 298:         undef unused-function stringop-truncation, \
> 
> Ok, let's not touch this global warning and rename the issue to "Fix misleading-indentation warnings in core JDK libraries". Leave the Awt2d change to another day.

What is the problem with Awt2d? Other conflicts?

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

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


From dnsimon at openjdk.org  Wed Oct  5 12:04:10 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 5 Oct 2022 12:04:10 GMT
Subject: RFR: 8290154: [JVMCI] partially implement JVMCI for RISC-V [v7]
In-Reply-To: <Jn4Z6du47opxp7ZjvR7yHcRjH4OzfgRNiyidixU7Tqo=.65056162-5b71-4d99-9bbf-10a756dc3578@github.com>
References: <Fo5zR0zWrySO82DNETw8MfSKJrPHNc7WI13We85rRTE=.a0691f98-9a15-453a-ad4a-67a9e1d490ca@github.com>
 <5AOnVFRDCk63egnuw1HsPUgB1N9E-YuygeIJZV9REZQ=.0118fb0e-184a-4580-ac3d-88238f9ca5a8@github.com>
 <OvCr3cX_4CNGKu2Rv48suVypNJr71shLhyZnBr3eecA=.98e5e22b-80e1-4127-9fef-a15b24be6ad5@github.com>
 <Jn4Z6du47opxp7ZjvR7yHcRjH4OzfgRNiyidixU7Tqo=.65056162-5b71-4d99-9bbf-10a756dc3578@github.com>
Message-ID: <69doshv-kwhZYUPEx6u98FZOse3rkizVg2WZkeML8Kc=.16884845-c9b3-4927-971d-0a3e6ba15aef@github.com>

On Wed, 24 Aug 2022 11:33:01 GMT, Fei Yang <fyang at openjdk.org> wrote:

>>> Do you have details about testing performed in Native Image as mentioned in PR decription?
>> 
>> Yes, the RISC-V LLVM backend for Native Image passes 99% of the tests performed, which is similar to the other LLVM backends.
>> 
>>> I see you added more changes in hotspot file sharedRuntime_riscv.cpp guarded by macro INCLUDE_JVMCI. Searching for INCLUDE_JVMCI or COMPILER2_OR_JVMCI in src/hotspot/cpu/aarch64, I see several more places checking for these macros. Have you checked if we need similar changes for your use case?
>> 
>> I first added the changes for all places where those macros are used, but since only modifying sharedRuntime_riscv.cpp was enough to make the tests pass, I did not wanted to add code that I was not sure was useful at the moment.
>> 
>>> Also could you explain the change made in hotspot file deoptimization.hpp? Thanks.
>> 
>> When the method is inlined, the `if (trap_request < 0)` check behaves incorrectly when the `nmethod` is compiled by JVMCI. Even though the boolean is true, the function returns -11 instead of -1, and the `if (unloaded_class_index >= 0)` checks have the same issue, causing an access to an illegal index of an array. I am not sure why this happens, as it works correctly for method not compiled by JVMCI.
>
>> > I see you added more changes in hotspot file sharedRuntime_riscv.cpp guarded by macro INCLUDE_JVMCI. Searching for INCLUDE_JVMCI or COMPILER2_OR_JVMCI in src/hotspot/cpu/aarch64, I see several more places checking for these macros. Have you checked if we need similar changes for your use case?
>> 
>> I first added the changes for all places where those macros are used, but since only modifying sharedRuntime_riscv.cpp was enough to make the tests pass, I did not wanted to add code that I was not sure was useful at the moment.
> 
> Well, that sounds fragile to me since you are depending on a relatively small set of JTreg tests here. I think an analysis is needed here to be sure about whether those are really needed or not.

@RealFYang are you ok with deferring further changes to a future RFE?

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

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


From shade at openjdk.org  Wed Oct  5 12:11:21 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 5 Oct 2022 12:11:21 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK [v2]
In-Reply-To: <1UQyX79zIVU7mGxkOTSULe7S7DZNDUjOy6NPnSP8V1c=.ddb4d2f9-f784-4fe2-9eb1-bb29349ecb55@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
 <LhmYvUkg786sWFBhYRIew2felVmcThp2M1tAfsQENtQ=.a4ea41ea-8f6a-4eb4-8d8f-7cb03807a306@github.com>
 <1UQyX79zIVU7mGxkOTSULe7S7DZNDUjOy6NPnSP8V1c=.ddb4d2f9-f784-4fe2-9eb1-bb29349ecb55@github.com>
Message-ID: <c7hWjn16Z60UOPEWegOIMbAk8RkWYbNvV_gEoPLbwZU=.8bf3e6e6-5fbd-4d3d-9662-b5e099ff6a89@github.com>

On Wed, 5 Oct 2022 12:01:00 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 298:
>> 
>>> 296:     HEADERS_FROM_SRC := $(LIBLCMS_HEADERS_FROM_SRC), \
>>> 297:     DISABLED_WARNINGS_gcc := format-nonliteral type-limits \
>>> 298:         undef unused-function stringop-truncation, \
>> 
>> Ok, let's not touch this global warning and rename the issue to "Fix misleading-indentation warnings in core JDK libraries". Leave the Awt2d change to another day.
>
> What is the problem with Awt2d? Other conflicts?

I am not completely sure all `misleading-indentation` warnings are fixed in Awt2d, this would require some more testing. I'd defer that to #10453.

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

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


From erikj at openjdk.org  Wed Oct  5 12:46:31 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 5 Oct 2022 12:46:31 GMT
Subject: Integrated: 8294310: compare.sh fails on macos after JDK-8293550
In-Reply-To: <1duWbv2JWP--JlbqP-BdtxBOM96S-kKWR0-DJGNgptI=.99b1255f-4851-4995-a5ff-a99a7cd1a526@github.com>
References: <1duWbv2JWP--JlbqP-BdtxBOM96S-kKWR0-DJGNgptI=.99b1255f-4851-4995-a5ff-a99a7cd1a526@github.com>
Message-ID: <OKYeQ5QgnJ2tjVRrNHtmN3eaNBrA-mrJwvvTag9YPec=.bf3b7d54-074c-45dd-bab8-972a45ed693a@github.com>

On Mon, 26 Sep 2022 22:51:22 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Since [JDK-8293550](https://bugs.openjdk.org/browse/JDK-8293550) we are adding adhoc signatures to all binaries on macos, and the compare script is no longer running cleanly. In order to compare binaries on macos, especially on aarch64, where signatures are mandatory, we will have to remove them first. They will never be exactly the same between two runs.
> 
> This patch adds `codesign --remove-signature` to compare.sh before comparing any executables or libraries. Stripping the signature has to happen after running `strip` as strip will fail otherwise. I also had to add a special option to strip to avoid warnings.
> 
> While enabling baseline compare runs for macosx-aarch64 in our CI, I discovered that were also not running testmake for aarch64, so I snuck in that change in jib-profiles.js here as well.

This pull request has now been integrated.

Changeset: b9eeec2b
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b9eeec2b6b8f97d2ba33462b27d091f918067f78
Stats:     14 lines in 3 files changed: 10 ins; 0 del; 4 mod

8294310: compare.sh fails on macos after JDK-8293550

Reviewed-by: ihse

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

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


From rgiulietti at openjdk.org  Wed Oct  5 13:50:23 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 5 Oct 2022 13:50:23 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK [v2]
In-Reply-To: <c7hWjn16Z60UOPEWegOIMbAk8RkWYbNvV_gEoPLbwZU=.8bf3e6e6-5fbd-4d3d-9662-b5e099ff6a89@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
 <LhmYvUkg786sWFBhYRIew2felVmcThp2M1tAfsQENtQ=.a4ea41ea-8f6a-4eb4-8d8f-7cb03807a306@github.com>
 <1UQyX79zIVU7mGxkOTSULe7S7DZNDUjOy6NPnSP8V1c=.ddb4d2f9-f784-4fe2-9eb1-bb29349ecb55@github.com>
 <c7hWjn16Z60UOPEWegOIMbAk8RkWYbNvV_gEoPLbwZU=.8bf3e6e6-5fbd-4d3d-9662-b5e099ff6a89@github.com>
Message-ID: <-dZ60_xB0xnIsH6YI7kFMQgtyaeLyYn60Ik0aK4ctzE=.66561a3c-2f68-40a2-a256-3f30b66ff444@github.com>

On Wed, 5 Oct 2022 12:07:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> What is the problem with Awt2d? Other conflicts?
>
> I am not completely sure all `misleading-indentation` warnings are fixed in Awt2d, this would require some more testing. I'd defer that to #10453.

Awt2dLibraries.gmk in https://github.com/openjdk/jdk/pull/10453 seems more about clang if I'm not mistaken, while this change is about gcc.
The JDK successfully builds on several platforms with this change.

What else could go wrong? I'm asking because I'm not a build engineering expert at all.

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

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


From shade at openjdk.org  Wed Oct  5 13:54:10 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 5 Oct 2022 13:54:10 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK [v2]
In-Reply-To: <-dZ60_xB0xnIsH6YI7kFMQgtyaeLyYn60Ik0aK4ctzE=.66561a3c-2f68-40a2-a256-3f30b66ff444@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
 <LhmYvUkg786sWFBhYRIew2felVmcThp2M1tAfsQENtQ=.a4ea41ea-8f6a-4eb4-8d8f-7cb03807a306@github.com>
 <1UQyX79zIVU7mGxkOTSULe7S7DZNDUjOy6NPnSP8V1c=.ddb4d2f9-f784-4fe2-9eb1-bb29349ecb55@github.com>
 <c7hWjn16Z60UOPEWegOIMbAk8RkWYbNvV_gEoPLbwZU=.8bf3e6e6-5fbd-4d3d-9662-b5e099ff6a89@github.com>
 <-dZ60_xB0xnIsH6YI7kFMQgtyaeLyYn60Ik0aK4ctzE=.66561a3c-2f68-40a2-a256-3f30b66ff444@github.com>
Message-ID: <0vEUzzox7stDb-K4l3Tlj3p5dyUDCKYcm3LcJC9DAd0=.1d0d5f0b-ec4e-40d0-9e6f-7ffae1e9d875@github.com>

On Wed, 5 Oct 2022 13:46:23 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> I am not completely sure all `misleading-indentation` warnings are fixed in Awt2d, this would require some more testing. I'd defer that to #10453.
>
> Awt2dLibraries.gmk in https://github.com/openjdk/jdk/pull/10453 seems more about clang if I'm not mistaken, while this change is about gcc.
> The JDK successfully builds on several platforms with this change.
> 
> What else could go wrong? I'm asking because I'm not a build engineering expert at all.

This could fail the build on some toolchains. Cleanliness and least surprise: this PR changes the particular files, and so it should remove the warnings for those specific files.

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

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


From rgiulietti at openjdk.org  Wed Oct  5 14:06:21 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 5 Oct 2022 14:06:21 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in core JDK
 libraries [v3]
In-Reply-To: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
Message-ID: <61eXki6R0QjODAaLPVm1PrjNlPD5LCjbvzeG9Iz12o8=.8f33b181-7ced-4ed8-bdd2-037e43fa56ec@github.com>

> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8294456: Fix misleading-indentation warnings in JDK

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10487/files
  - new: https://git.openjdk.org/jdk/pull/10487/files/4581b7dd..7b455e5a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10487&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10487&range=01-02

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

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


From rgiulietti at openjdk.org  Wed Oct  5 14:06:24 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 5 Oct 2022 14:06:24 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in core JDK
 libraries [v2]
In-Reply-To: <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
Message-ID: <jdqZWOfEPFZIDV15uRNw-D7L7OUcQLJG2D1V26WOGZw=.a9bd1fcc-ab7e-445f-9878-998a7150fd13@github.com>

On Wed, 5 Oct 2022 10:02:49 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - 8294456: Fix misleading-indentation warnings in JDK
>    
>    Merge branch 'master' into JDK-8294456
>  - 8294456: Fix misleading-indentation warnings in JDK

Restored `misleading-indentation` warning in `Awt2dLibraries.gmk`

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

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


From shade at openjdk.org  Wed Oct  5 15:05:22 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 5 Oct 2022 15:05:22 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in core JDK
 libraries [v3]
In-Reply-To: <61eXki6R0QjODAaLPVm1PrjNlPD5LCjbvzeG9Iz12o8=.8f33b181-7ced-4ed8-bdd2-037e43fa56ec@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <61eXki6R0QjODAaLPVm1PrjNlPD5LCjbvzeG9Iz12o8=.8f33b181-7ced-4ed8-bdd2-037e43fa56ec@github.com>
Message-ID: <kASsj6bokAL0NZ2yQiugQbCEYx9nS6Y8DhMkTqyIZdo=.f4e6c2c7-0173-4ac0-a0fb-de0628e79255@github.com>

On Wed, 5 Oct 2022 14:06:21 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8294456: Fix misleading-indentation warnings in JDK

Marked as reviewed by shade (Reviewer).

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

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


From darcy at openjdk.org  Wed Oct  5 16:39:32 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 5 Oct 2022 16:39:32 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v9]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <T3sWlUnikg_EsuKqJ5PFiXj8IDAbk0fYG-WR3iLLvTw=.19912185-605f-4201-8022-0ffb7e00342d@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

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 12 additional commits since the last revision:

 - Merge branch 'master' into JDK-8294618
 - Update accessibility URLs.
 - Merge branch 'master' into JDK-8294618
 - Update make directory.
 - Update doc directory files.
 - Update hg URLs to git.
 - Merge branch 'master' into JDK-8294618
 - http -> https
 - Undo manpage update.
 - Update copyright.
 - ... and 2 more: https://git.openjdk.org/jdk/compare/8aa24fec...eba2bd4b

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/4055f1a6..eba2bd4b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=07-08

  Stats: 1452 lines in 87 files changed: 912 ins; 312 del; 228 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

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


From darcy at openjdk.org  Wed Oct  5 16:52:27 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 5 Oct 2022 16:52:27 GMT
Subject: Integrated: JDK-8294618: Update openjdk.java.net => openjdk.org
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <vtc6z3XjCCr9yLV3usCQemL0opkJB2S_3H8IZGWwD_A=.7c03befe-b74b-48e0-ad2d-3594d6ebc1b5@github.com>

On Fri, 30 Sep 2022 00:33:57 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

This pull request has now been integrated.

Changeset: 536c9a51
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/536c9a512ea90d97a1ae5310453410d55db98bdd
Stats:     128 lines in 45 files changed: 0 ins; 0 del; 128 mod

8294618: Update openjdk.java.net => openjdk.org

Reviewed-by: mikael, iris, joehw, prr, ihse

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

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


From mikael at openjdk.org  Wed Oct  5 17:06:45 2022
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 5 Oct 2022 17:06:45 GMT
Subject: RFR: 8286037: Bump minimum boot jdk to JDK 19
Message-ID: <9c092caRoZP30mX2MI9S10X8RtMaZqSWctFrPppLiaI=.7167c6ab-b809-4512-8ee4-b8af6fcae1b0@github.com>

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

Testing: tier1-5, GHA builds

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

Commit messages:
 - Fix URLs
 - 8286037: Bump minimum boot jdk to JDK 19

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

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


From ctornqvi at openjdk.org  Wed Oct  5 17:12:18 2022
From: ctornqvi at openjdk.org (Christian Tornqvist)
Date: Wed, 5 Oct 2022 17:12:18 GMT
Subject: RFR: 8286037: Bump minimum boot jdk to JDK 19
In-Reply-To: <9c092caRoZP30mX2MI9S10X8RtMaZqSWctFrPppLiaI=.7167c6ab-b809-4512-8ee4-b8af6fcae1b0@github.com>
References: <9c092caRoZP30mX2MI9S10X8RtMaZqSWctFrPppLiaI=.7167c6ab-b809-4512-8ee4-b8af6fcae1b0@github.com>
Message-ID: <RvODuNGQRDH4sR1retpWHsSjKIIgokPR4NE1In4cGak=.1fb5c0a3-f63e-4651-a589-6c2c3ceda013@github.com>

On Tue, 4 Oct 2022 22:20:57 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

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

Marked as reviewed by ctornqvi (Reviewer).

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

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


From darcy at openjdk.org  Wed Oct  5 17:18:18 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 5 Oct 2022 17:18:18 GMT
Subject: RFR: 8286037: Bump minimum boot jdk to JDK 19
In-Reply-To: <9c092caRoZP30mX2MI9S10X8RtMaZqSWctFrPppLiaI=.7167c6ab-b809-4512-8ee4-b8af6fcae1b0@github.com>
References: <9c092caRoZP30mX2MI9S10X8RtMaZqSWctFrPppLiaI=.7167c6ab-b809-4512-8ee4-b8af6fcae1b0@github.com>
Message-ID: <LR0aOXqOVug6FicAztGCi0RO_qeHXVVQwWBUCi1ma7E=.1a2fdea2-4dff-485d-a48f-899dbbe07817@github.com>

On Tue, 4 Oct 2022 22:20:57 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

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

Marked as reviewed by darcy (Reviewer).

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

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


From shade at openjdk.org  Wed Oct  5 17:18:18 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 5 Oct 2022 17:18:18 GMT
Subject: RFR: 8286037: Bump minimum boot jdk to JDK 19
In-Reply-To: <9c092caRoZP30mX2MI9S10X8RtMaZqSWctFrPppLiaI=.7167c6ab-b809-4512-8ee4-b8af6fcae1b0@github.com>
References: <9c092caRoZP30mX2MI9S10X8RtMaZqSWctFrPppLiaI=.7167c6ab-b809-4512-8ee4-b8af6fcae1b0@github.com>
Message-ID: <f0cpA4rn4hCqdtt1p1Mive5yL2FESqQiurKTsAD2MSo=.c712329a-0f98-4041-bc9a-b6af0689d12d@github.com>

On Tue, 4 Oct 2022 22:20:57 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

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

Marked as reviewed by shade (Reviewer).

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

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


From erikj at openjdk.org  Wed Oct  5 17:25:09 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 5 Oct 2022 17:25:09 GMT
Subject: RFR: 8286037: Bump minimum boot jdk to JDK 19
In-Reply-To: <9c092caRoZP30mX2MI9S10X8RtMaZqSWctFrPppLiaI=.7167c6ab-b809-4512-8ee4-b8af6fcae1b0@github.com>
References: <9c092caRoZP30mX2MI9S10X8RtMaZqSWctFrPppLiaI=.7167c6ab-b809-4512-8ee4-b8af6fcae1b0@github.com>
Message-ID: <NUiKqzYdBI0NsA4yj_pFFPxwfn9vpg_O-ihQ_PpjkbA=.539d19b3-8f21-4973-bf4c-e27ea249470c@github.com>

On Tue, 4 Oct 2022 22:20:57 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

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

Marked as reviewed by erikj (Reviewer).

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

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


From shurailine at openjdk.org  Wed Oct  5 21:31:12 2022
From: shurailine at openjdk.org (Alexandre Iline)
Date: Wed, 5 Oct 2022 21:31:12 GMT
Subject: RFR: JDK-8292330: Update JCov version to 3.0.13
Message-ID: <XmBk2LSfOsTk8aCYPx3oBXbrzY0DquTcVn2O8R0V72A=.897d1bcc-5dbc-4f46-9e83-9176e4e656a2@github.com>

Switch to a new JCov version

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

Commit messages:
 - JDK-8292330: Update JCov version to 3.0.13

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

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


From erikj at openjdk.org  Wed Oct  5 23:17:16 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 5 Oct 2022 23:17:16 GMT
Subject: RFR: JDK-8292330: Update JCov version to 3.0.13
In-Reply-To: <XmBk2LSfOsTk8aCYPx3oBXbrzY0DquTcVn2O8R0V72A=.897d1bcc-5dbc-4f46-9e83-9176e4e656a2@github.com>
References: <XmBk2LSfOsTk8aCYPx3oBXbrzY0DquTcVn2O8R0V72A=.897d1bcc-5dbc-4f46-9e83-9176e4e656a2@github.com>
Message-ID: <V8VxxPFk3uL2-cWCMbiAhPqZWFpTrfaplLOK0KWOunk=.624519fc-4533-4f78-99e3-c0a458290d4d@github.com>

On Wed, 5 Oct 2022 21:23:49 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> Switch to a new JCov version

Marked as reviewed by erikj (Reviewer).

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

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


From shurailine at openjdk.org  Thu Oct  6 00:24:41 2022
From: shurailine at openjdk.org (Alexandre Iline)
Date: Thu, 6 Oct 2022 00:24:41 GMT
Subject: Integrated: JDK-8292330: Update JCov version to 3.0.13
In-Reply-To: <XmBk2LSfOsTk8aCYPx3oBXbrzY0DquTcVn2O8R0V72A=.897d1bcc-5dbc-4f46-9e83-9176e4e656a2@github.com>
References: <XmBk2LSfOsTk8aCYPx3oBXbrzY0DquTcVn2O8R0V72A=.897d1bcc-5dbc-4f46-9e83-9176e4e656a2@github.com>
Message-ID: <QfBBaTnUH9GjflDlfD8tDcHMZs2bRoOtQd7xx026oek=.3d643bf0-b1a2-457a-aea2-5dcfea0fdd29@github.com>

On Wed, 5 Oct 2022 21:23:49 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> Switch to a new JCov version

This pull request has now been integrated.

Changeset: e986a97a
Author:    Alexandre Iline <shurailine at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e986a97a9652eab9a64505673e884eb3eb123166
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8292330: Update JCov version to 3.0.13

Reviewed-by: erikj

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

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


From rgiulietti at openjdk.org  Thu Oct  6 09:35:09 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 6 Oct 2022 09:35:09 GMT
Subject: Integrated: 8294456: Fix misleading-indentation warnings in core JDK
 libraries
In-Reply-To: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
Message-ID: <p6anLs2K5nMnmfJGCi71-RbijOfCBjjLd-pwBJQgucg=.0ed1c704-1575-4ff0-9c9e-754ec656ca72@github.com>

On Thu, 29 Sep 2022 13:11:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.

This pull request has now been integrated.

Changeset: 2ceebf68
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2ceebf681ffd6f9bf6967fd81b30d721bc010b94
Stats:     8 lines in 3 files changed: 1 ins; 1 del; 6 mod

8294456: Fix misleading-indentation warnings in core JDK libraries

Reviewed-by: shade, rriggs, iris, darcy

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

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


From matthias.baesken at sap.com  Thu Oct  6 11:34:32 2022
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 6 Oct 2022 11:34:32 +0000
Subject: configure checks for package handler tools on Windows
Message-ID: <AM9PR02MB6770D69523026BCFEA942945935C9@AM9PR02MB6770.eurprd02.prod.outlook.com>

Hello , currently  we check in

make/autoconf/help.m4

for a couple of well known package handler tools :

AC_DEFUN_ONCE([HELP_SETUP_DEPENDENCY_HELP],
[
  UTIL_LOOKUP_PROGS(PKGHANDLER, zypper apt-get yum brew port pkgutil pkgadd pacman apk)
])

This might be a great thing on UNIX/Mac , but on Windows  we just get

checking for zypper... [not found]
checking for apt-get... [not found]
checking for yum... [not found]
checking for brew... [not found]
checking for port... [not found]
checking for pkgutil... [not found]
checking for pkgadd... [not found]
checking for pacman... [not found]
checking for apk... [not found]

and the whole check looks a bit questionable.  So should we avoid those checks on Windows ? Or do they play some role (I have to admit that I just use cygwin maybe those tools
  are more important on non-Cygwin Windows environments) ?

For other (Windows only) checks  started from

  make/autoconf/configure.ac

we seem to check the OS before doing something (e.g. BASIC_WINDOWS_FINALIZE_FIXPATH).

Best regards, Matthias



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20221006/cb7b78d9/attachment.htm>

From fyang at openjdk.org  Thu Oct  6 12:29:32 2022
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 6 Oct 2022 12:29:32 GMT
Subject: RFR: 8290154: [JVMCI] partially implement JVMCI for RISC-V [v10]
In-Reply-To: <fY-DJipWPTG2ZvunzFEuTUUSGH1iy1dUzPCLyNdhJQc=.ad6a9b2b-8ca6-4233-bb8d-6651f8e7d7be@github.com>
References: <Fo5zR0zWrySO82DNETw8MfSKJrPHNc7WI13We85rRTE=.a0691f98-9a15-453a-ad4a-67a9e1d490ca@github.com>
 <01N2Slfoz83bKVvbH3Ja0O0cOI-rcagrV6jeIdi3dws=.4cce1f7e-2223-4013-bb11-8319aef46444@github.com>
 <fY-DJipWPTG2ZvunzFEuTUUSGH1iy1dUzPCLyNdhJQc=.ad6a9b2b-8ca6-4233-bb8d-6651f8e7d7be@github.com>
Message-ID: <8WpmQnd37FlbLW2mt5xvMqTg4vVH_AZs8ng-3310Sg0=.6499c9a4-3b0c-4714-91ec-aa5d9c6a3d80@github.com>

On Wed, 5 Oct 2022 11:33:14 GMT, Sacha Coppey <duke at openjdk.org> wrote:

> Hello, this PR has been stuck for some time now. What should I do to proceed?

The current version does not build. I will take another look after this is rebased on the latest jdk master.

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

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


From duke at openjdk.org  Thu Oct  6 12:41:46 2022
From: duke at openjdk.org (Sacha Coppey)
Date: Thu, 6 Oct 2022 12:41:46 GMT
Subject: RFR: 8290154: [JVMCI] partially implement JVMCI for RISC-V [v11]
In-Reply-To: <Fo5zR0zWrySO82DNETw8MfSKJrPHNc7WI13We85rRTE=.a0691f98-9a15-453a-ad4a-67a9e1d490ca@github.com>
References: <Fo5zR0zWrySO82DNETw8MfSKJrPHNc7WI13We85rRTE=.a0691f98-9a15-453a-ad4a-67a9e1d490ca@github.com>
Message-ID: <4ozXv5Ok4bRtzCO28vQ3BSb_NLatUYdcT6u_rHCqk08=.7f12ef55-5276-4919-be3c-c8ffc45c0c2b@github.com>

> This patch adds a partial JVMCI implementation for RISC-V, to allow using the GraalVM Native Image RISC-V LLVM backend, which does not use JVMCI for code emission.
> It creates the jdk.vm.ci.riscv64 and jdk.vm.ci.hotspot.riscv64 packages, as well as implements a part of jvmciCodeInstaller_riscv64.cpp. To check for correctness, it enables JVMCI code installation tests on RISC-V. More testing is performed in Native Image.

Sacha Coppey 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 noinline attribute by fixing sign extended value
 - Remove vector registers from get_hotspot_reg
 - Add a comments for the change in deoptimization.hpp
 - Fix error when emitting LUI and removed vector registers
 - Ensure all JVMCI tests pass on RISC-V
 - Add space in switch
 - Avoid using set_destination when call is not jal
 - Use nativeInstruction_at instead of nativeCall_at to avoid wrongly initializating a call
 - 8290154: [JVMCI] Implement JVMCI for RISC-V

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

Changes: https://git.openjdk.org/jdk/pull/9587/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9587&range=10
  Stats: 1723 lines in 20 files changed: 1701 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/9587.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9587/head:pull/9587

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


From duke at openjdk.org  Thu Oct  6 17:18:36 2022
From: duke at openjdk.org (Sacha Coppey)
Date: Thu, 6 Oct 2022 17:18:36 GMT
Subject: RFR: 8290154: [JVMCI] partially implement JVMCI for RISC-V [v12]
In-Reply-To: <Fo5zR0zWrySO82DNETw8MfSKJrPHNc7WI13We85rRTE=.a0691f98-9a15-453a-ad4a-67a9e1d490ca@github.com>
References: <Fo5zR0zWrySO82DNETw8MfSKJrPHNc7WI13We85rRTE=.a0691f98-9a15-453a-ad4a-67a9e1d490ca@github.com>
Message-ID: <h_zj-dFjW05pqAuZg63UtrSdP4RC_ip2ZsZnfPfgskA=.a43ead7c-a4c0-4bc3-8af6-ffa54053caa1@github.com>

> This patch adds a partial JVMCI implementation for RISC-V, to allow using the GraalVM Native Image RISC-V LLVM backend, which does not use JVMCI for code emission.
> It creates the jdk.vm.ci.riscv64 and jdk.vm.ci.hotspot.riscv64 packages, as well as implements a part of jvmciCodeInstaller_riscv64.cpp. To check for correctness, it enables JVMCI code installation tests on RISC-V. More testing is performed in Native Image.

Sacha Coppey has updated the pull request incrementally with one additional commit since the last revision:

  Replace RegisterImpl and FloatRegisterImpl uses by Register and FloatRegister

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9587/files
  - new: https://git.openjdk.org/jdk/pull/9587/files/46159813..225fee42

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9587&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9587&range=10-11

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

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


From duke at openjdk.org  Thu Oct  6 17:18:37 2022
From: duke at openjdk.org (Sacha Coppey)
Date: Thu, 6 Oct 2022 17:18:37 GMT
Subject: RFR: 8290154: [JVMCI] partially implement JVMCI for RISC-V [v10]
In-Reply-To: <8WpmQnd37FlbLW2mt5xvMqTg4vVH_AZs8ng-3310Sg0=.6499c9a4-3b0c-4714-91ec-aa5d9c6a3d80@github.com>
References: <Fo5zR0zWrySO82DNETw8MfSKJrPHNc7WI13We85rRTE=.a0691f98-9a15-453a-ad4a-67a9e1d490ca@github.com>
 <01N2Slfoz83bKVvbH3Ja0O0cOI-rcagrV6jeIdi3dws=.4cce1f7e-2223-4013-bb11-8319aef46444@github.com>
 <fY-DJipWPTG2ZvunzFEuTUUSGH1iy1dUzPCLyNdhJQc=.ad6a9b2b-8ca6-4233-bb8d-6651f8e7d7be@github.com>
 <8WpmQnd37FlbLW2mt5xvMqTg4vVH_AZs8ng-3310Sg0=.6499c9a4-3b0c-4714-91ec-aa5d9c6a3d80@github.com>
Message-ID: <ybMOqPfiSwFuXC8bNHVIE2ot3nubwCuCQcAqYUwc7vs=.4073e05b-e947-4808-afe6-f96df23379d5@github.com>

On Thu, 6 Oct 2022 12:27:11 GMT, Fei Yang <fyang at openjdk.org> wrote:

> The current version does not build. I will take another look after this is rebased on the latest jdk master.

Sorry for the delay, I rebased the PR and fixed the building issue.

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

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


From mikael at openjdk.org  Thu Oct  6 17:38:24 2022
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 6 Oct 2022 17:38:24 GMT
Subject: Integrated: 8286037: Bump minimum boot jdk to JDK 19
In-Reply-To: <9c092caRoZP30mX2MI9S10X8RtMaZqSWctFrPppLiaI=.7167c6ab-b809-4512-8ee4-b8af6fcae1b0@github.com>
References: <9c092caRoZP30mX2MI9S10X8RtMaZqSWctFrPppLiaI=.7167c6ab-b809-4512-8ee4-b8af6fcae1b0@github.com>
Message-ID: <QEgJpmScnA1_DlGA4yI9SDam5A3q4oIIQiQrlcWZvzM=.cd3b57be-b5a1-4359-be38-6b3543c8cece@github.com>

On Tue, 4 Oct 2022 22:20:57 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: 85569e96
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/85569e966c22e5b5314a157d05c43c0f6e8c2b28
Stats:     8 lines in 3 files changed: 0 ins; 0 del; 8 mod

8286037: Bump minimum boot jdk to JDK 19

Reviewed-by: ctornqvi, darcy, shade, erikj

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

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


From shade at openjdk.org  Fri Oct  7 07:56:12 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 7 Oct 2022 07:56:12 GMT
Subject: RFR: 8294941: GHA: Cut down cross-compilation sysroots
Message-ID: <9eAzRLctRc3Qlz3TqXQSKwWvTdydLoJcSr1zaBq5j_o=.75f4c773-250e-4166-a1b0-78ccdbb9374b@github.com>

In GHA cross-compilation, we don't need everything from the sysroot, because we use native compilers for the compilation. Therefore, we can cut them even deeper and reclaim significant amount of cache space. This would also make cache eviction less likely, which saves time on recreating the sysroots when that happens.

Current sysroots take about 300M per arch, which quickly multiplies up for multiple arches (we build 5 now) users (ballparking at about 200 active contributors). This amounts to about 1500M caches per job, and 300G in caches across our org. 

In my local tests, new aarch64 sysroot tar.gz gets reduced from 315M to just 85M, about 3.7x improvement. Even deeper cuts are possible, but they would affect the redundant `.so`-s in `/usr/lib/${arch}/`. That would be much more fragile to do and might affect our builds. Therefore, I stopped at doing just these.

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

Commit messages:
 - Fix

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

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


From yadongwang at openjdk.org  Fri Oct  7 09:04:33 2022
From: yadongwang at openjdk.org (Yadong Wang)
Date: Fri, 7 Oct 2022 09:04:33 GMT
Subject: RFR: 8290154: [JVMCI] partially implement JVMCI for RISC-V [v12]
In-Reply-To: <h_zj-dFjW05pqAuZg63UtrSdP4RC_ip2ZsZnfPfgskA=.a43ead7c-a4c0-4bc3-8af6-ffa54053caa1@github.com>
References: <Fo5zR0zWrySO82DNETw8MfSKJrPHNc7WI13We85rRTE=.a0691f98-9a15-453a-ad4a-67a9e1d490ca@github.com>
 <h_zj-dFjW05pqAuZg63UtrSdP4RC_ip2ZsZnfPfgskA=.a43ead7c-a4c0-4bc3-8af6-ffa54053caa1@github.com>
Message-ID: <6xoiOoUbDCCRPGfYz4RIcaKp2pQAVtCbhH4qQgNU-7M=.9df9466b-5145-4aa9-a810-e2cd23b79bf6@github.com>

On Thu, 6 Oct 2022 17:18:36 GMT, Sacha Coppey <duke at openjdk.org> wrote:

>> This patch adds a partial JVMCI implementation for RISC-V, to allow using the GraalVM Native Image RISC-V LLVM backend, which does not use JVMCI for code emission.
>> It creates the jdk.vm.ci.riscv64 and jdk.vm.ci.hotspot.riscv64 packages, as well as implements a part of jvmciCodeInstaller_riscv64.cpp. To check for correctness, it enables JVMCI code installation tests on RISC-V. More testing is performed in Native Image.
>
> Sacha Coppey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace RegisterImpl and FloatRegisterImpl uses by Register and FloatRegister

lgtm(not a reviewer)

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

Marked as reviewed by yadongwang (Author).

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


From duke at openjdk.org  Fri Oct  7 09:29:56 2022
From: duke at openjdk.org (Sacha Coppey)
Date: Fri, 7 Oct 2022 09:29:56 GMT
Subject: RFR: 8290154: [JVMCI] partially implement JVMCI for RISC-V [v13]
In-Reply-To: <Fo5zR0zWrySO82DNETw8MfSKJrPHNc7WI13We85rRTE=.a0691f98-9a15-453a-ad4a-67a9e1d490ca@github.com>
References: <Fo5zR0zWrySO82DNETw8MfSKJrPHNc7WI13We85rRTE=.a0691f98-9a15-453a-ad4a-67a9e1d490ca@github.com>
Message-ID: <hiIXoe3BYxtW6k4uS8CZbOx4NWy73vVsfpb0ygfd3OY=.2d209466-72cf-45c6-b9fd-135c63c0c1cf@github.com>

> This patch adds a partial JVMCI implementation for RISC-V, to allow using the GraalVM Native Image RISC-V LLVM backend, which does not use JVMCI for code emission.
> It creates the jdk.vm.ci.riscv64 and jdk.vm.ci.hotspot.riscv64 packages, as well as implements a part of jvmciCodeInstaller_riscv64.cpp. To check for correctness, it enables JVMCI code installation tests on RISC-V. More testing is performed in Native Image.

Sacha Coppey has updated the pull request incrementally with one additional commit since the last revision:

  Update a copyright header

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9587/files
  - new: https://git.openjdk.org/jdk/pull/9587/files/225fee42..e7913fad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9587&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9587&range=11-12

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

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


From clanger at openjdk.org  Fri Oct  7 09:34:16 2022
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 7 Oct 2022 09:34:16 GMT
Subject: RFR: 8294941: GHA: Cut down cross-compilation sysroots
In-Reply-To: <9eAzRLctRc3Qlz3TqXQSKwWvTdydLoJcSr1zaBq5j_o=.75f4c773-250e-4166-a1b0-78ccdbb9374b@github.com>
References: <9eAzRLctRc3Qlz3TqXQSKwWvTdydLoJcSr1zaBq5j_o=.75f4c773-250e-4166-a1b0-78ccdbb9374b@github.com>
Message-ID: <P792M6XZ3P-0z8_FnPYcmn5CJ-WrtsPu2jKXt6GeYCk=.027d7725-7258-4068-b004-b14006ff9afb@github.com>

On Fri, 7 Oct 2022 07:48:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> In GHA cross-compilation, we don't need everything from the sysroot, because we use native compilers for the compilation. Therefore, we can cut them even deeper and reclaim significant amount of cache space. This would also make cache eviction less likely, which saves time on recreating the sysroots when that happens.
> 
> Current sysroots take about 300M per arch, which quickly multiplies up for multiple arches (we build 5 now), users (ballparking at about 200 active contributors). This amounts to about 1500M caches per job, and 300G in caches across our org for a single JDK tree. Update releases also use GHA for their testing, but the number of contributors there is lower. Still, I think it slides to TB territory now.
> 
> In my local tests, new aarch64 sysroot tar.gz gets reduced from 315M to just 85M, about 3.7x improvement. Even deeper cuts are possible, but they would affect the redundant `.so`-s in `/usr/lib/${arch}/`. That would be much more fragile to do and might affect our builds. Therefore, I stopped at doing just these.

Looks good.

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

Marked as reviewed by clanger (Reviewer).

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


From duke at openjdk.org  Fri Oct  7 13:12:54 2022
From: duke at openjdk.org (Sacha Coppey)
Date: Fri, 7 Oct 2022 13:12:54 GMT
Subject: Integrated: 8290154: [JVMCI] partially implement JVMCI for RISC-V
In-Reply-To: <Fo5zR0zWrySO82DNETw8MfSKJrPHNc7WI13We85rRTE=.a0691f98-9a15-453a-ad4a-67a9e1d490ca@github.com>
References: <Fo5zR0zWrySO82DNETw8MfSKJrPHNc7WI13We85rRTE=.a0691f98-9a15-453a-ad4a-67a9e1d490ca@github.com>
Message-ID: <WPb-eLqBNosTRPzUJz3LUZOWgYDm7ffOrAZt2P8OaaY=.1be50cd0-7b39-4bcf-bfd7-273fffe14bd3@github.com>

On Thu, 21 Jul 2022 10:18:05 GMT, Sacha Coppey <duke at openjdk.org> wrote:

> This patch adds a partial JVMCI implementation for RISC-V, to allow using the GraalVM Native Image RISC-V LLVM backend, which does not use JVMCI for code emission.
> It creates the jdk.vm.ci.riscv64 and jdk.vm.ci.hotspot.riscv64 packages, as well as implements a part of jvmciCodeInstaller_riscv64.cpp. To check for correctness, it enables JVMCI code installation tests on RISC-V. More testing is performed in Native Image.

This pull request has now been integrated.

Changeset: 7a194d31
Author:    Sacha Coppey <sacha.coppey at oracle.com>
Committer: Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7a194d31a3f2f78211f035f4591845bf2b465aec
Stats:     1722 lines in 20 files changed: 1700 ins; 0 del; 22 mod

8290154: [JVMCI] partially implement JVMCI for RISC-V

Reviewed-by: ihse, dnsimon, yadongwang

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

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


From duke at openjdk.org  Fri Oct  7 14:25:41 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Fri, 7 Oct 2022 14:25:41 GMT
Subject: RFR: 8286394: Address possibly lossy conversions in jdk.naming.dns
Message-ID: <l1_iyh7y9_miGXeVopY9JvMF8jmRy7MY3n-8PzVcHYY=.0fa1eefa-eeed-46de-bbe1-0855c247d103@github.com>

Added an int cast for the `timeoutLeft` assignment, looking through the code and other uses of the variable it seems to show no issues with lossy conversion. As part of this I removed the file to disable the conversion warning

I tested this build and it doesn't give any warnings on this file

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

Commit messages:
 - added int cast and reenabled warning for lossy conversion

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

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


From rriggs at openjdk.org  Fri Oct  7 14:37:14 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Oct 2022 14:37:14 GMT
Subject: RFR: 8286394: Address possibly lossy conversions in jdk.naming.dns
In-Reply-To: <l1_iyh7y9_miGXeVopY9JvMF8jmRy7MY3n-8PzVcHYY=.0fa1eefa-eeed-46de-bbe1-0855c247d103@github.com>
References: <l1_iyh7y9_miGXeVopY9JvMF8jmRy7MY3n-8PzVcHYY=.0fa1eefa-eeed-46de-bbe1-0855c247d103@github.com>
Message-ID: <etd42HG31qyS7qJDyw1WSao3dM2lrQnbuDcjbhbMROw=.3f0ea55a-9bcc-4de9-9f68-5708e3cc2f26@github.com>

On Fri, 7 Oct 2022 14:14:13 GMT, Darragh Clarke <duke at openjdk.org> wrote:

> Added an int cast for the `timeoutLeft` assignment, looking through the code and other uses of the variable it seems to show no issues with lossy conversion. As part of this I removed the file to disable the conversion warning
> 
> I tested this build and it doesn't give any warnings on this file

LGTM

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

Marked as reviewed by rriggs (Reviewer).

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


From aefimov at openjdk.org  Fri Oct  7 14:55:29 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 7 Oct 2022 14:55:29 GMT
Subject: RFR: 8286394: Address possibly lossy conversions in jdk.naming.dns
In-Reply-To: <l1_iyh7y9_miGXeVopY9JvMF8jmRy7MY3n-8PzVcHYY=.0fa1eefa-eeed-46de-bbe1-0855c247d103@github.com>
References: <l1_iyh7y9_miGXeVopY9JvMF8jmRy7MY3n-8PzVcHYY=.0fa1eefa-eeed-46de-bbe1-0855c247d103@github.com>
Message-ID: <2C6dgLdGl6jh2hWZ_orw0I0qAlGkQ7bDuC2mf4nKkbw=.3691e3fc-ec0c-406d-b71c-b69cb4b932e8@github.com>

On Fri, 7 Oct 2022 14:14:13 GMT, Darragh Clarke <duke at openjdk.org> wrote:

> Added an int cast for the `timeoutLeft` assignment, looking through the code and other uses of the variable it seems to show no issues with lossy conversion. As part of this I removed the file to disable the conversion warning
> 
> I tested this build and it doesn't give any warnings on this file

Marked as reviewed by aefimov (Committer).

Looks good. I can help with sponsoring this change.

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

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


From duke at openjdk.org  Fri Oct  7 16:08:11 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Fri, 7 Oct 2022 16:08:11 GMT
Subject: Integrated: 8286394: Address possibly lossy conversions in
 jdk.naming.dns
In-Reply-To: <l1_iyh7y9_miGXeVopY9JvMF8jmRy7MY3n-8PzVcHYY=.0fa1eefa-eeed-46de-bbe1-0855c247d103@github.com>
References: <l1_iyh7y9_miGXeVopY9JvMF8jmRy7MY3n-8PzVcHYY=.0fa1eefa-eeed-46de-bbe1-0855c247d103@github.com>
Message-ID: <F_33FlpPuwSqImI1_V6lu_OT_LM0vubW_8flVkfil2g=.af20dd70-d378-4b97-8540-b48560df22ad@github.com>

On Fri, 7 Oct 2022 14:14:13 GMT, Darragh Clarke <duke at openjdk.org> wrote:

> Added an int cast for the `timeoutLeft` assignment, looking through the code and other uses of the variable it seems to show no issues with lossy conversion. As part of this I removed the file to disable the conversion warning
> 
> I tested this build and it doesn't give any warnings on this file

This pull request has now been integrated.

Changeset: 67210abd
Author:    Darragh Clarke <Darragh.clarke at oracle.com>
Committer: Aleksei Efimov <aefimov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/67210abd04683a3a16ec8af0948030a934e5ce15
Stats:     2 lines in 2 files changed: 0 ins; 1 del; 1 mod

8286394: Address possibly lossy conversions in jdk.naming.dns

Reviewed-by: rriggs, aefimov

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

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


From shade at openjdk.org  Fri Oct  7 16:41:21 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 7 Oct 2022 16:41:21 GMT
Subject: RFR: 8294941: GHA: Cut down cross-compilation sysroots
In-Reply-To: <9eAzRLctRc3Qlz3TqXQSKwWvTdydLoJcSr1zaBq5j_o=.75f4c773-250e-4166-a1b0-78ccdbb9374b@github.com>
References: <9eAzRLctRc3Qlz3TqXQSKwWvTdydLoJcSr1zaBq5j_o=.75f4c773-250e-4166-a1b0-78ccdbb9374b@github.com>
Message-ID: <ny3wR6hRcM4TBDD-8vdhjQ74eMZibMM0D_XKNtU2YTs=.6f98dabd-5a69-49ba-99a1-7224fb4c69c3@github.com>

On Fri, 7 Oct 2022 07:48:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> In GHA cross-compilation, we don't need everything from the sysroot, because we use native compilers for the compilation. Therefore, we can cut them even deeper and reclaim significant amount of cache space. This would also make cache eviction less likely, which saves time on recreating the sysroots when that happens.
> 
> Current sysroots take about 300M per arch, which quickly multiplies up for multiple arches (we build 5 now), users (ballparking at about 200 active contributors). This amounts to about 1500M caches per job, and 300G in caches across our org for a single JDK tree. Update releases also use GHA for their testing, but the number of contributors there is lower. Still, I think it slides to TB territory now.
> 
> In my local tests, new aarch64 sysroot tar.gz gets reduced from 315M to just 85M, about 3.7x improvement. Even deeper cuts are possible, but they would affect the redundant `.so`-s in `/usr/lib/${arch}/`. That would be much more fragile to do and might affect our builds. Therefore, I stopped at doing just these.

Thanks! If any build-dev folks ack this, I can integrate this today :)

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

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


From erikj at openjdk.org  Fri Oct  7 16:49:37 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 7 Oct 2022 16:49:37 GMT
Subject: RFR: 8294941: GHA: Cut down cross-compilation sysroots
In-Reply-To: <9eAzRLctRc3Qlz3TqXQSKwWvTdydLoJcSr1zaBq5j_o=.75f4c773-250e-4166-a1b0-78ccdbb9374b@github.com>
References: <9eAzRLctRc3Qlz3TqXQSKwWvTdydLoJcSr1zaBq5j_o=.75f4c773-250e-4166-a1b0-78ccdbb9374b@github.com>
Message-ID: <-zK92sVPnNgNbToznZH-POw3v7wdLJ1HEN6Td5WtwqM=.b45479ad-fcf6-4e9b-8ef3-e502f96dff4b@github.com>

On Fri, 7 Oct 2022 07:48:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> In GHA cross-compilation, we don't need everything from the sysroot, because we use native compilers for the compilation. Therefore, we can cut them even deeper and reclaim significant amount of cache space. This would also make cache eviction less likely, which saves time on recreating the sysroots when that happens.
> 
> Current sysroots take about 300M per arch, which quickly multiplies up for multiple arches (we build 5 now), users (ballparking at about 200 active contributors). This amounts to about 1500M caches per job, and 300G in caches across our org for a single JDK tree. Update releases also use GHA for their testing, but the number of contributors there is lower. Still, I think it slides to TB territory now.
> 
> In my local tests, new aarch64 sysroot tar.gz gets reduced from 315M to just 85M, about 3.7x improvement. Even deeper cuts are possible, but they would affect the redundant `.so`-s in `/usr/lib/${arch}/`. That would be much more fragile to do and might affect our builds. Therefore, I stopped at doing just these.

Seems fine to me. Nice space savings!

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

Marked as reviewed by erikj (Reviewer).

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


From shade at openjdk.org  Fri Oct  7 17:08:17 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 7 Oct 2022 17:08:17 GMT
Subject: RFR: 8294941: GHA: Cut down cross-compilation sysroots
In-Reply-To: <9eAzRLctRc3Qlz3TqXQSKwWvTdydLoJcSr1zaBq5j_o=.75f4c773-250e-4166-a1b0-78ccdbb9374b@github.com>
References: <9eAzRLctRc3Qlz3TqXQSKwWvTdydLoJcSr1zaBq5j_o=.75f4c773-250e-4166-a1b0-78ccdbb9374b@github.com>
Message-ID: <VecPQsvSryi_kMeOIAaAgnKc_k0ecqDBIZGXoHGd3uk=.8b22bc11-7e7d-498b-96a9-cb4ce1a63d26@github.com>

On Fri, 7 Oct 2022 07:48:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> In GHA cross-compilation, we don't need everything from the sysroot, because we use native compilers for the compilation. Therefore, we can cut them even deeper and reclaim significant amount of cache space. This would also make cache eviction less likely, which saves time on recreating the sysroots when that happens.
> 
> Current sysroots take about 300M per arch, which quickly multiplies up for multiple arches (we build 5 now), users (ballparking at about 200 active contributors). This amounts to about 1500M caches per job, and 300G in caches across our org for a single JDK tree. Update releases also use GHA for their testing, but the number of contributors there is lower. Still, I think it slides to TB territory now.
> 
> In my local tests, new aarch64 sysroot tar.gz gets reduced from 315M to just 85M, about 3.7x improvement. Even deeper cuts are possible, but they would affect the redundant `.so`-s in `/usr/lib/${arch}/`. That would be much more fragile to do and might affect our builds. Therefore, I stopped at doing just these.

Thanks!

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

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


From shade at openjdk.org  Fri Oct  7 17:15:31 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 7 Oct 2022 17:15:31 GMT
Subject: Integrated: 8294941: GHA: Cut down cross-compilation sysroots
In-Reply-To: <9eAzRLctRc3Qlz3TqXQSKwWvTdydLoJcSr1zaBq5j_o=.75f4c773-250e-4166-a1b0-78ccdbb9374b@github.com>
References: <9eAzRLctRc3Qlz3TqXQSKwWvTdydLoJcSr1zaBq5j_o=.75f4c773-250e-4166-a1b0-78ccdbb9374b@github.com>
Message-ID: <Xp2JgOjbh8f1k1WiZD622ImgsLTNy82OH5IY6S_4-JA=.0d1398f4-95b8-4cde-8488-c37667737c7f@github.com>

On Fri, 7 Oct 2022 07:48:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> In GHA cross-compilation, we don't need everything from the sysroot, because we use native compilers for the compilation. Therefore, we can cut them even deeper and reclaim significant amount of cache space. This would also make cache eviction less likely, which saves time on recreating the sysroots when that happens.
> 
> Current sysroots take about 300M per arch, which quickly multiplies up for multiple arches (we build 5 now), users (ballparking at about 200 active contributors). This amounts to about 1500M caches per job, and 300G in caches across our org for a single JDK tree. Update releases also use GHA for their testing, but the number of contributors there is lower. Still, I think it slides to TB territory now.
> 
> In my local tests, new aarch64 sysroot tar.gz gets reduced from 315M to just 85M, about 3.7x improvement. Even deeper cuts are possible, but they would affect the redundant `.so`-s in `/usr/lib/${arch}/`. That would be much more fragile to do and might affect our builds. Therefore, I stopped at doing just these.

This pull request has now been integrated.

Changeset: a1747ef8
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a1747ef81a10e84177f474565193204ceaa0ede8
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8294941: GHA: Cut down cross-compilation sysroots

Reviewed-by: clanger, erikj

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

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


From shade at openjdk.org  Fri Oct  7 17:24:47 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 7 Oct 2022 17:24:47 GMT
Subject: RFR: 8294956: GHA: qemu-debootstrap is deprecated, use the regular one
Message-ID: <ZcPgKX3J833gjePzrTbgItCXisdY4LLIC5514owFfxo=.d149b11a-45d1-4188-b0fb-294d35fae925@github.com>

On current Ubuntu systems, qemu-debootstrap is deprecated. It prints the warning messages like:


$ sudo qemu-debootstrap --arch=arm64 --verbose --include=fakeroot,symlinks,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng-dev --resolve-deps bullseye aarch64-sysroot https://httpredir.debian.org/debian/
...
W: qemu-debootstrap is deprecated. Please use regular debootstrap directly

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

Commit messages:
 - Fix

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

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


From erikj at openjdk.org  Fri Oct  7 17:33:21 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 7 Oct 2022 17:33:21 GMT
Subject: RFR: 8294956: GHA: qemu-debootstrap is deprecated,
 use the regular one
In-Reply-To: <ZcPgKX3J833gjePzrTbgItCXisdY4LLIC5514owFfxo=.d149b11a-45d1-4188-b0fb-294d35fae925@github.com>
References: <ZcPgKX3J833gjePzrTbgItCXisdY4LLIC5514owFfxo=.d149b11a-45d1-4188-b0fb-294d35fae925@github.com>
Message-ID: <Q1cUFEUTArHKzqdIWkIOTh_jTyojK3sdy9Xx7Zb0rEg=.949b0db2-bebf-404d-bcc9-8d2efb8786cf@github.com>

On Fri, 7 Oct 2022 17:13:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> On current Ubuntu systems, qemu-debootstrap is deprecated. It prints the warning messages like:
> 
> 
> $ sudo qemu-debootstrap --arch=arm64 --verbose --include=fakeroot,symlinks,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng-dev --resolve-deps bullseye aarch64-sysroot https://httpredir.debian.org/debian/
> ...
> W: qemu-debootstrap is deprecated. Please use regular debootstrap directly

Seems fine if that works and doesn't print warnings.

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

Marked as reviewed by erikj (Reviewer).

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


From kbarrett at openjdk.org  Sun Oct  9 01:46:16 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 9 Oct 2022 01:46:16 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code
In-Reply-To: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
Message-ID: <_vNpHQsYGB0Em5NjD1plwOpmcDcDIqf1T0i7gOj4nKs=.3a01519f-5f75-4805-8b9a-4230d1a31204@github.com>

On Thu, 29 Sep 2022 16:12:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:

Changes requested by kbarrett (Reviewer).

test/hotspot/gtest/runtime/test_signals.cpp line 49:

> 47:   static void check_handlers() {
> 48:     struct sigaction act, old_SIGFPE_act, old_SIGILL_act;
> 49:     act.sa_handler = CAST_FROM_FN_PTR(sa_handler_t, sig_handler);

This is similarly wrong code that should be fixed instead of doing weird casting dances.  The problem here is that sig_handler has the wrong signature.  It should be just `void sig_handler(int)`.  Fix that and not casts needed.

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

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


From kbarrett at openjdk.org  Sun Oct  9 01:46:17 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 9 Oct 2022 01:46:17 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code
In-Reply-To: <t1X4oiPfM2ZDNQPceadU5bsr1Kg5VQWppWYjWVeHVHI=.14ae324c-b439-4b75-8c64-5c5e33e7d915@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <t1X4oiPfM2ZDNQPceadU5bsr1Kg5VQWppWYjWVeHVHI=.14ae324c-b439-4b75-8c64-5c5e33e7d915@github.com>
Message-ID: <I3ESJ8EIT8yXtevTGqeOQJVjgj9al7rqAMDVaD17LcE=.af674e89-edfe-4b84-aaa5-88ce92561a32@github.com>

On Fri, 30 Sep 2022 04:53:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:
>
> src/hotspot/os/posix/signals_posix.cpp line 1727:
> 
>> 1725:   // Set up signal handler for suspend/resume
>> 1726:   act.sa_flags = SA_RESTART|SA_SIGINFO;
>> 1727:   act.sa_handler = CAST_FROM_FN_PTR(sa_handler_t, SR_handler);
> 
> The underlying cast in the macro seems a little odd for this situation but if it appeases the compiler then that is fine.

No, don't do this.  The code is just wrong, and should be fixed.

We have a struct sigaction.  We've set the sa_flags member to a value that
includes SA_SIGINFO.  That means the 3 argument sa_sigaction handler is
supposed to be invoked.

We're storing the SR_handler (cast to a value matching the type of the
sa_handler member of the sigaction). This is "working" purely by accident.
Apparently on all POSIX platforms we support, the sa_handler and sa_sigaction
occupy the same memory (being in a union, which is permitted by the spec).

The signature for SR_handler should be changed from
void SR_handler(int, siginfo_t*, ucontext_t*)
to
void SR_handler(int, siginfo_t*, void*)
and adjust the code to deal with the change to the type of the 3rd parameter.

Then we can just assign the sa_sigaction member to SR_handler without any casts.

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

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


From kbarrett at openjdk.org  Sun Oct  9 03:00:09 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 9 Oct 2022 03:00:09 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code
In-Reply-To: <_vNpHQsYGB0Em5NjD1plwOpmcDcDIqf1T0i7gOj4nKs=.3a01519f-5f75-4805-8b9a-4230d1a31204@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <_vNpHQsYGB0Em5NjD1plwOpmcDcDIqf1T0i7gOj4nKs=.3a01519f-5f75-4805-8b9a-4230d1a31204@github.com>
Message-ID: <jpL-bb0C1xWA3yIZaALPQCGpur2GSoUZx4lPhvTZrik=.d1b8ab36-653c-49a5-a531-4817ec0585df@github.com>

On Sun, 9 Oct 2022 01:43:26 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:
>
> test/hotspot/gtest/runtime/test_signals.cpp line 49:
> 
>> 47:   static void check_handlers() {
>> 48:     struct sigaction act, old_SIGFPE_act, old_SIGILL_act;
>> 49:     act.sa_handler = CAST_FROM_FN_PTR(sa_handler_t, sig_handler);
> 
> This is similarly wrong code that should be fixed instead of doing weird casting dances.  The problem here is that sig_handler has the wrong signature.  It should be just `void sig_handler(int)`.  Fix that and not casts needed.

This one is even worse than the other.  Here we're installing a handler function taking 3 arguments in such a way that it will only be called with one.  Weee!

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

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


From kbarrett at openjdk.org  Sun Oct  9 05:41:53 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 9 Oct 2022 05:41:53 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code
In-Reply-To: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
Message-ID: <iYezptZ6KPvk3Atzbvuhs-QRWd9uuS6WyrEq4MiOHGE=.94287867-eebd-494a-b97d-6d944c911edc@github.com>

On Thu, 29 Sep 2022 16:12:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:

make/hotspot/lib/CompileJvm.gmk line 147:

> 145: # Now set up the actual compilation of the main hotspot native library
> 146: 
> 147: # TODO: Should merge once JDK-8294314 is in.

Left-over comment should be removed.

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

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


From dholmes at openjdk.org  Mon Oct 10 04:49:32 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Oct 2022 04:49:32 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code
In-Reply-To: <I3ESJ8EIT8yXtevTGqeOQJVjgj9al7rqAMDVaD17LcE=.af674e89-edfe-4b84-aaa5-88ce92561a32@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <t1X4oiPfM2ZDNQPceadU5bsr1Kg5VQWppWYjWVeHVHI=.14ae324c-b439-4b75-8c64-5c5e33e7d915@github.com>
 <I3ESJ8EIT8yXtevTGqeOQJVjgj9al7rqAMDVaD17LcE=.af674e89-edfe-4b84-aaa5-88ce92561a32@github.com>
Message-ID: <KVRtujr_dFUhRwCBFdRvoP9mAFrElYXxLIUvhHb2ws4=.d8188453-59de-413b-b07e-744407f61013@github.com>

On Sun, 9 Oct 2022 01:40:29 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/os/posix/signals_posix.cpp line 1727:
>> 
>>> 1725:   // Set up signal handler for suspend/resume
>>> 1726:   act.sa_flags = SA_RESTART|SA_SIGINFO;
>>> 1727:   act.sa_handler = CAST_FROM_FN_PTR(sa_handler_t, SR_handler);
>> 
>> The underlying cast in the macro seems a little odd for this situation but if it appeases the compiler then that is fine.
>
> No, don't do this.  The code is just wrong, and should be fixed.
> 
> We have a struct sigaction.  We've set the sa_flags member to a value that
> includes SA_SIGINFO.  That means the 3 argument sa_sigaction handler is
> supposed to be invoked.
> 
> We're storing the SR_handler (cast to a value matching the type of the
> sa_handler member of the sigaction). This is "working" purely by accident.
> Apparently on all POSIX platforms we support, the sa_handler and sa_sigaction
> occupy the same memory (being in a union, which is permitted by the spec).
> 
> The signature for SR_handler should be changed from
> void SR_handler(int, siginfo_t*, ucontext_t*)
> to
> void SR_handler(int, siginfo_t*, void*)
> and adjust the code to deal with the change to the type of the 3rd parameter.
> 
> Then we can just assign the sa_sigaction member to SR_handler without any casts.

But this is how POSIX specifies it: `sigaction.sa_handler` is declared as `void(*) (int)` - so that is what we have to use when storing the handler address. But the handler itself has to be the three arg version because that is how it will be called.

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

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


From dholmes at openjdk.org  Mon Oct 10 04:49:32 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Oct 2022 04:49:32 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code
In-Reply-To: <KVRtujr_dFUhRwCBFdRvoP9mAFrElYXxLIUvhHb2ws4=.d8188453-59de-413b-b07e-744407f61013@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <t1X4oiPfM2ZDNQPceadU5bsr1Kg5VQWppWYjWVeHVHI=.14ae324c-b439-4b75-8c64-5c5e33e7d915@github.com>
 <I3ESJ8EIT8yXtevTGqeOQJVjgj9al7rqAMDVaD17LcE=.af674e89-edfe-4b84-aaa5-88ce92561a32@github.com>
 <KVRtujr_dFUhRwCBFdRvoP9mAFrElYXxLIUvhHb2ws4=.d8188453-59de-413b-b07e-744407f61013@github.com>
Message-ID: <5gHhzngXCdin5SaTRi41oVHEasuLPFxqGZDvRZqNPPc=.fa6cc437-0514-4990-ae6a-8e4b8b3016bb@github.com>

On Mon, 10 Oct 2022 04:43:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> No, don't do this.  The code is just wrong, and should be fixed.
>> 
>> We have a struct sigaction.  We've set the sa_flags member to a value that
>> includes SA_SIGINFO.  That means the 3 argument sa_sigaction handler is
>> supposed to be invoked.
>> 
>> We're storing the SR_handler (cast to a value matching the type of the
>> sa_handler member of the sigaction). This is "working" purely by accident.
>> Apparently on all POSIX platforms we support, the sa_handler and sa_sigaction
>> occupy the same memory (being in a union, which is permitted by the spec).
>> 
>> The signature for SR_handler should be changed from
>> void SR_handler(int, siginfo_t*, ucontext_t*)
>> to
>> void SR_handler(int, siginfo_t*, void*)
>> and adjust the code to deal with the change to the type of the 3rd parameter.
>> 
>> Then we can just assign the sa_sigaction member to SR_handler without any casts.
>
> But this is how POSIX specifies it: `sigaction.sa_handler` is declared as `void(*) (int)` - so that is what we have to use when storing the handler address. But the handler itself has to be the three arg version because that is how it will be called.

Oh! Sorry I wasn't reading the `sigaction` definition properly I missed it contains two "handler" slots and we are using the wrong one!

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

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


From xuelei at openjdk.org  Mon Oct 10 05:22:09 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 10 Oct 2022 05:22:09 GMT
Subject: RFR: 8295010: EC limbs addition and subtraction limit
Message-ID: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>

Hi,

May I have this update reviewed?  With this update, the result will be always reduced in EC limbs addition and subtraction operations in the JDK implementation.

In the current implementation, the EC limbs addition and subtraction result is not reduced before the value is returned.  This behavior is different from multiplication and square.  To get it right, a maximum addition limit is introduced for EC limbs addition and subtraction.  If the limit is reached, an exception will be thrown so as to indicate an EC implementation problem.  The exception is not recoverable from the viewpoint of an application.

The design is error prone as the EC implementation code must be carefully checked so that the limit cannot reach. If a reach is noticed, a reduce operation would have to be hard-coded additionally. In the FieldGen.java implementation, the limit can only be 1 or 2 as the implementation code is only able to handle 2.  But the FieldGen.java does not really check if 1 or 2 really works for the specific filed generation parameters.

The design impact the performance as well. Because of this limit, the maximum limb size is 28 bits for 2 max adding limit. Otherwise there are integer (long) overflow issues. For example for 256 bits curves, 10 limbs are required for 28-bit limb size; and 9 limbs for 29-bit size. By reducing 1 limbs from 10 to 9, the Signature performance could get improved by 20%.

In the IntegerPolynomial class description, it is said "All IntegerPolynomial implementations allow at most one addition before multiplication. Additions after that will result in an ArithmeticException." It's too strict to follow without exam the code very carefully. Indeed, the implementation does not really follow the spec, and 2 addition may be allowed.

It would be nice if there is no addition limit, and then we are free from these issues. It is doable by reducing the limbs in the adding and subtraction operations, as other operations as multiplication. And then the code related to the limit is not necessary any longer. The code can do any many additions as required.

The benchmark for ECDSA Signature is checked in order to see how much the performance could be impacted. Here are the benchmark numbers before the patch applied:

Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
Signatures.sign               64  thrpt   15  1414.463 ?  9.616  ops/s
Signatures.sign              512  thrpt   15  1409.023 ? 14.636  ops/s
Signatures.sign             2048  thrpt   15  1414.488 ?  4.728  ops/s
Signatures.sign            16384  thrpt   15  1385.685 ?  4.476  ops/s


and here are the numbers with this patch applied:

Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
Signatures.sign               64  thrpt   15  1293.658 ?  8.358  ops/s
Signatures.sign              512  thrpt   15  1298.404 ?  4.344  ops/s
Signatures.sign             2048  thrpt   15  1289.732 ? 19.748  ops/s
Signatures.sign            16384  thrpt   15  1278.980 ? 13.483  ops/s


>From the numbers, it looks like the performance impact is about 10%.  However, the performance impact could get rewarded by using less limbs.  For examples for secp256r1, I updated the limbs from [10 to 9 for integer operations](https://github.com/openjdk/jdk/pull/10398), and run the benchmark together with this patch, I could see the performance improvement as follow:

Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
Signatures.sign               64  thrpt   15  1578.568 ? 11.000  ops/s
Signatures.sign              512  thrpt   15  1596.058 ?  4.184  ops/s
Signatures.sign             2048  thrpt   15  1591.519 ?  6.444  ops/s
Signatures.sign            16384  thrpt   15  1563.480 ?  6.837  ops/s
``` 

The following are numbers for secp256r1 key generation, without this patch:

Benchmark                      Mode  Cnt     Score   Error  Units
KeyPairGenerators.keyPairGen  thrpt   15  1531.026 ? 9.869  ops/s


With this patch:

Benchmark                      Mode  Cnt     Score    Error  Units
KeyPairGenerators.keyPairGen  thrpt   15  1367.162 ? 50.322  ops/s


with improved limbs (from 10 to 9):

Benchmark                      Mode  Cnt     Score    Error  Units
KeyPairGenerators.keyPairGen  thrpt   15  1713.097 ? 8.003  ops/s

If considering this PR together with [PR for JDK-8294248](https://github.com/openjdk/jdk/pull/10398), performance improvement could be expected for EC crypto primitives.

Thanks,
Xuelei

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

Commit messages:
 - add the key pair generation bench code
 - remove tabs
 - 8295010: EC limbs addition and subtraction limit

Changes: https://git.openjdk.org/jdk/pull/10624/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10624&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295010
  Stats: 256 lines in 13 files changed: 128 ins; 94 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/10624.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10624/head:pull/10624

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


From dzhang at openjdk.org  Mon Oct 10 06:39:21 2022
From: dzhang at openjdk.org (Dingli Zhang)
Date: Mon, 10 Oct 2022 06:39:21 GMT
Subject: RFR: 8295033: hsdis configure error when cross-compiling with
 --with-binutils-src
Message-ID: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>

I built hsdis with the following parameters from source code of binutils while cross-compiling:

--with-hsdis=binutils \
--with-binutils-src=/home/dingli/jdk-tools/binutils-2.38


But configure will exit with the following error:

checking whether we are cross compiling... configure: error: in `/home/dingli/jdk-tools/binutils-2.38-src':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
configure: Automatic building of binutils failed on configure. Try building it manually
configure: error: Cannot continue
configure exiting with result code 1


The reason for the error is that binutils wants to be configured with --host during cross-compilation. So we can determine if we are currently cross-compiling and add the --host parameter to binutils_target:

diff --git a/make/autoconf/lib-hsdis.m4 b/make/autoconf/lib-hsdis.m4
index d72bbf6df32..dddc1cf6a4d 100644
--- a/make/autoconf/lib-hsdis.m4
+++ b/make/autoconf/lib-hsdis.m4
@@ -175,7 +175,11 @@ AC_DEFUN([LIB_BUILD_BINUTILS],
       fi
     else
       binutils_cc="$CC $SYSROOT_CFLAGS"
- binutils_target=""
+ if test "x$host" = "x$build"; then
+ binutils_target=""
+ else
+ binutils_target="--host=$host"
+ fi
     fi
     binutils_cflags="$binutils_cflags $MACHINE_FLAG $JVM_PICFLAG $C_O_FLAG_NORM"


In the meantime, I removed some useless code about hsdis-demo because hsdis-demo.c was removed in [JDK-8275128](https://bugs.openjdk.org/browse/JDK-8275128) .

## Testing:

- cross compile for RISC-V on x86_64

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

Commit messages:
 - Remove useless code related to hsdis-demo.c in Makefile
 - Add hsdis-src support for cross-compile

Changes: https://git.openjdk.org/jdk/pull/10628/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10628&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295033
  Stats: 14 lines in 2 files changed: 4 ins; 8 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10628.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10628/head:pull/10628

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


From shade at openjdk.org  Mon Oct 10 12:09:51 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Oct 2022 12:09:51 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code
In-Reply-To: <iYezptZ6KPvk3Atzbvuhs-QRWd9uuS6WyrEq4MiOHGE=.94287867-eebd-494a-b97d-6d944c911edc@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <iYezptZ6KPvk3Atzbvuhs-QRWd9uuS6WyrEq4MiOHGE=.94287867-eebd-494a-b97d-6d944c911edc@github.com>
Message-ID: <gw8Po8np2WcQ2_wRwJVx9lFeIbgl5ivTMaByaFHoJno=.f80c365c-29f4-4458-89cc-8f9a0e82e243@github.com>

On Sun, 9 Oct 2022 05:39:26 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:
>
> make/hotspot/lib/CompileJvm.gmk line 147:
> 
>> 145: # Now set up the actual compilation of the main hotspot native library
>> 146: 
>> 147: # TODO: Should merge once JDK-8294314 is in.
> 
> Left-over comment should be removed.

I shall, once JDK-8294314 integrates. I am keeping those build changes to force a merge conflict.

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

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


From djelinski at openjdk.org  Mon Oct 10 12:13:57 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 10 Oct 2022 12:13:57 GMT
Subject: RFR: 8295010: EC limbs addition and subtraction limit
In-Reply-To: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
Message-ID: <N5AS7hNT4XpvMjQnvFILMwf0Pt1d81x-gGveYpBWPd0=.4812c26d-f930-4852-87e5-f99af5ddf198@github.com>

On Sun, 9 Oct 2022 06:53:19 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?  With this update, the result will be always reduced in EC limbs addition and subtraction operations in the JDK implementation.
> 
> In the current implementation, the EC limbs addition and subtraction result is not reduced before the value is returned.  This behavior is different from multiplication and square.  To get it right, a maximum addition limit is introduced for EC limbs addition and subtraction.  If the limit is reached, an exception will be thrown so as to indicate an EC implementation problem.  The exception is not recoverable from the viewpoint of an application.
> 
> The design is error prone as the EC implementation code must be carefully checked so that the limit cannot reach. If a reach is noticed, a reduce operation would have to be hard-coded additionally. In the FieldGen.java implementation, the limit can only be 1 or 2 as the implementation code is only able to handle 2.  But the FieldGen.java does not really check if 1 or 2 really works for the specific filed generation parameters.
> 
> The design impact the performance as well. Because of this limit, the maximum limb size is 28 bits for 2 max adding limit. Otherwise there are integer (long) overflow issues. For example for 256 bits curves, 10 limbs are required for 28-bit limb size; and 9 limbs for 29-bit size. By reducing 1 limbs from 10 to 9, the Signature performance could get improved by 20%.
> 
> In the IntegerPolynomial class description, it is said "All IntegerPolynomial implementations allow at most one addition before multiplication. Additions after that will result in an ArithmeticException." It's too strict to follow without exam the code very carefully. Indeed, the implementation does not really follow the spec, and 2 addition may be allowed.
> 
> It would be nice if there is no addition limit, and then we are free from these issues. It is doable by reducing the limbs in the adding and subtraction operations, as other operations as multiplication. And then the code related to the limit is not necessary any longer. The code can do any many additions as required.
> 
> The benchmark for ECDSA Signature is checked in order to see how much the performance could be impacted. Here are the benchmark numbers before the patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1414.463 ?  9.616  ops/s
> Signatures.sign              512  thrpt   15  1409.023 ? 14.636  ops/s
> Signatures.sign             2048  thrpt   15  1414.488 ?  4.728  ops/s
> Signatures.sign            16384  thrpt   15  1385.685 ?  4.476  ops/s
> 
> 
> and here are the numbers with this patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1293.658 ?  8.358  ops/s
> Signatures.sign              512  thrpt   15  1298.404 ?  4.344  ops/s
> Signatures.sign             2048  thrpt   15  1289.732 ? 19.748  ops/s
> Signatures.sign            16384  thrpt   15  1278.980 ? 13.483  ops/s
> 
> 
> From the numbers, it looks like the performance impact is about 10%.  However, the performance impact could get rewarded by using less limbs.  For examples for secp256r1, I updated the limbs from [10 to 9 for integer operations](https://github.com/openjdk/jdk/pull/10398), and run the benchmark together with this patch, I could see the performance improvement as follow:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1578.568 ? 11.000  ops/s
> Signatures.sign              512  thrpt   15  1596.058 ?  4.184  ops/s
> Signatures.sign             2048  thrpt   15  1591.519 ?  6.444  ops/s
> Signatures.sign            16384  thrpt   15  1563.480 ?  6.837  ops/s
> ``` 
> 
> The following are numbers for secp256r1 key generation, without this patch:
> 
> Benchmark                      Mode  Cnt     Score   Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1531.026 ? 9.869  ops/s
> 
> 
> With this patch:
> 
> Benchmark                      Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1367.162 ? 50.322  ops/s
> 
> 
> with improved limbs (from 10 to 9):
> 
> Benchmark                      Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1713.097 ? 8.003  ops/s
> 
> If considering this PR together with [PR for JDK-8294248](https://github.com/openjdk/jdk/pull/10398), performance improvement could be expected for EC crypto primitives.
> 
> Thanks,
> Xuelei

That's a pretty significant performance degradation (8%?), and as far as I could tell, it will affect all EC and XEC implementations. On the other hand, #10398 only improves performance of P256. I'm not sure that's a tradeoff we want to make.

IMO working with setReduced is not that bad; we always invoke the same set of operations in the same sequence, so if we forget to reduce a number before multiplying, every EC operation will fail. Could we introduce just enough reduce / setReduced calls to make P256 work reliably with 9 limbs? What impact would it have on P384?

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

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


From shade at openjdk.org  Mon Oct 10 12:23:02 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Oct 2022 12:23:02 GMT
Subject: RFR: 8294956: GHA: qemu-debootstrap is deprecated,
 use the regular one
In-Reply-To: <ZcPgKX3J833gjePzrTbgItCXisdY4LLIC5514owFfxo=.d149b11a-45d1-4188-b0fb-294d35fae925@github.com>
References: <ZcPgKX3J833gjePzrTbgItCXisdY4LLIC5514owFfxo=.d149b11a-45d1-4188-b0fb-294d35fae925@github.com>
Message-ID: <wuDFE9xMK9XKyCO1ZwteL420qESv2NTsdMmtPKezw3k=.f8282225-e950-4fd2-a413-eb9921ed9637@github.com>

On Fri, 7 Oct 2022 17:13:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> On current Ubuntu systems, qemu-debootstrap is deprecated. It prints the warning messages like:
> 
> 
> $ sudo qemu-debootstrap --arch=arm64 --verbose --include=fakeroot,symlinks,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng-dev --resolve-deps bullseye aarch64-sysroot https://httpredir.debian.org/debian/
> ...
> W: qemu-debootstrap is deprecated. Please use regular debootstrap directly

Checked that GHA logs do not contain warnings. Looks safe.

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

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


From shade at openjdk.org  Mon Oct 10 12:23:03 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Oct 2022 12:23:03 GMT
Subject: Integrated: 8294956: GHA: qemu-debootstrap is deprecated,
 use the regular one
In-Reply-To: <ZcPgKX3J833gjePzrTbgItCXisdY4LLIC5514owFfxo=.d149b11a-45d1-4188-b0fb-294d35fae925@github.com>
References: <ZcPgKX3J833gjePzrTbgItCXisdY4LLIC5514owFfxo=.d149b11a-45d1-4188-b0fb-294d35fae925@github.com>
Message-ID: <3A1aUzfQ_AbuqPeYXF54UYkYdQW0jxJInMw6uwF7U10=.d330fa89-15ab-49fc-a028-07e299fab11e@github.com>

On Fri, 7 Oct 2022 17:13:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> On current Ubuntu systems, qemu-debootstrap is deprecated. It prints the warning messages like:
> 
> 
> $ sudo qemu-debootstrap --arch=arm64 --verbose --include=fakeroot,symlinks,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng-dev --resolve-deps bullseye aarch64-sysroot https://httpredir.debian.org/debian/
> ...
> W: qemu-debootstrap is deprecated. Please use regular debootstrap directly

This pull request has now been integrated.

Changeset: c5f462e8
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c5f462e83b85ec53ec395622063a5b131aaf0827
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8294956: GHA: qemu-debootstrap is deprecated, use the regular one

Reviewed-by: erikj

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

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


From shade at openjdk.org  Mon Oct 10 12:32:39 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Oct 2022 12:32:39 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
Message-ID: <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>

> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:

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 four additional commits since the last revision:

 - Naming
 - Redo using the proper signatures
 - Merge branch 'master' into JDK-8294594-warning-cast-function-type-signals
 - Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10494/files
  - new: https://git.openjdk.org/jdk/pull/10494/files/2ca21e2a..c469e840

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10494&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10494&range=00-01

  Stats: 14704 lines in 421 files changed: 10039 ins; 3141 del; 1524 mod
  Patch: https://git.openjdk.org/jdk/pull/10494.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10494/head:pull/10494

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


From shade at openjdk.org  Mon Oct 10 12:32:41 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Oct 2022 12:32:41 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <I3ESJ8EIT8yXtevTGqeOQJVjgj9al7rqAMDVaD17LcE=.af674e89-edfe-4b84-aaa5-88ce92561a32@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <t1X4oiPfM2ZDNQPceadU5bsr1Kg5VQWppWYjWVeHVHI=.14ae324c-b439-4b75-8c64-5c5e33e7d915@github.com>
 <I3ESJ8EIT8yXtevTGqeOQJVjgj9al7rqAMDVaD17LcE=.af674e89-edfe-4b84-aaa5-88ce92561a32@github.com>
Message-ID: <fNhrkwJvEgI6KbtawXuiMs7N9hDaLThkaTYQmdRjzaI=.2512c593-209d-46a1-9c01-ef57bda747d4@github.com>

On Sun, 9 Oct 2022 01:40:29 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/os/posix/signals_posix.cpp line 1727:
>> 
>>> 1725:   // Set up signal handler for suspend/resume
>>> 1726:   act.sa_flags = SA_RESTART|SA_SIGINFO;
>>> 1727:   act.sa_handler = CAST_FROM_FN_PTR(sa_handler_t, SR_handler);
>> 
>> The underlying cast in the macro seems a little odd for this situation but if it appeases the compiler then that is fine.
>
> No, don't do this.  The code is just wrong, and should be fixed.
> 
> We have a struct sigaction.  We've set the sa_flags member to a value that
> includes SA_SIGINFO.  That means the 3 argument sa_sigaction handler is
> supposed to be invoked.
> 
> We're storing the SR_handler (cast to a value matching the type of the
> sa_handler member of the sigaction). This is "working" purely by accident.
> Apparently on all POSIX platforms we support, the sa_handler and sa_sigaction
> occupy the same memory (being in a union, which is permitted by the spec).
> 
> The signature for SR_handler should be changed from
> void SR_handler(int, siginfo_t*, ucontext_t*)
> to
> void SR_handler(int, siginfo_t*, void*)
> and adjust the code to deal with the change to the type of the 3rd parameter.
> 
> Then we can just assign the sa_sigaction member to SR_handler without any casts.

This is an excellent catch, @kimbarrett! I think I missed it the same way David did: I completely missed there is `sa_handler` and `sa_sigaction`! Re-done this in new commits.

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

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


From shade at openjdk.org  Mon Oct 10 12:44:57 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Oct 2022 12:44:57 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <jpL-bb0C1xWA3yIZaALPQCGpur2GSoUZx4lPhvTZrik=.d1b8ab36-653c-49a5-a531-4817ec0585df@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <_vNpHQsYGB0Em5NjD1plwOpmcDcDIqf1T0i7gOj4nKs=.3a01519f-5f75-4805-8b9a-4230d1a31204@github.com>
 <jpL-bb0C1xWA3yIZaALPQCGpur2GSoUZx4lPhvTZrik=.d1b8ab36-653c-49a5-a531-4817ec0585df@github.com>
Message-ID: <9jSmtB93I6PqKwew8D1kiLHK-AR2DiSn1NbWlUBpivs=.72a241dc-9cb6-4d57-abaf-b49153e4a360@github.com>

On Sun, 9 Oct 2022 02:57:36 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> test/hotspot/gtest/runtime/test_signals.cpp line 49:
>> 
>>> 47:   static void check_handlers() {
>>> 48:     struct sigaction act, old_SIGFPE_act, old_SIGILL_act;
>>> 49:     act.sa_handler = CAST_FROM_FN_PTR(sa_handler_t, sig_handler);
>> 
>> This is similarly wrong code that should be fixed instead of doing weird casting dances.  The problem here is that sig_handler has the wrong signature.  It should be just `void sig_handler(int)`.  Fix that and not casts needed.
>
> This one is even worse than the other.  Here we're installing a handler function taking 3 arguments in such a way that it will only be called with one.  Weee!

:facepalm:

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

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


From erikj at openjdk.org  Mon Oct 10 12:53:54 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 10 Oct 2022 12:53:54 GMT
Subject: RFR: 8295033: hsdis configure error when cross-compiling with
 --with-binutils-src
In-Reply-To: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
References: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
Message-ID: <CPL2m66D-FBivDUdNOBwDDdgAPU-Rd-JHK2mWxzsX9c=.5f5fcf4c-cf6e-48b6-b13a-8f4903296f33@github.com>

On Mon, 10 Oct 2022 06:32:09 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> I built hsdis with the following parameters from source code of binutils while cross-compiling:
> 
> --with-hsdis=binutils \
> --with-binutils-src=/home/dingli/jdk-tools/binutils-2.38
> 
> 
> But configure will exit with the following error:
> 
> checking whether we are cross compiling... configure: error: in `/home/dingli/jdk-tools/binutils-2.38-src':
> configure: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details
> configure: Automatic building of binutils failed on configure. Try building it manually
> configure: error: Cannot continue
> configure exiting with result code 1
> 
> 
> The reason for the error is that binutils wants to be configured with --host during cross-compilation. So we can determine if we are currently cross-compiling and add the --host parameter to binutils_target:
> 
> diff --git a/make/autoconf/lib-hsdis.m4 b/make/autoconf/lib-hsdis.m4
> index d72bbf6df32..dddc1cf6a4d 100644
> --- a/make/autoconf/lib-hsdis.m4
> +++ b/make/autoconf/lib-hsdis.m4
> @@ -175,7 +175,11 @@ AC_DEFUN([LIB_BUILD_BINUTILS],
>        fi
>      else
>        binutils_cc="$CC $SYSROOT_CFLAGS"
> -      binutils_target=""
> +      if test "x$host" = "x$build"; then
> +        binutils_target=""
> +      else
> +        binutils_target="--host=$host"
> +      fi
>      fi
>      binutils_cflags="$binutils_cflags $MACHINE_FLAG $JVM_PICFLAG $C_O_FLAG_NORM"
>  
> 
> 
> In the meantime, I removed some useless code about hsdis-demo because hsdis-demo.c was removed in [JDK-8275128](https://bugs.openjdk.org/browse/JDK-8275128) .
> 
> ## Testing:
> 
> - cross compile for RISC-V on x86_64

Build changes look ok to me.

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

Marked as reviewed by erikj (Reviewer).

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


From dzhang at openjdk.org  Mon Oct 10 13:36:46 2022
From: dzhang at openjdk.org (Dingli Zhang)
Date: Mon, 10 Oct 2022 13:36:46 GMT
Subject: RFR: 8295033: hsdis configure error when cross-compiling with
 --with-binutils-src
In-Reply-To: <CPL2m66D-FBivDUdNOBwDDdgAPU-Rd-JHK2mWxzsX9c=.5f5fcf4c-cf6e-48b6-b13a-8f4903296f33@github.com>
References: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
 <CPL2m66D-FBivDUdNOBwDDdgAPU-Rd-JHK2mWxzsX9c=.5f5fcf4c-cf6e-48b6-b13a-8f4903296f33@github.com>
Message-ID: <zwdBe4rC7pET8WBhlR-xUmD4zHs03xQiZIBF_rBvfCg=.0878d8d9-4150-42c6-930c-cd96bd856e1a@github.com>

On Mon, 10 Oct 2022 12:50:08 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> I built hsdis with the following parameters from source code of binutils while cross-compiling:
>> 
>> --with-hsdis=binutils \
>> --with-binutils-src=/home/dingli/jdk-tools/binutils-2.38
>> 
>> 
>> But configure will exit with the following error:
>> 
>> checking whether we are cross compiling... configure: error: in `/home/dingli/jdk-tools/binutils-2.38-src':
>> configure: error: cannot run C compiled programs.
>> If you meant to cross compile, use `--host'.
>> See `config.log' for more details
>> configure: Automatic building of binutils failed on configure. Try building it manually
>> configure: error: Cannot continue
>> configure exiting with result code 1
>> 
>> 
>> The reason for the error is that binutils wants to be configured with --host during cross-compilation. So we can determine if we are currently cross-compiling and add the --host parameter to binutils_target:
>> 
>> diff --git a/make/autoconf/lib-hsdis.m4 b/make/autoconf/lib-hsdis.m4
>> index d72bbf6df32..dddc1cf6a4d 100644
>> --- a/make/autoconf/lib-hsdis.m4
>> +++ b/make/autoconf/lib-hsdis.m4
>> @@ -175,7 +175,11 @@ AC_DEFUN([LIB_BUILD_BINUTILS],
>>        fi
>>      else
>>        binutils_cc="$CC $SYSROOT_CFLAGS"
>> -      binutils_target=""
>> +      if test "x$host" = "x$build"; then
>> +        binutils_target=""
>> +      else
>> +        binutils_target="--host=$host"
>> +      fi
>>      fi
>>      binutils_cflags="$binutils_cflags $MACHINE_FLAG $JVM_PICFLAG $C_O_FLAG_NORM"
>>  
>> 
>> 
>> In the meantime, I removed some useless code about hsdis-demo because hsdis-demo.c was removed in [JDK-8275128](https://bugs.openjdk.org/browse/JDK-8275128) .
>> 
>> ## Testing:
>> 
>> - cross compile for RISC-V on x86_64
>
> Build changes look ok to me.

@erikj79 Thanks for the review!

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

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


From xuelei at openjdk.org  Mon Oct 10 14:57:56 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 10 Oct 2022 14:57:56 GMT
Subject: RFR: 8295010: EC limbs addition and subtraction limit
In-Reply-To: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
Message-ID: <9okcLWyRTZycrqqn3fItFL7uuYnxaqSAuHz27hyvw0U=.a09b79b6-2fcc-48ee-901c-a8ceeab97456@github.com>

On Sun, 9 Oct 2022 06:53:19 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?  With this update, the result will be always reduced in EC limbs addition and subtraction operations in the JDK implementation.
> 
> In the current implementation, the EC limbs addition and subtraction result is not reduced before the value is returned.  This behavior is different from multiplication and square.  To get it right, a maximum addition limit is introduced for EC limbs addition and subtraction.  If the limit is reached, an exception will be thrown so as to indicate an EC implementation problem.  The exception is not recoverable from the viewpoint of an application.
> 
> The design is error prone as the EC implementation code must be carefully checked so that the limit cannot reach. If a reach is noticed, a reduce operation would have to be hard-coded additionally. In the FieldGen.java implementation, the limit can only be 1 or 2 as the implementation code is only able to handle 2.  But the FieldGen.java does not really check if 1 or 2 really works for the specific filed generation parameters.
> 
> The design impact the performance as well. Because of this limit, the maximum limb size is 28 bits for 2 max adding limit. Otherwise there are integer (long) overflow issues. For example for 256 bits curves, 10 limbs are required for 28-bit limb size; and 9 limbs for 29-bit size. By reducing 1 limbs from 10 to 9, the Signature performance could get improved by 20%.
> 
> In the IntegerPolynomial class description, it is said "All IntegerPolynomial implementations allow at most one addition before multiplication. Additions after that will result in an ArithmeticException." It's too strict to follow without exam the code very carefully. Indeed, the implementation does not really follow the spec, and 2 addition may be allowed.
> 
> It would be nice if there is no addition limit, and then we are free from these issues. It is doable by reducing the limbs in the adding and subtraction operations, as other operations as multiplication. And then the code related to the limit is not necessary any longer. The code can do any many additions as required.
> 
> The benchmark for ECDSA Signature is checked in order to see how much the performance could be impacted. Here are the benchmark numbers before the patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1414.463 ?  9.616  ops/s
> Signatures.sign              512  thrpt   15  1409.023 ? 14.636  ops/s
> Signatures.sign             2048  thrpt   15  1414.488 ?  4.728  ops/s
> Signatures.sign            16384  thrpt   15  1385.685 ?  4.476  ops/s
> 
> 
> and here are the numbers with this patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1293.658 ?  8.358  ops/s
> Signatures.sign              512  thrpt   15  1298.404 ?  4.344  ops/s
> Signatures.sign             2048  thrpt   15  1289.732 ? 19.748  ops/s
> Signatures.sign            16384  thrpt   15  1278.980 ? 13.483  ops/s
> 
> 
> From the numbers, it looks like the performance impact is about 10%.  However, the performance impact could get rewarded by using less limbs.  For examples for secp256r1, I updated the limbs from [10 to 9 for integer operations](https://github.com/openjdk/jdk/pull/10398), and run the benchmark together with this patch, I could see the performance improvement as follow:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1578.568 ? 11.000  ops/s
> Signatures.sign              512  thrpt   15  1596.058 ?  4.184  ops/s
> Signatures.sign             2048  thrpt   15  1591.519 ?  6.444  ops/s
> Signatures.sign            16384  thrpt   15  1563.480 ?  6.837  ops/s
> ``` 
> 
> The following are numbers for secp256r1 key generation, without this patch:
> 
> Benchmark                      Mode  Cnt     Score   Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1531.026 ? 9.869  ops/s
> 
> 
> With this patch:
> 
> Benchmark                      Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1367.162 ? 50.322  ops/s
> 
> 
> with improved limbs (from 10 to 9):
> 
> Benchmark                      Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1713.097 ? 8.003  ops/s
> 
> If considering this PR together with [PR for JDK-8294248](https://github.com/openjdk/jdk/pull/10398), performance improvement could be expected for EC crypto primitives.
> 
> Thanks,
> Xuelei

Thank you for looking into the PR.

> On the other hand, #10398 only improves performance of P256. I'm not sure that's a tradeoff we want to make.

If I get it right, all supported curves could be improved by 1 limb in implementation.

> Could we introduce just enough reduce / setReduced calls to make P256 work reliably with 9 limbs?

Yes, it is doable as well by limit the maxAdd to 1 in the implementation.  This approach needs to adjust the code accordingly, just as what we did to make maxAdd 2 works.   The performance impact is limited.  This approach has better performance (about 20%) if reducing the limbs to 9 for P256.

> IMO working with setReduced is not that bad;

Hm, I may be focus too much on the error-prone design.  Let me check what it could be by limit the maxAdd to 1 always.

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

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


From jwaters at openjdk.org  Mon Oct 10 15:24:37 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 10 Oct 2022 15:24:37 GMT
Subject: RFR: 8295070: Introduce more target combinations for compiler flags
Message-ID: <alUrMJ4fQy9z3dKu3BideMeVLc7DhlUbd_IWx79mZVU=.74eb4654-00b0-497f-9450-e87d9b435e37@github.com>

Several parts of the make system in the JDK has large parts of cluttered if branches dedicated to setting flags for the specific compiler used in the build. This could be more neatly accomplished by instead adding more target combinations in SetupNativeCompilation so the callsite can more cleanly specify which OS and compiler it desires to set these flags for. The change currently includes:

DISABLED_WARNINGS (including per file warnings), CFLAGS/CXXFLAGS and LDFLAGS: Compiler-then-OS (The priority shown reflects how the flags depend more so on the compiler)
LIBS: OS-then-Compiler, as libraries typically vary based on the system being compiled for

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

Commit messages:
 - Document changes
 - Extra combinations for CFLAGS, DISABLED_WARNINGS, LDFLAGS and LIBS

Changes: https://git.openjdk.org/jdk/pull/10634/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10634&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295070
  Stats: 47 lines in 1 file changed: 37 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10634.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10634/head:pull/10634

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


From jwaters at openjdk.org  Mon Oct 10 15:26:41 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 10 Oct 2022 15:26:41 GMT
Subject: RFR: 8295070: Introduce more target combinations for compiler
 flags [v2]
In-Reply-To: <alUrMJ4fQy9z3dKu3BideMeVLc7DhlUbd_IWx79mZVU=.74eb4654-00b0-497f-9450-e87d9b435e37@github.com>
References: <alUrMJ4fQy9z3dKu3BideMeVLc7DhlUbd_IWx79mZVU=.74eb4654-00b0-497f-9450-e87d9b435e37@github.com>
Message-ID: <vHiAdUi3KxStERzUTw7BEKXwBn1cbdQrYt-jIouX1-E=.bbfce6b5-361e-488b-a39d-4e69287115a8@github.com>

> Several parts of the make system in the JDK has large parts of cluttered if branches dedicated to setting flags for the specific compiler used in the build. This could be more neatly accomplished by instead adding more target combinations in SetupNativeCompilation so the callsite can more cleanly specify which OS and compiler it desires to set these flags for. The change currently includes:
> 
> DISABLED_WARNINGS (including per file warnings), CFLAGS/CXXFLAGS and LDFLAGS: Compiler-then-OS (The priority shown reflects how the flags depend more so on the compiler)
> LIBS: OS-then-Compiler, as libraries typically vary based on the system being compiled for

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Missing newline

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10634/files
  - new: https://git.openjdk.org/jdk/pull/10634/files/391f4ec6..0244a6e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10634&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10634&range=00-01

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

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


From jwaters at openjdk.org  Mon Oct 10 15:29:16 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 10 Oct 2022 15:29:16 GMT
Subject: RFR: 8295070: Introduce more target combinations for compiler
 flags [v3]
In-Reply-To: <alUrMJ4fQy9z3dKu3BideMeVLc7DhlUbd_IWx79mZVU=.74eb4654-00b0-497f-9450-e87d9b435e37@github.com>
References: <alUrMJ4fQy9z3dKu3BideMeVLc7DhlUbd_IWx79mZVU=.74eb4654-00b0-497f-9450-e87d9b435e37@github.com>
Message-ID: <dEz1C15HnujCTsRaRZ_0G9DV_Z0fyun60AzAfq04hNw=.92012cfb-2a75-4d7f-b062-b5b40b102b4e@github.com>

> Several parts of the make system in the JDK has large parts of cluttered if branches dedicated to setting flags for the specific compiler used in the build. This could be more neatly accomplished by instead adding more target combinations in SetupNativeCompilation so the callsite can more cleanly specify which OS and compiler it desires to set these flags for. The change currently includes:
> 
> DISABLED_WARNINGS (including per file warnings), CFLAGS/CXXFLAGS and LDFLAGS: Compiler-then-OS (The priority shown reflects how the flags depend more so on the compiler)
> LIBS: OS-then-Compiler, as libraries typically vary based on the system being compiled for

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Extra spacing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10634/files
  - new: https://git.openjdk.org/jdk/pull/10634/files/0244a6e1..9c394a77

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10634&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10634&range=01-02

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

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


From erikj at openjdk.org  Mon Oct 10 17:42:11 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 10 Oct 2022 17:42:11 GMT
Subject: RFR: 8295070: Introduce more target combinations for compiler
 flags [v3]
In-Reply-To: <dEz1C15HnujCTsRaRZ_0G9DV_Z0fyun60AzAfq04hNw=.92012cfb-2a75-4d7f-b062-b5b40b102b4e@github.com>
References: <alUrMJ4fQy9z3dKu3BideMeVLc7DhlUbd_IWx79mZVU=.74eb4654-00b0-497f-9450-e87d9b435e37@github.com>
 <dEz1C15HnujCTsRaRZ_0G9DV_Z0fyun60AzAfq04hNw=.92012cfb-2a75-4d7f-b062-b5b40b102b4e@github.com>
Message-ID: <zHE96psmrBEI8Jc6qDzP3VQrZHWn41hbtCsa6aPmi00=.b019a466-5107-4c0d-903d-54586025cf5a@github.com>

On Mon, 10 Oct 2022 15:29:16 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Several parts of the make system in the JDK has large parts of cluttered if branches dedicated to setting flags for the specific compiler used in the build. This could be more neatly accomplished by instead adding more target combinations in SetupNativeCompilation so the callsite can more cleanly specify which OS and compiler it desires to set these flags for. The change currently includes:
>> 
>> DISABLED_WARNINGS (including per file warnings), CFLAGS/CXXFLAGS and LDFLAGS: Compiler-then-OS (The priority shown reflects how the flags depend more so on the compiler)
>> LIBS: OS-then-Compiler, as libraries typically vary based on the system being compiled for
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extra spacing

I think this looks good, but if Magnus is around to comment I would value his input.

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

Marked as reviewed by erikj (Reviewer).

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


From kbarrett at openjdk.org  Mon Oct 10 19:59:51 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 10 Oct 2022 19:59:51 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
Message-ID: <-rK8vM7SBOjsiYzFMMNmAtXNimDEmw6jyiYeRdXQOAk=.dcb5e445-1e7d-456a-9469-76f45e53a334@github.com>

On Mon, 10 Oct 2022 12:32:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:
>
> 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 four additional commits since the last revision:
> 
>  - Naming
>  - Redo using the proper signatures
>  - Merge branch 'master' into JDK-8294594-warning-cast-function-type-signals
>  - Fix

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From xuelei at openjdk.org  Mon Oct 10 23:01:17 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 10 Oct 2022 23:01:17 GMT
Subject: RFR: 8295010: EC limbs addition and subtraction limit
In-Reply-To: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
Message-ID: <5na2V7FIy4G-YTiXKJcvedTts0lgkZHheSx7eMyXKtg=.815c3626-98e8-47f0-bcf5-1875fd0f3077@github.com>

On Sun, 9 Oct 2022 06:53:19 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?  With this update, the result will be always reduced in EC limbs addition and subtraction operations in the JDK implementation.
> 
> In the current implementation, the EC limbs addition and subtraction result is not reduced before the value is returned.  This behavior is different from multiplication and square.  To get it right, a maximum addition limit is introduced for EC limbs addition and subtraction.  If the limit is reached, an exception will be thrown so as to indicate an EC implementation problem.  The exception is not recoverable from the viewpoint of an application.
> 
> The design is error prone as the EC implementation code must be carefully checked so that the limit cannot reach. If a reach is noticed, a reduce operation would have to be hard-coded additionally. In the FieldGen.java implementation, the limit can only be 1 or 2 as the implementation code is only able to handle 2.  But the FieldGen.java does not really check if 1 or 2 really works for the specific filed generation parameters.
> 
> The design impact the performance as well. Because of this limit, the maximum limb size is 28 bits for 2 max adding limit. Otherwise there are integer (long) overflow issues. For example for 256 bits curves, 10 limbs are required for 28-bit limb size; and 9 limbs for 29-bit size. By reducing 1 limbs from 10 to 9, the Signature performance could get improved by 20%.
> 
> In the IntegerPolynomial class description, it is said "All IntegerPolynomial implementations allow at most one addition before multiplication. Additions after that will result in an ArithmeticException." It's too strict to follow without exam the code very carefully. Indeed, the implementation does not really follow the spec, and 2 addition may be allowed.
> 
> It would be nice if there is no addition limit, and then we are free from these issues. It is doable by reducing the limbs in the adding and subtraction operations, as other operations as multiplication. And then the code related to the limit is not necessary any longer. The code can do any many additions as required.
> 
> The benchmark for ECDSA Signature is checked in order to see how much the performance could be impacted. Here are the benchmark numbers before the patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1414.463 ?  9.616  ops/s
> Signatures.sign              512  thrpt   15  1409.023 ? 14.636  ops/s
> Signatures.sign             2048  thrpt   15  1414.488 ?  4.728  ops/s
> Signatures.sign            16384  thrpt   15  1385.685 ?  4.476  ops/s
> 
> 
> and here are the numbers with this patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1293.658 ?  8.358  ops/s
> Signatures.sign              512  thrpt   15  1298.404 ?  4.344  ops/s
> Signatures.sign             2048  thrpt   15  1289.732 ? 19.748  ops/s
> Signatures.sign            16384  thrpt   15  1278.980 ? 13.483  ops/s
> 
> 
> From the numbers, it looks like the performance impact is about 10%.  However, the performance impact could get rewarded by using less limbs.  For examples for secp256r1, I updated the limbs from [10 to 9 for integer operations](https://github.com/openjdk/jdk/pull/10398), and run the benchmark together with this patch, I could see the performance improvement as follow:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1578.568 ? 11.000  ops/s
> Signatures.sign              512  thrpt   15  1596.058 ?  4.184  ops/s
> Signatures.sign             2048  thrpt   15  1591.519 ?  6.444  ops/s
> Signatures.sign            16384  thrpt   15  1563.480 ?  6.837  ops/s
> ``` 
> 
> The following are numbers for secp256r1 key generation, without this patch:
> 
> Benchmark                      Mode  Cnt     Score   Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1531.026 ? 9.869  ops/s
> 
> 
> With this patch:
> 
> Benchmark                      Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1367.162 ? 50.322  ops/s
> 
> 
> with improved limbs (from 10 to 9):
> 
> Benchmark                      Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1713.097 ? 8.003  ops/s
> 
> If considering this PR together with [PR for JDK-8294248](https://github.com/openjdk/jdk/pull/10398), performance improvement could be expected for EC crypto primitives.
> 
> Thanks,
> Xuelei

Close it for now.  I will open it again when I have a solution for better performance.

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

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


From xuelei at openjdk.org  Mon Oct 10 23:01:19 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 10 Oct 2022 23:01:19 GMT
Subject: Withdrawn: 8295010: EC limbs addition and subtraction limit
In-Reply-To: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
Message-ID: <TqtW2Lf6ZDNbox8kzJ5qV77mPy949LD9jcPNIR3dgZc=.426bc5a9-ebcf-4b10-9dc8-9795e52587f2@github.com>

On Sun, 9 Oct 2022 06:53:19 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?  With this update, the result will be always reduced in EC limbs addition and subtraction operations in the JDK implementation.
> 
> In the current implementation, the EC limbs addition and subtraction result is not reduced before the value is returned.  This behavior is different from multiplication and square.  To get it right, a maximum addition limit is introduced for EC limbs addition and subtraction.  If the limit is reached, an exception will be thrown so as to indicate an EC implementation problem.  The exception is not recoverable from the viewpoint of an application.
> 
> The design is error prone as the EC implementation code must be carefully checked so that the limit cannot reach. If a reach is noticed, a reduce operation would have to be hard-coded additionally. In the FieldGen.java implementation, the limit can only be 1 or 2 as the implementation code is only able to handle 2.  But the FieldGen.java does not really check if 1 or 2 really works for the specific filed generation parameters.
> 
> The design impact the performance as well. Because of this limit, the maximum limb size is 28 bits for 2 max adding limit. Otherwise there are integer (long) overflow issues. For example for 256 bits curves, 10 limbs are required for 28-bit limb size; and 9 limbs for 29-bit size. By reducing 1 limbs from 10 to 9, the Signature performance could get improved by 20%.
> 
> In the IntegerPolynomial class description, it is said "All IntegerPolynomial implementations allow at most one addition before multiplication. Additions after that will result in an ArithmeticException." It's too strict to follow without exam the code very carefully. Indeed, the implementation does not really follow the spec, and 2 addition may be allowed.
> 
> It would be nice if there is no addition limit, and then we are free from these issues. It is doable by reducing the limbs in the adding and subtraction operations, as other operations as multiplication. And then the code related to the limit is not necessary any longer. The code can do any many additions as required.
> 
> The benchmark for ECDSA Signature is checked in order to see how much the performance could be impacted. Here are the benchmark numbers before the patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1414.463 ?  9.616  ops/s
> Signatures.sign              512  thrpt   15  1409.023 ? 14.636  ops/s
> Signatures.sign             2048  thrpt   15  1414.488 ?  4.728  ops/s
> Signatures.sign            16384  thrpt   15  1385.685 ?  4.476  ops/s
> 
> 
> and here are the numbers with this patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1293.658 ?  8.358  ops/s
> Signatures.sign              512  thrpt   15  1298.404 ?  4.344  ops/s
> Signatures.sign             2048  thrpt   15  1289.732 ? 19.748  ops/s
> Signatures.sign            16384  thrpt   15  1278.980 ? 13.483  ops/s
> 
> 
> From the numbers, it looks like the performance impact is about 10%.  However, the performance impact could get rewarded by using less limbs.  For examples for secp256r1, I updated the limbs from [10 to 9 for integer operations](https://github.com/openjdk/jdk/pull/10398), and run the benchmark together with this patch, I could see the performance improvement as follow:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1578.568 ? 11.000  ops/s
> Signatures.sign              512  thrpt   15  1596.058 ?  4.184  ops/s
> Signatures.sign             2048  thrpt   15  1591.519 ?  6.444  ops/s
> Signatures.sign            16384  thrpt   15  1563.480 ?  6.837  ops/s
> ``` 
> 
> The following are numbers for secp256r1 key generation, without this patch:
> 
> Benchmark                      Mode  Cnt     Score   Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1531.026 ? 9.869  ops/s
> 
> 
> With this patch:
> 
> Benchmark                      Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1367.162 ? 50.322  ops/s
> 
> 
> with improved limbs (from 10 to 9):
> 
> Benchmark                      Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1713.097 ? 8.003  ops/s
> 
> If considering this PR together with [PR for JDK-8294248](https://github.com/openjdk/jdk/pull/10398), performance improvement could be expected for EC crypto primitives.
> 
> Thanks,
> Xuelei

This pull request has been closed without being integrated.

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

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


From dholmes at openjdk.org  Tue Oct 11 01:51:20 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Oct 2022 01:51:20 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
Message-ID: <VKINUWO-QctcaSiPS-qsrBVsepqtihEDqJFKNBJrXa0=.d0e02d97-c30c-40a9-9d99-b9b0a1c92e89@github.com>

On Mon, 10 Oct 2022 12:32:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:
>
> 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 four additional commits since the last revision:
> 
>  - Naming
>  - Redo using the proper signatures
>  - Merge branch 'master' into JDK-8294594-warning-cast-function-type-signals
>  - Fix

Fix looks good as far as it goes (can't believe I didn't see what was going on here!) - but `os::signal` is still broken as it uses `sa_handler` instead of `sa_sigaction`.

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

Changes requested by dholmes (Reviewer).

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


From djelinski at openjdk.org  Tue Oct 11 07:31:19 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 11 Oct 2022 07:31:19 GMT
Subject: RFR: 8294997: Improve ECC math operations
Message-ID: <GY_kY9Ie7r40qRXHahsJnz1Xyxi2o1LM2cbxGccsWx0=.8a8b7251-7420-4337-8b62-bb00abbb60d1@github.com>

This patch rewrites some BigInteger and curve point operations used in EC calculations:
- coefficient * 2^power is equivalent to coefficient << power
- number mod 2^n is equivalent to number & (2^n-1)
- pair of IntegerModuloP operations:
t2 = t1+t1
t1 = t1+t2
is equivalent to t1=t1*3, which is now implemented more efficiently.

Benchmarked the code using not-yet-merged benchmark from #10544. Results on x64 before:

Benchmark ? ? ? ?(messageLength) ? Mode ?Cnt ? ? Score ? Error ?Units
Signatures.sign ? ? ? ? ? ? ? 64 ?thrpt ? 15 ?1578.907 ? 1.522 ?ops/s

After:

Benchmark ? ? ? ?(messageLength) ? Mode ?Cnt ? ? Score ? Error ?Units
Signatures.sign ? ? ? ? ? ? ? 64 ?thrpt ? 15 ?1679.495 ? 3.883 ?ops/s

Greatest part of the improvement is related to ECOperations changes; BigInteger modifications provide only marginal gains (1584 ops/s without ECOperations changes).

Tier1-3 tests continue to pass.

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

Commit messages:
 - Remove commented out code
 - Simplify multiplication
 - Simplify mod
 - Simplify math
 - Remove biginteger modulo operation

Changes: https://git.openjdk.org/jdk/pull/10614/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10614&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294997
  Stats: 50 lines in 6 files changed: 2 ins; 23 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/10614.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10614/head:pull/10614

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


From kbarrett at openjdk.org  Tue Oct 11 07:48:31 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 11 Oct 2022 07:48:31 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <VKINUWO-QctcaSiPS-qsrBVsepqtihEDqJFKNBJrXa0=.d0e02d97-c30c-40a9-9d99-b9b0a1c92e89@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
 <VKINUWO-QctcaSiPS-qsrBVsepqtihEDqJFKNBJrXa0=.d0e02d97-c30c-40a9-9d99-b9b0a1c92e89@github.com>
Message-ID: <5c7KNhNgs7Fg2ZNwr6X72zfqytPBvq5n_Vr8AvrX30o=.659b507d-f75f-4490-b5ea-6c6f50b15374@github.com>

On Tue, 11 Oct 2022 01:47:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Fix looks good as far as it goes (can't believe I didn't see what was going on here!) - but `os::signal` is still broken as it uses `sa_handler` instead of `sa_sigaction`.

Yikes!  I think this change should proceed as is, and `os::signal` should be looked at as a new issue.  That looks messy :(

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

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


From shade at openjdk.org  Tue Oct 11 08:13:24 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Oct 2022 08:13:24 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <5c7KNhNgs7Fg2ZNwr6X72zfqytPBvq5n_Vr8AvrX30o=.659b507d-f75f-4490-b5ea-6c6f50b15374@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
 <VKINUWO-QctcaSiPS-qsrBVsepqtihEDqJFKNBJrXa0=.d0e02d97-c30c-40a9-9d99-b9b0a1c92e89@github.com>
 <5c7KNhNgs7Fg2ZNwr6X72zfqytPBvq5n_Vr8AvrX30o=.659b507d-f75f-4490-b5ea-6c6f50b15374@github.com>
Message-ID: <NGvQZdueqf_R_0CXHQRGZhiEESfdokg1yeqnutgKFXo=.ed4c4aad-c9aa-4330-a1b7-232240eb9d14@github.com>

On Tue, 11 Oct 2022 07:44:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > Fix looks good as far as it goes (can't believe I didn't see what was going on here!) - but `os::signal` is still broken as it uses `sa_handler` instead of `sa_sigaction`.
> 
> Yikes! I think this change should proceed as is, and `os::signal` should be looked at as a new issue. That looks messy :(

There is no rush, because we are waiting for another build system change to drop. 

Why can't we do the same thing we did for `SR_handler` in `SR_initialize`?


@@ -864,7 +864,7 @@ void* os::signal(int signal_number, void* handler) {
   remove_error_signals_from_set(&(sigAct.sa_mask));
 
   sigAct.sa_flags   = SA_RESTART|SA_SIGINFO;
-  sigAct.sa_handler = CAST_TO_FN_PTR(sa_handler_t, handler);
+  sigAct.sa_sigaction = CAST_TO_FN_PTR(sa_sigaction_t, handler);
 
   if (sigaction(signal_number, &sigAct, &oldSigAct)) {
     // -1 means registration failed


It matches what we should do for `SIG_INFO` flag, and as Kim said, it is still likely yields the same code as `sa_handler` and `sa_sigaction` are probably the same on currently supported systems.

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

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


From kbarrett at openjdk.org  Tue Oct 11 08:31:46 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 11 Oct 2022 08:31:46 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <NGvQZdueqf_R_0CXHQRGZhiEESfdokg1yeqnutgKFXo=.ed4c4aad-c9aa-4330-a1b7-232240eb9d14@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
 <VKINUWO-QctcaSiPS-qsrBVsepqtihEDqJFKNBJrXa0=.d0e02d97-c30c-40a9-9d99-b9b0a1c92e89@github.com>
 <5c7KNhNgs7Fg2ZNwr6X72zfqytPBvq5n_Vr8AvrX30o=.659b507d-f75f-4490-b5ea-6c6f50b15374@github.com>
 <NGvQZdueqf_R_0CXHQRGZhiEESfdokg1yeqnutgKFXo=.ed4c4aad-c9aa-4330-a1b7-232240eb9d14@github.com>
Message-ID: <7DnCphTnvHF8WA3ki9dLidoxEe64MRWZZpx9u9rIfSY=.6333dff8-ef6a-4aec-8e53-2e14e89b8be4@github.com>

On Tue, 11 Oct 2022 08:11:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > > Fix looks good as far as it goes (can't believe I didn't see what was going on here!) - but `os::signal` is still broken as it uses `sa_handler` instead of `sa_sigaction`.
> > 
> > 
> > Yikes! I think this change should proceed as is, and `os::signal` should be looked at as a new issue. That looks messy :(
> 
> There is no rush, because we are waiting for another build system change to drop.
> 
> Why can't we do the same thing we did for `SR_handler` in `SR_initialize`?
> 
> ```
> @@ -864,7 +864,7 @@ void* os::signal(int signal_number, void* handler) {
>    remove_error_signals_from_set(&(sigAct.sa_mask));
>  
>    sigAct.sa_flags   = SA_RESTART|SA_SIGINFO;
> -  sigAct.sa_handler = CAST_TO_FN_PTR(sa_handler_t, handler);
> +  sigAct.sa_sigaction = CAST_TO_FN_PTR(sa_sigaction_t, handler);
>  
>    if (sigaction(signal_number, &sigAct, &oldSigAct)) {
>      // -1 means registration failed
> ```
> 
> It matches what we should do for `SIG_INFO` flag, and as Kim said, it is still likely yields the same code as `sa_handler` and `sa_sigaction` are probably the same on currently supported systems.

For POSIX we expect the handler argument for os::signal to be a sigaction handler (taking 3 arguments).  For Windows we expect os::signal to take a 1 argument handler, since Windows seemingly doesn't support the sigaction stuff.  How is that a portability layer?

So all of the calls are going to need their handler functions examined.  In at least one use (in os_windows), the UserHandler function takes 3 arguments though only uses one, and is called with only one.

Looking at where os::signal is called, it's not clear it needs to be in os, and given the inconsistent expectations it probably shouldn't be.  All calls are in posix-specific or windows-specific files.  I'd suggest removing os::signal entirely, and having windows code use ::signal and posix code use ::sigaction.  Maybe with some convenience wrappers around each, but those wrappers are windows-specific or posix-specific and never the twain shall meet.

That all seems to me like it would be better to separate from this change, keeping this one nice and simple.

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

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


From shade at openjdk.org  Tue Oct 11 08:40:24 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Oct 2022 08:40:24 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <7DnCphTnvHF8WA3ki9dLidoxEe64MRWZZpx9u9rIfSY=.6333dff8-ef6a-4aec-8e53-2e14e89b8be4@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
 <VKINUWO-QctcaSiPS-qsrBVsepqtihEDqJFKNBJrXa0=.d0e02d97-c30c-40a9-9d99-b9b0a1c92e89@github.com>
 <5c7KNhNgs7Fg2ZNwr6X72zfqytPBvq5n_Vr8AvrX30o=.659b507d-f75f-4490-b5ea-6c6f50b15374@github.com>
 <NGvQZdueqf_R_0CXHQRGZhiEESfdokg1yeqnutgKFXo=.ed4c4aad-c9aa-4330-a1b7-232240eb9d14@github.com>
 <7DnCphTnvHF8WA3ki9dLidoxEe64MRWZZpx9u9rIfSY=.6333dff8-ef6a-4aec-8e53-2e14e89b8be4@github.com>
Message-ID: <JgXGBX5vNzKs2x1uHC0caBx2mvyfjPwNxAibAc3FCtA=.125ef708-513c-46fb-a2f5-6a9c4d9b703f@github.com>

On Tue, 11 Oct 2022 08:28:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> For POSIX we expect the handler argument for os::signal to be a sigaction handler (taking 3 arguments). For Windows we expect os::signal to take a 1 argument handler, since Windows seemingly doesn't support the sigaction stuff. How is that a portability layer?

D'oh.

> That all seems to me like it would be better to separate from this change, keeping this one nice and simple.

Agreed.

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

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


From kbarrett at openjdk.org  Tue Oct 11 08:58:23 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 11 Oct 2022 08:58:23 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <JgXGBX5vNzKs2x1uHC0caBx2mvyfjPwNxAibAc3FCtA=.125ef708-513c-46fb-a2f5-6a9c4d9b703f@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
 <VKINUWO-QctcaSiPS-qsrBVsepqtihEDqJFKNBJrXa0=.d0e02d97-c30c-40a9-9d99-b9b0a1c92e89@github.com>
 <5c7KNhNgs7Fg2ZNwr6X72zfqytPBvq5n_Vr8AvrX30o=.659b507d-f75f-4490-b5ea-6c6f50b15374@github.com>
 <NGvQZdueqf_R_0CXHQRGZhiEESfdokg1yeqnutgKFXo=.ed4c4aad-c9aa-4330-a1b7-232240eb9d14@github.com>
 <7DnCphTnvHF8WA3ki9dLidoxEe64MRWZZpx9u9rIfSY=.6333dff8-ef6a-4aec-8e53-2e14e89b8be4@github.com>
 <JgXGBX5vNzKs2x1uHC0caBx2mvyfjPwNxAibAc3FCtA=.125ef708-513c-46fb-a2f5-6a9c4d9b703f@github.com>
Message-ID: <iRIbXyZEMCfifFjBA5mbpnqGWiNnjOone8Z81u2v_FM=.89c46b19-08e1-4458-9460-3d53c48e7ecb@github.com>

On Tue, 11 Oct 2022 08:37:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > For POSIX we expect the handler argument for os::signal to be a sigaction handler (taking 3 arguments). For Windows we expect os::signal to take a 1 argument handler, since Windows seemingly doesn't support the sigaction stuff. How is that a portability layer?

I'll file a bug report for this.

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

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


From kbarrett at openjdk.org  Tue Oct 11 09:16:33 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 11 Oct 2022 09:16:33 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <iRIbXyZEMCfifFjBA5mbpnqGWiNnjOone8Z81u2v_FM=.89c46b19-08e1-4458-9460-3d53c48e7ecb@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
 <VKINUWO-QctcaSiPS-qsrBVsepqtihEDqJFKNBJrXa0=.d0e02d97-c30c-40a9-9d99-b9b0a1c92e89@github.com>
 <5c7KNhNgs7Fg2ZNwr6X72zfqytPBvq5n_Vr8AvrX30o=.659b507d-f75f-4490-b5ea-6c6f50b15374@github.com>
 <NGvQZdueqf_R_0CXHQRGZhiEESfdokg1yeqnutgKFXo=.ed4c4aad-c9aa-4330-a1b7-232240eb9d14@github.com>
 <7DnCphTnvHF8WA3ki9dLidoxEe64MRWZZpx9u9rIfSY=.6333dff8-ef6a-4aec-8e53-2e14e89b8be4@github.com>
 <JgXGBX5vNzKs2x1uHC0caBx2mvyfjPwNxAibAc3FCtA=.125ef708-513c-46fb-a2f5-6a9c4d9b703f@github.com>
 <iRIbXyZEMCfifFjBA5mbpnqGWiNnjOone8Z81u2v_FM=.89c46b19-08e1-4458-9460-3d53c48e7ecb@github.com>
Message-ID: <Smx5R78KX2yKKXaoVgTJpS1mEaDVLGMv2KO462Enlpc=.c7f4b7a7-ad23-4353-9d00-1fa9e25afebd@github.com>

On Tue, 11 Oct 2022 08:54:42 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > > For POSIX we expect the handler argument for os::signal to be a sigaction handler (taking 3 arguments). For Windows we expect os::signal to take a 1 argument handler, since Windows seemingly doesn't support the sigaction stuff. How is that a portability layer?
> 
> I'll file a bug report for this.

https://bugs.openjdk.org/browse/JDK-8295125

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

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


From shade at openjdk.org  Tue Oct 11 09:55:25 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Oct 2022 09:55:25 GMT
Subject: RFR: 8295033: hsdis configure error when cross-compiling with
 --with-binutils-src
In-Reply-To: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
References: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
Message-ID: <aYppPS6EFMw3c4vY3iz_w1AEOPFeguoiwPjA0uXMrOc=.422799bc-974f-46c0-8deb-63d0b588966d@github.com>

On Mon, 10 Oct 2022 06:32:09 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> I built hsdis with the following parameters from source code of binutils while cross-compiling:
> 
> --with-hsdis=binutils \
> --with-binutils-src=/home/dingli/jdk-tools/binutils-2.38
> 
> 
> But configure will exit with the following error:
> 
> checking whether we are cross compiling... configure: error: in `/home/dingli/jdk-tools/binutils-2.38-src':
> configure: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details
> configure: Automatic building of binutils failed on configure. Try building it manually
> configure: error: Cannot continue
> configure exiting with result code 1
> 
> 
> The reason for the error is that binutils wants to be configured with --host during cross-compilation. So we can determine if we are currently cross-compiling and add the --host parameter to binutils_target:
> 
> diff --git a/make/autoconf/lib-hsdis.m4 b/make/autoconf/lib-hsdis.m4
> index d72bbf6df32..dddc1cf6a4d 100644
> --- a/make/autoconf/lib-hsdis.m4
> +++ b/make/autoconf/lib-hsdis.m4
> @@ -175,7 +175,11 @@ AC_DEFUN([LIB_BUILD_BINUTILS],
>        fi
>      else
>        binutils_cc="$CC $SYSROOT_CFLAGS"
> -      binutils_target=""
> +      if test "x$host" = "x$build"; then
> +        binutils_target=""
> +      else
> +        binutils_target="--host=$host"
> +      fi
>      fi
>      binutils_cflags="$binutils_cflags $MACHINE_FLAG $JVM_PICFLAG $C_O_FLAG_NORM"
>  
> 
> 
> In the meantime, I removed some useless code about hsdis-demo because hsdis-demo.c was removed in [JDK-8275128](https://bugs.openjdk.org/browse/JDK-8275128) .
> 
> ## Testing:
> 
> - cross compile for RISC-V on x86_64

I think it requires a bit more fiddling for other arches:


$ CXX=aarch64-linux-gnu-g++ CC=aarch64-linux-gnu-gcc sh ./configure --with-debug-level=fastdebug --openjdk-target=aarch64-linux-gnu --with-sysroot=/chroots/arm64 --with-boot-jdk=/home/shade/Install/jdk19u-ea --with-hsdis=binutils --with-binutils-src=binutils-2.39
...

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

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


From shade at openjdk.org  Tue Oct 11 10:11:26 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Oct 2022 10:11:26 GMT
Subject: RFR: 8295033: hsdis configure error when cross-compiling with
 --with-binutils-src
In-Reply-To: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
References: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
Message-ID: <k2jkxel8q8eybj1dYxUUiTphWQXjCz3wTFZOdLV7RWk=.b5967932-9c61-4bd8-967d-2540e3b72957@github.com>

On Mon, 10 Oct 2022 06:32:09 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> I built hsdis with the following parameters from source code of binutils while cross-compiling:
> 
> --with-hsdis=binutils \
> --with-binutils-src=/home/dingli/jdk-tools/binutils-2.38
> 
> 
> But configure will exit with the following error:
> 
> checking whether we are cross compiling... configure: error: in `/home/dingli/jdk-tools/binutils-2.38-src':
> configure: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details
> configure: Automatic building of binutils failed on configure. Try building it manually
> configure: error: Cannot continue
> configure exiting with result code 1
> 
> 
> The reason for the error is that binutils wants to be configured with --host during cross-compilation. So we can determine if we are currently cross-compiling and add the --host parameter to binutils_target:
> 
> diff --git a/make/autoconf/lib-hsdis.m4 b/make/autoconf/lib-hsdis.m4
> index d72bbf6df32..dddc1cf6a4d 100644
> --- a/make/autoconf/lib-hsdis.m4
> +++ b/make/autoconf/lib-hsdis.m4
> @@ -175,7 +175,11 @@ AC_DEFUN([LIB_BUILD_BINUTILS],
>        fi
>      else
>        binutils_cc="$CC $SYSROOT_CFLAGS"
> -      binutils_target=""
> +      if test "x$host" = "x$build"; then
> +        binutils_target=""
> +      else
> +        binutils_target="--host=$host"
> +      fi
>      fi
>      binutils_cflags="$binutils_cflags $MACHINE_FLAG $JVM_PICFLAG $C_O_FLAG_NORM"
>  
> 
> 
> In the meantime, I removed some useless code about hsdis-demo because hsdis-demo.c was removed in [JDK-8275128](https://bugs.openjdk.org/browse/JDK-8275128) .
> 
> ## Testing:
> 
> - cross compile for RISC-V on x86_64

I think checking it like this would be more robust?


      if test "x$conf_openjdk_target" != "x"; then
        binutils_target="--host=$conf_openjdk_target"
      else
        binutils_target=""
      fi


This allows me to produce AArch64 hsdis:


$ file ./build/linux-aarch64-server-fastdebug/support/hsdis/libhsdis.so
./build/linux-aarch64-server-fastdebug/support/hsdis/libhsdis.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[sha1]=c709135f1f2ef2bee329550044fabea35e33ebb3, not stripped

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

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


From shade at openjdk.org  Tue Oct 11 10:43:23 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Oct 2022 10:43:23 GMT
Subject: RFR: 8295033: hsdis configure error when cross-compiling with
 --with-binutils-src
In-Reply-To: <k2jkxel8q8eybj1dYxUUiTphWQXjCz3wTFZOdLV7RWk=.b5967932-9c61-4bd8-967d-2540e3b72957@github.com>
References: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
 <k2jkxel8q8eybj1dYxUUiTphWQXjCz3wTFZOdLV7RWk=.b5967932-9c61-4bd8-967d-2540e3b72957@github.com>
Message-ID: <tCguV2JDu1NdFibYeJq_TDI_T_Ve3On8X2PBirEZnzo=.bdda6cc8-be27-417e-8eb3-738497528c3f@github.com>

On Tue, 11 Oct 2022 10:09:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I think checking it like this would be more robust?
> 
> ```
>       if test "x$conf_openjdk_target" != "x"; then
>         binutils_target="--host=$conf_openjdk_target"
>       else
>         binutils_target=""
>       fi
> ```

Also need to pass `AR` to binutils build and configure with `AR=riscv64-linux-gnu-ar` to get the RISC-V cross-build back:


diff --git a/make/autoconf/lib-hsdis.m4 b/make/autoconf/lib-hsdis.m4
index d72bbf6df32..7be49fbf778 100644
--- a/make/autoconf/lib-hsdis.m4
+++ b/make/autoconf/lib-hsdis.m4
@@ -175,12 +175,16 @@ AC_DEFUN([LIB_BUILD_BINUTILS],
       fi
     else
       binutils_cc="$CC $SYSROOT_CFLAGS"
-      binutils_target=""
+      if test "x$conf_openjdk_target" != "x"; then
+        binutils_target="--host=$conf_openjdk_target"
+      else
+        binutils_target=""
+      fi
     fi
     binutils_cflags="$binutils_cflags $MACHINE_FLAG $JVM_PICFLAG $C_O_FLAG_NORM"
 
     AC_MSG_NOTICE([Running binutils configure])
-    AC_MSG_NOTICE([configure command line: ./configure --disable-nls CFLAGS="$binutils_cflags" CC="$binutils_cc" $binutils_target])
+    AC_MSG_NOTICE([configure command line: ./configure --disable-nls CFLAGS="$binutils_cflags" CC="$binutils_cc" AR="$AR" $binutils_target])
     saved_dir=`pwd`
     cd "$BINUTILS_SRC"
     ./configure --disable-nls CFLAGS="$binutils_cflags" CC="$binutils_cc" $binutils_target


This allows building hsdis on following arches with server ports:


i686-linux-gnu
x86_64-linux-gnu
aarch64-linux-gnu
powerpc64le-linux-gnu
s390x-linux-gnu
arm-linux-gnueabihf
riscv64-linux-gnu

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

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


From ihse at openjdk.org  Tue Oct 11 10:51:29 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 11 Oct 2022 10:51:29 GMT
Subject: RFR: 8295033: hsdis configure error when cross-compiling with
 --with-binutils-src
In-Reply-To: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
References: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
Message-ID: <dRqcO1dL44H2qOlMflfgvdpur2RNJnw6P1LNlZZ6PLw=.f1b0a846-1659-48af-9773-97761aad6cda@github.com>

On Mon, 10 Oct 2022 06:32:09 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> I built hsdis with the following parameters from source code of binutils while cross-compiling:
> 
> --with-hsdis=binutils \
> --with-binutils-src=/home/dingli/jdk-tools/binutils-2.38
> 
> 
> But configure will exit with the following error:
> 
> checking whether we are cross compiling... configure: error: in `/home/dingli/jdk-tools/binutils-2.38-src':
> configure: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details
> configure: Automatic building of binutils failed on configure. Try building it manually
> configure: error: Cannot continue
> configure exiting with result code 1
> 
> 
> The reason for the error is that binutils wants to be configured with --host during cross-compilation. So we can determine if we are currently cross-compiling and add the --host parameter to binutils_target:
> 
> diff --git a/make/autoconf/lib-hsdis.m4 b/make/autoconf/lib-hsdis.m4
> index d72bbf6df32..dddc1cf6a4d 100644
> --- a/make/autoconf/lib-hsdis.m4
> +++ b/make/autoconf/lib-hsdis.m4
> @@ -175,7 +175,11 @@ AC_DEFUN([LIB_BUILD_BINUTILS],
>        fi
>      else
>        binutils_cc="$CC $SYSROOT_CFLAGS"
> -      binutils_target=""
> +      if test "x$host" = "x$build"; then
> +        binutils_target=""
> +      else
> +        binutils_target="--host=$host"
> +      fi
>      fi
>      binutils_cflags="$binutils_cflags $MACHINE_FLAG $JVM_PICFLAG $C_O_FLAG_NORM"
>  
> 
> 
> In the meantime, I removed some useless code about hsdis-demo because hsdis-demo.c was removed in [JDK-8275128](https://bugs.openjdk.org/browse/JDK-8275128) .
> 
> ## Testing:
> 
> - cross compile for RISC-V on x86_64

Looks good to me.

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

Marked as reviewed by ihse (Reviewer).

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


From shade at openjdk.org  Tue Oct 11 11:15:23 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Oct 2022 11:15:23 GMT
Subject: RFR: 8295033: hsdis configure error when cross-compiling with
 --with-binutils-src
In-Reply-To: <tCguV2JDu1NdFibYeJq_TDI_T_Ve3On8X2PBirEZnzo=.bdda6cc8-be27-417e-8eb3-738497528c3f@github.com>
References: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
 <k2jkxel8q8eybj1dYxUUiTphWQXjCz3wTFZOdLV7RWk=.b5967932-9c61-4bd8-967d-2540e3b72957@github.com>
 <tCguV2JDu1NdFibYeJq_TDI_T_Ve3On8X2PBirEZnzo=.bdda6cc8-be27-417e-8eb3-738497528c3f@github.com>
Message-ID: <uIU0Mgtcn9h2v2NpoGN3-gcI9zUTyRJWAmCLcaR7SDs=.469288f5-cd46-4c41-af03-04b451259840@github.com>

On Tue, 11 Oct 2022 10:41:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This allows building hsdis on following arches with server ports:

Also these Zero ports produce `hsdis` binaries as well (they are not as useful there, though, because no JIT compilers are done there):


alpha-linux-gnu
arm-linux-gnueabi
m68k-linux-gnu
mips64el-linux-gnuabi64
mipsel-linux-gnu
powerpc-linux-gnu
sh4-linux-gnu
sparc64-linux-gnu

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

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


From ihse at openjdk.org  Tue Oct 11 11:37:04 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 11 Oct 2022 11:37:04 GMT
Subject: RFR: 8295033: hsdis configure error when cross-compiling with
 --with-binutils-src
In-Reply-To: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
References: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
Message-ID: <7RkL4CT3ovVO7aMm9y08k0sLDg1mK2TouRRGRHc97M8=.60c4178e-0e2d-439e-8342-0e5603004e17@github.com>

On Mon, 10 Oct 2022 06:32:09 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> I built hsdis with the following parameters from source code of binutils while cross-compiling:
> 
> --with-hsdis=binutils \
> --with-binutils-src=/home/dingli/jdk-tools/binutils-2.38
> 
> 
> But configure will exit with the following error:
> 
> checking whether we are cross compiling... configure: error: in `/home/dingli/jdk-tools/binutils-2.38-src':
> configure: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details
> configure: Automatic building of binutils failed on configure. Try building it manually
> configure: error: Cannot continue
> configure exiting with result code 1
> 
> 
> The reason for the error is that binutils wants to be configured with --host during cross-compilation. So we can determine if we are currently cross-compiling and add the --host parameter to binutils_target:
> 
> diff --git a/make/autoconf/lib-hsdis.m4 b/make/autoconf/lib-hsdis.m4
> index d72bbf6df32..dddc1cf6a4d 100644
> --- a/make/autoconf/lib-hsdis.m4
> +++ b/make/autoconf/lib-hsdis.m4
> @@ -175,7 +175,11 @@ AC_DEFUN([LIB_BUILD_BINUTILS],
>        fi
>      else
>        binutils_cc="$CC $SYSROOT_CFLAGS"
> -      binutils_target=""
> +      if test "x$host" = "x$build"; then
> +        binutils_target=""
> +      else
> +        binutils_target="--host=$host"
> +      fi
>      fi
>      binutils_cflags="$binutils_cflags $MACHINE_FLAG $JVM_PICFLAG $C_O_FLAG_NORM"
>  
> 
> 
> In the meantime, I removed some useless code about hsdis-demo because hsdis-demo.c was removed in [JDK-8275128](https://bugs.openjdk.org/browse/JDK-8275128) .
> 
> ## Testing:
> 
> - cross compile for RISC-V on x86_64

Changing my review; we need to take this for another spin.

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

Changes requested by ihse (Reviewer).

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


From ihse at openjdk.org  Tue Oct 11 11:37:07 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 11 Oct 2022 11:37:07 GMT
Subject: RFR: 8295033: hsdis configure error when cross-compiling with
 --with-binutils-src
In-Reply-To: <k2jkxel8q8eybj1dYxUUiTphWQXjCz3wTFZOdLV7RWk=.b5967932-9c61-4bd8-967d-2540e3b72957@github.com>
References: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
 <k2jkxel8q8eybj1dYxUUiTphWQXjCz3wTFZOdLV7RWk=.b5967932-9c61-4bd8-967d-2540e3b72957@github.com>
Message-ID: <zpAAN0djEp4PzD3MZmC6oyYT16X9X5bLrmRUow7CaSc=.8f2fb5e7-bd42-4733-929d-363668d50108@github.com>

On Tue, 11 Oct 2022 10:09:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I think checking it like this would be more robust?
> 
> ```
>       if test "x$conf_openjdk_target" != "x"; then
>         binutils_target="--host=$conf_openjdk_target"
>       else
>         binutils_target=""
>       fi
> ```
> 
> This allows me to produce AArch64 hsdis:
> 
> ```
> $ file ./build/linux-aarch64-server-fastdebug/support/hsdis/libhsdis.so
> ./build/linux-aarch64-server-fastdebug/support/hsdis/libhsdis.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[sha1]=c709135f1f2ef2bee329550044fabea35e33ebb3, not stripped
> ```

Yeah, you're onto something. We should not check the autoconf variables.

I'd even recommend testing for cross compilation like this:

    if test "x$COMPILE_TYPE" = xcross; then
      # ...


We also have a `CROSS_COMPILE_ARCH` which is set to `$OPENJDK_$1_CPU_LEGACY`, but right now I can't say how it relates to `$conf_openjdk_target`. But I'd rather not use the `$conf_...` variables outside the option testing code. If we do need it, and it is not already available, we should "export" it by giving it a separate, uppercase variable name.

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

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


From ihse at openjdk.org  Tue Oct 11 11:40:14 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 11 Oct 2022 11:40:14 GMT
Subject: RFR: 8295033: hsdis configure error when cross-compiling with
 --with-binutils-src
In-Reply-To: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
References: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
Message-ID: <lZvDuxk3uUxRurORyAKxBaKKJJ9_VCDzh63rWySZFzQ=.7ca22270-ab85-426d-aeec-223de1c4e7e9@github.com>

On Mon, 10 Oct 2022 06:32:09 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> I built hsdis with the following parameters from source code of binutils while cross-compiling:
> 
> --with-hsdis=binutils \
> --with-binutils-src=/home/dingli/jdk-tools/binutils-2.38
> 
> 
> But configure will exit with the following error:
> 
> checking whether we are cross compiling... configure: error: in `/home/dingli/jdk-tools/binutils-2.38-src':
> configure: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details
> configure: Automatic building of binutils failed on configure. Try building it manually
> configure: error: Cannot continue
> configure exiting with result code 1
> 
> 
> The reason for the error is that binutils wants to be configured with --host during cross-compilation. So we can determine if we are currently cross-compiling and add the --host parameter to binutils_target:
> 
> diff --git a/make/autoconf/lib-hsdis.m4 b/make/autoconf/lib-hsdis.m4
> index d72bbf6df32..dddc1cf6a4d 100644
> --- a/make/autoconf/lib-hsdis.m4
> +++ b/make/autoconf/lib-hsdis.m4
> @@ -175,7 +175,11 @@ AC_DEFUN([LIB_BUILD_BINUTILS],
>        fi
>      else
>        binutils_cc="$CC $SYSROOT_CFLAGS"
> -      binutils_target=""
> +      if test "x$host" = "x$build"; then
> +        binutils_target=""
> +      else
> +        binutils_target="--host=$host"
> +      fi
>      fi
>      binutils_cflags="$binutils_cflags $MACHINE_FLAG $JVM_PICFLAG $C_O_FLAG_NORM"
>  
> 
> 
> In the meantime, I removed some useless code about hsdis-demo because hsdis-demo.c was removed in [JDK-8275128](https://bugs.openjdk.org/browse/JDK-8275128) .
> 
> ## Testing:
> 
> - cross compile for RISC-V on x86_64

Ok, we already have an exported value for `$host`, which is `$OPENJDK_TARGET_AUTOCONF_NAME`. Also, `$conf_openjdk_target` is used in the wrapper configure script. It is probably leaking into the main generated autoconf script, but it is definitely not supposed to be used there. Instead, it should only be used to setup the `--host=` option to autoconf. So looking for `$host` is fine I suppose, but we should do it using the OPENJDK_TARGET_AUTOCONF_NAME variable.

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

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


From shade at openjdk.org  Tue Oct 11 13:09:14 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Oct 2022 13:09:14 GMT
Subject: RFR: 8295033: hsdis configure error when cross-compiling with
 --with-binutils-src
In-Reply-To: <lZvDuxk3uUxRurORyAKxBaKKJJ9_VCDzh63rWySZFzQ=.7ca22270-ab85-426d-aeec-223de1c4e7e9@github.com>
References: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
 <lZvDuxk3uUxRurORyAKxBaKKJJ9_VCDzh63rWySZFzQ=.7ca22270-ab85-426d-aeec-223de1c4e7e9@github.com>
Message-ID: <e5DT5nP8d-mH8eK1LmZileBLS8Z9_t8yczGUIf1i1Zg=.c7c7cd8e-f3ef-4b60-b472-44528549fbea@github.com>

On Tue, 11 Oct 2022 11:38:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Ok, we already have an exported value for `$host`, which is `$OPENJDK_TARGET_AUTOCONF_NAME`. Also, `$conf_openjdk_target` is used in the wrapper configure script. It is probably leaking into the main generated autoconf script, but it is definitely not supposed to be used there. Instead, it should only be used to setup the `--host=` option to autoconf. So looking for `$host` is fine I suppose, but we should do it using the OPENJDK_TARGET_AUTOCONF_NAME variable.

Quite!

Applying this patch over the PR:


diff --git a/make/autoconf/lib-hsdis.m4 b/make/autoconf/lib-hsdis.m4
index dddc1cf6a4d..72bd08c7108 100644
--- a/make/autoconf/lib-hsdis.m4
+++ b/make/autoconf/lib-hsdis.m4
@@ -175,10 +175,10 @@ AC_DEFUN([LIB_BUILD_BINUTILS],
       fi
     else
       binutils_cc="$CC $SYSROOT_CFLAGS"
-      if test "x$host" = "x$build"; then
-        binutils_target=""
+      if test "x$COMPILE_TYPE" = xcross; then
+        binutils_target="--host=$OPENJDK_TARGET_AUTOCONF_NAME"
       else
-        binutils_target="--host=$host"
+        binutils_target=""
       fi
     fi
     binutils_cflags="$binutils_cflags $MACHINE_FLAG $JVM_PICFLAG $C_O_FLAG_NORM"


...successfully produces the hsdis binaries on all these platforms:


server-release-aarch64-linux-gnu-10
server-release-arm-linux-gnueabihf-10
server-release-i686-linux-gnu-10
server-release-powerpc64le-linux-gnu-10
server-release-powerpc64-linux-gnu-10
server-release-riscv64-linux-gnu-10
server-release-s390x-linux-gnu-10
server-release-x86_64-linux-gnu-10
zero-release-aarch64-linux-gnu-10
zero-release-alpha-linux-gnu-10
zero-release-arm-linux-gnueabi-10
zero-release-arm-linux-gnueabihf-10
zero-release-i686-linux-gnu-10
zero-release-m68k-linux-gnu-10
zero-release-mips64el-linux-gnuabi64-10
zero-release-mipsel-linux-gnu-10
zero-release-powerpc64le-linux-gnu-10
zero-release-powerpc64-linux-gnu-10
zero-release-powerpc-linux-gnu-10
zero-release-riscv64-linux-gnu-10
zero-release-s390x-linux-gnu-10
zero-release-sh4-linux-gnu-10
zero-release-sparc64-linux-gnu-10
zero-release-x86_64-linux-gnu-10


Therefore, I believe this is what we should do and then call it a day. (Then I also need to start building all these hsdis-es at [https://builds.shipilev.net/hsdis/](https://builds.shipilev.net/hsdis/))

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

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


From dholmes at openjdk.org  Tue Oct 11 13:12:13 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Oct 2022 13:12:13 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
Message-ID: <7zK0uy01g7MNXeNK-40g97ir_PCUCKUkSoto8jxEIgA=.da3eb364-3f42-47dd-ab02-960a710a4c0f@github.com>

On Mon, 10 Oct 2022 12:32:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:
>
> 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 four additional commits since the last revision:
> 
>  - Naming
>  - Redo using the proper signatures
>  - Merge branch 'master' into JDK-8294594-warning-cast-function-type-signals
>  - Fix

Okay I agree it makes no sense to have `os::signal` as shared code because you can't use it in a platform independent manner.

I can take that new bug (thanks @kimbarrett ) unless @shipilev  really wants it? :)

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

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


From shade at openjdk.org  Tue Oct 11 13:12:13 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Oct 2022 13:12:13 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <JgXGBX5vNzKs2x1uHC0caBx2mvyfjPwNxAibAc3FCtA=.125ef708-513c-46fb-a2f5-6a9c4d9b703f@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
 <VKINUWO-QctcaSiPS-qsrBVsepqtihEDqJFKNBJrXa0=.d0e02d97-c30c-40a9-9d99-b9b0a1c92e89@github.com>
 <5c7KNhNgs7Fg2ZNwr6X72zfqytPBvq5n_Vr8AvrX30o=.659b507d-f75f-4490-b5ea-6c6f50b15374@github.com>
 <NGvQZdueqf_R_0CXHQRGZhiEESfdokg1yeqnutgKFXo=.ed4c4aad-c9aa-4330-a1b7-232240eb9d14@github.com>
 <7DnCphTnvHF8WA3ki9dLidoxEe64MRWZZpx9u9rIfSY=.6333dff8-ef6a-4aec-8e53-2e14e89b8be4@github.com>
 <JgXGBX5vNzKs2x1uHC0caBx2mvyfjPwNxAibAc3FCtA=.125ef708-513c-46fb-a2f5-6a9c4d9b703f@github.com>
Message-ID: <9k-Cf-C0Ny8c81LyOQakF-rlew2c3nC5mVHnEgL8YQE=.19689a5d-ed54-486d-a683-d60a05f9fe37@github.com>

On Tue, 11 Oct 2022 08:37:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> > > Fix looks good as far as it goes (can't believe I didn't see what was going on here!) - but `os::signal` is still broken as it uses `sa_handler` instead of `sa_sigaction`.
>>> > 
>>> > 
>>> > Yikes! I think this change should proceed as is, and `os::signal` should be looked at as a new issue. That looks messy :(
>>> 
>>> There is no rush, because we are waiting for another build system change to drop.
>>> 
>>> Why can't we do the same thing we did for `SR_handler` in `SR_initialize`?
>>> 
>>> ```
>>> @@ -864,7 +864,7 @@ void* os::signal(int signal_number, void* handler) {
>>>    remove_error_signals_from_set(&(sigAct.sa_mask));
>>>  
>>>    sigAct.sa_flags   = SA_RESTART|SA_SIGINFO;
>>> -  sigAct.sa_handler = CAST_TO_FN_PTR(sa_handler_t, handler);
>>> +  sigAct.sa_sigaction = CAST_TO_FN_PTR(sa_sigaction_t, handler);
>>>  
>>>    if (sigaction(signal_number, &sigAct, &oldSigAct)) {
>>>      // -1 means registration failed
>>> ```
>>> 
>>> It matches what we should do for `SIG_INFO` flag, and as Kim said, it is still likely yields the same code as `sa_handler` and `sa_sigaction` are probably the same on currently supported systems.
>> 
>> For POSIX we expect the handler argument for os::signal to be a sigaction handler (taking 3 arguments).  For Windows we expect os::signal to take a 1 argument handler, since Windows seemingly doesn't support the sigaction stuff.  How is that a portability layer?
>> 
>> So all of the calls are going to need their handler functions examined.  In at least one use (in os_windows), the UserHandler function takes 3 arguments though only uses one, and is called with only one.
>> 
>> Looking at where os::signal is called, it's not clear it needs to be in os, and given the inconsistent expectations it probably shouldn't be.  All calls are in posix-specific or windows-specific files.  I'd suggest removing os::signal entirely, and having windows code use ::signal and posix code use ::sigaction.  Maybe with some convenience wrappers around each, but those wrappers are windows-specific or posix-specific and never the twain shall meet.
>> 
>> That all seems to me like it would be better to separate from this change, keeping this one nice and simple.
>
>> For POSIX we expect the handler argument for os::signal to be a sigaction handler (taking 3 arguments). For Windows we expect os::signal to take a 1 argument handler, since Windows seemingly doesn't support the sigaction stuff. How is that a portability layer?
> 
> D'oh.
> 
>> That all seems to me like it would be better to separate from this change, keeping this one nice and simple.
> 
> Agreed.

> ...unless @shipilev really wants it? :)

No, I do NOT want it :) I'll be happy to test it, though.

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

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


From ihse at openjdk.org  Tue Oct 11 16:00:27 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 11 Oct 2022 16:00:27 GMT
Subject: RFR: 8295033: hsdis configure error when cross-compiling with
 --with-binutils-src
In-Reply-To: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
References: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
Message-ID: <Th_6wXzOl6qV7uq6uTCq2uDpkkhga4YAqkhRRFhVeCU=.243fd956-ec10-4d23-8a33-e54d75a0b8e8@github.com>

On Mon, 10 Oct 2022 06:32:09 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> I built hsdis with the following parameters from source code of binutils while cross-compiling:
> 
> --with-hsdis=binutils \
> --with-binutils-src=/home/dingli/jdk-tools/binutils-2.38
> 
> 
> But configure will exit with the following error:
> 
> checking whether we are cross compiling... configure: error: in `/home/dingli/jdk-tools/binutils-2.38-src':
> configure: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details
> configure: Automatic building of binutils failed on configure. Try building it manually
> configure: error: Cannot continue
> configure exiting with result code 1
> 
> 
> The reason for the error is that binutils wants to be configured with --host during cross-compilation. So we can determine if we are currently cross-compiling and add the --host parameter to binutils_target:
> 
> diff --git a/make/autoconf/lib-hsdis.m4 b/make/autoconf/lib-hsdis.m4
> index d72bbf6df32..dddc1cf6a4d 100644
> --- a/make/autoconf/lib-hsdis.m4
> +++ b/make/autoconf/lib-hsdis.m4
> @@ -175,7 +175,11 @@ AC_DEFUN([LIB_BUILD_BINUTILS],
>        fi
>      else
>        binutils_cc="$CC $SYSROOT_CFLAGS"
> -      binutils_target=""
> +      if test "x$host" = "x$build"; then
> +        binutils_target=""
> +      else
> +        binutils_target="--host=$host"
> +      fi
>      fi
>      binutils_cflags="$binutils_cflags $MACHINE_FLAG $JVM_PICFLAG $C_O_FLAG_NORM"
>  
> 
> 
> In the meantime, I removed some useless code about hsdis-demo because hsdis-demo.c was removed in [JDK-8275128](https://bugs.openjdk.org/browse/JDK-8275128) .
> 
> ## Testing:
> 
> - cross compile for RISC-V on x86_64

Also, I think we can skip the demo Makefile changes from this PR.

In fact, I'm surprised `src/utils/hsdis/Makefile` is still there. I was sure I removed it when  I rewrote the build of hsdis to utilize the normal build system with JDK-8188073. I'd rather open a separate issue and just remove the file.

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

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


From ihse at openjdk.org  Tue Oct 11 16:03:20 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 11 Oct 2022 16:03:20 GMT
Subject: RFR: 8295033: hsdis configure error when cross-compiling with
 --with-binutils-src
In-Reply-To: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
References: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
Message-ID: <sgLxVDkp5AR4a1IwZmknQAKPdRhadfYbnX-GzBJJF2A=.6f224065-b5b5-49da-9177-f5211e3ceaef@github.com>

On Mon, 10 Oct 2022 06:32:09 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> I built hsdis with the following parameters from source code of binutils while cross-compiling:
> 
> --with-hsdis=binutils \
> --with-binutils-src=/home/dingli/jdk-tools/binutils-2.38
> 
> 
> But configure will exit with the following error:
> 
> checking whether we are cross compiling... configure: error: in `/home/dingli/jdk-tools/binutils-2.38-src':
> configure: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details
> configure: Automatic building of binutils failed on configure. Try building it manually
> configure: error: Cannot continue
> configure exiting with result code 1
> 
> 
> The reason for the error is that binutils wants to be configured with --host during cross-compilation. So we can determine if we are currently cross-compiling and add the --host parameter to binutils_target:
> 
> diff --git a/make/autoconf/lib-hsdis.m4 b/make/autoconf/lib-hsdis.m4
> index d72bbf6df32..dddc1cf6a4d 100644
> --- a/make/autoconf/lib-hsdis.m4
> +++ b/make/autoconf/lib-hsdis.m4
> @@ -175,7 +175,11 @@ AC_DEFUN([LIB_BUILD_BINUTILS],
>        fi
>      else
>        binutils_cc="$CC $SYSROOT_CFLAGS"
> -      binutils_target=""
> +      if test "x$host" = "x$build"; then
> +        binutils_target=""
> +      else
> +        binutils_target="--host=$host"
> +      fi
>      fi
>      binutils_cflags="$binutils_cflags $MACHINE_FLAG $JVM_PICFLAG $C_O_FLAG_NORM"
>  
> 
> 
> In the meantime, I removed some useless code about hsdis-demo because hsdis-demo.c was removed in [JDK-8275128](https://bugs.openjdk.org/browse/JDK-8275128) .
> 
> ## Testing:
> 
> - cross compile for RISC-V on x86_64

See https://github.com/openjdk/jdk/pull/10660 ([JDK-8295163](https://bugs.openjdk.org/browse/JDK-8295163)) for the removal of the Makefile.

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

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


From ihse at openjdk.org  Tue Oct 11 16:07:14 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 11 Oct 2022 16:07:14 GMT
Subject: RFR: 8295163: Remove old hsdis Makefile
Message-ID: <tHLL5Hmfit_ciMlOc4lMgGEdgVelb4CeRlVBhcPfrKY=.d9e7b57b-dacf-4368-af56-e1663c039716@github.com>

For some reason the old Makefile for hsdis was not removed when the build was moved into the normal build system in [JDK-8188073](https://bugs.openjdk.org/browse/JDK-8188073). This should be fixed.

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

Commit messages:
 - 8295163: Remove old hsdis Makefile

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

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


From shade at openjdk.org  Tue Oct 11 16:22:12 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Oct 2022 16:22:12 GMT
Subject: RFR: 8295163: Remove old hsdis Makefile
In-Reply-To: <tHLL5Hmfit_ciMlOc4lMgGEdgVelb4CeRlVBhcPfrKY=.d9e7b57b-dacf-4368-af56-e1663c039716@github.com>
References: <tHLL5Hmfit_ciMlOc4lMgGEdgVelb4CeRlVBhcPfrKY=.d9e7b57b-dacf-4368-af56-e1663c039716@github.com>
Message-ID: <fI8jkPWAVEmszCrjCnNG9jM2ETsHGxpuVTAq4oeWmxk=.c944d79d-1810-432b-ad89-caf12779778f@github.com>

On Tue, 11 Oct 2022 16:00:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> For some reason the old Makefile for hsdis was not removed when the build was moved into the normal build system in [JDK-8188073](https://bugs.openjdk.org/browse/JDK-8188073). This should be fixed.

Marked as reviewed by shade (Reviewer).

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

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


From duke at openjdk.org  Tue Oct 11 16:28:12 2022
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 11 Oct 2022 16:28:12 GMT
Subject: RFR: 8294997: Improve ECC math operations
In-Reply-To: <GY_kY9Ie7r40qRXHahsJnz1Xyxi2o1LM2cbxGccsWx0=.8a8b7251-7420-4337-8b62-bb00abbb60d1@github.com>
References: <GY_kY9Ie7r40qRXHahsJnz1Xyxi2o1LM2cbxGccsWx0=.8a8b7251-7420-4337-8b62-bb00abbb60d1@github.com>
Message-ID: <-Bo8rvaYhDcHMXyMX3pHH08SdLVwOIkIw4WL2boLkW8=.259acf33-4b17-491e-9466-cbba4de9482e@github.com>

On Fri, 7 Oct 2022 21:11:39 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch rewrites some BigInteger and curve point operations used in EC calculations:
> - coefficient * 2^power is equivalent to coefficient << power
> - number mod 2^n is equivalent to number & (2^n-1)
> - pair of IntegerModuloP operations:
> t2 = t1+t1
> t1 = t1+t2
> is equivalent to t1=t1*3, which is now implemented more efficiently.
> 
> Benchmarked the code using not-yet-merged benchmark from #10544. Results on x64 before:
> 
> Benchmark ? ? ? ?(messageLength) ? Mode ?Cnt ? ? Score ? Error ?Units
> Signatures.sign ? ? ? ? ? ? ? 64 ?thrpt ? 15 ?1578.907 ? 1.522 ?ops/s
> 
> After:
> 
> Benchmark ? ? ? ?(messageLength) ? Mode ?Cnt ? ? Score ? Error ?Units
> Signatures.sign ? ? ? ? ? ? ? 64 ?thrpt ? 15 ?1679.495 ? 3.883 ?ops/s
> 
> Greatest part of the improvement is related to ECOperations changes; BigInteger modifications provide only marginal gains (1584 ops/s without ECOperations changes).
> 
> Tier1-3 tests continue to pass.

In src/java.base/share/classes/sun/security/provider/DSAParameterGenerator.java there a still some mod(Biginteger.TWO.pow(...)) type subexpressions, e.g. in lines 214, 220, 231, 240 (not that it matters much).

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

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


From iris at openjdk.org  Tue Oct 11 16:32:14 2022
From: iris at openjdk.org (Iris Clark)
Date: Tue, 11 Oct 2022 16:32:14 GMT
Subject: RFR: 8295163: Remove old hsdis Makefile
In-Reply-To: <tHLL5Hmfit_ciMlOc4lMgGEdgVelb4CeRlVBhcPfrKY=.d9e7b57b-dacf-4368-af56-e1663c039716@github.com>
References: <tHLL5Hmfit_ciMlOc4lMgGEdgVelb4CeRlVBhcPfrKY=.d9e7b57b-dacf-4368-af56-e1663c039716@github.com>
Message-ID: <mVgblBGsSjZR3AHW0aFrcUFReYGVvJnvG-MBmFouFXQ=.47dbe045-a58a-4c21-9680-251cebb7515d@github.com>

On Tue, 11 Oct 2022 16:00:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> For some reason the old Makefile for hsdis was not removed when the build was moved into the normal build system in [JDK-8188073](https://bugs.openjdk.org/browse/JDK-8188073). This should be fixed.

Marked as reviewed by iris (Reviewer).

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

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


From ihse at openjdk.org  Tue Oct 11 16:38:50 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 11 Oct 2022 16:38:50 GMT
Subject: Integrated: 8295163: Remove old hsdis Makefile
In-Reply-To: <tHLL5Hmfit_ciMlOc4lMgGEdgVelb4CeRlVBhcPfrKY=.d9e7b57b-dacf-4368-af56-e1663c039716@github.com>
References: <tHLL5Hmfit_ciMlOc4lMgGEdgVelb4CeRlVBhcPfrKY=.d9e7b57b-dacf-4368-af56-e1663c039716@github.com>
Message-ID: <FGaTdssxWpWCl4gJZOH8JwOfCJy7vBiux9Vn0K3rYOE=.42e4b1d8-ebb3-4421-b029-c11d0bf3ee47@github.com>

On Tue, 11 Oct 2022 16:00:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> For some reason the old Makefile for hsdis was not removed when the build was moved into the normal build system in [JDK-8188073](https://bugs.openjdk.org/browse/JDK-8188073). This should be fixed.

This pull request has now been integrated.

Changeset: e1a77cfd
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e1a77cfd5f296e3e77c945a20d3688e6774dee29
Stats:     214 lines in 1 file changed: 0 ins; 214 del; 0 mod

8295163: Remove old hsdis Makefile

Reviewed-by: shade, iris

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

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


From jwaters at openjdk.org  Tue Oct 11 16:42:15 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 11 Oct 2022 16:42:15 GMT
Subject: RFR: 8295070: Introduce more target combinations for compiler
 flags [v3]
In-Reply-To: <zHE96psmrBEI8Jc6qDzP3VQrZHWn41hbtCsa6aPmi00=.b019a466-5107-4c0d-903d-54586025cf5a@github.com>
References: <alUrMJ4fQy9z3dKu3BideMeVLc7DhlUbd_IWx79mZVU=.74eb4654-00b0-497f-9450-e87d9b435e37@github.com>
 <dEz1C15HnujCTsRaRZ_0G9DV_Z0fyun60AzAfq04hNw=.92012cfb-2a75-4d7f-b062-b5b40b102b4e@github.com>
 <zHE96psmrBEI8Jc6qDzP3VQrZHWn41hbtCsa6aPmi00=.b019a466-5107-4c0d-903d-54586025cf5a@github.com>
Message-ID: <CVjuhzDd2izFDhn9GHRxeDhF_PsRgkbF9-x7JGPvnN4=.212ae2a1-a728-4f9c-a51c-c5170ada6946@github.com>

On Mon, 10 Oct 2022 17:38:57 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I think this looks good, but if Magnus is around to comment I would value his input.

I understand, @magicus would this be a reasonable change?

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

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


From aph at openjdk.org  Tue Oct 11 16:54:19 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 11 Oct 2022 16:54:19 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java floating-point
 arithmetic
Message-ID: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>

A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.

The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522

One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 

However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.

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

Commit messages:
 - Whitespace
 - 8295159: DSO created with -ffast-math breaks Java floating-point arithmetic
 - 8295159: test cases

Changes: https://git.openjdk.org/jdk/pull/10661/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10661&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295159
  Stats: 193 lines in 5 files changed: 171 ins; 19 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10661.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10661/head:pull/10661

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


From aph at openjdk.org  Tue Oct 11 16:54:20 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 11 Oct 2022 16:54:20 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic
In-Reply-To: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
Message-ID: <JJhK3Y6aieI-8zNu8anpIUrj6n-MhWkHp2uJCDbcNbs=.0376afdc-7dc4-4232-b889-14e3f467fc82@github.com>

On Tue, 11 Oct 2022 16:02:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
> 
> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
> 
> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
> 
> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.

Also: this patch is Linux-only. I'll ask for help from build experts to make the tests GCC-only; it's not clear to me how.

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

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


From xuelei at openjdk.org  Tue Oct 11 17:52:18 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 11 Oct 2022 17:52:18 GMT
Subject: RFR: 8294997: Improve ECC math operations
In-Reply-To: <GY_kY9Ie7r40qRXHahsJnz1Xyxi2o1LM2cbxGccsWx0=.8a8b7251-7420-4337-8b62-bb00abbb60d1@github.com>
References: <GY_kY9Ie7r40qRXHahsJnz1Xyxi2o1LM2cbxGccsWx0=.8a8b7251-7420-4337-8b62-bb00abbb60d1@github.com>
Message-ID: <LFGRTvDblWch9YmcId_w5L61hwfKWiGwyqybJFHL3jM=.0d5b0ac0-985a-4969-a812-e77db4f1d205@github.com>

On Fri, 7 Oct 2022 21:11:39 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch rewrites some BigInteger and curve point operations used in EC calculations:
> - coefficient * 2^power is equivalent to coefficient << power
> - number mod 2^n is equivalent to number & (2^n-1)
> - pair of IntegerModuloP operations:
> t2 = t1+t1
> t1 = t1+t2
> is equivalent to t1=t1*3, which is now implemented more efficiently.
> 
> Benchmarked the code using not-yet-merged benchmark from #10544. Results on x64 before:
> 
> Benchmark ? ? ? ?(messageLength) ? Mode ?Cnt ? ? Score ? Error ?Units
> Signatures.sign ? ? ? ? ? ? ? 64 ?thrpt ? 15 ?1578.907 ? 1.522 ?ops/s
> 
> After:
> 
> Benchmark ? ? ? ?(messageLength) ? Mode ?Cnt ? ? Score ? Error ?Units
> Signatures.sign ? ? ? ? ? ? ? 64 ?thrpt ? 15 ?1679.495 ? 3.883 ?ops/s
> 
> Greatest part of the improvement is related to ECOperations changes; BigInteger modifications provide only marginal gains (1584 ops/s without ECOperations changes).
> 
> Tier1-3 tests continue to pass.

src/java.base/share/classes/sun/security/provider/DSAParameterGenerator.java line 240:

> 238:                     W = W.add(V[i].shiftLeft(i * outLen));
> 239:                 }
> 240:                 W = W.add((V[n].mod(BigInteger.TWO.pow(b)))

Did you want to update the "BigInteger.TWO.pow(b)" as well?

src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomial.java line 332:

> 330: 
> 331:     protected void setLimbsValuePositive(BigInteger v, long[] limbs) {
> 332:         assert bitsPerLimb < 32;

I may have this assert in the constructors as it is a final field.

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

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


From ihse at openjdk.org  Tue Oct 11 17:57:10 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 11 Oct 2022 17:57:10 GMT
Subject: RFR: 8295070: Introduce more target combinations for compiler
 flags [v3]
In-Reply-To: <dEz1C15HnujCTsRaRZ_0G9DV_Z0fyun60AzAfq04hNw=.92012cfb-2a75-4d7f-b062-b5b40b102b4e@github.com>
References: <alUrMJ4fQy9z3dKu3BideMeVLc7DhlUbd_IWx79mZVU=.74eb4654-00b0-497f-9450-e87d9b435e37@github.com>
 <dEz1C15HnujCTsRaRZ_0G9DV_Z0fyun60AzAfq04hNw=.92012cfb-2a75-4d7f-b062-b5b40b102b4e@github.com>
Message-ID: <fPojm75lVmxhCuWlM74x82xgFgYtJOxx034nnqzfLZI=.4f65ab95-702c-4852-885f-e89f5fb93bdd@github.com>

On Mon, 10 Oct 2022 15:29:16 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Several parts of the make system in the JDK has large parts of cluttered if branches dedicated to setting flags for the specific compiler used in the build. This could be more neatly accomplished by instead adding more target combinations in SetupNativeCompilation so the callsite can more cleanly specify which OS and compiler it desires to set these flags for. The change currently includes:
>> 
>> DISABLED_WARNINGS (including per file warnings), CFLAGS/CXXFLAGS and LDFLAGS: Compiler-then-OS (The priority shown reflects how the flags depend more so on the compiler)
>> LIBS: OS-then-Compiler, as libraries typically vary based on the system being compiled for
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extra spacing

I can't see anything inherently wrong in the patch, but every extra combination adds extra complexity. 

I just would like to see some concrete examples of where these new additions would help, so we're not just pouring in additional combinations "just for the sake of it".

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

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


From dcubed at openjdk.org  Tue Oct 11 18:52:08 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 11 Oct 2022 18:52:08 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic
In-Reply-To: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
Message-ID: <_1A5xHTrbMO1_G-ctty0HXkdBhoTSPRo_MRMFktm1xY=.aded8e35-ba59-433e-8e41-af3b80ffeca6@github.com>

On Tue, 11 Oct 2022 16:02:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
> 
> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
> 
> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
> 
> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.

It seems strange to me that the native library part is here:

test/hotspot/jtreg/runtime/jni/TestDenormalFloat/libfast-math.c

and the two test files are here:

test/hotspot/jtreg/compiler/floatingpoint/TestDenormalDouble.java
test/hotspot/jtreg/compiler/floatingpoint/TestDenormalFloat.java

And the two tests don't have "@run main/native"... Maybe I'm missing
something about what you're trying to test here.

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

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


From dholmes at openjdk.org  Tue Oct 11 21:20:03 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Oct 2022 21:20:03 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
Message-ID: <7QKz3KHYBdzXj3wdQT9PsvKO689fN2orAqHJvYdl5OA=.baa36d64-5587-461a-8edd-f929c6923580@github.com>

On Mon, 10 Oct 2022 12:32:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:
>
> 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 four additional commits since the last revision:
> 
>  - Naming
>  - Redo using the proper signatures
>  - Merge branch 'master' into JDK-8294594-warning-cast-function-type-signals
>  - Fix

So this is okay to go in in current form, as per discussions. os::signal will be handled separately.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

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


From dholmes at openjdk.org  Wed Oct 12 00:26:04 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 12 Oct 2022 00:26:04 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic
In-Reply-To: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
Message-ID: <q5mkCQ_oFkkbfMfSRZ5juwhKRk-0iLtI_4joFOBexyM=.06d04d72-c840-45a9-9f2d-8f5516c6253e@github.com>

On Tue, 11 Oct 2022 16:02:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
> 
> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
> 
> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
> 
> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.

test/hotspot/jtreg/runtime/jni/TestDenormalFloat/libfast-math.c line 24:

> 22:  */
> 23: 
> 24: 

A comment as to why this file exists will help future maintainers.

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

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


From dholmes at openjdk.org  Wed Oct 12 00:41:05 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 12 Oct 2022 00:41:05 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic
In-Reply-To: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
Message-ID: <yT1eFrpO6OYr1ick-L0ZnLZqMgHJmuXJRM6qnBwDkOk=.510a404d-5166-4bb8-be1e-d11deb53bdb4@github.com>

On Tue, 11 Oct 2022 16:02:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
> 
> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
> 
> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
> 
> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.

This appears to be a 10 year old bug in gcc. Have we ever had any issues reported because of this? Inserting a workaround now seems rather late. Any FP-using native code can potentially break Java's FP semantics if it messes with the FPU control world (ref the old Borland compilers).

Shouldn't any workaround only be needed for the internals of `System.loadLibrary` as other JDK usages of `dlopen` should know what they are opening and that they are libraries that don't have this problem?

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

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


From dzhang at openjdk.org  Wed Oct 12 01:20:38 2022
From: dzhang at openjdk.org (Dingli Zhang)
Date: Wed, 12 Oct 2022 01:20:38 GMT
Subject: RFR: 8295033: hsdis configure error when cross-compiling with
 --with-binutils-src [v2]
In-Reply-To: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
References: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
Message-ID: <HCBws8CTA0eOk_B5sg7s37bpQ6g7BNsUYMoRE_4I9Oo=.4093da1e-aef5-4e7e-a393-108335964080@github.com>

> I built hsdis with the following parameters from source code of binutils while cross-compiling:
> 
> --with-hsdis=binutils \
> --with-binutils-src=/home/dingli/jdk-tools/binutils-2.38
> 
> 
> But configure will exit with the following error:
> 
> checking whether we are cross compiling... configure: error: in `/home/dingli/jdk-tools/binutils-2.38-src':
> configure: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details
> configure: Automatic building of binutils failed on configure. Try building it manually
> configure: error: Cannot continue
> configure exiting with result code 1
> 
> 
> The reason for the error is that binutils wants to be configured with --host during cross-compilation. So we can determine if we are currently cross-compiling and add the --host parameter to binutils_target:
> 
> diff --git a/make/autoconf/lib-hsdis.m4 b/make/autoconf/lib-hsdis.m4
> index d72bbf6df32..dddc1cf6a4d 100644
> --- a/make/autoconf/lib-hsdis.m4
> +++ b/make/autoconf/lib-hsdis.m4
> @@ -175,7 +175,11 @@ AC_DEFUN([LIB_BUILD_BINUTILS],
>        fi
>      else
>        binutils_cc="$CC $SYSROOT_CFLAGS"
> -      binutils_target=""
> +      if test "x$host" = "x$build"; then
> +        binutils_target=""
> +      else
> +        binutils_target="--host=$host"
> +      fi
>      fi
>      binutils_cflags="$binutils_cflags $MACHINE_FLAG $JVM_PICFLAG $C_O_FLAG_NORM"
>  
> 
> 
> In the meantime, I removed some useless code about hsdis-demo because hsdis-demo.c was removed in [JDK-8275128](https://bugs.openjdk.org/browse/JDK-8275128) .
> 
> ## Testing:
> 
> - cross compile for RISC-V on x86_64

Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision:

  Remove old hsdis Makefile

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10628/files
  - new: https://git.openjdk.org/jdk/pull/10628/files/21cc4d06..e937b657

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10628&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10628&range=00-01

  Stats: 206 lines in 1 file changed: 0 ins; 206 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10628.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10628/head:pull/10628

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


From dzhang at openjdk.org  Wed Oct 12 01:23:25 2022
From: dzhang at openjdk.org (Dingli Zhang)
Date: Wed, 12 Oct 2022 01:23:25 GMT
Subject: RFR: 8295033: hsdis configure error when cross-compiling with
 --with-binutils-src [v3]
In-Reply-To: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
References: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
Message-ID: <cRJ2nGlNNk1BD_nZHpVagY_ti4viZsHKFJ_qeghTT-0=.dcadc097-8281-4b07-9ee5-b76ee227c020@github.com>

> I built hsdis with the following parameters from source code of binutils while cross-compiling:
> 
> --with-hsdis=binutils \
> --with-binutils-src=/home/dingli/jdk-tools/binutils-2.38
> 
> 
> But configure will exit with the following error:
> 
> checking whether we are cross compiling... configure: error: in `/home/dingli/jdk-tools/binutils-2.38-src':
> configure: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details
> configure: Automatic building of binutils failed on configure. Try building it manually
> configure: error: Cannot continue
> configure exiting with result code 1
> 
> 
> The reason for the error is that binutils wants to be configured with --host during cross-compilation. So we can determine if we are currently cross-compiling and add the --host parameter to binutils_target:
> 
> diff --git a/make/autoconf/lib-hsdis.m4 b/make/autoconf/lib-hsdis.m4
> index d72bbf6df32..dddc1cf6a4d 100644
> --- a/make/autoconf/lib-hsdis.m4
> +++ b/make/autoconf/lib-hsdis.m4
> @@ -175,7 +175,11 @@ AC_DEFUN([LIB_BUILD_BINUTILS],
>        fi
>      else
>        binutils_cc="$CC $SYSROOT_CFLAGS"
> -      binutils_target=""
> +      if test "x$host" = "x$build"; then
> +        binutils_target=""
> +      else
> +        binutils_target="--host=$host"
> +      fi
>      fi
>      binutils_cflags="$binutils_cflags $MACHINE_FLAG $JVM_PICFLAG $C_O_FLAG_NORM"
>  
> 
> 
> In the meantime, I removed some useless code about hsdis-demo because hsdis-demo.c was removed in [JDK-8275128](https://bugs.openjdk.org/browse/JDK-8275128) .
> 
> ## Testing:
> 
> - cross compile for RISC-V on x86_64

Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision:

  Use COMPILE_TYPE and OPENJDK_TARGET_AUTOCONF_NAME instead

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10628/files
  - new: https://git.openjdk.org/jdk/pull/10628/files/e937b657..f18f31d9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10628&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10628&range=01-02

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

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


From dzhang at openjdk.org  Wed Oct 12 01:25:22 2022
From: dzhang at openjdk.org (Dingli Zhang)
Date: Wed, 12 Oct 2022 01:25:22 GMT
Subject: RFR: 8295033: hsdis configure error when cross-compiling with
 --with-binutils-src [v4]
In-Reply-To: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
References: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
Message-ID: <-d_kjF_i0HhCPvZZVFFMzJSj36MHbfxfoxXpNoJFvaA=.b4199717-eac0-4eae-ae61-f3ce96c86892@github.com>

> I built hsdis with the following parameters from source code of binutils while cross-compiling:
> 
> --with-hsdis=binutils \
> --with-binutils-src=/home/dingli/jdk-tools/binutils-2.38
> 
> 
> But configure will exit with the following error:
> 
> checking whether we are cross compiling... configure: error: in `/home/dingli/jdk-tools/binutils-2.38-src':
> configure: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details
> configure: Automatic building of binutils failed on configure. Try building it manually
> configure: error: Cannot continue
> configure exiting with result code 1
> 
> 
> The reason for the error is that binutils wants to be configured with --host during cross-compilation. So we can determine if we are currently cross-compiling and add the --host parameter to binutils_target:
> 
> diff --git a/make/autoconf/lib-hsdis.m4 b/make/autoconf/lib-hsdis.m4
> index d72bbf6df32..dddc1cf6a4d 100644
> --- a/make/autoconf/lib-hsdis.m4
> +++ b/make/autoconf/lib-hsdis.m4
> @@ -175,7 +175,11 @@ AC_DEFUN([LIB_BUILD_BINUTILS],
>        fi
>      else
>        binutils_cc="$CC $SYSROOT_CFLAGS"
> -      binutils_target=""
> +      if test "x$host" = "x$build"; then
> +        binutils_target=""
> +      else
> +        binutils_target="--host=$host"
> +      fi
>      fi
>      binutils_cflags="$binutils_cflags $MACHINE_FLAG $JVM_PICFLAG $C_O_FLAG_NORM"
>  
> 
> 
> In the meantime, I removed some useless code about hsdis-demo because hsdis-demo.c was removed in [JDK-8275128](https://bugs.openjdk.org/browse/JDK-8275128) .
> 
> ## Testing:
> 
> - cross compile for RISC-V on x86_64

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

 - Use COMPILE_TYPE and OPENJDK_TARGET_AUTOCONF_NAME instead
 - Add hsdis-src support for cross-compile

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

Changes: https://git.openjdk.org/jdk/pull/10628/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10628&range=03
  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10628.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10628/head:pull/10628

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


From dzhang at openjdk.org  Wed Oct 12 01:29:36 2022
From: dzhang at openjdk.org (Dingli Zhang)
Date: Wed, 12 Oct 2022 01:29:36 GMT
Subject: RFR: 8295033: hsdis configure error when cross-compiling with
 --with-binutils-src
In-Reply-To: <e5DT5nP8d-mH8eK1LmZileBLS8Z9_t8yczGUIf1i1Zg=.c7c7cd8e-f3ef-4b60-b472-44528549fbea@github.com>
References: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
 <lZvDuxk3uUxRurORyAKxBaKKJJ9_VCDzh63rWySZFzQ=.7ca22270-ab85-426d-aeec-223de1c4e7e9@github.com>
 <e5DT5nP8d-mH8eK1LmZileBLS8Z9_t8yczGUIf1i1Zg=.c7c7cd8e-f3ef-4b60-b472-44528549fbea@github.com>
Message-ID: <Uc3LL3QWBWD37BjjgG9lHj4_cbrbNIraeMh5KFWfSlE=.ecf45a9d-7696-4d44-83c5-a5be9f79a08b@github.com>

On Tue, 11 Oct 2022 12:57:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Ok, we already have an exported value for `$host`, which is `$OPENJDK_TARGET_AUTOCONF_NAME`. Also, `$conf_openjdk_target` is used in the wrapper configure script. It is probably leaking into the main generated autoconf script, but it is definitely not supposed to be used there. Instead, it should only be used to setup the `--host=` option to autoconf. So looking for `$host` is fine I suppose, but we should do it using the OPENJDK_TARGET_AUTOCONF_NAME variable.
>
>> Ok, we already have an exported value for `$host`, which is `$OPENJDK_TARGET_AUTOCONF_NAME`. Also, `$conf_openjdk_target` is used in the wrapper configure script. It is probably leaking into the main generated autoconf script, but it is definitely not supposed to be used there. Instead, it should only be used to setup the `--host=` option to autoconf. So looking for `$host` is fine I suppose, but we should do it using the OPENJDK_TARGET_AUTOCONF_NAME variable.
> 
> Quite!
> 
> Applying this patch over the PR:
> 
> 
> diff --git a/make/autoconf/lib-hsdis.m4 b/make/autoconf/lib-hsdis.m4
> index dddc1cf6a4d..72bd08c7108 100644
> --- a/make/autoconf/lib-hsdis.m4
> +++ b/make/autoconf/lib-hsdis.m4
> @@ -175,10 +175,10 @@ AC_DEFUN([LIB_BUILD_BINUTILS],
>        fi
>      else
>        binutils_cc="$CC $SYSROOT_CFLAGS"
> -      if test "x$host" = "x$build"; then
> -        binutils_target=""
> +      if test "x$COMPILE_TYPE" = xcross; then
> +        binutils_target="--host=$OPENJDK_TARGET_AUTOCONF_NAME"
>        else
> -        binutils_target="--host=$host"
> +        binutils_target=""
>        fi
>      fi
>      binutils_cflags="$binutils_cflags $MACHINE_FLAG $JVM_PICFLAG $C_O_FLAG_NORM"
> 
> 
> ...successfully produces the hsdis binaries on all these platforms:
> 
> 
> server-release-aarch64-linux-gnu-10
> server-release-arm-linux-gnueabihf-10
> server-release-i686-linux-gnu-10
> server-release-powerpc64le-linux-gnu-10
> server-release-powerpc64-linux-gnu-10
> server-release-riscv64-linux-gnu-10
> server-release-s390x-linux-gnu-10
> server-release-x86_64-linux-gnu-10
> zero-release-aarch64-linux-gnu-10
> zero-release-alpha-linux-gnu-10
> zero-release-arm-linux-gnueabi-10
> zero-release-arm-linux-gnueabihf-10
> zero-release-i686-linux-gnu-10
> zero-release-m68k-linux-gnu-10
> zero-release-mips64el-linux-gnuabi64-10
> zero-release-mipsel-linux-gnu-10
> zero-release-powerpc64le-linux-gnu-10
> zero-release-powerpc64-linux-gnu-10
> zero-release-powerpc-linux-gnu-10
> zero-release-riscv64-linux-gnu-10
> zero-release-s390x-linux-gnu-10
> zero-release-sh4-linux-gnu-10
> zero-release-sparc64-linux-gnu-10
> zero-release-x86_64-linux-gnu-10
> 
> 
> Therefore, I believe this is what we should do and then call it a day. (Then I also need to start building all these hsdis-es at [https://builds.shipilev.net/hsdis/](https://builds.shipilev.net/hsdis/))

@shipilev @magicus Thanks for the review!
I have skipped the demo Makefile changes from this PR and applied the patch from @shipilev.

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

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


From ihse at openjdk.org  Wed Oct 12 06:23:18 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 06:23:18 GMT
Subject: RFR: 8295033: hsdis configure error when cross-compiling with
 --with-binutils-src [v4]
In-Reply-To: <-d_kjF_i0HhCPvZZVFFMzJSj36MHbfxfoxXpNoJFvaA=.b4199717-eac0-4eae-ae61-f3ce96c86892@github.com>
References: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
 <-d_kjF_i0HhCPvZZVFFMzJSj36MHbfxfoxXpNoJFvaA=.b4199717-eac0-4eae-ae61-f3ce96c86892@github.com>
Message-ID: <uhdxxB9IOZppV0oHd9AZzmOE4yQVpMGElkM3n0Zmx2g=.26ff05e2-baa8-44d4-8558-56338389ecde@github.com>

On Wed, 12 Oct 2022 01:25:22 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

>> I built hsdis with the following parameters from source code of binutils while cross-compiling:
>> 
>> --with-hsdis=binutils \
>> --with-binutils-src=/home/dingli/jdk-tools/binutils-2.38
>> 
>> 
>> But configure will exit with the following error:
>> 
>> checking whether we are cross compiling... configure: error: in `/home/dingli/jdk-tools/binutils-2.38-src':
>> configure: error: cannot run C compiled programs.
>> If you meant to cross compile, use `--host'.
>> See `config.log' for more details
>> configure: Automatic building of binutils failed on configure. Try building it manually
>> configure: error: Cannot continue
>> configure exiting with result code 1
>> 
>> 
>> The reason for the error is that binutils wants to be configured with --host during cross-compilation. So we can determine if we are currently cross-compiling and add the --host parameter to binutils_target:
>> 
>> diff --git a/make/autoconf/lib-hsdis.m4 b/make/autoconf/lib-hsdis.m4
>> index d72bbf6df32..dddc1cf6a4d 100644
>> --- a/make/autoconf/lib-hsdis.m4
>> +++ b/make/autoconf/lib-hsdis.m4
>> @@ -175,7 +175,11 @@ AC_DEFUN([LIB_BUILD_BINUTILS],
>>        fi
>>      else
>>        binutils_cc="$CC $SYSROOT_CFLAGS"
>> -      binutils_target=""
>> +      if test "x$host" = "x$build"; then
>> +        binutils_target=""
>> +      else
>> +        binutils_target="--host=$host"
>> +      fi
>>      fi
>>      binutils_cflags="$binutils_cflags $MACHINE_FLAG $JVM_PICFLAG $C_O_FLAG_NORM"
>>  
>> 
>> 
>> In the meantime, I removed some useless code about hsdis-demo because hsdis-demo.c was removed in [JDK-8275128](https://bugs.openjdk.org/browse/JDK-8275128) .
>> 
>> ## Testing:
>> 
>> - cross compile for RISC-V on x86_64
>
> Dingli Zhang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Use COMPILE_TYPE and OPENJDK_TARGET_AUTOCONF_NAME instead
>  - Add hsdis-src support for cross-compile

Thank you. This looks good now.

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

Marked as reviewed by ihse (Reviewer).

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


From shade at openjdk.org  Wed Oct 12 06:27:37 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 12 Oct 2022 06:27:37 GMT
Subject: RFR: 8295033: hsdis configure error when cross-compiling with
 --with-binutils-src [v4]
In-Reply-To: <-d_kjF_i0HhCPvZZVFFMzJSj36MHbfxfoxXpNoJFvaA=.b4199717-eac0-4eae-ae61-f3ce96c86892@github.com>
References: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
 <-d_kjF_i0HhCPvZZVFFMzJSj36MHbfxfoxXpNoJFvaA=.b4199717-eac0-4eae-ae61-f3ce96c86892@github.com>
Message-ID: <XDek9RMFEvmTp-dtP7G4WaZ92x3jD1mkaRnIEaaIkwM=.2d347f41-277d-45c4-b986-87af9e26f0d4@github.com>

On Wed, 12 Oct 2022 01:25:22 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

>> I built hsdis with the following parameters from source code of binutils while cross-compiling:
>> 
>> --with-hsdis=binutils \
>> --with-binutils-src=/home/dingli/jdk-tools/binutils-2.38
>> 
>> 
>> But configure will exit with the following error:
>> 
>> checking whether we are cross compiling... configure: error: in `/home/dingli/jdk-tools/binutils-2.38-src':
>> configure: error: cannot run C compiled programs.
>> If you meant to cross compile, use `--host'.
>> See `config.log' for more details
>> configure: Automatic building of binutils failed on configure. Try building it manually
>> configure: error: Cannot continue
>> configure exiting with result code 1
>> 
>> 
>> The reason for the error is that binutils wants to be configured with --host during cross-compilation. So we can determine if we are currently cross-compiling and add the --host parameter to binutils_target:
>> 
>> diff --git a/make/autoconf/lib-hsdis.m4 b/make/autoconf/lib-hsdis.m4
>> index d72bbf6df32..dddc1cf6a4d 100644
>> --- a/make/autoconf/lib-hsdis.m4
>> +++ b/make/autoconf/lib-hsdis.m4
>> @@ -175,7 +175,11 @@ AC_DEFUN([LIB_BUILD_BINUTILS],
>>        fi
>>      else
>>        binutils_cc="$CC $SYSROOT_CFLAGS"
>> -      binutils_target=""
>> +      if test "x$host" = "x$build"; then
>> +        binutils_target=""
>> +      else
>> +        binutils_target="--host=$host"
>> +      fi
>>      fi
>>      binutils_cflags="$binutils_cflags $MACHINE_FLAG $JVM_PICFLAG $C_O_FLAG_NORM"
>>  
>> 
>> 
>> In the meantime, I removed some useless code about hsdis-demo because hsdis-demo.c was removed in [JDK-8275128](https://bugs.openjdk.org/browse/JDK-8275128) .
>> 
>> ## Testing:
>> 
>> - cross compile for RISC-V on x86_64
>
> Dingli Zhang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Use COMPILE_TYPE and OPENJDK_TARGET_AUTOCONF_NAME instead
>  - Add hsdis-src support for cross-compile

Testing...

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

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


From shade at openjdk.org  Wed Oct 12 07:24:13 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 12 Oct 2022 07:24:13 GMT
Subject: RFR: 8295033: hsdis configure error when cross-compiling with
 --with-binutils-src [v4]
In-Reply-To: <-d_kjF_i0HhCPvZZVFFMzJSj36MHbfxfoxXpNoJFvaA=.b4199717-eac0-4eae-ae61-f3ce96c86892@github.com>
References: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
 <-d_kjF_i0HhCPvZZVFFMzJSj36MHbfxfoxXpNoJFvaA=.b4199717-eac0-4eae-ae61-f3ce96c86892@github.com>
Message-ID: <zNxDw4VPDRkgu2dSBTvXtzUeI5m3wrvG1rPqypTP_aU=.b1ac2af0-1878-45a1-9689-1da7a819ee2d@github.com>

On Wed, 12 Oct 2022 01:25:22 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

>> I built hsdis with the following parameters from source code of binutils while cross-compiling:
>> 
>> --with-hsdis=binutils \
>> --with-binutils-src=/home/dingli/jdk-tools/binutils-2.38
>> 
>> 
>> But configure will exit with the following error:
>> 
>> checking whether we are cross compiling... configure: error: in `/home/dingli/jdk-tools/binutils-2.38-src':
>> configure: error: cannot run C compiled programs.
>> If you meant to cross compile, use `--host'.
>> See `config.log' for more details
>> configure: Automatic building of binutils failed on configure. Try building it manually
>> configure: error: Cannot continue
>> configure exiting with result code 1
>> 
>> 
>> The reason for the error is that binutils wants to be configured with --host during cross-compilation. So we can determine if we are currently cross-compiling and add the --host parameter to binutils_target:
>> 
>> diff --git a/make/autoconf/lib-hsdis.m4 b/make/autoconf/lib-hsdis.m4
>> index d72bbf6df32..dddc1cf6a4d 100644
>> --- a/make/autoconf/lib-hsdis.m4
>> +++ b/make/autoconf/lib-hsdis.m4
>> @@ -175,7 +175,11 @@ AC_DEFUN([LIB_BUILD_BINUTILS],
>>        fi
>>      else
>>        binutils_cc="$CC $SYSROOT_CFLAGS"
>> -      binutils_target=""
>> +      if test "x$host" = "x$build"; then
>> +        binutils_target=""
>> +      else
>> +        binutils_target="--host=$host"
>> +      fi
>>      fi
>>      binutils_cflags="$binutils_cflags $MACHINE_FLAG $JVM_PICFLAG $C_O_FLAG_NORM"
>>  
>> 
>> 
>> In the meantime, I removed some useless code about hsdis-demo because hsdis-demo.c was removed in [JDK-8275128](https://bugs.openjdk.org/browse/JDK-8275128) .
>> 
>> ## Testing:
>> 
>> - cross compile for RISC-V on x86_64
>
> Dingli Zhang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Use COMPILE_TYPE and OPENJDK_TARGET_AUTOCONF_NAME instead
>  - Add hsdis-src support for cross-compile

Marked as reviewed by shade (Reviewer).

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

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


From dzhang at openjdk.org  Wed Oct 12 07:27:30 2022
From: dzhang at openjdk.org (Dingli Zhang)
Date: Wed, 12 Oct 2022 07:27:30 GMT
Subject: Integrated: 8295033: hsdis configure error when cross-compiling with
 --with-binutils-src
In-Reply-To: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
References: <7Wdr-gXbChQY_IO3AugyoiHBW9EMfY8QV1mkqf4rO9s=.8a19002f-247b-47a3-bd6a-baf60db38f3a@github.com>
Message-ID: <h0UvZvFdOAaPf4Gf22CwPc5jGPbws-b0AxqcsoF2Odg=.8fe1bcff-149b-456c-98b3-9f2ebb778054@github.com>

On Mon, 10 Oct 2022 06:32:09 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> I built hsdis with the following parameters from source code of binutils while cross-compiling:
> 
> --with-hsdis=binutils \
> --with-binutils-src=/home/dingli/jdk-tools/binutils-2.38
> 
> 
> But configure will exit with the following error:
> 
> checking whether we are cross compiling... configure: error: in `/home/dingli/jdk-tools/binutils-2.38-src':
> configure: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details
> configure: Automatic building of binutils failed on configure. Try building it manually
> configure: error: Cannot continue
> configure exiting with result code 1
> 
> 
> The reason for the error is that binutils wants to be configured with --host during cross-compilation. So we can determine if we are currently cross-compiling and add the --host parameter to binutils_target:
> 
> diff --git a/make/autoconf/lib-hsdis.m4 b/make/autoconf/lib-hsdis.m4
> index d72bbf6df32..dddc1cf6a4d 100644
> --- a/make/autoconf/lib-hsdis.m4
> +++ b/make/autoconf/lib-hsdis.m4
> @@ -175,7 +175,11 @@ AC_DEFUN([LIB_BUILD_BINUTILS],
>        fi
>      else
>        binutils_cc="$CC $SYSROOT_CFLAGS"
> -      binutils_target=""
> +      if test "x$host" = "x$build"; then
> +        binutils_target=""
> +      else
> +        binutils_target="--host=$host"
> +      fi
>      fi
>      binutils_cflags="$binutils_cflags $MACHINE_FLAG $JVM_PICFLAG $C_O_FLAG_NORM"
>  
> 
> 
> In the meantime, I removed some useless code about hsdis-demo because hsdis-demo.c was removed in [JDK-8275128](https://bugs.openjdk.org/browse/JDK-8275128) .
> 
> ## Testing:
> 
> - cross compile for RISC-V on x86_64

This pull request has now been integrated.

Changeset: 392f35df
Author:    Dingli Zhang <dzhang at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/392f35df4be1a9a8d7a67a25ae01230c7dd060ac
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8295033: hsdis configure error when cross-compiling with --with-binutils-src

Reviewed-by: erikj, ihse, shade

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

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


From ihse at openjdk.org  Wed Oct 12 08:13:04 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 08:13:04 GMT
Subject: RFR: 8295192: Use original configure command line when called from a
 script
Message-ID: <CfmrQekVnw-igzz3MoM3hU4jQUsoQvZqy9IaMczGOUY=.0608299e-8bf2-4ef7-af33-98df034de847@github.com>

Sometimes, the configure script is not called directly, but indirectly, using e.g. a wrapper script. This happens for instance in the case of using jib.sh.

In such cases, calling "make reconfigure" will not re-execute the original wrapper script. This can result in subtle bugs.

Instead, make a way to save the original command line from a wrapper script, and use that instead when running "make reconfigure". 

This PR also includes the corresponding changes needed to utilize this in jib.sh.

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

Commit messages:
 - 8295192: Use original configure command line when called from a script

Changes: https://git.openjdk.org/jdk/pull/10669/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10669&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295192
  Stats: 57 lines in 5 files changed: 54 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10669.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10669/head:pull/10669

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


From ihse at openjdk.org  Wed Oct 12 09:17:42 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 09:17:42 GMT
Subject: RFR: 8295198: Update more openjdk.java.net => openjdk.org URLs
Message-ID: <7EaJFlv0rkHlPIx439wEahllhClGQMg4XOjQAeEghT8=.9fa317de-73e5-4e90-a686-17e530cbda98@github.com>

In [JDK-8294618](https://bugs.openjdk.org/browse/JDK-8294618), many of the old references to openjdk.java.net was updated.

The test code was intentionally left out of that change, but some other instances were missed, though.

This patch will fix those misses (but will still leave test code changes to a separate fix).

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

Commit messages:
 - Fix https matching bug
 - Update java.1 from java.md
 - Update html version
 - Update openjdk.java.net -> openjdk.org

Changes: https://git.openjdk.org/jdk/pull/10670/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10670&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295198
  Stats: 22 lines in 6 files changed: 0 ins; 1 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/10670.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10670/head:pull/10670

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


From ihse at openjdk.org  Wed Oct 12 09:23:07 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 09:23:07 GMT
Subject: RFR: 8295198: Update more openjdk.java.net => openjdk.org URLs
In-Reply-To: <7EaJFlv0rkHlPIx439wEahllhClGQMg4XOjQAeEghT8=.9fa317de-73e5-4e90-a686-17e530cbda98@github.com>
References: <7EaJFlv0rkHlPIx439wEahllhClGQMg4XOjQAeEghT8=.9fa317de-73e5-4e90-a686-17e530cbda98@github.com>
Message-ID: <bfeAoJ2VpCMMTU9kHSLSTqWHg-dUIxvCsduOwmCzn8M=.4c71f004-93dd-409e-8e8d-1401bac85aaa@github.com>

On Wed, 12 Oct 2022 09:08:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In [JDK-8294618](https://bugs.openjdk.org/browse/JDK-8294618), many of the old references to openjdk.java.net was updated.
> 
> The test code was intentionally left out of that change, but some other instances were missed, though.
> 
> This patch will fix those misses (but will still leave test code changes to a separate fix).

src/java.base/share/man/java.1 line 4394:

> 4392: .PP
> 4393: See \f[B]CodeHeap State Analytics (OpenJDK)\f[R]
> 4394: [https://bugs.openjdk.org/secure/attachment/75649/JVM_CodeHeap_StateAnalytics_V2.pdf]

A reflection is that this does not seem like a good permanent URL to refer to in our specifications; but I'll leave that to someone else to fix.

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

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


From ihse at openjdk.org  Wed Oct 12 09:52:26 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 09:52:26 GMT
Subject: RFR: 8295205: Add jcheck whitespace checking for markdown files
Message-ID: <JwAKg2dZVM1FL866mSl5HD8OaLQn1cpUHfV_BSEpIBs=.6d783546-3b70-4858-b070-d7476d12b58c@github.com>

Markdown files are basically source code for documentation. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.

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

Commit messages:
 - 8295205: Add jcheck whitespace checking for markdown files

Changes: https://git.openjdk.org/jdk/pull/10671/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10671&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295205
  Stats: 34 lines in 9 files changed: 0 ins; 0 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/10671.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10671/head:pull/10671

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


From ihse at openjdk.org  Wed Oct 12 10:31:51 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 10:31:51 GMT
Subject: RFR: 8295211: Fix autoconf 2.71 warning
 "AC_CHECK_HEADERS: you should use literals"
Message-ID: <TFuckcu3wKtT0Cq53Ti_mAli1s-JLUxTtuFBEeVO7sw=.745e1a6f-998c-47f1-8d35-5ee13223b0b6@github.com>

In autoconf 2.71, there is a warning generated for calling AC_CHECK_HEADERS with a variable.

It is not clear to me why they consider this to be a problem, but the warning is printed whenever you run configure with autoconf 2.71 or newer, and it is annoying.

We're only doing this in one place. Let's hardcode the values instead so we get rid of the warning.

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

Commit messages:
 - 8295211: Fix autoconf 2.71 warning "AC_CHECK_HEADERS: you should use literals"

Changes: https://git.openjdk.org/jdk/pull/10672/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10672&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295211
  Stats: 31 lines in 1 file changed: 17 ins; 12 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10672.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10672/head:pull/10672

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


From shade at openjdk.org  Wed Oct 12 10:37:17 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 12 Oct 2022 10:37:17 GMT
Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v9]
In-Reply-To: <raPwK4VE7-ZMPnxybyP5v-uAchQUSnJ7zX7ldZtsWNM=.0c96acda-f793-4938-9d3f-081f6c365966@github.com>
References: <RrlZAKdgm0ZtogXG3iVPpmaFQB1Y0kQL2bQPGe6eRus=.95a23c3d-ae0c-4c8f-aab0-2d755236f6f7@github.com>
 <QWwKfSzL01bIjdz18HwvCnQuP1vbWkipFGmf5nlPCp0=.05ec869f-c3d6-4048-9d03-e7f23e5c7ec6@github.com>
 <uziscjqZmhO0X87EwnMVWqUZGjl2T8plwe5SrJ42Iww=.a18553e1-39fc-46ea-a8ea-988924ea195f@github.com>
 <_O1386bHeagTrVI68UU0GbvMWV8XtiRE3phbjYFZ81A=.b35c61a2-af07-43f8-8fab-cb218059e465@github.com>
 <raPwK4VE7-ZMPnxybyP5v-uAchQUSnJ7zX7ldZtsWNM=.0c96acda-f793-4938-9d3f-081f6c365966@github.com>
Message-ID: <Blcd1AJIwa9T43uwcUJsSI8SsgKVUn2mYVofjKNZLsU=.ad707177-fc46-4b7f-afa7-a715167be7af@github.com>

On Tue, 27 Sep 2022 19:07:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> @shipilev I had hoped this PR would trigger warning hunting in Hotspot, but I did not anticipate that it would happen even before it was pushed! ;-) Let me know when you are done fixing individual warnings; there seem to be little point in integrating this until these fixes has started to slow down.
>> 
>> Well, as I dig deeper into this mess, my PRs that fix the warnings stray away from being trivial, and build changes are a small parts of them. The actual "meat" of the patches requires review. So, I am actually thinking we should integrate this PR first, wait a little, collate possible build failures due to missing disabled warnings, adding more affected files in these declarations. It would make the actual warning fix PRs more to the point: they would have to only touch the files where warnings were specifically disabled. (The same goes for JDK-side PRs, I think)
>
> @shipilev So you want me to integrate this first, and then you follow up with your fixes?

Hey @magicus, are you going forward with this PR, or?

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

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


From ihse at openjdk.org  Wed Oct 12 10:42:12 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 10:42:12 GMT
Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v17]
In-Reply-To: <nTsZndruuOc8tTl1rkASvuBs4FKS-DinuIutwWIP8RI=.d597a15b-2e8a-4f25-a458-7c689c0a7ab1@github.com>
References: <RrlZAKdgm0ZtogXG3iVPpmaFQB1Y0kQL2bQPGe6eRus=.95a23c3d-ae0c-4c8f-aab0-2d755236f6f7@github.com>
 <nTsZndruuOc8tTl1rkASvuBs4FKS-DinuIutwWIP8RI=.d597a15b-2e8a-4f25-a458-7c689c0a7ab1@github.com>
Message-ID: <CguRJxH8UeFnRFzN_J9A7LvHxYjUbkQ7uCtGBTv5kQk=.f9760334-1a72-451f-9a9c-e8e3242a57e6@github.com>

On Wed, 28 Sep 2022 19:52:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot.
>> 
>> Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files.
>> 
>> Some warnings didn't trigger in any file anymore, and could just be removed.
>> 
>> Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back.
>> 
>> I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily.
>> 
>> I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround.
>> 
>> It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++).
>> 
>> Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert jvm variants hack

Yes, that is my intention. I've been away for almost two weeks, taking care of my kids and then getting ill myself. :-( I'm wading through my backlog, and intend to get back to this very soon.

**Note to self** Remaining to be done:
 - [ ] Fix Windows warnings according to Kim's list
 - [ ] Check JvmOverrideFiles.gmk according to Aleksey's suggestion

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

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


From ihse at openjdk.org  Wed Oct 12 10:45:26 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 10:45:26 GMT
Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v18]
In-Reply-To: <RrlZAKdgm0ZtogXG3iVPpmaFQB1Y0kQL2bQPGe6eRus=.95a23c3d-ae0c-4c8f-aab0-2d755236f6f7@github.com>
References: <RrlZAKdgm0ZtogXG3iVPpmaFQB1Y0kQL2bQPGe6eRus=.95a23c3d-ae0c-4c8f-aab0-2d755236f6f7@github.com>
Message-ID: <OamAHBQDF0Pm1O4rCe82TTo19vcOFl-1WP6vEArVJ5c=.d4c84703-bcab-4173-b6c6-9af4d66191e6@github.com>

> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot.
> 
> Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.
> 
> Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back.
> 
> I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily.
> 
> I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround.
> 
> It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++).
> 
> Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed.

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 29 additional commits since the last revision:

 - Merge branch 'master' into hotspot-warnings-per-file
 - Revert jvm variants hack
 - Revert "TESTING GHA v2: Previous attempt was botched"
   
   This reverts commit 4a51a15cd73ebc6aa96ad04f9b1eb88e2683c82f.
 - Add missing sub workflow inputs
 - Pass additional arguments to GHA runs
 - TESTING GHA v2: Previous attempt was botched
 - TESTING: enable all variants
 - add address for cgroupV1Subsystem_linux.cpp (thanks @shqking)
   
   Co-authored-by: Hao Sun <hao.sun at arm.com>
 - Add misleading-indentation for client (thanks @shqking)
   
   Co-authored-by: Hao Sun <hao.sun at arm.com>
 - Don't need empty-body for ad_ppc.cpp now that it is globally disabled
 - ... and 19 more: https://git.openjdk.org/jdk/compare/21647a39...f4f65396

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10414/files
  - new: https://git.openjdk.org/jdk/pull/10414/files/d6c52a2a..f4f65396

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=16-17

  Stats: 27023 lines in 667 files changed: 16269 ins; 7621 del; 3133 mod
  Patch: https://git.openjdk.org/jdk/pull/10414.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10414/head:pull/10414

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


From ihse at openjdk.org  Wed Oct 12 10:48:12 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 10:48:12 GMT
Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v19]
In-Reply-To: <RrlZAKdgm0ZtogXG3iVPpmaFQB1Y0kQL2bQPGe6eRus=.95a23c3d-ae0c-4c8f-aab0-2d755236f6f7@github.com>
References: <RrlZAKdgm0ZtogXG3iVPpmaFQB1Y0kQL2bQPGe6eRus=.95a23c3d-ae0c-4c8f-aab0-2d755236f6f7@github.com>
Message-ID: <VGSmBOajMAELG0Uvemm_1HmrE-NPVH94OpN5xKv6Sc4=.793d548b-f996-496e-9fc6-837ee62b8e51@github.com>

> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot.
> 
> Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.
> 
> Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back.
> 
> I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily.
> 
> I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround.
> 
> It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++).
> 
> Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed.

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

  Restore msvc 4127 - conditional expression is constant

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10414/files
  - new: https://git.openjdk.org/jdk/pull/10414/files/f4f65396..f952fecd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=17-18

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

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


From ihse at openjdk.org  Wed Oct 12 10:55:07 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 10:55:07 GMT
Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v20]
In-Reply-To: <RrlZAKdgm0ZtogXG3iVPpmaFQB1Y0kQL2bQPGe6eRus=.95a23c3d-ae0c-4c8f-aab0-2d755236f6f7@github.com>
References: <RrlZAKdgm0ZtogXG3iVPpmaFQB1Y0kQL2bQPGe6eRus=.95a23c3d-ae0c-4c8f-aab0-2d755236f6f7@github.com>
Message-ID: <f816Pku53Tl26MvkqHczmNij7Gih8-l03bERZK1nfss=.e11e3389-64fd-463f-bc03-4f85f48de2aa@github.com>

> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot.
> 
> Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.
> 
> Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back.
> 
> I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily.
> 
> I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround.
> 
> It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++).
> 
> Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed.

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

  Move disabled warnings from JvmOverrideFiles.gmk to the new per-file disabling framework
  
  (maybe-uninitialized is always turned off so skip those files)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10414/files
  - new: https://git.openjdk.org/jdk/pull/10414/files/f952fecd..8b4433e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=18-19

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

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


From ihse at openjdk.org  Wed Oct 12 11:04:14 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 11:04:14 GMT
Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v21]
In-Reply-To: <RrlZAKdgm0ZtogXG3iVPpmaFQB1Y0kQL2bQPGe6eRus=.95a23c3d-ae0c-4c8f-aab0-2d755236f6f7@github.com>
References: <RrlZAKdgm0ZtogXG3iVPpmaFQB1Y0kQL2bQPGe6eRus=.95a23c3d-ae0c-4c8f-aab0-2d755236f6f7@github.com>
Message-ID: <D-ITPMwo33auL08XGAc39o68120N5xzJrdU8_oNZEOY=.9d2c0e17-e793-4d85-9304-5c94d813d216@github.com>

> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot.
> 
> Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.
> 
> Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back.
> 
> I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily.
> 
> I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround.
> 
> It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++).
> 
> Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed.

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

  Github workflow changes were not supposed to be in this PR...

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10414/files
  - new: https://git.openjdk.org/jdk/pull/10414/files/8b4433e2..64c86d46

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=19-20

  Stats: 60 lines in 5 files changed: 0 ins; 52 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/10414.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10414/head:pull/10414

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


From ihse at openjdk.org  Wed Oct 12 11:04:14 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 11:04:14 GMT
Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v9]
In-Reply-To: <Blcd1AJIwa9T43uwcUJsSI8SsgKVUn2mYVofjKNZLsU=.ad707177-fc46-4b7f-afa7-a715167be7af@github.com>
References: <RrlZAKdgm0ZtogXG3iVPpmaFQB1Y0kQL2bQPGe6eRus=.95a23c3d-ae0c-4c8f-aab0-2d755236f6f7@github.com>
 <QWwKfSzL01bIjdz18HwvCnQuP1vbWkipFGmf5nlPCp0=.05ec869f-c3d6-4048-9d03-e7f23e5c7ec6@github.com>
 <uziscjqZmhO0X87EwnMVWqUZGjl2T8plwe5SrJ42Iww=.a18553e1-39fc-46ea-a8ea-988924ea195f@github.com>
 <_O1386bHeagTrVI68UU0GbvMWV8XtiRE3phbjYFZ81A=.b35c61a2-af07-43f8-8fab-cb218059e465@github.com>
 <raPwK4VE7-ZMPnxybyP5v-uAchQUSnJ7zX7ldZtsWNM=.0c96acda-f793-4938-9d3f-081f6c365966@github.com>
 <Blcd1AJIwa9T43uwcUJsSI8SsgKVUn2mYVofjKNZLsU=.ad707177-fc46-4b7f-afa7-a715167be7af@github.com>
Message-ID: <LHaaa9LtF2cnWPoWlQiodT4uGE684kxAXG1C0K59i0Q=.a0569330-4781-442a-928e-624ad69e7bbe@github.com>

On Wed, 12 Oct 2022 10:35:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> @shipilev So you want me to integrate this first, and then you follow up with your fixes?
>
> Hey @magicus, are you going forward with this PR, or?

@shipilev In a "tenth time's the charm" spirit, here's what I do think is actually a PR that can be integrated. 

(This one was really messy, both due to me being a bit sloppy and too trigger-happy at times, and due to the complex situation of changing warnings across multiple combinations of variants, compilers, platforms, etc.)

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

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


From shade at openjdk.org  Wed Oct 12 11:11:07 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 12 Oct 2022 11:11:07 GMT
Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v9]
In-Reply-To: <Blcd1AJIwa9T43uwcUJsSI8SsgKVUn2mYVofjKNZLsU=.ad707177-fc46-4b7f-afa7-a715167be7af@github.com>
References: <RrlZAKdgm0ZtogXG3iVPpmaFQB1Y0kQL2bQPGe6eRus=.95a23c3d-ae0c-4c8f-aab0-2d755236f6f7@github.com>
 <QWwKfSzL01bIjdz18HwvCnQuP1vbWkipFGmf5nlPCp0=.05ec869f-c3d6-4048-9d03-e7f23e5c7ec6@github.com>
 <uziscjqZmhO0X87EwnMVWqUZGjl2T8plwe5SrJ42Iww=.a18553e1-39fc-46ea-a8ea-988924ea195f@github.com>
 <_O1386bHeagTrVI68UU0GbvMWV8XtiRE3phbjYFZ81A=.b35c61a2-af07-43f8-8fab-cb218059e465@github.com>
 <raPwK4VE7-ZMPnxybyP5v-uAchQUSnJ7zX7ldZtsWNM=.0c96acda-f793-4938-9d3f-081f6c365966@github.com>
 <Blcd1AJIwa9T43uwcUJsSI8SsgKVUn2mYVofjKNZLsU=.ad707177-fc46-4b7f-afa7-a715167be7af@github.com>
Message-ID: <1JwBm4xpt9EfiFBlkharONlS8E3RjMDXq2sCtQyu0UQ=.efc05433-4767-4863-bfbc-b5cf6aba672c@github.com>

On Wed, 12 Oct 2022 10:35:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> @shipilev So you want me to integrate this first, and then you follow up with your fixes?
>
> Hey @magicus, are you going forward with this PR, or?

> @shipilev In a "tenth time's the charm" spirit, here's what I do think is actually a PR that can be integrated.

Cool! I'll try to schedule the overnight build-matrix run to see if anything is broken.

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

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


From ihse at openjdk.org  Wed Oct 12 11:13:16 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 11:13:16 GMT
Subject: RFR: 8295213: Run GHA manually with user-specified make and configure
 arguments
Message-ID: <FKBotp8a9yQa5qRoU-kzYgg62UHs-0wM-rbli1UPrzY=.1537013e-dfe9-4e99-b446-249247885e17@github.com>

It is a trivial addition to our GHA scripts to allow the user to trigger a manual run, and to provide additional arguments to `make` and `configure` for that run. (Not all arguments will succeed though, if it conflicts with the GHA setup.) But it is an easy way to test some specific ways of building.

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

Commit messages:
 - 8295213: Run GHA manually with user-specified make and configure arguments

Changes: https://git.openjdk.org/jdk/pull/10673/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10673&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295213
  Stats: 60 lines in 5 files changed: 52 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/10673.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10673/head:pull/10673

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


From ihse at openjdk.org  Wed Oct 12 11:31:26 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 11:31:26 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic
In-Reply-To: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
Message-ID: <n_ZFb-TZHY5W6Y95v49wvK1rLGH3E4tUUI4xkFoOq3E=.7ae67835-6e3e-4d70-a6e8-ec6aa2414eb8@github.com>

On Tue, 11 Oct 2022 16:02:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
> 
> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
> 
> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
> 
> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.

I think this looks okay from a build perspective. I second David's opinion that the empty file should have a comment explaining that it exists to be compiled with a special flag.

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

Marked as reviewed by ihse (Reviewer).

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


From ihse at openjdk.org  Wed Oct 12 11:31:27 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 11:31:27 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic
In-Reply-To: <JJhK3Y6aieI-8zNu8anpIUrj6n-MhWkHp2uJCDbcNbs=.0376afdc-7dc4-4232-b889-14e3f467fc82@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <JJhK3Y6aieI-8zNu8anpIUrj6n-MhWkHp2uJCDbcNbs=.0376afdc-7dc4-4232-b889-14e3f467fc82@github.com>
Message-ID: <vfPoZy9uWPo7hkwdsoW-U8r3p_m2qgRHpuONPajPu6Q=.4f6e52e1-8826-49a4-b424-36a11d5e57d5@github.com>

On Tue, 11 Oct 2022 16:50:33 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Also: this patch is Linux-only. I'll ask for help from build experts to make the tests GCC-only; it's not clear to me how.

@theRealAph We currently have a more or less 1-to-1 relationship between OS and compiler. From a portability perspective this is not ideal, but it is also hard to keep some kind of theoretical barrier when it never is tested.

Are you worried that this is a problem that occurs with gcc on other platforms as well, or that it occurs on linux with other compilers than gcc? 

We do not support gcc on macos, windows or aix, which leaves linux as the only gcc platform in the mainline (ports in separate repos will have to handle this themselves). We do support using clang on linux instead of gcc (but do not test it regularly). But my impression here is that this is more of a gcc-problem than a linux problem..?

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

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


From ihse at openjdk.org  Wed Oct 12 11:41:27 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 11:41:27 GMT
Subject: RFR: 8294549: configure script should detect unsupported path
In-Reply-To: <INSePlc55Rszv4HetLtZS6-BnsZ2irY5hSeNTiipxwE=.55a00ecc-3f61-4615-96fd-7198a7b4ac63@github.com>
References: <INSePlc55Rszv4HetLtZS6-BnsZ2irY5hSeNTiipxwE=.55a00ecc-3f61-4615-96fd-7198a7b4ac63@github.com>
Message-ID: <qrvHmA8QrxMqgUCvNl_afTwaLVBe5iA6--Rg4vhCjTA=.06f3822b-bbbe-4f9a-ab52-99f7e0a2469c@github.com>

On Thu, 29 Sep 2022 00:09:37 GMT, Mike Duigou <mduigou at openjdk.org> wrote:

> The OpenJDK build system does not support building when the source code resides on a path that contains a space. This requirement is documented in the build instructions but not enforced by the configure script.
> 
> This change adds an explicit checks to the wrapper `configure` script that fail the build if the source code to be built is located in a directory who's path contains a space character or the build path cannot be determined.
> 
> Includes some idiom modernization and shell scripting best practices changes.

I agree that `configure` should detect and enforce build requirements.

However, this is done in the wrong place. At the very least it should move to `make/autoconf/configure` as Erik says. 

But I think we can do even better. Normally, all checks that requirements are fulfilled are done by the actual autoconf script. We already do some checking on the top-level dir in `BASIC_SETUP_PATHS` in `basic.m4`. This would be the proper place to also check for spaces.

Or is it the case that we cannot even start to execute the real autoconf script if there are spaces in the path? If so, I think we should fix those issues by proper quoting. We can't do that over the entire code base, but I think we can afford to do that in the bootstrapping part, so we can actually get to the real configure script.

Oh, and hi Mike! :) Long time no see... (Didn't at first understand this was you)

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

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


From ihse at openjdk.org  Wed Oct 12 11:50:06 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 11:50:06 GMT
Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed [v4]
In-Reply-To: <jx2kU4A0gxp4YCjuO5EP-nxww4wpHTc-vAZd9pJ__TE=.2b87d2e4-8fc8-4bbf-837c-0bac60362121@github.com>
References: <Cuo-hZ2dmp5Su2aMvYe3k_w_rEuzCk7F8wpeCsQuyMA=.911a0412-42c0-44a1-8863-e94e5a7970e7@github.com>
 <jx2kU4A0gxp4YCjuO5EP-nxww4wpHTc-vAZd9pJ__TE=.2b87d2e4-8fc8-4bbf-837c-0bac60362121@github.com>
Message-ID: <CD4i-QPJIM0KxBo236cZFLR2WujfOC5B1zyYx2iNpTE=.ab2c01d9-c411-47fe-a028-f8e9f9e90b36@github.com>

On Tue, 11 Oct 2022 08:18:08 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> The DWARF debugging symbols emitted by Clang is different from what GCC is emitting. While GCC produces a complete `.debug_aranges` section (which is required in the DWARF parser), Clang does not. As a result, the DWARF parser cannot find the necessary information to proceed and create the line number information:
>> 
>> The `.debug_aranges` section contains address range to compilation unit offset mappings. The parsing algorithm can just walk through all these entries to find the correct address range that contains the library offset of the current pc. This gives us the compilation unit offset into the `.debug_info` section from where we can proceed to parse the line number information.
>> 
>> Without a complete `.debug_aranges` section, we fail with an assertion that we could not find the correct entry. Since [JDK-8293402](https://bugs.openjdk.org/browse/JDK-8293402), we will still get the complete stack trace at least. Nevertheless, we should still fix this assertion failure of course. But that would require a different parsing approach. We need to parse the entire `.debug_info` section instead to get to the correct compilation unit. This, however, would require a lot more work. 
>> 
>> I therefore suggest to disable DWARF parsing for Clang for now and file an RFE to support Clang in the future with a different parsing approach. I'm using the `__clang__` `ifdef` to bail out in `get_source_info()` and disable the `gtests`. I've noticed that we are currently running the `gtests` with `NOT PRODUCT` which I think is not necessary - the gtests should also work fine with product builds. I've corrected this as well but that could also be done separately.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn 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 six additional commits since the last revision:
> 
>  - Always read full filename and strip prefix path and only then cut filename to fit output buffer
>  - Merge branch 'master' into JDK-8293422
>  - Merge branch 'master' into JDK-8293422
>  - Review comments from Thomas
>  - Change old bailout fix to only apply to Clang versions older than 5.0 and add new fix with -gdwarf-aranges + -gdwarf-4 for Clang 5.0+
>  - 8293422: DWARF emitted by Clang cannot be parsed

We currently require clang 3.5 (when building on linux I presume; Xcode has their very own peculiar way of versioning clang). Maybe this is too old? Should we instead raise the bar to require clang 5.0, so we can skip the test?

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

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


From ihse at openjdk.org  Wed Oct 12 11:54:13 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 11:54:13 GMT
Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed [v4]
In-Reply-To: <jx2kU4A0gxp4YCjuO5EP-nxww4wpHTc-vAZd9pJ__TE=.2b87d2e4-8fc8-4bbf-837c-0bac60362121@github.com>
References: <Cuo-hZ2dmp5Su2aMvYe3k_w_rEuzCk7F8wpeCsQuyMA=.911a0412-42c0-44a1-8863-e94e5a7970e7@github.com>
 <jx2kU4A0gxp4YCjuO5EP-nxww4wpHTc-vAZd9pJ__TE=.2b87d2e4-8fc8-4bbf-837c-0bac60362121@github.com>
Message-ID: <f0M_E9XFKZ_DaAwPqPjagjICPrEQdDBCaeeTEPQ2-rw=.524d1321-ef82-4fcd-8519-263a023a78e6@github.com>

On Tue, 11 Oct 2022 08:18:08 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> The DWARF debugging symbols emitted by Clang is different from what GCC is emitting. While GCC produces a complete `.debug_aranges` section (which is required in the DWARF parser), Clang does not. As a result, the DWARF parser cannot find the necessary information to proceed and create the line number information:
>> 
>> The `.debug_aranges` section contains address range to compilation unit offset mappings. The parsing algorithm can just walk through all these entries to find the correct address range that contains the library offset of the current pc. This gives us the compilation unit offset into the `.debug_info` section from where we can proceed to parse the line number information.
>> 
>> Without a complete `.debug_aranges` section, we fail with an assertion that we could not find the correct entry. Since [JDK-8293402](https://bugs.openjdk.org/browse/JDK-8293402), we will still get the complete stack trace at least. Nevertheless, we should still fix this assertion failure of course. But that would require a different parsing approach. We need to parse the entire `.debug_info` section instead to get to the correct compilation unit. This, however, would require a lot more work. 
>> 
>> I therefore suggest to disable DWARF parsing for Clang for now and file an RFE to support Clang in the future with a different parsing approach. I'm using the `__clang__` `ifdef` to bail out in `get_source_info()` and disable the `gtests`. I've noticed that we are currently running the `gtests` with `NOT PRODUCT` which I think is not necessary - the gtests should also work fine with product builds. I've corrected this as well but that could also be done separately.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn 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 six additional commits since the last revision:
> 
>  - Always read full filename and strip prefix path and only then cut filename to fit output buffer
>  - Merge branch 'master' into JDK-8293422
>  - Merge branch 'master' into JDK-8293422
>  - Review comments from Thomas
>  - Change old bailout fix to only apply to Clang versions older than 5.0 and add new fix with -gdwarf-aranges + -gdwarf-4 for Clang 5.0+
>  - 8293422: DWARF emitted by Clang cannot be parsed

Yeah, clang 5.0 was released in 2017. I'd recommend you just hard-code in the dwarf flags and instead apply this:

diff --git a/make/autoconf/toolchain.m4 b/make/autoconf/toolchain.m4
index adb4e182dcc..e1c097916d8 100644
--- a/make/autoconf/toolchain.m4
+++ b/make/autoconf/toolchain.m4
@@ -50,7 +50,7 @@ TOOLCHAIN_DESCRIPTION_microsoft="Microsoft Visual Studio"
 TOOLCHAIN_DESCRIPTION_xlc="IBM XL C/C++"
 
 # Minimum supported versions, empty means unspecified
-TOOLCHAIN_MINIMUM_VERSION_clang="3.5"
+TOOLCHAIN_MINIMUM_VERSION_clang="5.0"
 TOOLCHAIN_MINIMUM_VERSION_gcc="6.0"
 TOOLCHAIN_MINIMUM_VERSION_microsoft="19.28.0.0" # VS2019 16.8, aka MSVC 14.28
 TOOLCHAIN_MINIMUM_VERSION_xlc=""
 ```

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

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


From aph at openjdk.org  Wed Oct 12 11:58:30 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 12 Oct 2022 11:58:30 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v2]
In-Reply-To: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
Message-ID: <MA9xp_rEpIYamG75PkBO7SE8HDY0cBMRZyPrsKM1PtQ=.dd9db5b4-f734-4bc5-8d89-b4d385a30e1e@github.com>

> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
> 
> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
> 
> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
> 
> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10661/files
  - new: https://git.openjdk.org/jdk/pull/10661/files/af243d47..8d834739

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10661&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10661&range=00-01

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

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


From shade at openjdk.org  Wed Oct 12 12:50:06 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 12 Oct 2022 12:50:06 GMT
Subject: RFR: 8295213: Run GHA manually with user-specified make and
 configure arguments
In-Reply-To: <FKBotp8a9yQa5qRoU-kzYgg62UHs-0wM-rbli1UPrzY=.1537013e-dfe9-4e99-b446-249247885e17@github.com>
References: <FKBotp8a9yQa5qRoU-kzYgg62UHs-0wM-rbli1UPrzY=.1537013e-dfe9-4e99-b446-249247885e17@github.com>
Message-ID: <gYXWOanM5B3_1fSvpmiedE9cnvxrwuey8m1tO5i100c=.7b69332e-8a33-4130-a31b-e84b5556b151@github.com>

On Wed, 12 Oct 2022 11:05:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> It is a trivial addition to our GHA scripts to allow the user to trigger a manual run, and to provide additional arguments to `make` and `configure` for that run. (Not all arguments will succeed though, if it conflicts with the GHA setup.) But it is an easy way to test some specific ways of building.

Looks okay to me.

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

Marked as reviewed by shade (Reviewer).

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


From shade at openjdk.org  Wed Oct 12 12:52:29 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 12 Oct 2022 12:52:29 GMT
Subject: RFR: 8295211: Fix autoconf 2.71 warning
 "AC_CHECK_HEADERS: you should use literals"
In-Reply-To: <TFuckcu3wKtT0Cq53Ti_mAli1s-JLUxTtuFBEeVO7sw=.745e1a6f-998c-47f1-8d35-5ee13223b0b6@github.com>
References: <TFuckcu3wKtT0Cq53Ti_mAli1s-JLUxTtuFBEeVO7sw=.745e1a6f-998c-47f1-8d35-5ee13223b0b6@github.com>
Message-ID: <ScXlW7l1eMR2eJAV7y-1akSszt_c4sSpw_PfNWvJnv8=.4f579c1d-d6e1-4ba5-b913-d06693935299@github.com>

On Wed, 12 Oct 2022 10:23:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In autoconf 2.71, there is a warning generated for calling AC_CHECK_HEADERS with a variable.
> 
> It is not clear to me why they consider this to be a problem, but the warning is printed whenever you run configure with autoconf 2.71 or newer, and it is annoying.
> 
> We're only doing this in one place. Let's hardcode the values instead so we get rid of the warning.

Looks okay to me.

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

Marked as reviewed by shade (Reviewer).

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


From erikj at openjdk.org  Wed Oct 12 13:13:03 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 12 Oct 2022 13:13:03 GMT
Subject: RFR: 8295192: Use original configure command line when called from
 a script
In-Reply-To: <CfmrQekVnw-igzz3MoM3hU4jQUsoQvZqy9IaMczGOUY=.0608299e-8bf2-4ef7-af33-98df034de847@github.com>
References: <CfmrQekVnw-igzz3MoM3hU4jQUsoQvZqy9IaMczGOUY=.0608299e-8bf2-4ef7-af33-98df034de847@github.com>
Message-ID: <68wMWdGbhsvcwbrVqxcrSZlfJKQgbx__U1ASDV1tzlM=.2e8a4759-f8b7-4050-92ed-224e731b2bba@github.com>

On Wed, 12 Oct 2022 08:07:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Sometimes, the configure script is not called directly, but indirectly, using e.g. a wrapper script. This happens for instance in the case of using jib.sh.
> 
> In such cases, calling "make reconfigure" will not re-execute the original wrapper script. This can result in subtle bugs.
> 
> Instead, make a way to save the original command line from a wrapper script, and use that instead when running "make reconfigure". 
> 
> This PR also includes the corresponding changes needed to utilize this in jib.sh.

I think this looks ok, but I hope you have tested it thoroughly as jib.sh is a pretty sensitive script to make changes to.

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

Marked as reviewed by erikj (Reviewer).

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


From erikj at openjdk.org  Wed Oct 12 13:17:04 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 12 Oct 2022 13:17:04 GMT
Subject: RFR: 8295198: Update more openjdk.java.net => openjdk.org URLs
In-Reply-To: <7EaJFlv0rkHlPIx439wEahllhClGQMg4XOjQAeEghT8=.9fa317de-73e5-4e90-a686-17e530cbda98@github.com>
References: <7EaJFlv0rkHlPIx439wEahllhClGQMg4XOjQAeEghT8=.9fa317de-73e5-4e90-a686-17e530cbda98@github.com>
Message-ID: <SecPkLOjd1Fh4hPYn6AXQoj8VnBCsgh9_D6YP08LTpM=.92b9d246-ed3c-4805-a2bb-81acf1cf3f35@github.com>

On Wed, 12 Oct 2022 09:08:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In [JDK-8294618](https://bugs.openjdk.org/browse/JDK-8294618), many of the old references to openjdk.java.net was updated.
> 
> The test code was intentionally left out of that change, but some other instances were missed, though.
> 
> This patch will fix those misses (but will still leave test code changes to a separate fix).

Marked as reviewed by erikj (Reviewer).

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

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


From erikj at openjdk.org  Wed Oct 12 13:19:22 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 12 Oct 2022 13:19:22 GMT
Subject: RFR: 8295205: Add jcheck whitespace checking for markdown files
In-Reply-To: <JwAKg2dZVM1FL866mSl5HD8OaLQn1cpUHfV_BSEpIBs=.6d783546-3b70-4858-b070-d7476d12b58c@github.com>
References: <JwAKg2dZVM1FL866mSl5HD8OaLQn1cpUHfV_BSEpIBs=.6d783546-3b70-4858-b070-d7476d12b58c@github.com>
Message-ID: <2owj2BREdvPlEo70s1rAvPywZeUPcimsej24fiAHyB4=.26f3a76b-0765-49ea-882d-591748bf1dcf@github.com>

On Wed, 12 Oct 2022 09:44:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Markdown files are basically source code for documentation. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.

Thank you! Since I enabled visible whitespace in emacs (to be able to properly edit makefiles) editing any file where trailing whitespace isn't enforced makes my eyes bleed. :)

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

Marked as reviewed by erikj (Reviewer).

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


From erikj at openjdk.org  Wed Oct 12 13:22:07 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 12 Oct 2022 13:22:07 GMT
Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v21]
In-Reply-To: <D-ITPMwo33auL08XGAc39o68120N5xzJrdU8_oNZEOY=.9d2c0e17-e793-4d85-9304-5c94d813d216@github.com>
References: <RrlZAKdgm0ZtogXG3iVPpmaFQB1Y0kQL2bQPGe6eRus=.95a23c3d-ae0c-4c8f-aab0-2d755236f6f7@github.com>
 <D-ITPMwo33auL08XGAc39o68120N5xzJrdU8_oNZEOY=.9d2c0e17-e793-4d85-9304-5c94d813d216@github.com>
Message-ID: <COesAV9tmq-MUNzKOCS6P51whzVWGstZqRAjFw39hWI=.543e974d-cade-4d33-b218-7d54ca45e91d@github.com>

On Wed, 12 Oct 2022 11:04:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot.
>> 
>> Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files.
>> 
>> Some warnings didn't trigger in any file anymore, and could just be removed.
>> 
>> Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back.
>> 
>> I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily.
>> 
>> I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround.
>> 
>> It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++).
>> 
>> Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Github workflow changes were not supposed to be in this PR...

Marked as reviewed by erikj (Reviewer).

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

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


From ihse at openjdk.org  Wed Oct 12 13:22:08 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 13:22:08 GMT
Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v21]
In-Reply-To: <D-ITPMwo33auL08XGAc39o68120N5xzJrdU8_oNZEOY=.9d2c0e17-e793-4d85-9304-5c94d813d216@github.com>
References: <RrlZAKdgm0ZtogXG3iVPpmaFQB1Y0kQL2bQPGe6eRus=.95a23c3d-ae0c-4c8f-aab0-2d755236f6f7@github.com>
 <D-ITPMwo33auL08XGAc39o68120N5xzJrdU8_oNZEOY=.9d2c0e17-e793-4d85-9304-5c94d813d216@github.com>
Message-ID: <SOh0if_Vgf5CSG69IDNNd0VTYObuAIEYtD6Zhe9gowI=.efcc30d8-6933-4301-86b3-bcd8aa316293@github.com>

On Wed, 12 Oct 2022 11:04:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot.
>> 
>> Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files.
>> 
>> Some warnings didn't trigger in any file anymore, and could just be removed.
>> 
>> Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back.
>> 
>> I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily.
>> 
>> I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround.
>> 
>> It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++).
>> 
>> Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Github workflow changes were not supposed to be in this PR...

Thanks. Maybe you can make some coffee of that excess 1 kWh heat? ;)

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

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


From erikj at openjdk.org  Wed Oct 12 13:26:20 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 12 Oct 2022 13:26:20 GMT
Subject: RFR: 8295211: Fix autoconf 2.71 warning
 "AC_CHECK_HEADERS: you should use literals"
In-Reply-To: <TFuckcu3wKtT0Cq53Ti_mAli1s-JLUxTtuFBEeVO7sw=.745e1a6f-998c-47f1-8d35-5ee13223b0b6@github.com>
References: <TFuckcu3wKtT0Cq53Ti_mAli1s-JLUxTtuFBEeVO7sw=.745e1a6f-998c-47f1-8d35-5ee13223b0b6@github.com>
Message-ID: <cfzaF2HccyYf69OEXCoCextX0Jjhrf_vvLFSjAOSnz0=.1c119368-214d-4fd4-ab91-f9e63aa29461@github.com>

On Wed, 12 Oct 2022 10:23:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In autoconf 2.71, there is a warning generated for calling AC_CHECK_HEADERS with a variable.
> 
> It is not clear to me why they consider this to be a problem, but the warning is printed whenever you run configure with autoconf 2.71 or newer, and it is annoying.
> 
> We're only doing this in one place. Let's hardcode the values instead so we get rid of the warning.

Marked as reviewed by erikj (Reviewer).

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

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


From ihse at openjdk.org  Wed Oct 12 13:34:13 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 13:34:13 GMT
Subject: RFR: 8295192: Use original configure command line when called from
 a script
In-Reply-To: <CfmrQekVnw-igzz3MoM3hU4jQUsoQvZqy9IaMczGOUY=.0608299e-8bf2-4ef7-af33-98df034de847@github.com>
References: <CfmrQekVnw-igzz3MoM3hU4jQUsoQvZqy9IaMczGOUY=.0608299e-8bf2-4ef7-af33-98df034de847@github.com>
Message-ID: <A2tqkhyaqvmRXcs19dZYKqXmBpTVWfR9Kg08c6AnE0Y=.4d4f8df4-5f2e-49a1-9051-f0c958ba7a96@github.com>

On Wed, 12 Oct 2022 08:07:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Sometimes, the configure script is not called directly, but indirectly, using e.g. a wrapper script. This happens for instance in the case of using jib.sh.
> 
> In such cases, calling "make reconfigure" will not re-execute the original wrapper script. This can result in subtle bugs.
> 
> Instead, make a way to save the original command line from a wrapper script, and use that instead when running "make reconfigure". 
> 
> This PR also includes the corresponding changes needed to utilize this in jib.sh.

I've verified that the environment variables are properly set. I don't know what else to test. Do you have any suggestions?

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

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


From ihse at openjdk.org  Wed Oct 12 13:34:32 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 13:34:32 GMT
Subject: Integrated: 8295205: Add jcheck whitespace checking for markdown files
In-Reply-To: <JwAKg2dZVM1FL866mSl5HD8OaLQn1cpUHfV_BSEpIBs=.6d783546-3b70-4858-b070-d7476d12b58c@github.com>
References: <JwAKg2dZVM1FL866mSl5HD8OaLQn1cpUHfV_BSEpIBs=.6d783546-3b70-4858-b070-d7476d12b58c@github.com>
Message-ID: <4JUC33BHEbQxyvmLXseCLGOGURYFR_6f0uHcyJaGUkc=.cb1528a9-2718-4bfc-9a70-dce6a9e4db00@github.com>

On Wed, 12 Oct 2022 09:44:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Markdown files are basically source code for documentation. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.

This pull request has now been integrated.

Changeset: 86078423
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/860784238ea1f3e4a817fc3c28fb89cfee7549dd
Stats:     34 lines in 9 files changed: 0 ins; 0 del; 34 mod

8295205: Add jcheck whitespace checking for markdown files

Reviewed-by: erikj

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

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


From kbarrett at openjdk.org  Wed Oct 12 13:37:13 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 12 Oct 2022 13:37:13 GMT
Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v21]
In-Reply-To: <D-ITPMwo33auL08XGAc39o68120N5xzJrdU8_oNZEOY=.9d2c0e17-e793-4d85-9304-5c94d813d216@github.com>
References: <RrlZAKdgm0ZtogXG3iVPpmaFQB1Y0kQL2bQPGe6eRus=.95a23c3d-ae0c-4c8f-aab0-2d755236f6f7@github.com>
 <D-ITPMwo33auL08XGAc39o68120N5xzJrdU8_oNZEOY=.9d2c0e17-e793-4d85-9304-5c94d813d216@github.com>
Message-ID: <f5OzDB4gnlueQO5ISaf2cn7vvMAT87nZjH_EF2KVB1U=.476423ed-39c9-41ce-ae2c-1d50920ff997@github.com>

On Wed, 12 Oct 2022 11:04:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot.
>> 
>> Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files.
>> 
>> Some warnings didn't trigger in any file anymore, and could just be removed.
>> 
>> Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back.
>> 
>> I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily.
>> 
>> I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround.
>> 
>> It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++).
>> 
>> Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Github workflow changes were not supposed to be in this PR...

make/hotspot/lib/CompileJvm.gmk line 92:

> 90: 
> 91: DISABLED_WARNINGS_clang := ignored-qualifiers sometimes-uninitialized \
> 92:     missing-braces delete-non-abstract-non-virtual-dtor unknown-pragmas

Shouldn't shift-negative-value be in the clang list too?

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

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


From ihse at openjdk.org  Wed Oct 12 13:37:14 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 13:37:14 GMT
Subject: Integrated: 8295211: Fix autoconf 2.71 warning
 "AC_CHECK_HEADERS: you should use literals"
In-Reply-To: <TFuckcu3wKtT0Cq53Ti_mAli1s-JLUxTtuFBEeVO7sw=.745e1a6f-998c-47f1-8d35-5ee13223b0b6@github.com>
References: <TFuckcu3wKtT0Cq53Ti_mAli1s-JLUxTtuFBEeVO7sw=.745e1a6f-998c-47f1-8d35-5ee13223b0b6@github.com>
Message-ID: <Reh1_8dTozbABvjEWc3amuBumUwi5H2DSCWAYP8LBNs=.9eb6f4be-37cc-4352-8a80-8e199748f227@github.com>

On Wed, 12 Oct 2022 10:23:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In autoconf 2.71, there is a warning generated for calling AC_CHECK_HEADERS with a variable.
> 
> It is not clear to me why they consider this to be a problem, but the warning is printed whenever you run configure with autoconf 2.71 or newer, and it is annoying.
> 
> We're only doing this in one place. Let's hardcode the values instead so we get rid of the warning.

This pull request has now been integrated.

Changeset: c357b590
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c357b5908a091a77bc2b26d74a38785412b88a73
Stats:     31 lines in 1 file changed: 17 ins; 12 del; 2 mod

8295211: Fix autoconf 2.71 warning "AC_CHECK_HEADERS: you should use literals"

Reviewed-by: shade, erikj

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

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


From ihse at openjdk.org  Wed Oct 12 13:38:22 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 13:38:22 GMT
Subject: Integrated: 8295198: Update more openjdk.java.net => openjdk.org URLs
In-Reply-To: <7EaJFlv0rkHlPIx439wEahllhClGQMg4XOjQAeEghT8=.9fa317de-73e5-4e90-a686-17e530cbda98@github.com>
References: <7EaJFlv0rkHlPIx439wEahllhClGQMg4XOjQAeEghT8=.9fa317de-73e5-4e90-a686-17e530cbda98@github.com>
Message-ID: <g0gDFAFsqlCPyH0w6XieaTurtqBksuinEbdiBOgLfuw=.b05f4242-0f85-4146-a20f-affc3a94bfd1@github.com>

On Wed, 12 Oct 2022 09:08:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In [JDK-8294618](https://bugs.openjdk.org/browse/JDK-8294618), many of the old references to openjdk.java.net was updated.
> 
> The test code was intentionally left out of that change, but some other instances were missed, though.
> 
> This patch will fix those misses (but will still leave test code changes to a separate fix).

This pull request has now been integrated.

Changeset: 84022605
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8402260535eae0fb8bca2327372d03e33cc2add9
Stats:     15 lines in 6 files changed: 0 ins; 1 del; 14 mod

8295198: Update more openjdk.java.net => openjdk.org URLs

Reviewed-by: erikj

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

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


From ihse at openjdk.org  Wed Oct 12 13:40:11 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 13:40:11 GMT
Subject: Integrated: 8295213: Run GHA manually with user-specified make and
 configure arguments
In-Reply-To: <FKBotp8a9yQa5qRoU-kzYgg62UHs-0wM-rbli1UPrzY=.1537013e-dfe9-4e99-b446-249247885e17@github.com>
References: <FKBotp8a9yQa5qRoU-kzYgg62UHs-0wM-rbli1UPrzY=.1537013e-dfe9-4e99-b446-249247885e17@github.com>
Message-ID: <SVaLgcvRZUX3K4LhN8gOgOs6SnGJPo2iTOLU5QLlsxo=.8fd57307-3b3a-4427-8b06-23ee5ac5d938@github.com>

On Wed, 12 Oct 2022 11:05:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> It is a trivial addition to our GHA scripts to allow the user to trigger a manual run, and to provide additional arguments to `make` and `configure` for that run. (Not all arguments will succeed though, if it conflicts with the GHA setup.) But it is an easy way to test some specific ways of building.

This pull request has now been integrated.

Changeset: 760a260f
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/760a260fbbe733a76c18e4d630999c94ac8cfe63
Stats:     60 lines in 5 files changed: 52 ins; 0 del; 8 mod

8295213: Run GHA manually with user-specified make and configure arguments

Reviewed-by: shade

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

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


From ihse at openjdk.org  Wed Oct 12 13:45:14 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 13:45:14 GMT
Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v21]
In-Reply-To: <f5OzDB4gnlueQO5ISaf2cn7vvMAT87nZjH_EF2KVB1U=.476423ed-39c9-41ce-ae2c-1d50920ff997@github.com>
References: <RrlZAKdgm0ZtogXG3iVPpmaFQB1Y0kQL2bQPGe6eRus=.95a23c3d-ae0c-4c8f-aab0-2d755236f6f7@github.com>
 <D-ITPMwo33auL08XGAc39o68120N5xzJrdU8_oNZEOY=.9d2c0e17-e793-4d85-9304-5c94d813d216@github.com>
 <f5OzDB4gnlueQO5ISaf2cn7vvMAT87nZjH_EF2KVB1U=.476423ed-39c9-41ce-ae2c-1d50920ff997@github.com>
Message-ID: <UAi3fwKEz_3ASlZTAe6KR5aFUUxGDatdQYaPnNjQEFQ=.2fafab0b-86a0-4c21-8e5f-dc2e5bd772f7@github.com>

On Wed, 12 Oct 2022 13:33:26 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Github workflow changes were not supposed to be in this PR...
>
> make/hotspot/lib/CompileJvm.gmk line 92:
> 
>> 90: 
>> 91: DISABLED_WARNINGS_clang := ignored-qualifiers sometimes-uninitialized \
>> 92:     missing-braces delete-non-abstract-non-virtual-dtor unknown-pragmas
> 
> Shouldn't shift-negative-value be in the clang list too?

Well, there is currently no instance of clang complaining about this. This could be due to:

* This warning does not really exist on clang
* Or it is not enabled by our current clang flags
* Or the code which triggers the warning in gcc is not reached by clang
* Or clang is smarter than gcc and can determine that the usage is ok after all
* Or clang is dumber than gcc and does not even see that there could have been a problem...

...

I'm kind of reluctant to add warnings to this list that have not occurred for real. My suggestion is that we add it here if we ever see it making incorrect claims. Ok?

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

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


From aph at openjdk.org  Wed Oct 12 13:54:05 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 12 Oct 2022 13:54:05 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic
In-Reply-To: <_1A5xHTrbMO1_G-ctty0HXkdBhoTSPRo_MRMFktm1xY=.aded8e35-ba59-433e-8e41-af3b80ffeca6@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <_1A5xHTrbMO1_G-ctty0HXkdBhoTSPRo_MRMFktm1xY=.aded8e35-ba59-433e-8e41-af3b80ffeca6@github.com>
Message-ID: <OVLVZCYSgwazKj11R8oB5RK6wPJUQTZr2yK43Sj_gaw=.e055f06b-1feb-4228-9a2c-ec9b6dda2759@github.com>

On Tue, 11 Oct 2022 18:45:56 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> It seems strange to me that the native library part is here:
> 
> test/hotspot/jtreg/runtime/jni/TestDenormalFloat/libfast-math.c
> 
> and the two test files are here:
> 
> test/hotspot/jtreg/compiler/floatingpoint/TestDenormalDouble.java test/hotspot/jtreg/compiler/floatingpoint/TestDenormalFloat.java

I already moved it.

> And the two tests don't have "@run main/native"... Maybe I'm missing something about what you're trying to test here.

Will fix.

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

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


From chagedorn at openjdk.org  Wed Oct 12 13:56:12 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 12 Oct 2022 13:56:12 GMT
Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed [v4]
In-Reply-To: <jx2kU4A0gxp4YCjuO5EP-nxww4wpHTc-vAZd9pJ__TE=.2b87d2e4-8fc8-4bbf-837c-0bac60362121@github.com>
References: <Cuo-hZ2dmp5Su2aMvYe3k_w_rEuzCk7F8wpeCsQuyMA=.911a0412-42c0-44a1-8863-e94e5a7970e7@github.com>
 <jx2kU4A0gxp4YCjuO5EP-nxww4wpHTc-vAZd9pJ__TE=.2b87d2e4-8fc8-4bbf-837c-0bac60362121@github.com>
Message-ID: <7OZU4WgKLkiepkWFzN_VP4zsHRy9EkbmOFtco2AAhPw=.35345d5f-100d-474a-a3cc-dcab48bc1219@github.com>

On Tue, 11 Oct 2022 08:18:08 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> The DWARF debugging symbols emitted by Clang is different from what GCC is emitting. While GCC produces a complete `.debug_aranges` section (which is required in the DWARF parser), Clang does not. As a result, the DWARF parser cannot find the necessary information to proceed and create the line number information:
>> 
>> The `.debug_aranges` section contains address range to compilation unit offset mappings. The parsing algorithm can just walk through all these entries to find the correct address range that contains the library offset of the current pc. This gives us the compilation unit offset into the `.debug_info` section from where we can proceed to parse the line number information.
>> 
>> Without a complete `.debug_aranges` section, we fail with an assertion that we could not find the correct entry. Since [JDK-8293402](https://bugs.openjdk.org/browse/JDK-8293402), we will still get the complete stack trace at least. Nevertheless, we should still fix this assertion failure of course. But that would require a different parsing approach. We need to parse the entire `.debug_info` section instead to get to the correct compilation unit. This, however, would require a lot more work. 
>> 
>> I therefore suggest to disable DWARF parsing for Clang for now and file an RFE to support Clang in the future with a different parsing approach. I'm using the `__clang__` `ifdef` to bail out in `get_source_info()` and disable the `gtests`. I've noticed that we are currently running the `gtests` with `NOT PRODUCT` which I think is not necessary - the gtests should also work fine with product builds. I've corrected this as well but that could also be done separately.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn 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 six additional commits since the last revision:
> 
>  - Always read full filename and strip prefix path and only then cut filename to fit output buffer
>  - Merge branch 'master' into JDK-8293422
>  - Merge branch 'master' into JDK-8293422
>  - Review comments from Thomas
>  - Change old bailout fix to only apply to Clang versions older than 5.0 and add new fix with -gdwarf-aranges + -gdwarf-4 for Clang 5.0+
>  - 8293422: DWARF emitted by Clang cannot be parsed

That would be an option to bump that minimum version to get rid of the `ifdefs` for clang 5.0. But since this has quite an impact, are we allowed to just do that in this change or is it required to have a separate task for that with approvals first? We would also need to change the docs to reflect that change etc.

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

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


From aph at openjdk.org  Wed Oct 12 14:00:31 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 12 Oct 2022 14:00:31 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic
In-Reply-To: <yT1eFrpO6OYr1ick-L0ZnLZqMgHJmuXJRM6qnBwDkOk=.510a404d-5166-4bb8-be1e-d11deb53bdb4@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <yT1eFrpO6OYr1ick-L0ZnLZqMgHJmuXJRM6qnBwDkOk=.510a404d-5166-4bb8-be1e-d11deb53bdb4@github.com>
Message-ID: <cQdg2lwETa4_9iZrl5_0yWLTgUOEHUXWWtLb_frahc0=.54c3365f-3b9b-4f36-8e47-f7719a669a45@github.com>

On Wed, 12 Oct 2022 00:38:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This appears to be a 10 year old bug in gcc. Have we ever had any issues reported because of this?

That's what is so insidious about messing with the floating-point control word: all that happens is people get slightly inaccurate results, which they don't notice.

> Inserting a workaround now seems rather late. Any FP-using native code can potentially break Java's FP semantics if it messes with the FPU control word (ref the old Borland compilers).

Indeed, but there seem to be a number of libraries out there compiled with -ffast-math. This is the kind of thing people do with highly performance-critical stuff like ray tracing, etc. But we don't want it to break Java.

> Shouldn't any workaround only be needed for the internals of `System.loadLibrary` as other JDK usages of `dlopen` should know what they are opening and that they are libraries that don't have this problem?

Maybe, but sometimes we use system- or user-provided librries.

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

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


From aph at openjdk.org  Wed Oct 12 14:00:31 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 12 Oct 2022 14:00:31 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic
In-Reply-To: <vfPoZy9uWPo7hkwdsoW-U8r3p_m2qgRHpuONPajPu6Q=.4f6e52e1-8826-49a4-b424-36a11d5e57d5@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <JJhK3Y6aieI-8zNu8anpIUrj6n-MhWkHp2uJCDbcNbs=.0376afdc-7dc4-4232-b889-14e3f467fc82@github.com>
 <vfPoZy9uWPo7hkwdsoW-U8r3p_m2qgRHpuONPajPu6Q=.4f6e52e1-8826-49a4-b424-36a11d5e57d5@github.com>
Message-ID: <0KP9pSAaKoDlHfA-yBHi1T4LXnIcPNIM0WnnYo1pwG8=.813aeb96-c059-4cb4-a10a-688e4e00ecf4@github.com>

On Wed, 12 Oct 2022 11:28:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > Also: this patch is Linux-only. I'll ask for help from build experts to make the tests GCC-only; it's not clear to me how.
> 
> @theRealAph We currently have a more or less 1-to-1 relationship between OS and compiler. From a portability perspective this is not ideal, but it is also hard to keep some kind of theoretical barrier when it never is tested.

I see.

> Are you worried that this is a problem that occurs with gcc on other platforms as well, or that it occurs on linux with other compilers than gcc?

The former.

> We do not support gcc on macos, windows or aix, which leaves linux as the only gcc platform in the mainline (ports in separate repos will have to handle this themselves). We do support using clang on linux instead of gcc (but do not test it regularly). But my impression here is that this is more of a gcc-problem than a linux problem..?

Probably, yes. I'm happy just to fix it on Linux.

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

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


From jwaters at openjdk.org  Wed Oct 12 14:06:03 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 12 Oct 2022 14:06:03 GMT
Subject: RFR: 8295070: Introduce more target combinations for compiler
 flags [v3]
In-Reply-To: <dEz1C15HnujCTsRaRZ_0G9DV_Z0fyun60AzAfq04hNw=.92012cfb-2a75-4d7f-b062-b5b40b102b4e@github.com>
References: <alUrMJ4fQy9z3dKu3BideMeVLc7DhlUbd_IWx79mZVU=.74eb4654-00b0-497f-9450-e87d9b435e37@github.com>
 <dEz1C15HnujCTsRaRZ_0G9DV_Z0fyun60AzAfq04hNw=.92012cfb-2a75-4d7f-b062-b5b40b102b4e@github.com>
Message-ID: <DAQK1LXO0twDsgbjHpEpslWenr-_9HC59OYN25zXwc4=.627800dc-4ae8-4970-8390-4df0316ba6a3@github.com>

On Mon, 10 Oct 2022 15:29:16 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Several parts of the make system in the JDK has large parts of cluttered if branches dedicated to setting flags for the specific compiler used in the build. This could be more neatly accomplished by instead adding more target combinations in SetupNativeCompilation so the callsite can more cleanly specify which OS and compiler it desires to set these flags for. The change currently includes:
>> 
>> DISABLED_WARNINGS (including per file warnings), CFLAGS/CXXFLAGS and LDFLAGS: Compiler-then-OS (The priority shown reflects how the flags depend more so on the compiler)
>> LIBS: OS-then-Compiler, as libraries typically vary based on the system being compiled for
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extra spacing

java.desktop and jdk.jpackage in particular suffer the most from this issue, as both have many flags that often different between these combinations, for instance in Awt2dLibraries.gmk:

LIBAWT_CFLAGS += -D__MEDIALIB_OLD_NAMES -D__USE_J2D_NAMES $(X_CFLAGS)

LIBAWT_CFLAGS += -DMLIB_NO_LIBSUNMATH

ifeq ($(call isTargetOs, windows), true)
  LIBAWT_CFLAGS += -EHsc -DUNICODE -D_UNICODE
  ifeq ($(call isTargetCpuBits, 64), true)
    LIBAWT_CFLAGS += -DMLIB_OS64BIT
  endif

  LIBAWT_RCFLAGS ?= -I$(TOPDIR)/src/java.base/windows/native/launcher/icons
  LIBAWT_VERSIONINFO_RESOURCE := $(TOPDIR)/src/$(MODULE)/windows/native/libawt/windows/awt.rc
endif

ifeq ($(call isTargetOs, linux), true)
  # FIXME: This is probably not what we want to do, but keep it now for compatibility.
  LIBAWT_CFLAGS += $(EXPORT_ALL_SYMBOLS)
endif

# Turn off all warnings for debug_mem.c This is needed because the specific warning
# about initializing a declared 'extern' cannot be turned off individually. Only
# applies to debug builds.
ifeq ($(TOOLCHAIN_TYPE), gcc)
  BUILD_LIBAWT_debug_mem.c_CFLAGS := -w
  # This option improves performance of MaskFill in Java2D by 20% for some gcc
  LIBAWT_CFLAGS += -fgcse-after-reload
endif
  ifeq ($(call isTargetOs, macosx), true)
    LIBSPLASHSCREEN_CFLAGS += -DWITH_MACOSX

    BUILD_LIBSPLASHSCREEN_java_awt_SplashScreen.c_CFLAGS := -x objective-c -O0
    BUILD_LIBSPLASHSCREEN_splashscreen_gfx_impl.c_CFLAGS := -x objective-c -O0
    BUILD_LIBSPLASHSCREEN_splashscreen_gif.c_CFLAGS := -x objective-c -O0
    BUILD_LIBSPLASHSCREEN_splashscreen_impl.c_CFLAGS := -x objective-c -O0
    BUILD_LIBSPLASHSCREEN_splashscreen_jpeg.c_CFLAGS := -x objective-c -O0
    BUILD_LIBSPLASHSCREEN_splashscreen_png.c_CFLAGS := -x objective-c -O0
    BUILD_LIBSPLASHSCREEN_splashscreen_sys.m_CFLAGS := -O0

  else ifeq ($(call isTargetOs, windows), true)
    LIBSPLASHSCREEN_CFLAGS += -DWITH_WIN32
  else
    LIBSPLASHSCREEN_CFLAGS += -DWITH_X11 $(X_CFLAGS)
  endif

  LIBSPLASHSCREEN_LIBS :=

  ifeq ($(call isTargetOs, macosx), true)
    LIBSPLASHSCREEN_LIBS += \
        $(LIBM) -lpthread -liconv -losxapp \
        -framework ApplicationServices \
        -framework Foundation \
        -framework Security \
        -framework Cocoa \
        -framework Metal
  else ifeq ($(call isTargetOs, windows), true)
    LIBSPLASHSCREEN_LIBS += kernel32.lib user32.lib gdi32.lib delayimp.lib $(WIN_JAVA_LIB) jvm.lib
  else
    LIBSPLASHSCREEN_LIBS += $(X_LIBS) -lX11 -lXext $(LIBM) -lpthread -ldl
  endif

  BUILD_LIBFREETYPE_CFLAGS := -DFT2_BUILD_LIBRARY $(EXPORT_ALL_SYMBOLS)

  # For use by libfontmanager:
  LIBFREETYPE_CFLAGS := -I$(BUILD_LIBFREETYPE_HEADER_DIRS)
  ifeq ($(call isTargetOs, windows), true)
    LIBFREETYPE_LIBS := $(SUPPORT_OUTPUTDIR)/native/$(MODULE)/libfreetype/freetype.lib
    # freetype now requires you to manually define this (see ftconfig.h)
    BUILD_LIBFREETYPE_CFLAGS += -DDLL_EXPORT
  else
    LIBFREETYPE_LIBS := -lfreetype
  endif

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

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


From aph at openjdk.org  Wed Oct 12 14:11:46 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 12 Oct 2022 14:11:46 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v3]
In-Reply-To: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
Message-ID: <Q4DgAWNodNVfyhW3KEHgtYSer--pdaNSeSywRshknuk=.27200268-29ee-4ad2-992a-c216c024d247@github.com>

> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
> 
> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
> 
> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
> 
> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10661/files
  - new: https://git.openjdk.org/jdk/pull/10661/files/8d834739..d5655d4e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10661&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10661&range=01-02

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

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


From aph at openjdk.org  Wed Oct 12 14:11:48 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 12 Oct 2022 14:11:48 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic
In-Reply-To: <0KP9pSAaKoDlHfA-yBHi1T4LXnIcPNIM0WnnYo1pwG8=.813aeb96-c059-4cb4-a10a-688e4e00ecf4@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <JJhK3Y6aieI-8zNu8anpIUrj6n-MhWkHp2uJCDbcNbs=.0376afdc-7dc4-4232-b889-14e3f467fc82@github.com>
 <vfPoZy9uWPo7hkwdsoW-U8r3p_m2qgRHpuONPajPu6Q=.4f6e52e1-8826-49a4-b424-36a11d5e57d5@github.com>
 <0KP9pSAaKoDlHfA-yBHi1T4LXnIcPNIM0WnnYo1pwG8=.813aeb96-c059-4cb4-a10a-688e4e00ecf4@github.com>
Message-ID: <czDJ1ZnsItR81JR0f34lsBlhdOngivD9ttarhNZYyPM=.03733815-7e01-4c79-9052-6bbff185cd27@github.com>

On Wed, 12 Oct 2022 13:58:06 GMT, Andrew Haley <aph at openjdk.org> wrote:

> We do not support gcc on macos, windows or aix, which leaves linux as the only gcc platform in the mainline (ports in separate repos will have to handle this themselves). We do support using clang on linux instead of gcc (but do not test it regularly). But my impression here is that this is more of a gcc-problem than a linux problem..?

Indeed. The problem is that we have no idea what compiler was used to compile the libraries we call, so I'd like to be conservative. The increase in runtime due to saving and restoring the floating-point environment is very low, given that `dlopen()` is a pretty expensive operation.

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

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


From ihse at openjdk.org  Wed Oct 12 14:15:39 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 14:15:39 GMT
Subject: RFR: 8295229: Try to verify gtest version
Message-ID: <XIEbWu2S5XQ_EOkB86p15BxKyrdUJjVSxTIMf4AMCmY=.b58124c1-16e3-4d6c-a2f2-290d467c25f5@github.com>

Inspired by the comment https://github.com/openjdk/jdk/pull/10503#issuecomment-1275500585 for JDK-8294623, I realized we need to do at least some kind of version verification of gtest.

Since gtest do not properly declare its version, this can't be done exactly, but we can look at some tell-tales and rule out versions that are way too far off.

I also updated the testing documentation to point to the build information about how to point to the gtest source, and the version requirements.

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

Commit messages:
 - 8295229: Try to verify gtest version

Changes: https://git.openjdk.org/jdk/pull/10677/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10677&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295229
  Stats: 26 lines in 3 files changed: 22 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10677.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10677/head:pull/10677

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


From ihse at openjdk.org  Wed Oct 12 14:20:08 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 14:20:08 GMT
Subject: RFR: 8295229: Try to verify gtest version [v2]
In-Reply-To: <XIEbWu2S5XQ_EOkB86p15BxKyrdUJjVSxTIMf4AMCmY=.b58124c1-16e3-4d6c-a2f2-290d467c25f5@github.com>
References: <XIEbWu2S5XQ_EOkB86p15BxKyrdUJjVSxTIMf4AMCmY=.b58124c1-16e3-4d6c-a2f2-290d467c25f5@github.com>
Message-ID: <nHoZ1K7dUwosAG2HXrTn1-vpJ_OLLf0-8clEF0faM9Q=.72c31884-e3b9-4d5a-aed2-d692f4962868@github.com>

> Inspired by the comment https://github.com/openjdk/jdk/pull/10503#issuecomment-1275500585 for JDK-8294623, I realized we need to do at least some kind of version verification of gtest.
> 
> Since gtest do not properly declare its version, this can't be done exactly, but we can look at some tell-tales and rule out versions that are way too far off.
> 
> I also updated the testing documentation to point to the build information about how to point to the gtest source, and the version requirements.

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 two additional commits since the last revision:

 - Merge branch 'master' into try-verify-gtest-version
 - 8295229: Try to verify gtest version

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10677/files
  - new: https://git.openjdk.org/jdk/pull/10677/files/81b7e4c9..9e0366a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10677&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10677&range=00-01

  Stats: 241 lines in 31 files changed: 139 ins; 23 del; 79 mod
  Patch: https://git.openjdk.org/jdk/pull/10677.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10677/head:pull/10677

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


From ihse at openjdk.org  Wed Oct 12 14:22:07 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 14:22:07 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v3]
In-Reply-To: <Q4DgAWNodNVfyhW3KEHgtYSer--pdaNSeSywRshknuk=.27200268-29ee-4ad2-992a-c216c024d247@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <Q4DgAWNodNVfyhW3KEHgtYSer--pdaNSeSywRshknuk=.27200268-29ee-4ad2-992a-c216c024d247@github.com>
Message-ID: <jsvu49diVRIHMpkZe4pheHQyFTCB__GyBoT1fF6_sRI=.17cf255f-58fe-4d05-be20-7a40f8a623fb@github.com>

On Wed, 12 Oct 2022 14:11:46 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>> 
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>> 
>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
>> 
>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

So you want to provide this dlopen wrapper for other platforms as well?

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

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


From ihse at openjdk.org  Wed Oct 12 14:30:07 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 14:30:07 GMT
Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed [v4]
In-Reply-To: <jx2kU4A0gxp4YCjuO5EP-nxww4wpHTc-vAZd9pJ__TE=.2b87d2e4-8fc8-4bbf-837c-0bac60362121@github.com>
References: <Cuo-hZ2dmp5Su2aMvYe3k_w_rEuzCk7F8wpeCsQuyMA=.911a0412-42c0-44a1-8863-e94e5a7970e7@github.com>
 <jx2kU4A0gxp4YCjuO5EP-nxww4wpHTc-vAZd9pJ__TE=.2b87d2e4-8fc8-4bbf-837c-0bac60362121@github.com>
Message-ID: <mP9vNVA88HN8lnZq6DHqVsvhQEIiBF61qMrU25Bk88w=.6aa400c4-2ce3-43f3-bb59-d14914d076f0@github.com>

On Tue, 11 Oct 2022 08:18:08 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> The DWARF debugging symbols emitted by Clang is different from what GCC is emitting. While GCC produces a complete `.debug_aranges` section (which is required in the DWARF parser), Clang does not. As a result, the DWARF parser cannot find the necessary information to proceed and create the line number information:
>> 
>> The `.debug_aranges` section contains address range to compilation unit offset mappings. The parsing algorithm can just walk through all these entries to find the correct address range that contains the library offset of the current pc. This gives us the compilation unit offset into the `.debug_info` section from where we can proceed to parse the line number information.
>> 
>> Without a complete `.debug_aranges` section, we fail with an assertion that we could not find the correct entry. Since [JDK-8293402](https://bugs.openjdk.org/browse/JDK-8293402), we will still get the complete stack trace at least. Nevertheless, we should still fix this assertion failure of course. But that would require a different parsing approach. We need to parse the entire `.debug_info` section instead to get to the correct compilation unit. This, however, would require a lot more work. 
>> 
>> I therefore suggest to disable DWARF parsing for Clang for now and file an RFE to support Clang in the future with a different parsing approach. I'm using the `__clang__` `ifdef` to bail out in `get_source_info()` and disable the `gtests`. I've noticed that we are currently running the `gtests` with `NOT PRODUCT` which I think is not necessary - the gtests should also work fine with product builds. I've corrected this as well but that could also be done separately.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn 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 six additional commits since the last revision:
> 
>  - Always read full filename and strip prefix path and only then cut filename to fit output buffer
>  - Merge branch 'master' into JDK-8293422
>  - Merge branch 'master' into JDK-8293422
>  - Review comments from Thomas
>  - Change old bailout fix to only apply to Clang versions older than 5.0 and add new fix with -gdwarf-aranges + -gdwarf-4 for Clang 5.0+
>  - 8293422: DWARF emitted by Clang cannot be parsed

If is is a big change or not depends on how it affects builds on macos. I assume that clang functionality that was published in 2017 is already incorporated in the minimum supported version of Xcode on mac. (This needs to be verified, though)

For clang on linux; Oracle do not regularly build linux with clang, nor do our GHA build scripts. I don't know if anyone regularly tests this. 

My guess is that the 3.5 limit was put in place when the clang for linux support was added, and it has not been modified since.

But you are probably right that it should be a separate PR, if not for anything else so to get proper attention to it. Do you want me to publish such a PR first, or do you want to continue with the current conditionals, and clean them up afterwards if/when we go to clang 5.0+?

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

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


From aph at openjdk.org  Wed Oct 12 14:33:18 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 12 Oct 2022 14:33:18 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v4]
In-Reply-To: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
Message-ID: <U8dR5QzygaDtakkpAX6h93wP3PtEVYCtQ9z_ubokLl4=.3cb43de2-ee5a-4037-8f60-48ca885cad11@github.com>

> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
> 
> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
> 
> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
> 
> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10661/files
  - new: https://git.openjdk.org/jdk/pull/10661/files/d5655d4e..fe388b8b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10661&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10661&range=02-03

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

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


From aph at openjdk.org  Wed Oct 12 14:37:37 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 12 Oct 2022 14:37:37 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v5]
In-Reply-To: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
Message-ID: <Cre-xBVajrbGp7Y6v8vP1rRiCOtdbkH6AJhHUwVXbww=.ad56e57b-db0a-4a57-9e47-b54b689a72cd@github.com>

> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
> 
> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
> 
> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
> 
> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10661/files
  - new: https://git.openjdk.org/jdk/pull/10661/files/fe388b8b..bcff4597

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10661&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10661&range=03-04

  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10661.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10661/head:pull/10661

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


From aph at openjdk.org  Wed Oct 12 14:43:10 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 12 Oct 2022 14:43:10 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v3]
In-Reply-To: <jsvu49diVRIHMpkZe4pheHQyFTCB__GyBoT1fF6_sRI=.17cf255f-58fe-4d05-be20-7a40f8a623fb@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <Q4DgAWNodNVfyhW3KEHgtYSer--pdaNSeSywRshknuk=.27200268-29ee-4ad2-992a-c216c024d247@github.com>
 <jsvu49diVRIHMpkZe4pheHQyFTCB__GyBoT1fF6_sRI=.17cf255f-58fe-4d05-be20-7a40f8a623fb@github.com>
Message-ID: <kOAZ8_R0TEsOh2UZs7ybORGY0_Fnd8u0KDWdVlE7wRI=.3aa9da86-f9a3-4980-a986-9e917d46cc66@github.com>

On Wed, 12 Oct 2022 14:19:53 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> So you want to provide this dlopen wrapper for other platforms as well?

I'm not sure. It sounds to me like a Linux-only patch would do it, but I think BSD uses GCC sometimes.
(Open/FreeBSD is downstream of OpenJDK, and I'd love to get it into mainline, but getting BSD contributors to sign OCA is hard.)

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

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


From xuelei at openjdk.org  Wed Oct 12 15:34:16 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 12 Oct 2022 15:34:16 GMT
Subject: RFR: 8295010: EC limbs addition and subtraction limit [v2]
In-Reply-To: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
Message-ID: <TAwK9hBDCv_-kKTS-MJWk0fBEJe2n33U-Ukgcoo3hMs=.882bfa2a-3992-4544-9eec-2eebf0692e02@github.com>

> Hi,
> 
> May I have this update reviewed?  With this update, the result will be always reduced in EC limbs addition and subtraction operations in the JDK implementation.
> 
> In the current implementation, the EC limbs addition and subtraction result is not reduced before the value is returned.  This behavior is different from multiplication and square.  To get it right, a maximum addition limit is introduced for EC limbs addition and subtraction.  If the limit is reached, an exception will be thrown so as to indicate an EC implementation problem.  The exception is not recoverable from the viewpoint of an application.
> 
> The design is error prone as the EC implementation code must be carefully checked so that the limit cannot reach. If a reach is noticed, a reduce operation would have to be hard-coded additionally. In the FieldGen.java implementation, the limit can only be 1 or 2 as the implementation code is only able to handle 2.  But the FieldGen.java does not really check if 1 or 2 really works for the specific filed generation parameters.
> 
> The design impact the performance as well. Because of this limit, the maximum limb size is 28 bits for 2 max adding limit. Otherwise there are integer (long) overflow issues. For example for 256 bits curves, 10 limbs are required for 28-bit limb size; and 9 limbs for 29-bit size. By reducing 1 limbs from 10 to 9, the Signature performance could get improved by 20%.
> 
> In the IntegerPolynomial class description, it is said "All IntegerPolynomial implementations allow at most one addition before multiplication. Additions after that will result in an ArithmeticException." It's too strict to follow without exam the code very carefully. Indeed, the implementation does not really follow the spec, and 2 addition may be allowed.
> 
> It would be nice if there is no addition limit, and then we are free from these issues. It is doable by reducing the limbs in the adding and subtraction operations, as other operations as multiplication. And then the code related to the limit is not necessary any longer. The code can do any many additions as required.
> 
> The benchmark for ECDSA Signature is checked in order to see how much the performance could be impacted. Here are the benchmark numbers before the patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1414.463 ?  9.616  ops/s
> Signatures.sign              512  thrpt   15  1409.023 ? 14.636  ops/s
> Signatures.sign             2048  thrpt   15  1414.488 ?  4.728  ops/s
> Signatures.sign            16384  thrpt   15  1385.685 ?  4.476  ops/s
> 
> 
> and here are the numbers with this patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1293.658 ?  8.358  ops/s
> Signatures.sign              512  thrpt   15  1298.404 ?  4.344  ops/s
> Signatures.sign             2048  thrpt   15  1289.732 ? 19.748  ops/s
> Signatures.sign            16384  thrpt   15  1278.980 ? 13.483  ops/s
> 
> 
> From the numbers, it looks like the performance impact is about 10%.  However, the performance impact could get rewarded by using less limbs.  For examples for secp256r1, I updated the limbs from [10 to 9 for integer operations](https://github.com/openjdk/jdk/pull/10398), and run the benchmark together with this patch, I could see the performance improvement as follow:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1578.568 ? 11.000  ops/s
> Signatures.sign              512  thrpt   15  1596.058 ?  4.184  ops/s
> Signatures.sign             2048  thrpt   15  1591.519 ?  6.444  ops/s
> Signatures.sign            16384  thrpt   15  1563.480 ?  6.837  ops/s
> ``` 
> 
> The following are numbers for secp256r1 key generation, without this patch:
> 
> Benchmark                      Mode  Cnt     Score   Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1531.026 ? 9.869  ops/s
> 
> 
> With this patch:
> 
> Benchmark                      Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1367.162 ? 50.322  ops/s
> 
> 
> with improved limbs (from 10 to 9):
> 
> Benchmark                      Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1713.097 ? 8.003  ops/s
> 
> If considering this PR together with [PR for JDK-8294248](https://github.com/openjdk/jdk/pull/10398), performance improvement could be expected for EC crypto primitives.
> 
> Thanks,
> Xuelei

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  reduce if needed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10624/files
  - new: https://git.openjdk.org/jdk/pull/10624/files/09747eb9..c2fa6e8b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10624&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10624&range=00-01

  Stats: 196 lines in 5 files changed: 147 ins; 4 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/10624.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10624/head:pull/10624

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


From aph at openjdk.org  Wed Oct 12 15:49:07 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 12 Oct 2022 15:49:07 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic
In-Reply-To: <cQdg2lwETa4_9iZrl5_0yWLTgUOEHUXWWtLb_frahc0=.54c3365f-3b9b-4f36-8e47-f7719a669a45@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <yT1eFrpO6OYr1ick-L0ZnLZqMgHJmuXJRM6qnBwDkOk=.510a404d-5166-4bb8-be1e-d11deb53bdb4@github.com>
 <cQdg2lwETa4_9iZrl5_0yWLTgUOEHUXWWtLb_frahc0=.54c3365f-3b9b-4f36-8e47-f7719a669a45@github.com>
Message-ID: <5hqEYIcXwutqjcM6g3AAeXGme5OpWZ9ooduEUiK3dp8=.457e808f-2c15-4b35-84e7-f6a24f27a858@github.com>

On Wed, 12 Oct 2022 13:56:56 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > This appears to be a 10 year old bug in gcc. Have we ever had any issues reported because of this?
> 
> That's what is so insidious about messing with the floating-point control word: all that happens is people get slightly inaccurate results, which they don't notice.

e.g. https://github.com/gevent/gevent/pull/1820 is for Python (SciPy) and adversely affects time to converge. I have no idea if other Java users have similar problems, but it's a bug that I'd like to go away.

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

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


From shade at openjdk.org  Wed Oct 12 16:13:12 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 12 Oct 2022 16:13:12 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v5]
In-Reply-To: <Cre-xBVajrbGp7Y6v8vP1rRiCOtdbkH6AJhHUwVXbww=.ad56e57b-db0a-4a57-9e47-b54b689a72cd@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <Cre-xBVajrbGp7Y6v8vP1rRiCOtdbkH6AJhHUwVXbww=.ad56e57b-db0a-4a57-9e47-b54b689a72cd@github.com>
Message-ID: <nM6J4hW498xns_hlrEI3_9uigk11bokDtApbp42xz7w=.9eaa7426-49e3-47f9-a041-404bc36b4f1a@github.com>

On Wed, 12 Oct 2022 14:37:37 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>> 
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>> 
>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
>> 
>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

I think the Java arithmetic correctness is the thing we are after. Allowing a stray library to break it seems very wrong. The alternative to this fix would be detecting the "bad" FPU flags like FTZ/DAZ, provided we can do that without messing with a whole lot of arch-specific code, and then asking users to opt-in for potentially breaking behavior.

But I believe current patch is the minimal thing we should do. Some nits:

src/hotspot/os/linux/os_linux.cpp line 113:

> 111: # include <sys/times.h>
> 112: # include <sys/types.h>
> 113: # include <sys/utsname.h>

Do we need to shuffle^W sort includes in this patch? I presume you'd want this patch to be cleanly backportable, which means it should probably be as point-y as it can get.

src/hotspot/os/linux/os_linux.cpp line 1747:

> 1745: void * os::Linux::dlopen_helper(const char *filename, char *ebuf,
> 1746:                                 int ebuflen) {
> 1747:   // JDK-8295159: Protect floating-point environment.

We need to be more verbose in these comments. Say something like:


There are known cases where global library initialization sets the FPU flags
that affect computation accuracy, for example, enabling Flush-To-Zero and
Denormals-Are-Zero. Do not let those libraries break the Java arithmetic.
Unfortunately, this might break the libraries that might depend on these FPU
features for performance and/or numerical "accuracy", but we need to protect 
the Java semantics first and foremost. See JDK-8295159.

src/hotspot/os/linux/os_linux.cpp line 1750:

> 1748:   fenv_t curr_fenv;
> 1749:   int rtn = fegetenv(&curr_fenv);
> 1750:   assert(rtn == 0, "must be.");

Suggestion:

  assert(rtn == 0, "fegetnv must succeed");

src/hotspot/os/linux/os_linux.cpp line 1753:

> 1751:   void * result = ::dlopen(filename, RTLD_LAZY);
> 1752:   rtn = fesetenv(&curr_fenv);
> 1753:   assert(rtn == 0, "must be.");

Suggestion:

  assert(rtn == 0, "fesetenv must succeed");

test/hotspot/jtreg/compiler/floatingpoint/TestDenormalFloat.java line 28:

> 26:  * @bug 8295159
> 27:  * @summary DSO created with -ffast-math breaks Java floating-point arithmetic
> 28:  * @run main/othervm compiler.floatingpoint.TestDenormalFloat

Should it have `/native` somewhere here?

test/hotspot/jtreg/compiler/floatingpoint/TestDenormalFloat.java line 39:

> 37: //      at compiler.floatingpoint.TestDenormalFloat.testFloats(TestDenormalFloat.java:47)
> 38: //      at compiler.floatingpoint.TestDenormalFloat.main(TestDenormalFloat.java:57)
> 39: 

This comment is redundant, I think. There seem to be little point to run these tests separately?

test/hotspot/jtreg/compiler/floatingpoint/TestDenormalFloat.java line 60:

> 58:     public static void main(String[] args) {
> 59:         testFloats();
> 60:         System.out.println("Loading libfast-math.so");

I propose we have the same logging statement in `TestDoubles`.

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

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


From aph at openjdk.org  Wed Oct 12 16:13:13 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 12 Oct 2022 16:13:13 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v5]
In-Reply-To: <nM6J4hW498xns_hlrEI3_9uigk11bokDtApbp42xz7w=.9eaa7426-49e3-47f9-a041-404bc36b4f1a@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <Cre-xBVajrbGp7Y6v8vP1rRiCOtdbkH6AJhHUwVXbww=.ad56e57b-db0a-4a57-9e47-b54b689a72cd@github.com>
 <nM6J4hW498xns_hlrEI3_9uigk11bokDtApbp42xz7w=.9eaa7426-49e3-47f9-a041-404bc36b4f1a@github.com>
Message-ID: <9bkcZXTPQDk2_dgCru30yVygdPp0Iga8MrJeINLd198=.8d4ca3c1-f9f4-45e8-afef-303af9f3fd5b@github.com>

On Wed, 12 Oct 2022 15:48:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Do we need to shuffle^W sort includes in this patch? I presume you'd want this patch to be cleanly backportable, which means it should probably be as point-y as it can get.

OK, I can back that part out.

> src/hotspot/os/linux/os_linux.cpp line 1747:
> 
>> 1745: void * os::Linux::dlopen_helper(const char *filename, char *ebuf,
>> 1746:                                 int ebuflen) {
>> 1747:   // JDK-8295159: Protect floating-point environment.
> 
> We need to be more verbose in these comments. Say something like:
> 
> 
> There are known cases where global library initialization sets the FPU flags
> that affect computation accuracy, for example, enabling Flush-To-Zero and
> Denormals-Are-Zero. Do not let those libraries break the Java arithmetic.
> Unfortunately, this might break the libraries that might depend on these FPU
> features for performance and/or numerical "accuracy", but we need to protect 
> the Java semantics first and foremost. See JDK-8295159.

Thanks, that is elegantly expressed.

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

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


From aph at openjdk.org  Wed Oct 12 16:20:10 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 12 Oct 2022 16:20:10 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v6]
In-Reply-To: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
Message-ID: <sjTC841rnzXlKIIvPNKE8i7Du-wj-_6GhUNgCij65L4=.f3565ba5-1259-4389-a747-0de6ef091900@github.com>

> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
> 
> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
> 
> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
> 
> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.

Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/hotspot/os/linux/os_linux.cpp
   
   Co-authored-by: Aleksey Shipil?v <shade at redhat.com>
 - Update src/hotspot/os/linux/os_linux.cpp
   
   Co-authored-by: Aleksey Shipil?v <shade at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10661/files
  - new: https://git.openjdk.org/jdk/pull/10661/files/bcff4597..3f442beb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10661&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10661&range=04-05

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

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


From xuelei at openjdk.org  Wed Oct 12 16:22:43 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 12 Oct 2022 16:22:43 GMT
Subject: RFR: 8295010: EC limbs addition and subtraction limit [v3]
In-Reply-To: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
Message-ID: <8ztnDOwivFAvV_iI6C3xHWfcwR-4qlURqhbI4KrAI68=.a1cbf54f-b2cb-4206-9d25-3be46bffdeaa@github.com>

> Hi,
> 
> May I have this update reviewed?  With this update, the result will be always reduced in EC limbs addition and subtraction operations in the JDK implementation.
> 
> In the current implementation, the EC limbs addition and subtraction result is not reduced before the value is returned.  This behavior is different from multiplication and square.  To get it right, a maximum addition limit is introduced for EC limbs addition and subtraction.  If the limit is reached, an exception will be thrown so as to indicate an EC implementation problem.  The exception is not recoverable from the viewpoint of an application.
> 
> The design is error prone as the EC implementation code must be carefully checked so that the limit cannot reach. If a reach is noticed, a reduce operation would have to be hard-coded additionally. In the FieldGen.java implementation, the limit can only be 1 or 2 as the implementation code is only able to handle 2.  But the FieldGen.java does not really check if 1 or 2 really works for the specific filed generation parameters.
> 
> The design impact the performance as well. Because of this limit, the maximum limb size is 28 bits for 2 max adding limit. Otherwise there are integer (long) overflow issues. For example for 256 bits curves, 10 limbs are required for 28-bit limb size; and 9 limbs for 29-bit size. By reducing 1 limbs from 10 to 9, the Signature performance could get improved by 20%.
> 
> In the IntegerPolynomial class description, it is said "All IntegerPolynomial implementations allow at most one addition before multiplication. Additions after that will result in an ArithmeticException." It's too strict to follow without exam the code very carefully. Indeed, the implementation does not really follow the spec, and 2 addition may be allowed.
> 
> It would be nice if there is no addition limit, and then we are free from these issues. It is doable by reducing the limbs in the adding and subtraction operations, as other operations as multiplication. And then the code related to the limit is not necessary any longer. The code can do any many additions as required.
> 
> The benchmark for ECDSA Signature is checked in order to see how much the performance could be impacted. Here are the benchmark numbers before the patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1414.463 ?  9.616  ops/s
> Signatures.sign              512  thrpt   15  1409.023 ? 14.636  ops/s
> Signatures.sign             2048  thrpt   15  1414.488 ?  4.728  ops/s
> Signatures.sign            16384  thrpt   15  1385.685 ?  4.476  ops/s
> 
> 
> and here are the numbers with this patch applied:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1293.658 ?  8.358  ops/s
> Signatures.sign              512  thrpt   15  1298.404 ?  4.344  ops/s
> Signatures.sign             2048  thrpt   15  1289.732 ? 19.748  ops/s
> Signatures.sign            16384  thrpt   15  1278.980 ? 13.483  ops/s
> 
> 
> From the numbers, it looks like the performance impact is about 10%.  However, the performance impact could get rewarded by using less limbs.  For examples for secp256r1, I updated the limbs from [10 to 9 for integer operations](https://github.com/openjdk/jdk/pull/10398), and run the benchmark together with this patch, I could see the performance improvement as follow:
> 
> Benchmark        (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign               64  thrpt   15  1578.568 ? 11.000  ops/s
> Signatures.sign              512  thrpt   15  1596.058 ?  4.184  ops/s
> Signatures.sign             2048  thrpt   15  1591.519 ?  6.444  ops/s
> Signatures.sign            16384  thrpt   15  1563.480 ?  6.837  ops/s
> ``` 
> 
> The following are numbers for secp256r1 key generation, without this patch:
> 
> Benchmark                      Mode  Cnt     Score   Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1531.026 ? 9.869  ops/s
> 
> 
> With this patch:
> 
> Benchmark                      Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1367.162 ? 50.322  ops/s
> 
> 
> with improved limbs (from 10 to 9):
> 
> Benchmark                      Mode  Cnt     Score    Error  Units
> KeyPairGenerators.keyPairGen  thrpt   15  1713.097 ? 8.003  ops/s
> 
> If considering this PR together with [PR for JDK-8294248](https://github.com/openjdk/jdk/pull/10398), performance improvement could be expected for EC crypto primitives.
> 
> Thanks,
> Xuelei

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  missed reduce

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10624/files
  - new: https://git.openjdk.org/jdk/pull/10624/files/c2fa6e8b..8f3ff011

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10624&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10624&range=01-02

  Stats: 14 lines in 1 file changed: 12 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10624.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10624/head:pull/10624

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


From erikj at openjdk.org  Wed Oct 12 16:39:08 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 12 Oct 2022 16:39:08 GMT
Subject: RFR: 8295229: Try to verify gtest version [v2]
In-Reply-To: <nHoZ1K7dUwosAG2HXrTn1-vpJ_OLLf0-8clEF0faM9Q=.72c31884-e3b9-4d5a-aed2-d692f4962868@github.com>
References: <XIEbWu2S5XQ_EOkB86p15BxKyrdUJjVSxTIMf4AMCmY=.b58124c1-16e3-4d6c-a2f2-290d467c25f5@github.com>
 <nHoZ1K7dUwosAG2HXrTn1-vpJ_OLLf0-8clEF0faM9Q=.72c31884-e3b9-4d5a-aed2-d692f4962868@github.com>
Message-ID: <F3AyAS6at5HZRCKQtZXJbLeb1vB0TyLftSGSeDjWSyY=.4f72d9bc-9d37-4cb8-bd89-cb712e871c48@github.com>

On Wed, 12 Oct 2022 14:20:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Inspired by the comment https://github.com/openjdk/jdk/pull/10503#issuecomment-1275500585 for JDK-8294623, I realized we need to do at least some kind of version verification of gtest.
>> 
>> Since gtest do not properly declare its version, this can't be done exactly, but we can look at some tell-tales and rule out versions that are way too far off.
>> 
>> I also updated the testing documentation to point to the build information about how to point to the gtest source, and the version requirements.
>
> 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into try-verify-gtest-version
>  - 8295229: Try to verify gtest version

Marked as reviewed by erikj (Reviewer).

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

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


From aph at openjdk.org  Wed Oct 12 17:00:15 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 12 Oct 2022 17:00:15 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
Message-ID: <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>

> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
> 
> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
> 
> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
> 
> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10661/files
  - new: https://git.openjdk.org/jdk/pull/10661/files/3f442beb..64ef36f3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10661&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10661&range=05-06

  Stats: 62 lines in 3 files changed: 27 ins; 29 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10661.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10661/head:pull/10661

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


From vlivanov at openjdk.org  Wed Oct 12 17:46:10 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 12 Oct 2022 17:46:10 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
Message-ID: <3CHKC_SEGCKm2D3rHntfxV21sx0G-AakDLPPf8rPwQc=.533cc9d9-f93b-4a6f-86f6-a221452045d4@github.com>

On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>> 
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>> 
>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
>> 
>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

Isn't it an illustration of a more general problem we have with native code where it can mess with FP environment at any time? 

We already have similar problems with MXCSR register and provide verification logic (part of `-Xcheck:jni`) to catch modifications and support conditional restoration of MXCSR register on x86_64. x86_32 validates x87 control word when `-Xcheck:jni` is enabled.

Should we do something similar here instead?

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

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


From jvernee at openjdk.org  Wed Oct 12 20:31:23 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 12 Oct 2022 20:31:23 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
Message-ID: <7yaDR-VCplkpcKoGwJ4_4rZczua_vXMVVXsZ4jFbwYg=.522bd3a5-4b70-4fd7-a6af-184fde528750@github.com>

On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>> 
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>> 
>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
>> 
>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

For upcalls on non-Windows platforms, we also save MXCSR and restore it after the call, and load a set standard value for the Java code that's about to be executed. (I'm not sure why this isn't done on Windows, tbh)

Relevant code for JNI is here:
- Downcalls: https://github.com/openjdk/jdk/blob/1961e81e02e707cd0c8241aa3af6ddabf7668589/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L5002
- Upcalls: https://github.com/openjdk/jdk/blob/1961e81e02e707cd0c8241aa3af6ddabf7668589/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#L262

FPCSR is only handled on non _LP64 it looks like.

I agree with Vladimir that this seems like a general problem of foreign code potentially messing with control bits (in theory, foreign code could violate its ABI in other ways as well). It seems that both major C/C++ x64 ABIs ([1], [2], [3]) treat the control bits as non-volatile, so the callee should preserve them. This is in theory a choice of a particular ABI, but I think in general we can assume foreign code does not modify the control bits. Though, we never know for sure of course, and I suppose this is where `RestoreMXCSROnJNICalls` comes in. There's no equivalent flag for FPCSR atm AFAICS, so the answer there seems to be "just don't do it".

Following that logic: from our perspective `dlopen` violates its ABI in certain cases. Preserving the control bits across calls to `dlopen` seems like a pragmatic solution. I'm not sure how important it is to have an opt-in for the current (broken) behavior...

[1]: https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170#fpcsr
[2]: https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170#mxcsr
[3]: https://refspecs.linuxbase.org/elf/x86_64-abi-0.99.pdf

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

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


From mcimadamore at openjdk.org  Wed Oct 12 20:39:06 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 12 Oct 2022 20:39:06 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <3CHKC_SEGCKm2D3rHntfxV21sx0G-AakDLPPf8rPwQc=.533cc9d9-f93b-4a6f-86f6-a221452045d4@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
 <3CHKC_SEGCKm2D3rHntfxV21sx0G-AakDLPPf8rPwQc=.533cc9d9-f93b-4a6f-86f6-a221452045d4@github.com>
Message-ID: <CfFMJqqw1EpqbX1K3Tv60TuX0M82gOsmBrblYzHniDo=.4226310a-1b26-4cd1-8a21-3df10cdb79b0@github.com>

On Wed, 12 Oct 2022 17:43:47 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Isn't it an illustration of a more general problem we have with native code where it can mess with FP environment at any time?
> 
> We already have similar problems with MXCSR register and provide verification logic (part of `-Xcheck:jni`) to catch modifications and support conditional restoration of MXCSR register on x86_64. x86_32 validates x87 control word when `-Xcheck:jni` is enabled.
> 
> Should we do something similar here instead?

I tend to agree. As others have observed, a `dlopen` call (or something with same nefarious behavior) could also happen inside JNI code. But I think the interesting (and perhaps surprising) part here is that, from the perspective of the developer, no native code has executed - only a library has been loaded (via `System::loadLibrary`).

Note also that this specific problem is triggered by `dlopen` itself, because certain libraries might have some "bad" (from the perspective of JVM) initialization code. But since we're talking about JNI, JNI_OnLoad is another potential source of problem, as its native code is executed as soon as the library is loaded (and that, too, can leave the JVM in a bad state).

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

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


From vlivanov at openjdk.org  Wed Oct 12 21:50:14 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 12 Oct 2022 21:50:14 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <CfFMJqqw1EpqbX1K3Tv60TuX0M82gOsmBrblYzHniDo=.4226310a-1b26-4cd1-8a21-3df10cdb79b0@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
 <3CHKC_SEGCKm2D3rHntfxV21sx0G-AakDLPPf8rPwQc=.533cc9d9-f93b-4a6f-86f6-a221452045d4@github.com>
 <CfFMJqqw1EpqbX1K3Tv60TuX0M82gOsmBrblYzHniDo=.4226310a-1b26-4cd1-8a21-3df10cdb79b0@github.com>
Message-ID: <x3HsPrEq0S7c6w4rl6L5qtNuSUTz3U_bv67H7VQCMiY=.a59e5245-6220-4596-b9f3-e44b20d5690d@github.com>

On Wed, 12 Oct 2022 20:35:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Note also that this specific problem is triggered by dlopen itself, because certain libraries might have some "bad" (from the perspective of JVM) initialization code.

... and it leads to another question whether the JVM itself is amenable to such problems. Do we need to sanitize the environment when returning from calls into the JVM?

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

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


From dzhang at openjdk.org  Thu Oct 13 02:58:07 2022
From: dzhang at openjdk.org (Dingli Zhang)
Date: Thu, 13 Oct 2022 02:58:07 GMT
Subject: RFR: 8295229: Try to verify gtest version [v2]
In-Reply-To: <nHoZ1K7dUwosAG2HXrTn1-vpJ_OLLf0-8clEF0faM9Q=.72c31884-e3b9-4d5a-aed2-d692f4962868@github.com>
References: <XIEbWu2S5XQ_EOkB86p15BxKyrdUJjVSxTIMf4AMCmY=.b58124c1-16e3-4d6c-a2f2-290d467c25f5@github.com>
 <nHoZ1K7dUwosAG2HXrTn1-vpJ_OLLf0-8clEF0faM9Q=.72c31884-e3b9-4d5a-aed2-d692f4962868@github.com>
Message-ID: <rguUQUmD0W6tQF8vlhWXpjtL4PuymrphlUpiN8UmnX8=.6350df8d-3dc4-458d-9ac8-9e229e2556ad@github.com>

On Wed, 12 Oct 2022 14:20:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Inspired by the comment https://github.com/openjdk/jdk/pull/10503#issuecomment-1275500585 for JDK-8294623, I realized we need to do at least some kind of version verification of gtest.
>> 
>> Since gtest do not properly declare its version, this can't be done exactly, but we can look at some tell-tales and rule out versions that are way too far off.
>> 
>> I also updated the testing documentation to point to the build information about how to point to the gtest source, and the version requirements.
>
> 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into try-verify-gtest-version
>  - 8295229: Try to verify gtest version

@magicus I truly appreciate your timely help!
It will be a convenient move for new developers.

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

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


From jrose at openjdk.org  Thu Oct 13 05:13:12 2022
From: jrose at openjdk.org (John R Rose)
Date: Thu, 13 Oct 2022 05:13:12 GMT
Subject: RFR: 8295229: Try to verify gtest version [v2]
In-Reply-To: <rguUQUmD0W6tQF8vlhWXpjtL4PuymrphlUpiN8UmnX8=.6350df8d-3dc4-458d-9ac8-9e229e2556ad@github.com>
References: <XIEbWu2S5XQ_EOkB86p15BxKyrdUJjVSxTIMf4AMCmY=.b58124c1-16e3-4d6c-a2f2-290d467c25f5@github.com>
 <nHoZ1K7dUwosAG2HXrTn1-vpJ_OLLf0-8clEF0faM9Q=.72c31884-e3b9-4d5a-aed2-d692f4962868@github.com>
 <rguUQUmD0W6tQF8vlhWXpjtL4PuymrphlUpiN8UmnX8=.6350df8d-3dc4-458d-9ac8-9e229e2556ad@github.com>
Message-ID: <uSFsGNtbLmqq8eCBxlrP4vZGAbPwWXZFbdDdTOxbnX8=.33db47fe-00b4-49b4-ae55-03a16fc962f5@github.com>

On Thu, 13 Oct 2022 02:56:01 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

>> 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 two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into try-verify-gtest-version
>>  - 8295229: Try to verify gtest version
>
> @magicus I truly appreciate your timely help!
> It will be a convenient move for new developers.

Looks good.  I guess we will have to find out be experience how fragile or robust are these new tests.  Thank you for cross-linking from testing.md to building.md.  I remember when I first worked with gtest the information was split between the two files, but not cross-linked, and I found it confusing to put the pieces together myself.  This makes learning gtest on hotspot easier for the next person, as @DingliZhang says.

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

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


From ihse at openjdk.org  Thu Oct 13 06:19:51 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 13 Oct 2022 06:19:51 GMT
Subject: Integrated: 8295229: Try to verify gtest version
In-Reply-To: <XIEbWu2S5XQ_EOkB86p15BxKyrdUJjVSxTIMf4AMCmY=.b58124c1-16e3-4d6c-a2f2-290d467c25f5@github.com>
References: <XIEbWu2S5XQ_EOkB86p15BxKyrdUJjVSxTIMf4AMCmY=.b58124c1-16e3-4d6c-a2f2-290d467c25f5@github.com>
Message-ID: <EMNWeiyJ2yRbi4VaX-dLry5lSgqLKUzoqoK1nYmvvZk=.c4c6e821-5856-4024-aadc-68afebfcf473@github.com>

On Wed, 12 Oct 2022 14:08:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Inspired by the comment https://github.com/openjdk/jdk/pull/10503#issuecomment-1275500585 for JDK-8294623, I realized we need to do at least some kind of version verification of gtest.
> 
> Since gtest do not properly declare its version, this can't be done exactly, but we can look at some tell-tales and rule out versions that are way too far off.
> 
> I also updated the testing documentation to point to the build information about how to point to the gtest source, and the version requirements.

This pull request has now been integrated.

Changeset: cd1357b0
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd1357b0af0d4e3b459fcf88e67510502464bb90
Stats:     23 lines in 3 files changed: 22 ins; 0 del; 1 mod

8295229: Try to verify gtest version

Reviewed-by: erikj

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

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


From chagedorn at openjdk.org  Thu Oct 13 07:33:08 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 13 Oct 2022 07:33:08 GMT
Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed [v4]
In-Reply-To: <mP9vNVA88HN8lnZq6DHqVsvhQEIiBF61qMrU25Bk88w=.6aa400c4-2ce3-43f3-bb59-d14914d076f0@github.com>
References: <Cuo-hZ2dmp5Su2aMvYe3k_w_rEuzCk7F8wpeCsQuyMA=.911a0412-42c0-44a1-8863-e94e5a7970e7@github.com>
 <jx2kU4A0gxp4YCjuO5EP-nxww4wpHTc-vAZd9pJ__TE=.2b87d2e4-8fc8-4bbf-837c-0bac60362121@github.com>
 <mP9vNVA88HN8lnZq6DHqVsvhQEIiBF61qMrU25Bk88w=.6aa400c4-2ce3-43f3-bb59-d14914d076f0@github.com>
Message-ID: <TNqJRVWrAi_p1nzsRunD7txS_aNG3DAUzPlK5WoLkrs=.cc4449bc-00ac-43ab-8109-6c0c65d3dc0d@github.com>

On Wed, 12 Oct 2022 14:28:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> If is is a big change or not depends on how it affects builds on macos. I assume that clang functionality that was published in 2017 is already incorporated in the minimum supported version of Xcode on mac. (This needs to be verified, though)
> 
> For clang on linux; Oracle do not regularly build linux with clang, nor do our GHA build scripts. I don't know if anyone regularly tests this.
> 
> My guess is that the 3.5 limit was put in place when the clang for linux support was added, and it has not been modified since.

Okay, I see, thanks for the summary!

> But you are probably right that it should be a separate PR, if not for anything else so to get proper attention to it.

Yes, it's probably better to get more attention for this update.

> Do you want me to publish such a PR first, or do you want to continue with the current conditionals, and clean them up afterwards if/when we go to clang 5.0+?

I think both is fine. But since I already have the patch ready, I suggest to move forward with it and then come back later to clean it up.

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

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


From luhenry at openjdk.org  Thu Oct 13 07:49:47 2022
From: luhenry at openjdk.org (Ludovic Henry)
Date: Thu, 13 Oct 2022 07:49:47 GMT
Subject: RFR: 8295262: Build binutils out of source tree
Message-ID: <NFuwvlXJiI8Zuqs3dhe5p74w0dWntpcQvDyaaEAtEXE=.142685f6-1ef1-464a-8b62-1eadf1f0b004@github.com>

Currently, when passing --with-binutils-src, binutils is built in the source tree. That leads to conflicting targets when compiling for different architectures (ex: amd64 on the host, and riscv64 or aarch64 for the target) from the same jdk source tree.

The simplest solution is to build binutils out-of-tree and into the build/<target>/binutils folder. These out-of-tree builds are already supported by binutils and only require some changes in the way we invoke the binutils/configure command.

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

Commit messages:
 - 8295262: Build binutils out of source tree

Changes: https://git.openjdk.org/jdk/pull/10689/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10689&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295262
  Stats: 32 lines in 2 files changed: 18 ins; 2 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/10689.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10689/head:pull/10689

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


From aph at openjdk.org  Thu Oct 13 07:51:11 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 13 Oct 2022 07:51:11 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <CfFMJqqw1EpqbX1K3Tv60TuX0M82gOsmBrblYzHniDo=.4226310a-1b26-4cd1-8a21-3df10cdb79b0@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
 <3CHKC_SEGCKm2D3rHntfxV21sx0G-AakDLPPf8rPwQc=.533cc9d9-f93b-4a6f-86f6-a221452045d4@github.com>
 <CfFMJqqw1EpqbX1K3Tv60TuX0M82gOsmBrblYzHniDo=.4226310a-1b26-4cd1-8a21-3df10cdb79b0@github.com>
Message-ID: <aWA19pG62Wukj26YzQLHpajAHJ_dRqcgAOCJ0ARwPhM=.c15b76b8-4250-4df9-b724-5df62f47de5c@github.com>

On Wed, 12 Oct 2022 20:35:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Isn't it an illustration of a more general problem we have with native code where it can mess with FP environment at any time?

Yes.

> We already have similar problems with MXCSR register and provide verification logic (part of `-Xcheck:jni`) to catch modifications and support conditional restoration of MXCSR register on x86_64. x86_32 validates x87 control word when `-Xcheck:jni` is enabled.
> 
> Should we do something similar here instead?

The problem is that this bug is very insidious: the user probably doesn't know that there's anything wrong, and almost certainly has no idea that it's anything to do with JNI.

Saving and restoring the floating-point environment across dlopen() is a compromise between adding extra code at JNI callouts, which can be expensive, and shifting the burden to the user.

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

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


From aph at openjdk.org  Thu Oct 13 07:53:12 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 13 Oct 2022 07:53:12 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <7yaDR-VCplkpcKoGwJ4_4rZczua_vXMVVXsZ4jFbwYg=.522bd3a5-4b70-4fd7-a6af-184fde528750@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
 <7yaDR-VCplkpcKoGwJ4_4rZczua_vXMVVXsZ4jFbwYg=.522bd3a5-4b70-4fd7-a6af-184fde528750@github.com>
Message-ID: <Q1yWSfB7lIS9BrX0LrX6EGJxGjl1P8GNJVyUabsXW0E=.f4594225-d4c8-424d-8068-415d9354f1b0@github.com>

On Wed, 12 Oct 2022 20:26:34 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Following that logic: from our perspective `dlopen` violates its ABI in certain cases. Preserving the control bits across calls to `dlopen` seems like a pragmatic solution. I'm not sure how important it is to have an opt-in for the current (broken) behavior...

Not at all, I'd have thought.

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

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


From shade at openjdk.org  Thu Oct 13 08:10:06 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 13 Oct 2022 08:10:06 GMT
Subject: RFR: 8295262: Build binutils out of source tree
In-Reply-To: <NFuwvlXJiI8Zuqs3dhe5p74w0dWntpcQvDyaaEAtEXE=.142685f6-1ef1-464a-8b62-1eadf1f0b004@github.com>
References: <NFuwvlXJiI8Zuqs3dhe5p74w0dWntpcQvDyaaEAtEXE=.142685f6-1ef1-464a-8b62-1eadf1f0b004@github.com>
Message-ID: <ibQwEJqJHOHlqetIY6lDYLDhjL0rwxsKeKyQ0KPn8JQ=.823b7faa-e3f4-4d1a-8454-60f059b6d8e2@github.com>

On Thu, 13 Oct 2022 07:43:33 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

> Currently, when passing --with-binutils-src, binutils is built in the source tree. That leads to conflicting targets when compiling for different architectures (ex: amd64 on the host, and riscv64 or aarch64 for the target) from the same jdk source tree.
> 
> The simplest solution is to build binutils out-of-tree and into the build/<target>/binutils folder. These out-of-tree builds are already supported by binutils and only require some changes in the way we invoke the binutils/configure command.

This generally looks good. I stumbled upon this issue when cross-compiling hsdis too! But we need some cleanups, I think:

make/autoconf/lib-hsdis.m4 line 184:

> 182:     else
> 183:       binutils_cc="$CC $SYSROOT_CFLAGS"
> 184:       if test "x$COMPILE_TYPE" = xcross; then

I am surprised this PR does not have a merge conflict against current mainline which already has this block. Can you please merge the fresh master to your PR?

src/utils/hsdis/binutils/hsdis-binutils.c line 571:

> 569:   dinfo->disassembler_options =
> 570:     disassembler_options != NULL && disassembler_options[0] != '\0' ?
> 571:       disassembler_options : NULL;

This hunk looks irrelevant to the issue?

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

Changes requested by shade (Reviewer).

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


From aph at openjdk.org  Thu Oct 13 08:33:07 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 13 Oct 2022 08:33:07 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
Message-ID: <Ml06BoJq9CWOjtSXU07rRCF97YroAnCnQhnkD6aiQJg=.2a0cc112-b6b0-43e8-a69e-2ff9926d6a93@github.com>

On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>> 
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>> 
>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
>> 
>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

Here's another possibility: save the FP environment over up- and down-calls, and restore it if the control bits have changed.
We can do that in a portable way, overriding it in a more performant way with arch-specific code.

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

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


From luhenry at openjdk.org  Thu Oct 13 08:41:35 2022
From: luhenry at openjdk.org (Ludovic Henry)
Date: Thu, 13 Oct 2022 08:41:35 GMT
Subject: RFR: 8295262: Build binutils out of source tree [v2]
In-Reply-To: <NFuwvlXJiI8Zuqs3dhe5p74w0dWntpcQvDyaaEAtEXE=.142685f6-1ef1-464a-8b62-1eadf1f0b004@github.com>
References: <NFuwvlXJiI8Zuqs3dhe5p74w0dWntpcQvDyaaEAtEXE=.142685f6-1ef1-464a-8b62-1eadf1f0b004@github.com>
Message-ID: <bSD_wby5_F8efochbwYMJ1HFmsm35YeBcvK5q10jXiA=.ab1c5a96-3358-4490-97c3-dd6aaf25790b@github.com>

> Currently, when passing --with-binutils-src, binutils is built in the source tree. That leads to conflicting targets when compiling for different architectures (ex: amd64 on the host, and riscv64 or aarch64 for the target) from the same jdk source tree.
> 
> The simplest solution is to build binutils out-of-tree and into the build/<target>/binutils folder. These out-of-tree builds are already supported by binutils and only require some changes in the way we invoke the binutils/configure command.

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

 - Remove unrelated change
 - Merge branch 'master' of github.com:openjdk/jdk into dev/ludovic/upstream-hsdis-cross-compile
 - 8295262: Build binutils out of source tree
   
   Currently, when passing --with-binutils-src, binutils is built in the source tree. That leads to conflicting targets when compiling for different architectures (ex: amd64 on the host, and riscv64 or aarch64 for the target) from the same jdk source tree.
   
   The simplest solution is to build binutils out-of-tree and into the build/<target>/binutils folder. These out-of-tree builds are already supported by binutils and only require some changes in the way we invoke the binutils/configure command.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10689/files
  - new: https://git.openjdk.org/jdk/pull/10689/files/b69fdbaa..8faf5083

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10689&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10689&range=00-01

  Stats: 14194 lines in 298 files changed: 10379 ins; 2288 del; 1527 mod
  Patch: https://git.openjdk.org/jdk/pull/10689.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10689/head:pull/10689

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


From luhenry at openjdk.org  Thu Oct 13 08:41:36 2022
From: luhenry at openjdk.org (Ludovic Henry)
Date: Thu, 13 Oct 2022 08:41:36 GMT
Subject: RFR: 8295262: Build binutils out of source tree [v2]
In-Reply-To: <ibQwEJqJHOHlqetIY6lDYLDhjL0rwxsKeKyQ0KPn8JQ=.823b7faa-e3f4-4d1a-8454-60f059b6d8e2@github.com>
References: <NFuwvlXJiI8Zuqs3dhe5p74w0dWntpcQvDyaaEAtEXE=.142685f6-1ef1-464a-8b62-1eadf1f0b004@github.com>
 <ibQwEJqJHOHlqetIY6lDYLDhjL0rwxsKeKyQ0KPn8JQ=.823b7faa-e3f4-4d1a-8454-60f059b6d8e2@github.com>
Message-ID: <ZZU-34CcBCuYVp-BJ9fPlskMG862QOHWCiq3R1ZU8YI=.58457a44-d20b-4d57-a92b-c5191a73065b@github.com>

On Thu, 13 Oct 2022 07:56:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Ludovic Henry has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Remove unrelated change
>>  - Merge branch 'master' of github.com:openjdk/jdk into dev/ludovic/upstream-hsdis-cross-compile
>>  - 8295262: Build binutils out of source tree
>>    
>>    Currently, when passing --with-binutils-src, binutils is built in the source tree. That leads to conflicting targets when compiling for different architectures (ex: amd64 on the host, and riscv64 or aarch64 for the target) from the same jdk source tree.
>>    
>>    The simplest solution is to build binutils out-of-tree and into the build/<target>/binutils folder. These out-of-tree builds are already supported by binutils and only require some changes in the way we invoke the binutils/configure command.
>
> src/utils/hsdis/binutils/hsdis-binutils.c line 571:
> 
>> 569:   dinfo->disassembler_options =
>> 570:     disassembler_options != NULL && disassembler_options[0] != '\0' ?
>> 571:       disassembler_options : NULL;
> 
> This hunk looks irrelevant to the issue?

I needed it to successfully run hsdis. I'll remove it, check if it's still necessary, and potentially submit it in another PR.

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

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


From shade at openjdk.org  Thu Oct 13 11:08:28 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 13 Oct 2022 11:08:28 GMT
Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v21]
In-Reply-To: <D-ITPMwo33auL08XGAc39o68120N5xzJrdU8_oNZEOY=.9d2c0e17-e793-4d85-9304-5c94d813d216@github.com>
References: <RrlZAKdgm0ZtogXG3iVPpmaFQB1Y0kQL2bQPGe6eRus=.95a23c3d-ae0c-4c8f-aab0-2d755236f6f7@github.com>
 <D-ITPMwo33auL08XGAc39o68120N5xzJrdU8_oNZEOY=.9d2c0e17-e793-4d85-9304-5c94d813d216@github.com>
Message-ID: <33IO5LNbo4XDhUV2tinAvOIBs7pOne5YuVzmR6qnb2g=.6edf4423-8e3b-4a0f-8d0c-5ba89a9cd94f@github.com>

On Wed, 12 Oct 2022 11:04:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot.
>> 
>> Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files.
>> 
>> Some warnings didn't trigger in any file anymore, and could just be removed.
>> 
>> Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back.
>> 
>> I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily.
>> 
>> I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround.
>> 
>> It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++).
>> 
>> Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Github workflow changes were not supposed to be in this PR...

Marked as reviewed by shade (Reviewer).

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

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


From shade at openjdk.org  Thu Oct 13 11:08:28 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 13 Oct 2022 11:08:28 GMT
Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v9]
In-Reply-To: <1JwBm4xpt9EfiFBlkharONlS8E3RjMDXq2sCtQyu0UQ=.efc05433-4767-4863-bfbc-b5cf6aba672c@github.com>
References: <RrlZAKdgm0ZtogXG3iVPpmaFQB1Y0kQL2bQPGe6eRus=.95a23c3d-ae0c-4c8f-aab0-2d755236f6f7@github.com>
 <QWwKfSzL01bIjdz18HwvCnQuP1vbWkipFGmf5nlPCp0=.05ec869f-c3d6-4048-9d03-e7f23e5c7ec6@github.com>
 <uziscjqZmhO0X87EwnMVWqUZGjl2T8plwe5SrJ42Iww=.a18553e1-39fc-46ea-a8ea-988924ea195f@github.com>
 <_O1386bHeagTrVI68UU0GbvMWV8XtiRE3phbjYFZ81A=.b35c61a2-af07-43f8-8fab-cb218059e465@github.com>
 <raPwK4VE7-ZMPnxybyP5v-uAchQUSnJ7zX7ldZtsWNM=.0c96acda-f793-4938-9d3f-081f6c365966@github.com>
 <Blcd1AJIwa9T43uwcUJsSI8SsgKVUn2mYVofjKNZLsU=.ad707177-fc46-4b7f-afa7-a715167be7af@github.com>
 <1JwBm4xpt9EfiFBlkharONlS8E3RjMDXq2sCtQyu0UQ=.efc05433-4767-4863-bfbc-b5cf6aba672c@github.com>
Message-ID: <O1awKRvPL7rWHXqb8rXKaDgQIJ5HVhqjV5bmC72WReY=.82d599bb-956c-4b5b-adee-526c54b53684@github.com>

On Wed, 12 Oct 2022 11:07:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > @shipilev In a "tenth time's the charm" spirit, here's what I do think is actually a PR that can be integrated.
> 
> Cool! I'll try to schedule the overnight build-matrix run to see if anything is broken.

I was able to build the matrix of:
 - `make hotspot`
 - GCC {9, 10}
 - {i686, x86_64, aarch64, powerpc64le, s390x, arm, riscv64, powerpc64}
 - {server, client, minimal, zero}
 - {release, fastdebug, slowdebug, optimized}

All these build with default warnings enabled, and they pass. So I think we are more or less safe with this minimization.

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

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


From shade at openjdk.org  Thu Oct 13 11:52:09 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 13 Oct 2022 11:52:09 GMT
Subject: RFR: 8295262: Build binutils out of source tree [v2]
In-Reply-To: <bSD_wby5_F8efochbwYMJ1HFmsm35YeBcvK5q10jXiA=.ab1c5a96-3358-4490-97c3-dd6aaf25790b@github.com>
References: <NFuwvlXJiI8Zuqs3dhe5p74w0dWntpcQvDyaaEAtEXE=.142685f6-1ef1-464a-8b62-1eadf1f0b004@github.com>
 <bSD_wby5_F8efochbwYMJ1HFmsm35YeBcvK5q10jXiA=.ab1c5a96-3358-4490-97c3-dd6aaf25790b@github.com>
Message-ID: <7LbdPchdt77O0Bh8XQW-x7jNefCcOVCxbXp6VeEufKg=.6e8c1095-454e-47ce-b071-f76915bf274e@github.com>

On Thu, 13 Oct 2022 08:41:35 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Currently, when passing --with-binutils-src, binutils is built in the source tree. That leads to conflicting targets when compiling for different architectures (ex: amd64 on the host, and riscv64 or aarch64 for the target) from the same jdk source tree.
>> 
>> The simplest solution is to build binutils out-of-tree and into the build/<target>/binutils folder. These out-of-tree builds are already supported by binutils and only require some changes in the way we invoke the binutils/configure command.
>
> Ludovic Henry has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Remove unrelated change
>  - Merge branch 'master' of github.com:openjdk/jdk into dev/ludovic/upstream-hsdis-cross-compile
>  - 8295262: Build binutils out of source tree
>    
>    Currently, when passing --with-binutils-src, binutils is built in the source tree. That leads to conflicting targets when compiling for different architectures (ex: amd64 on the host, and riscv64 or aarch64 for the target) from the same jdk source tree.
>    
>    The simplest solution is to build binutils out-of-tree and into the build/<target>/binutils folder. These out-of-tree builds are already supported by binutils and only require some changes in the way we invoke the binutils/configure command.

This looks good to me. I tested hsdis builds on these platforms and they pass:


server-release-aarch64-linux-gnu
server-release-arm-linux-gnueabihf
server-release-i686-linux-gnu
server-release-powerpc64le-linux-gnu
server-release-powerpc64-linux-gnu-
server-release-riscv64-linux-gnu
server-release-s390x-linux-gnu
server-release-x86_64-linux-gnu
zero-release-alpha-linux-gnu
zero-release-arm-linux-gnueabi
zero-release-arm-linux-gnueabihf
zero-release-m68k-linux-gnu
zero-release-mips64el-linux-gnuabi64
zero-release-mipsel-linux-gnu
zero-release-powerpc-linux-gnu
zero-release-sh4-linux-gnu
zero-release-sparc64-linux-gnu

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

Marked as reviewed by shade (Reviewer).

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


From erikj at openjdk.org  Thu Oct 13 13:36:19 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 13 Oct 2022 13:36:19 GMT
Subject: RFR: 8295262: Build binutils out of source tree [v2]
In-Reply-To: <bSD_wby5_F8efochbwYMJ1HFmsm35YeBcvK5q10jXiA=.ab1c5a96-3358-4490-97c3-dd6aaf25790b@github.com>
References: <NFuwvlXJiI8Zuqs3dhe5p74w0dWntpcQvDyaaEAtEXE=.142685f6-1ef1-464a-8b62-1eadf1f0b004@github.com>
 <bSD_wby5_F8efochbwYMJ1HFmsm35YeBcvK5q10jXiA=.ab1c5a96-3358-4490-97c3-dd6aaf25790b@github.com>
Message-ID: <XO0MtetEqNWVLs1U3XDlAJ7kGZeWxdUpXqrG1nvfeFE=.4513e54b-358b-4bae-bbb9-a2a82cdc1afa@github.com>

On Thu, 13 Oct 2022 08:41:35 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Currently, when passing --with-binutils-src, binutils is built in the source tree. That leads to conflicting targets when compiling for different architectures (ex: amd64 on the host, and riscv64 or aarch64 for the target) from the same jdk source tree.
>> 
>> The simplest solution is to build binutils out-of-tree and into the build/<target>/binutils folder. These out-of-tree builds are already supported by binutils and only require some changes in the way we invoke the binutils/configure command.
>
> Ludovic Henry has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Remove unrelated change
>  - Merge branch 'master' of github.com:openjdk/jdk into dev/ludovic/upstream-hsdis-cross-compile
>  - 8295262: Build binutils out of source tree
>    
>    Currently, when passing --with-binutils-src, binutils is built in the source tree. That leads to conflicting targets when compiling for different architectures (ex: amd64 on the host, and riscv64 or aarch64 for the target) from the same jdk source tree.
>    
>    The simplest solution is to build binutils out-of-tree and into the build/<target>/binutils folder. These out-of-tree builds are already supported by binutils and only require some changes in the way we invoke the binutils/configure command.

Marked as reviewed by erikj (Reviewer).

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

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


From shade at openjdk.org  Thu Oct 13 15:12:36 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 13 Oct 2022 15:12:36 GMT
Subject: RFR: 8295262: Build binutils out of source tree [v2]
In-Reply-To: <bSD_wby5_F8efochbwYMJ1HFmsm35YeBcvK5q10jXiA=.ab1c5a96-3358-4490-97c3-dd6aaf25790b@github.com>
References: <NFuwvlXJiI8Zuqs3dhe5p74w0dWntpcQvDyaaEAtEXE=.142685f6-1ef1-464a-8b62-1eadf1f0b004@github.com>
 <bSD_wby5_F8efochbwYMJ1HFmsm35YeBcvK5q10jXiA=.ab1c5a96-3358-4490-97c3-dd6aaf25790b@github.com>
Message-ID: <K9_imonJX8sxMOkd0fzCgfRL-jk2dqmrI54Z6KVftUY=.affb8023-88fe-487c-946a-4e5f974aedbe@github.com>

On Thu, 13 Oct 2022 08:41:35 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Currently, when passing --with-binutils-src, binutils is built in the source tree. That leads to conflicting targets when compiling for different architectures (ex: amd64 on the host, and riscv64 or aarch64 for the target) from the same jdk source tree.
>> 
>> The simplest solution is to build binutils out-of-tree and into the build/<target>/binutils folder. These out-of-tree builds are already supported by binutils and only require some changes in the way we invoke the binutils/configure command.
>
> Ludovic Henry has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Remove unrelated change
>  - Merge branch 'master' of github.com:openjdk/jdk into dev/ludovic/upstream-hsdis-cross-compile
>  - 8295262: Build binutils out of source tree
>    
>    Currently, when passing --with-binutils-src, binutils is built in the source tree. That leads to conflicting targets when compiling for different architectures (ex: amd64 on the host, and riscv64 or aarch64 for the target) from the same jdk source tree.
>    
>    The simplest solution is to build binutils out-of-tree and into the build/<target>/binutils folder. These out-of-tree builds are already supported by binutils and only require some changes in the way we invoke the binutils/configure command.

I think we want to ask @magicus about this as well, maybe he will discover some unusual quirks in this code. Otherwise, I'll sponsor.

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

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


From vlivanov at openjdk.org  Thu Oct 13 18:13:41 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 13 Oct 2022 18:13:41 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <aWA19pG62Wukj26YzQLHpajAHJ_dRqcgAOCJ0ARwPhM=.c15b76b8-4250-4df9-b724-5df62f47de5c@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
 <3CHKC_SEGCKm2D3rHntfxV21sx0G-AakDLPPf8rPwQc=.533cc9d9-f93b-4a6f-86f6-a221452045d4@github.com>
 <CfFMJqqw1EpqbX1K3Tv60TuX0M82gOsmBrblYzHniDo=.4226310a-1b26-4cd1-8a21-3df10cdb79b0@github.com>
 <aWA19pG62Wukj26YzQLHpajAHJ_dRqcgAOCJ0ARwPhM=.c15b76b8-4250-4df9-b724-5df62f47de5c@github.com>
Message-ID: <wVqjuZv0owbhLTk6UkN-RmNfqU_xVCrOqrHo2lgvdpo=.2a2f4c74-14ac-4909-8738-1e4917b1a9eb@github.com>

On Thu, 13 Oct 2022 07:47:20 GMT, Andrew Haley <aph at openjdk.org> wrote:

> The problem is that this bug is very insidious: the user probably doesn't know that there's anything wrong, and almost certainly has no idea that it's anything to do with JNI.

I'm still trying to grasp why the current problem is something different from what we experienced before.

Some platforms (x86_32 and AArch32) provide a way to restore FP environment, but it is turned off by default. Why x86_64 case is different, so it requires the logic to be turned on by default? Does the same reasoning apply to those platforms as well and we want to have `AlwaysRestoreFPU` turned on by default?    


$ grep -r AlwaysRestoreFPU src/hotspot/
src/hotspot//cpu/x86/templateInterpreterGenerator_x86.cpp:  if (AlwaysRestoreFPU) {
src/hotspot//cpu/x86/sharedRuntime_x86_32.cpp:  if (AlwaysRestoreFPU) {
src/hotspot//cpu/arm/sharedRuntime_arm.cpp:  if (AlwaysRestoreFPU) {
src/hotspot//cpu/arm/templateInterpreterGenerator_arm.cpp:  if (AlwaysRestoreFPU) {
src/hotspot//share/runtime/globals.hpp:  product(bool, AlwaysRestoreFPU, false,                                    \

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

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


From xuelei at openjdk.org  Thu Oct 13 18:15:30 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 13 Oct 2022 18:15:30 GMT
Subject: RFR: 8295010: Reduce if required in EC limbs operations [v4]
In-Reply-To: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
References: <2DzGzDVogoWGjWSdG9Oze5y4zIyJSITvspjsdQwhAV0=.962757f4-148f-4815-82ac-d472e5956820@github.com>
Message-ID: <5Rxxu4nDHnboRpDrotQIOCJ70X-DqhSmmgG5J0AAp9o=.6838cd69-8c6a-48dd-913a-9ec9706a9640@github.com>

> Hi,
> 
> May I have this update reviewed?  With this update, the result will be reduced if required in EC limbs operations in the JDK implementation.
> 
> In the current implementation, the EC limbs addition and subtraction result is not reduced before the value is returned.  This behavior is different from multiplication and square.  To get it right, a maximum addition limit is introduced for EC limbs addition and subtraction.  If the limit is reached, an exception will be thrown so as to indicate an EC implementation problem.  The exception is not recoverable from the viewpoint of an application.
> 
> The design is error prone as the EC implementation code must be carefully checked so that the limit cannot reach. If a reach is noticed, a reduce operation would have to be hard-coded additionally. In the FieldGen.java implementation, the limit can only be 1 or 2 as the implementation code is only able to handle 2.  But the FieldGen.java does not really check if 1 or 2 really works for the specific filed generation parameters.
> 
> The design impact the performance as well. Because of this limit, the maximum limb size is 28 bits for 2 max adding limit. Otherwise there are integer (long) overflow issues. For example for 256 bits curves, 10 limbs are required for 28-bit limb size; and 9 limbs for 29-bit size. By reducing 1 limbs from 10 to 9, the Signature performance could get improved by 20%.
> 
> In the IntegerPolynomial class description, it is said "All IntegerPolynomial implementations allow at most one addition before multiplication. Additions after that will result in an ArithmeticException." It's too strict to follow without exam the code very carefully. Indeed, the implementation does not really follow the spec, and 2 addition may be allowed.
> 
> It would be nice if there is no addition limit, and then we are free from these issues. It is doable by reducing the limbs if required for EC limbs operations.
> 
> The benchmark for ECDSA Signature is checked in order to see how much the performance could be impacted. Here are the benchmark numbers before the patch applied:
> 
> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign    secp256r1               64  thrpt   15  1417.507 ?  5.809  ops/s
> Signatures.sign    secp256r1              512  thrpt   15  1412.620 ?  7.040  ops/s
> Signatures.sign    secp256r1             2048  thrpt   15  1417.364 ?  6.643  ops/s
> Signatures.sign    secp256r1            16384  thrpt   15  1364.720 ? 44.354  ops/s
> Signatures.sign    secp384r1               64  thrpt   15   609.924 ?  9.858  ops/s
> Signatures.sign    secp384r1              512  thrpt   15   610.873 ?  5.519  ops/s
> Signatures.sign    secp384r1             2048  thrpt   15   608.573 ? 13.324  ops/s
> Signatures.sign    secp384r1            16384  thrpt   15   597.802 ?  7.074  ops/s
> Signatures.sign    secp521r1               64  thrpt   15   301.954 ?  6.449  ops/s
> Signatures.sign    secp521r1              512  thrpt   15   300.774 ?  5.849  ops/s
> Signatures.sign    secp521r1             2048  thrpt   15   295.831 ?  8.423  ops/s
> Signatures.sign    secp521r1            16384  thrpt   15   276.258 ? 43.146  ops/s
> Signatures.sign      Ed25519               64  thrpt   15  1171.878 ?  4.187  ops/s
> Signatures.sign      Ed25519              512  thrpt   15  1175.175 ?  4.611  ops/s
> Signatures.sign      Ed25519             2048  thrpt   15  1168.459 ?  5.750  ops/s
> Signatures.sign      Ed25519            16384  thrpt   15  1086.906 ?  6.514  ops/s
> Signatures.sign        Ed448               64  thrpt   15   326.475 ?  3.274  ops/s
> Signatures.sign        Ed448              512  thrpt   15   328.709 ?  3.867  ops/s
> Signatures.sign        Ed448             2048  thrpt   15   315.480 ? 15.377  ops/s
> Signatures.sign        Ed448            16384  thrpt   15   312.388 ?  1.067  ops/s
> 
> 
> and here are the numbers with this patch applied:
> 
> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign    secp256r1               64  thrpt   15  1377.447 ? 38.889  ops/s
> Signatures.sign    secp256r1              512  thrpt   15  1403.149 ?  5.151  ops/s
> Signatures.sign    secp256r1             2048  thrpt   15  1401.101 ?  6.937  ops/s
> Signatures.sign    secp256r1            16384  thrpt   15  1381.855 ? 10.606  ops/s
> Signatures.sign    secp384r1               64  thrpt   15   595.979 ?  1.967  ops/s
> Signatures.sign    secp384r1              512  thrpt   15   592.419 ?  6.087  ops/s
> Signatures.sign    secp384r1             2048  thrpt   15   581.800 ? 18.815  ops/s
> Signatures.sign    secp384r1            16384  thrpt   15   583.224 ?  9.856  ops/s
> Signatures.sign    secp521r1               64  thrpt   15   264.772 ? 36.883  ops/s
> Signatures.sign    secp521r1              512  thrpt   15   302.084 ?  1.074  ops/s
> Signatures.sign    secp521r1             2048  thrpt   15   296.619 ?  3.272  ops/s
> Signatures.sign    secp521r1            16384  thrpt   15   290.112 ?  5.085  ops/s
> Signatures.sign      Ed25519               64  thrpt   15  1163.293 ?  4.266  ops/s
> Signatures.sign      Ed25519              512  thrpt   15  1157.093 ?  8.145  ops/s
> Signatures.sign      Ed25519             2048  thrpt   15  1140.900 ?  8.660  ops/s
> Signatures.sign      Ed25519            16384  thrpt   15  1053.233 ? 40.591  ops/s
> Signatures.sign        Ed448               64  thrpt   15   317.509 ?  6.870  ops/s
> Signatures.sign        Ed448              512  thrpt   15   320.975 ?  1.534  ops/s
> Signatures.sign        Ed448             2048  thrpt   15   322.157 ?  1.914  ops/s
> Signatures.sign        Ed448            16384  thrpt   15   303.532 ?  6.419  ops/s
> 
> 
> From the numbers, it looks like the performance impact is limited.  Based on this update, the performance could get rewarded by using less limbs.  For examples if using less limbs for secp256r1/secp384r1/secp521r1, [see PR for PR for JDK-8294248](https://github.com/openjdk/jdk/pull/10398), and run the benchmark together with this patch, I could see the performance improvement as follow (note: I did not update to use less limbs for Ed25519/Ed448 yet, the numbers listed below for them are just for comparing with the numbers above):
> 
> Benchmark        (curveName)  (messageLength)   Mode  Cnt     Score    Error  Units
> Signatures.sign    secp256r1               64  thrpt   15  1632.905 ? 12.235  ops/s
> Signatures.sign    secp256r1              512  thrpt   15  1626.057 ?  3.052  ops/s
> Signatures.sign    secp256r1             2048  thrpt   15  1625.676 ?  8.435  ops/s
> Signatures.sign    secp256r1            16384  thrpt   15  1603.612 ?  4.289  ops/s
> Signatures.sign    secp384r1               64  thrpt   15   605.713 ? 14.951  ops/s
> Signatures.sign    secp384r1              512  thrpt   15   608.920 ?  7.715  ops/s
> Signatures.sign    secp384r1             2048  thrpt   15   601.338 ?  1.638  ops/s
> Signatures.sign    secp384r1            16384  thrpt   15   602.315 ?  3.308  ops/s
> Signatures.sign    secp521r1               64  thrpt   15   320.946 ?  0.877  ops/s
> Signatures.sign    secp521r1              512  thrpt   15   322.642 ?  1.222  ops/s
> Signatures.sign    secp521r1             2048  thrpt   15   322.204 ?  1.929  ops/s
> Signatures.sign    secp521r1            16384  thrpt   15   316.769 ?  5.398  ops/s
> Signatures.sign      Ed25519               64  thrpt   15  1143.084 ? 13.169  ops/s
> Signatures.sign      Ed25519              512  thrpt   15  1145.780 ?  7.880  ops/s
> Signatures.sign      Ed25519             2048  thrpt   15  1144.818 ?  5.768  ops/s
> Signatures.sign      Ed25519            16384  thrpt   15  1081.061 ?  8.283  ops/s
> Signatures.sign        Ed448               64  thrpt   15   321.304 ?  0.638  ops/s
> Signatures.sign        Ed448              512  thrpt   15   320.501 ?  1.924  ops/s
> Signatures.sign        Ed448             2048  thrpt   15   319.234 ?  1.082  ops/s
> Signatures.sign        Ed448            16384  thrpt   15   306.937 ?  1.060  ops/s
> ``` 
> 
> If considering this PR together with [PR for JDK-8294248](https://github.com/openjdk/jdk/pull/10398), performance improvement could be expected for EC crypto primitives.
> 
> Thanks,
> Xuelei

Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge master
 - missed reduce
 - reduce if needed
 - add the key pair generation bench code
 - remove tabs
 - 8295010: EC limbs addition and subtraction limit

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

Changes: https://git.openjdk.org/jdk/pull/10624/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10624&range=03
  Stats: 291 lines in 10 files changed: 233 ins; 35 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/10624.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10624/head:pull/10624

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


From aph-open at littlepinkcloud.com  Fri Oct 14 09:45:27 2022
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Fri, 14 Oct 2022 10:45:27 +0100
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <wVqjuZv0owbhLTk6UkN-RmNfqU_xVCrOqrHo2lgvdpo=.2a2f4c74-14ac-4909-8738-1e4917b1a9eb@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
 <3CHKC_SEGCKm2D3rHntfxV21sx0G-AakDLPPf8rPwQc=.533cc9d9-f93b-4a6f-86f6-a221452045d4@github.com>
 <CfFMJqqw1EpqbX1K3Tv60TuX0M82gOsmBrblYzHniDo=.4226310a-1b26-4cd1-8a21-3df10cdb79b0@github.com>
 <aWA19pG62Wukj26YzQLHpajAHJ_dRqcgAOCJ0ARwPhM=.c15b76b8-4250-4df9-b724-5df62f47de5c@github.com>
 <wVqjuZv0owbhLTk6UkN-RmNfqU_xVCrOqrHo2lgvdpo=.2a2f4c74-14ac-4909-8738-1e4917b1a9eb@github.com>
Message-ID: <a9c3f8f5-43ca-3a31-1c5f-38a935d5f046@littlepinkcloud.com>

On 10/13/22 19:13, Vladimir Ivanov wrote:
> On Thu, 13 Oct 2022 07:47:20 GMT, Andrew Haley <aph at openjdk.org> wrote:
> 
>> The problem is that this bug is very insidious: the user probably doesn't know that there's anything wrong, and almost certainly has no idea that it's anything to do with JNI.
> 
> I'm still trying to grasp why the current problem is something different from what we experienced before.

I don't know anything about what we experienced before. In any case,
I'm not sure that precedent applies here: the problem is that there
are shared libraries in use which break IEEE semantics. This is
an insidious bug, and my proposed fix costs almost nothing.

> Some platforms (x86_32 and AArch32) provide a way to restore FP environment, but it is turned off by default. Why x86_64 case is different, so it requires the logic to be turned on by default? Does the same reasoning apply to those platforms as well and we want to have `AlwaysRestoreFPU` turned on by default?

My patch is not in any way x86_64-specific. At present it is Linux-specific,
but I have my doubts that it should be.
> $ grep -r AlwaysRestoreFPU src/hotspot/
> src/hotspot//cpu/x86/templateInterpreterGenerator_x86.cpp:  if (AlwaysRestoreFPU) {
> src/hotspot//cpu/x86/sharedRuntime_x86_32.cpp:  if (AlwaysRestoreFPU) {
> src/hotspot//cpu/arm/sharedRuntime_arm.cpp:  if (AlwaysRestoreFPU) {
> src/hotspot//cpu/arm/templateInterpreterGenerator_arm.cpp:  if (AlwaysRestoreFPU) {
> src/hotspot//share/runtime/globals.hpp:  product(bool, AlwaysRestoreFPU, false,                                    \
> 
> -------------
> 
> PR: https://git.openjdk.org/jdk/pull/10661

x86-32 has a very specific problem: its default floating-point precision is
AFAIK extended float, which does not meet Java specs. Also, restoring the
FPU after every JNI call is expensive.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671



From kbarrett at openjdk.org  Sat Oct 15 08:14:09 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 15 Oct 2022 08:14:09 GMT
Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v21]
In-Reply-To: <D-ITPMwo33auL08XGAc39o68120N5xzJrdU8_oNZEOY=.9d2c0e17-e793-4d85-9304-5c94d813d216@github.com>
References: <RrlZAKdgm0ZtogXG3iVPpmaFQB1Y0kQL2bQPGe6eRus=.95a23c3d-ae0c-4c8f-aab0-2d755236f6f7@github.com>
 <D-ITPMwo33auL08XGAc39o68120N5xzJrdU8_oNZEOY=.9d2c0e17-e793-4d85-9304-5c94d813d216@github.com>
Message-ID: <5CNdaZqYt3cnZZBbs9QDN4K7ebprUsUV3W4-D0m32lA=.d46ec09f-97ea-4656-a3fc-78ac5190e76b@github.com>

On Wed, 12 Oct 2022 11:04:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot.
>> 
>> Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files.
>> 
>> Some warnings didn't trigger in any file anymore, and could just be removed.
>> 
>> Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back.
>> 
>> I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily.
>> 
>> I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround.
>> 
>> It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++).
>> 
>> Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Github workflow changes were not supposed to be in this PR...

Looks good.

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

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


From kbarrett at openjdk.org  Sat Oct 15 08:14:10 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 15 Oct 2022 08:14:10 GMT
Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v21]
In-Reply-To: <UAi3fwKEz_3ASlZTAe6KR5aFUUxGDatdQYaPnNjQEFQ=.2fafab0b-86a0-4c21-8e5f-dc2e5bd772f7@github.com>
References: <RrlZAKdgm0ZtogXG3iVPpmaFQB1Y0kQL2bQPGe6eRus=.95a23c3d-ae0c-4c8f-aab0-2d755236f6f7@github.com>
 <D-ITPMwo33auL08XGAc39o68120N5xzJrdU8_oNZEOY=.9d2c0e17-e793-4d85-9304-5c94d813d216@github.com>
 <f5OzDB4gnlueQO5ISaf2cn7vvMAT87nZjH_EF2KVB1U=.476423ed-39c9-41ce-ae2c-1d50920ff997@github.com>
 <UAi3fwKEz_3ASlZTAe6KR5aFUUxGDatdQYaPnNjQEFQ=.2fafab0b-86a0-4c21-8e5f-dc2e5bd772f7@github.com>
Message-ID: <XnUkhhPl-wdkzCgcXKpPyiPEYZjQh1hsru2AJaiFyP4=.68b83491-2e57-427d-8784-5b6e14a39172@github.com>

On Wed, 12 Oct 2022 13:42:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/hotspot/lib/CompileJvm.gmk line 92:
>> 
>>> 90: 
>>> 91: DISABLED_WARNINGS_clang := ignored-qualifiers sometimes-uninitialized \
>>> 92:     missing-braces delete-non-abstract-non-virtual-dtor unknown-pragmas
>> 
>> Shouldn't shift-negative-value be in the clang list too?
>
> Well, there is currently no instance of clang complaining about this. This could be due to:
> 
> * This warning does not really exist on clang
> * Or it is not enabled by our current clang flags
> * Or the code which triggers the warning in gcc is not reached by clang
> * Or clang is smarter than gcc and can determine that the usage is ok after all
> * Or clang is dumber than gcc and does not even see that there could have been a problem...
> 
> ...
> 
> I'm kind of reluctant to add warnings to this list that have not occurred for real. My suggestion is that we add it here if we ever see it making incorrect claims. Ok?

I'm worried about someone encountering it and uglifying code to work around
it. OTOH, I don't know why we're not seeing this warning with clang, as there
is shared code that should trigger it (and does for gcc). So I'm okay with it
as is.

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

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


From jwaters at openjdk.org  Sun Oct 16 08:45:54 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 16 Oct 2022 08:45:54 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make
Message-ID: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>

Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

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

Commit messages:
 - Commit remaining libraries
 - Merge branch 'openjdk:master' into patch-2
 - Comment change, force link failures to determine libraries to include in make
 - Update WinSysInfo.cpp
 - Update WinFileUtils.cpp
 - Update WinApp.cpp
 - Update MsiUtils.cpp
 - Update MsiDb.cpp
 - Update MsiCA.cpp
 - Update Guid.cpp
 - ... and 12 more: https://git.openjdk.org/jdk/compare/0043d58c...cfa80528

Changes: https://git.openjdk.org/jdk/pull/10633/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295231
  Stats: 35 lines in 14 files changed: 3 ins; 22 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10633.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10633/head:pull/10633

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


From alanb at openjdk.org  Sun Oct 16 13:21:53 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 16 Oct 2022 13:21:53 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <hKcmTXbzhLs2BLZ0U1CK9-buNYwtqqgbj23R5dRFHxQ=.d67542a4-fe38-4c4a-8d1e-f58e2264f175@github.com>

On Mon, 10 Oct 2022 14:15:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c line 38:

> 36: 
> 37: #include <Mswsock.h>
> 38: #pragma comment(lib, "Mswsock.lib")

I think this came about with one of the early Microsoft contributions to have transferTo optionally use TransmitFile on Windows. This create the dependency on Mswsock.

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

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


From dholmes at openjdk.org  Mon Oct 17 02:42:48 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 17 Oct 2022 02:42:48 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <bcCMkRFyhoaqWFr-bpraFJLPnv9jB1ozA700K_-JLZ8=.f5a0047d-7674-4b17-8eae-28b72ed4d816@github.com>

On Mon, 10 Oct 2022 14:15:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

I don't agree with the justification here. This seems very windows specific but I like the idea that the source code tracks its own library dependencies. If I am writing some windows code that uses a particular Windows API which in turn requires a specific windows library, then these pragma comments seem an ideal way to express that dependency. This has the advantage that (a) the developer doesn't require detailed knowledge of the build system to make things work; and (b) there is more chance that if the code is later removed then removing the linking of the library will not get overlooked.

YMMV.

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

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


From stuefe at openjdk.org  Mon Oct 17 06:08:04 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 17 Oct 2022 06:08:04 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <fqolzndii_HWLbTdOthl88tMEu7oWcPrrze74rHVQlY=.07f4b867-564f-4758-a665-b209b1cfa979@github.com>

On Mon, 10 Oct 2022 14:15:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

I like this change. I am pretty sure not many know about this feature at all, we don't have that many knowledgeable Windows developers. If the methods are equivalent, I prefer linking via make file.

Pinging @magicus, maybe he can chime in.

Cheers, Thomas

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

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


From shade at openjdk.org  Mon Oct 17 07:58:02 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 17 Oct 2022 07:58:02 GMT
Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v21]
In-Reply-To: <5CNdaZqYt3cnZZBbs9QDN4K7ebprUsUV3W4-D0m32lA=.d46ec09f-97ea-4656-a3fc-78ac5190e76b@github.com>
References: <RrlZAKdgm0ZtogXG3iVPpmaFQB1Y0kQL2bQPGe6eRus=.95a23c3d-ae0c-4c8f-aab0-2d755236f6f7@github.com>
 <D-ITPMwo33auL08XGAc39o68120N5xzJrdU8_oNZEOY=.9d2c0e17-e793-4d85-9304-5c94d813d216@github.com>
 <5CNdaZqYt3cnZZBbs9QDN4K7ebprUsUV3W4-D0m32lA=.d46ec09f-97ea-4656-a3fc-78ac5190e76b@github.com>
Message-ID: <G25fcPEie8V45Ec2CWQyQHrOpp2u1fVgjnfxmKENMuI=.42a49126-c9d7-49ca-b165-5461284110e3@github.com>

On Sat, 15 Oct 2022 08:11:39 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Looks good.

I think you want to do the actual "Approve" to supersede your previous "Request changes" review.

Anyway, I think we are good for integration here, @magicus?

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

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


From ihse at openjdk.org  Mon Oct 17 09:20:15 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 17 Oct 2022 09:20:15 GMT
Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed [v4]
In-Reply-To: <jx2kU4A0gxp4YCjuO5EP-nxww4wpHTc-vAZd9pJ__TE=.2b87d2e4-8fc8-4bbf-837c-0bac60362121@github.com>
References: <Cuo-hZ2dmp5Su2aMvYe3k_w_rEuzCk7F8wpeCsQuyMA=.911a0412-42c0-44a1-8863-e94e5a7970e7@github.com>
 <jx2kU4A0gxp4YCjuO5EP-nxww4wpHTc-vAZd9pJ__TE=.2b87d2e4-8fc8-4bbf-837c-0bac60362121@github.com>
Message-ID: <N3M1Xj5bkBL6JdbE8tnrL2BiT0FbXDaPBBVm3KpuZ9g=.2b784c24-172d-4ab7-b6eb-b03b1b45ce78@github.com>

On Tue, 11 Oct 2022 08:18:08 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> The DWARF debugging symbols emitted by Clang is different from what GCC is emitting. While GCC produces a complete `.debug_aranges` section (which is required in the DWARF parser), Clang does not. As a result, the DWARF parser cannot find the necessary information to proceed and create the line number information:
>> 
>> The `.debug_aranges` section contains address range to compilation unit offset mappings. The parsing algorithm can just walk through all these entries to find the correct address range that contains the library offset of the current pc. This gives us the compilation unit offset into the `.debug_info` section from where we can proceed to parse the line number information.
>> 
>> Without a complete `.debug_aranges` section, we fail with an assertion that we could not find the correct entry. Since [JDK-8293402](https://bugs.openjdk.org/browse/JDK-8293402), we will still get the complete stack trace at least. Nevertheless, we should still fix this assertion failure of course. But that would require a different parsing approach. We need to parse the entire `.debug_info` section instead to get to the correct compilation unit. This, however, would require a lot more work. 
>> 
>> I therefore suggest to disable DWARF parsing for Clang for now and file an RFE to support Clang in the future with a different parsing approach. I'm using the `__clang__` `ifdef` to bail out in `get_source_info()` and disable the `gtests`. I've noticed that we are currently running the `gtests` with `NOT PRODUCT` which I think is not necessary - the gtests should also work fine with product builds. I've corrected this as well but that could also be done separately.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn 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 six additional commits since the last revision:
> 
>  - Always read full filename and strip prefix path and only then cut filename to fit output buffer
>  - Merge branch 'master' into JDK-8293422
>  - Merge branch 'master' into JDK-8293422
>  - Review comments from Thomas
>  - Change old bailout fix to only apply to Clang versions older than 5.0 and add new fix with -gdwarf-aranges + -gdwarf-4 for Clang 5.0+
>  - 8293422: DWARF emitted by Clang cannot be parsed

Build changes are approved.

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

Marked as reviewed by ihse (Reviewer).

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


From ihse at openjdk.org  Mon Oct 17 09:20:15 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 17 Oct 2022 09:20:15 GMT
Subject: RFR: 8295262: Build binutils out of source tree [v2]
In-Reply-To: <bSD_wby5_F8efochbwYMJ1HFmsm35YeBcvK5q10jXiA=.ab1c5a96-3358-4490-97c3-dd6aaf25790b@github.com>
References: <NFuwvlXJiI8Zuqs3dhe5p74w0dWntpcQvDyaaEAtEXE=.142685f6-1ef1-464a-8b62-1eadf1f0b004@github.com>
 <bSD_wby5_F8efochbwYMJ1HFmsm35YeBcvK5q10jXiA=.ab1c5a96-3358-4490-97c3-dd6aaf25790b@github.com>
Message-ID: <_hJi-YdLKH3Sh2dZFiNoym6rGmrRdCGsCETpfbynh1I=.fb3f5139-3606-4ffc-82cc-2e9d1a11c2da@github.com>

On Thu, 13 Oct 2022 08:41:35 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Currently, when passing --with-binutils-src, binutils is built in the source tree. That leads to conflicting targets when compiling for different architectures (ex: amd64 on the host, and riscv64 or aarch64 for the target) from the same jdk source tree.
>> 
>> The simplest solution is to build binutils out-of-tree and into the build/<target>/binutils folder. These out-of-tree builds are already supported by binutils and only require some changes in the way we invoke the binutils/configure command.
>
> Ludovic Henry has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Remove unrelated change
>  - Merge branch 'master' of github.com:openjdk/jdk into dev/ludovic/upstream-hsdis-cross-compile
>  - 8295262: Build binutils out of source tree
>    
>    Currently, when passing --with-binutils-src, binutils is built in the source tree. That leads to conflicting targets when compiling for different architectures (ex: amd64 on the host, and riscv64 or aarch64 for the target) from the same jdk source tree.
>    
>    The simplest solution is to build binutils out-of-tree and into the build/<target>/binutils folder. These out-of-tree builds are already supported by binutils and only require some changes in the way we invoke the binutils/configure command.

Other than that, it looks good.

make/autoconf/lib-hsdis.m4 line 137:

> 135:   UTIL_FIXUP_PATH(BINUTILS_SRC)
> 136: 
> 137:   BINUTILS_DIR="${OUTPUTDIR}/binutils"

Suggestion:

  BINUTILS_DIR="$CONFIGURESUPPORT_OUTPUTDIR/binutils"


Rationale: "configure-support" includes things that are created by the configure script. We try to avoid cluttering the top level build directory.

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

Marked as reviewed by ihse (Reviewer).

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


From ihse at openjdk.org  Mon Oct 17 09:21:03 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 17 Oct 2022 09:21:03 GMT
Subject: RFR: 8295070: Introduce more target combinations for compiler
 flags [v3]
In-Reply-To: <dEz1C15HnujCTsRaRZ_0G9DV_Z0fyun60AzAfq04hNw=.92012cfb-2a75-4d7f-b062-b5b40b102b4e@github.com>
References: <alUrMJ4fQy9z3dKu3BideMeVLc7DhlUbd_IWx79mZVU=.74eb4654-00b0-497f-9450-e87d9b435e37@github.com>
 <dEz1C15HnujCTsRaRZ_0G9DV_Z0fyun60AzAfq04hNw=.92012cfb-2a75-4d7f-b062-b5b40b102b4e@github.com>
Message-ID: <NLcmaDBMDmpJLQKTvr_3-hcJ3VcOdrp2-GJwWLTYvgM=.877f1979-5fe6-48eb-9405-a31cc00beb0d@github.com>

On Mon, 10 Oct 2022 15:29:16 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Several parts of the make system in the JDK has large parts of cluttered if branches dedicated to setting flags for the specific compiler used in the build. This could be more neatly accomplished by instead adding more target combinations in SetupNativeCompilation so the callsite can more cleanly specify which OS and compiler it desires to set these flags for. The change currently includes:
>> 
>> DISABLED_WARNINGS (including per file warnings), CFLAGS/CXXFLAGS and LDFLAGS: Compiler-then-OS (The priority shown reflects how the flags depend more so on the compiler)
>> LIBS: OS-then-Compiler, as libraries typically vary based on the system being compiled for
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extra spacing

Okay, go ahead.

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

Marked as reviewed by ihse (Reviewer).

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


From ihse at openjdk.org  Mon Oct 17 09:27:10 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 17 Oct 2022 09:27:10 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <F1p3brXZg3gn7JGfj3lajFmsQIxJ4Cvu6l1Xnd5mSyE=.6543a51c-bf60-45a2-9ad0-be7e2d87a074@github.com>

On Mon, 10 Oct 2022 14:15:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

Marked as reviewed by ihse (Reviewer).

Wow. I did not even know this was possible. Thank you for fixing this! I would have been mighty surprised if I were to learn that a library has more dependencies than the one in the makefile.

@dholmes-ora The point is that we need to be consistent. If we would go that route, then *all* libraries should be loaded by pragmas. That could of course be an alternative, but I really see no upside to it. To do it like we currently do, load 99% of the libraries via make files, and then have few scattered pragmas, that's just bad.

@TheShermanTanker Question: is this a Windows-specific thing, or are there pragma-loaded libraries for other compilers as well?

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

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


From ihse at openjdk.org  Mon Oct 17 09:32:13 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 17 Oct 2022 09:32:13 GMT
Subject: Integrated: 8295192: Use original configure command line when called
 from a script
In-Reply-To: <CfmrQekVnw-igzz3MoM3hU4jQUsoQvZqy9IaMczGOUY=.0608299e-8bf2-4ef7-af33-98df034de847@github.com>
References: <CfmrQekVnw-igzz3MoM3hU4jQUsoQvZqy9IaMczGOUY=.0608299e-8bf2-4ef7-af33-98df034de847@github.com>
Message-ID: <YTUpExQOHqfTb8L06Q8CZkPrEOwtoTxwidJuhQ75N3M=.41e919c0-7dd7-4042-8320-195de494821f@github.com>

On Wed, 12 Oct 2022 08:07:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Sometimes, the configure script is not called directly, but indirectly, using e.g. a wrapper script. This happens for instance in the case of using jib.sh.
> 
> In such cases, calling "make reconfigure" will not re-execute the original wrapper script. This can result in subtle bugs.
> 
> Instead, make a way to save the original command line from a wrapper script, and use that instead when running "make reconfigure". 
> 
> This PR also includes the corresponding changes needed to utilize this in jib.sh.

This pull request has now been integrated.

Changeset: 552d8a28
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/552d8a2821f03046896a728d6e4cec0ef754d3f4
Stats:     57 lines in 5 files changed: 54 ins; 0 del; 3 mod

8295192: Use original configure command line when called from a script

Reviewed-by: erikj

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

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


From ihse at openjdk.org  Mon Oct 17 09:34:12 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 17 Oct 2022 09:34:12 GMT
Subject: Integrated: 8294314: Minimize disabled warnings in hotspot
In-Reply-To: <RrlZAKdgm0ZtogXG3iVPpmaFQB1Y0kQL2bQPGe6eRus=.95a23c3d-ae0c-4c8f-aab0-2d755236f6f7@github.com>
References: <RrlZAKdgm0ZtogXG3iVPpmaFQB1Y0kQL2bQPGe6eRus=.95a23c3d-ae0c-4c8f-aab0-2d755236f6f7@github.com>
Message-ID: <o0bu1YzYDGQRLJ0WBtFAgJBY94LMIjUn43x2BYYKoFw=.a48a9463-ef47-4019-b21a-5fa3eecefba4@github.com>

On Fri, 23 Sep 2022 20:22:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot.
> 
> Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.
> 
> Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back.
> 
> I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily.
> 
> I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround.
> 
> It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++).
> 
> Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed.

This pull request has now been integrated.

Changeset: 7743345f
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7743345f6f73398f280fd18364b4cea10a6b0f2f
Stats:     65 lines in 5 files changed: 41 ins; 8 del; 16 mod

8294314: Minimize disabled warnings in hotspot

Co-authored-by: Aleksey Shipilev <shade at openjdk.org>
Reviewed-by: erikj, shade

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

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


From luhenry at openjdk.org  Mon Oct 17 09:37:08 2022
From: luhenry at openjdk.org (Ludovic Henry)
Date: Mon, 17 Oct 2022 09:37:08 GMT
Subject: RFR: 8295262: Build binutils out of source tree [v3]
In-Reply-To: <NFuwvlXJiI8Zuqs3dhe5p74w0dWntpcQvDyaaEAtEXE=.142685f6-1ef1-464a-8b62-1eadf1f0b004@github.com>
References: <NFuwvlXJiI8Zuqs3dhe5p74w0dWntpcQvDyaaEAtEXE=.142685f6-1ef1-464a-8b62-1eadf1f0b004@github.com>
Message-ID: <UL5_BtamFkQrmGqdGp4yE8WNMFEDZ9fxJYx1vIBhvBI=.ade995e5-3704-468a-8c91-51d85c906722@github.com>

> Currently, when passing --with-binutils-src, binutils is built in the source tree. That leads to conflicting targets when compiling for different architectures (ex: amd64 on the host, and riscv64 or aarch64 for the target) from the same jdk source tree.
> 
> The simplest solution is to build binutils out-of-tree and into the build/<target>/binutils folder. These out-of-tree builds are already supported by binutils and only require some changes in the way we invoke the binutils/configure command.

Ludovic Henry has updated the pull request incrementally with one additional commit since the last revision:

  Update make/autoconf/lib-hsdis.m4
  
  Co-authored-by: Magnus Ihse Bursie <mag at icus.se>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10689/files
  - new: https://git.openjdk.org/jdk/pull/10689/files/8faf5083..c78d2f02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10689&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10689&range=01-02

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

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


From luhenry at openjdk.org  Mon Oct 17 09:37:10 2022
From: luhenry at openjdk.org (Ludovic Henry)
Date: Mon, 17 Oct 2022 09:37:10 GMT
Subject: RFR: 8295262: Build binutils out of source tree [v2]
In-Reply-To: <_hJi-YdLKH3Sh2dZFiNoym6rGmrRdCGsCETpfbynh1I=.fb3f5139-3606-4ffc-82cc-2e9d1a11c2da@github.com>
References: <NFuwvlXJiI8Zuqs3dhe5p74w0dWntpcQvDyaaEAtEXE=.142685f6-1ef1-464a-8b62-1eadf1f0b004@github.com>
 <bSD_wby5_F8efochbwYMJ1HFmsm35YeBcvK5q10jXiA=.ab1c5a96-3358-4490-97c3-dd6aaf25790b@github.com>
 <_hJi-YdLKH3Sh2dZFiNoym6rGmrRdCGsCETpfbynh1I=.fb3f5139-3606-4ffc-82cc-2e9d1a11c2da@github.com>
Message-ID: <7ir20KAH1sJ8GnXNVSdB4tyqlj0tommVEnYdPsaBgZM=.008b3839-a21c-4295-a249-6ee3a086942d@github.com>

On Mon, 17 Oct 2022 09:17:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Ludovic Henry has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Remove unrelated change
>>  - Merge branch 'master' of github.com:openjdk/jdk into dev/ludovic/upstream-hsdis-cross-compile
>>  - 8295262: Build binutils out of source tree
>>    
>>    Currently, when passing --with-binutils-src, binutils is built in the source tree. That leads to conflicting targets when compiling for different architectures (ex: amd64 on the host, and riscv64 or aarch64 for the target) from the same jdk source tree.
>>    
>>    The simplest solution is to build binutils out-of-tree and into the build/<target>/binutils folder. These out-of-tree builds are already supported by binutils and only require some changes in the way we invoke the binutils/configure command.
>
> Other than that, it looks good.

@magicus thanks! I committed your change.

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

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


From ihse at openjdk.org  Mon Oct 17 12:24:35 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 17 Oct 2022 12:24:35 GMT
Subject: RFR: 8295262: Build binutils out of source tree [v3]
In-Reply-To: <UL5_BtamFkQrmGqdGp4yE8WNMFEDZ9fxJYx1vIBhvBI=.ade995e5-3704-468a-8c91-51d85c906722@github.com>
References: <NFuwvlXJiI8Zuqs3dhe5p74w0dWntpcQvDyaaEAtEXE=.142685f6-1ef1-464a-8b62-1eadf1f0b004@github.com>
 <UL5_BtamFkQrmGqdGp4yE8WNMFEDZ9fxJYx1vIBhvBI=.ade995e5-3704-468a-8c91-51d85c906722@github.com>
Message-ID: <acy8VbdWSMUw7CCfFz1C_TNypTjhwulSlvdaykqpNrE=.7d6d77cb-5d5f-4dc3-8252-0ca865dad20d@github.com>

On Mon, 17 Oct 2022 09:37:08 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Currently, when passing --with-binutils-src, binutils is built in the source tree. That leads to conflicting targets when compiling for different architectures (ex: amd64 on the host, and riscv64 or aarch64 for the target) from the same jdk source tree.
>> 
>> The simplest solution is to build binutils out-of-tree and into the build/<target>/binutils folder. These out-of-tree builds are already supported by binutils and only require some changes in the way we invoke the binutils/configure command.
>
> Ludovic Henry has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update make/autoconf/lib-hsdis.m4
>   
>   Co-authored-by: Magnus Ihse Bursie <mag at icus.se>

Marked as reviewed by ihse (Reviewer).

If you redo `/integrate`, I can sponsor.

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

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


From shade at openjdk.org  Mon Oct 17 13:40:23 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 17 Oct 2022 13:40:23 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v3]
In-Reply-To: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
Message-ID: <wOwAcasbkjXaIE6ke1Yp7cMRXdjbqo2sJspN_CeNm3k=.63b98484-ac36-46de-9887-d2f9e4bb6ede@github.com>

> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:

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

 - Merge branch 'master' into JDK-8294594-warning-cast-function-type-signals
 - Naming
 - Redo using the proper signatures
 - Merge branch 'master' into JDK-8294594-warning-cast-function-type-signals
 - Fix

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

Changes: https://git.openjdk.org/jdk/pull/10494/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10494&range=02
  Stats: 10 lines in 4 files changed: 0 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/10494.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10494/head:pull/10494

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


From shade at openjdk.org  Mon Oct 17 13:46:48 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 17 Oct 2022 13:46:48 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v3]
In-Reply-To: <wOwAcasbkjXaIE6ke1Yp7cMRXdjbqo2sJspN_CeNm3k=.63b98484-ac36-46de-9887-d2f9e4bb6ede@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <wOwAcasbkjXaIE6ke1Yp7cMRXdjbqo2sJspN_CeNm3k=.63b98484-ac36-46de-9887-d2f9e4bb6ede@github.com>
Message-ID: <VFPpswrGh6Ime5XRVhjxlIe8knmxj6tiP1YA0s76dkk=.5a5d9d17-2759-43b3-9b26-fff9073e2145@github.com>

On Mon, 17 Oct 2022 13:40:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8294594-warning-cast-function-type-signals
>  - Naming
>  - Redo using the proper signatures
>  - Merge branch 'master' into JDK-8294594-warning-cast-function-type-signals
>  - Fix

Build system changes now merged with upstream (look how nice they are). Ready to integrate.

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

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


From shade at openjdk.org  Mon Oct 17 13:59:30 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 17 Oct 2022 13:59:30 GMT
Subject: RFR: 8294591: Fix cast-function-type warning in TemplateTable [v3]
In-Reply-To: <F9kScSH8YZ9kK8XAcl5pPPE6sPrHCBUc_zNriSaP8EU=.d5c7452c-72ed-4f41-9dea-5bd8a7fccbc0@github.com>
References: <F9kScSH8YZ9kK8XAcl5pPPE6sPrHCBUc_zNriSaP8EU=.d5c7452c-72ed-4f41-9dea-5bd8a7fccbc0@github.com>
Message-ID: <ySu9_wOCt2gftFjuwf3sFmwsz-D0Xh5zBfEM5YPyUKU=.1ca50edc-3a45-4936-aa72-c64a260dac43@github.com>

> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have `templateTable.cpp` excluded with cast-function-type warning. The underlying cause for it is casting functions for `ldc` bytecodes, which take `bool`-typed handlers:

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into JDK-8294591-warning-cast-function-type-templatetable
 - Also disable warnings in gtests
 - Fix

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

Changes: https://git.openjdk.org/jdk/pull/10493/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10493&range=02
  Stats: 41 lines in 10 files changed: 6 ins; 1 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/10493.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10493/head:pull/10493

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


From luhenry at openjdk.org  Mon Oct 17 14:06:46 2022
From: luhenry at openjdk.org (Ludovic Henry)
Date: Mon, 17 Oct 2022 14:06:46 GMT
Subject: Integrated: 8295262: Build binutils out of source tree
In-Reply-To: <NFuwvlXJiI8Zuqs3dhe5p74w0dWntpcQvDyaaEAtEXE=.142685f6-1ef1-464a-8b62-1eadf1f0b004@github.com>
References: <NFuwvlXJiI8Zuqs3dhe5p74w0dWntpcQvDyaaEAtEXE=.142685f6-1ef1-464a-8b62-1eadf1f0b004@github.com>
Message-ID: <lf3HcgEQzQVjvCP4wY94t0_Rb1BWOKv13wN3Mx4Og2g=.bac1ee40-5c98-4825-b114-27a8cee37200@github.com>

On Thu, 13 Oct 2022 07:43:33 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

> Currently, when passing --with-binutils-src, binutils is built in the source tree. That leads to conflicting targets when compiling for different architectures (ex: amd64 on the host, and riscv64 or aarch64 for the target) from the same jdk source tree.
> 
> The simplest solution is to build binutils out-of-tree and into the build/<target>/binutils folder. These out-of-tree builds are already supported by binutils and only require some changes in the way we invoke the binutils/configure command.

This pull request has now been integrated.

Changeset: 4d37ef2d
Author:    Ludovic Henry <luhenry at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4d37ef2d545c016e6c3ad52171ea961d4406726f
Stats:     24 lines in 1 file changed: 12 ins; 2 del; 10 mod

8295262: Build binutils out of source tree

Reviewed-by: shade, erikj, ihse

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

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


From jwaters at openjdk.org  Mon Oct 17 14:21:32 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 14:21:32 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make
In-Reply-To: <F1p3brXZg3gn7JGfj3lajFmsQIxJ4Cvu6l1Xnd5mSyE=.6543a51c-bf60-45a2-9ad0-be7e2d87a074@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
 <F1p3brXZg3gn7JGfj3lajFmsQIxJ4Cvu6l1Xnd5mSyE=.6543a51c-bf60-45a2-9ad0-be7e2d87a074@github.com>
Message-ID: <yQkQ2fv6xhYKVjxQcawlr6dCgrA2Ic4GM1JgBnS7-QA=.0e6d20f9-8857-49c6-9cae-1ea5681a28fe@github.com>

On Mon, 17 Oct 2022 09:24:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> @TheShermanTanker Question: is this a Windows-specific thing, or are there pragma-loaded libraries for other compilers as well?

To my knowledge only Visual C++ has the ability to perform linking through pragmas, the comment pragma works by leaving a linker comment in the object file (hence the name), meaning this only works with the Visual C++ linker, so while clang does support this pragma with clang-cl, for the use cases in the JDK it wouldn't matter. gcc does not have an equivalent pragma (or provide support for linking from inside source files at all, for that matter)

> If the methods are equivalent, I prefer linking via make file.

There isn't any difference between the 2 unless the library is tampered with by `-nodefaultlib`, but I can only find that specified in https://github.com/openjdk/jdk/blob/a033aa5a3d9c63d72d11af218b9896b037fbd8de/make/autoconf/flags-other.m4#L38 and https://github.com/openjdk/jdk/blob/392f35df4be1a9a8d7a67a25ae01230c7dd060ac/make/autoconf/lib-hsdis.m4#L45, neither of which have an effect on the libraries in this changeset

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

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


From jwaters at openjdk.org  Mon Oct 17 14:25:08 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 14:25:08 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v2]
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <3fTguMGwo3QBguzYDzhuTVTiqTzn8ZVPiGM5xYuqZbw=.96637af9-ed38-49aa-aa99-71c656a11320@github.com>

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

Julian Waters has updated the pull request incrementally with two additional commits since the last revision:

 - user32
 - Mswsock.lib requirement

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10633/files
  - new: https://git.openjdk.org/jdk/pull/10633/files/cfa80528..54e6ec10

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=00-01

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

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


From jwaters at openjdk.org  Mon Oct 17 14:27:32 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 14:27:32 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v3]
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <2ETlbmDLPJuS-GkWsIceJISmHts7aROCmrbPKS3lsag=.1fbf54ad-a174-4865-87b1-66c20004cb12@github.com>

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Update Guid.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10633/files
  - new: https://git.openjdk.org/jdk/pull/10633/files/54e6ec10..fe15f907

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=01-02

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

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


From jwaters at openjdk.org  Mon Oct 17 14:27:32 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 14:27:32 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v3]
In-Reply-To: <hKcmTXbzhLs2BLZ0U1CK9-buNYwtqqgbj23R5dRFHxQ=.d67542a4-fe38-4c4a-8d1e-f58e2264f175@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
 <hKcmTXbzhLs2BLZ0U1CK9-buNYwtqqgbj23R5dRFHxQ=.d67542a4-fe38-4c4a-8d1e-f58e2264f175@github.com>
Message-ID: <Sdp31g_wPD_84xtCvZxXWZziMxRFoBtCKGaTuAYkJEE=.44879988-0df8-4555-af8f-96fd82870594@github.com>

On Sun, 16 Oct 2022 13:18:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update Guid.cpp
>
> src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c line 38:
> 
>> 36: 
>> 37: #include <Mswsock.h>
>> 38: #pragma comment(lib, "Mswsock.lib")
> 
> I think this came about with one of the early Microsoft contributions to have transferTo optionally use TransmitFile on Windows. This created the dependency on Mswsock. It's not clear why a pragma was used though.

I believe it may have had to do with explicitly showing the dependency as David suggests, I added a comment explaining this just in case

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

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


From jwaters at openjdk.org  Mon Oct 17 14:31:46 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 14:31:46 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v4]
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <ri6EV_458kAizhAbMhhxjl61sZnt8A5hJLODyolkuHk=.b0ee311b-a516-4430-9ca6-3198d05fe584@github.com>

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

Julian Waters has updated the pull request incrementally with five additional commits since the last revision:

 - Update WinSysInfo.cpp
 - Update WinApp.cpp
 - Update MsiUtils.cpp
 - Update MsiDb.cpp
 - Update MsiCA.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10633/files
  - new: https://git.openjdk.org/jdk/pull/10633/files/fe15f907..8afaf85d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=02-03

  Stats: 12 lines in 5 files changed: 11 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10633.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10633/head:pull/10633

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


From jwaters at openjdk.org  Mon Oct 17 14:35:32 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 14:35:32 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v5]
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <1FdeByT381QCHgVhV7RfaietWwt_xj2jmQuZBFklSJM=.0cfa6d5d-3ccd-45cf-84c4-66d3e8b595e4@github.com>

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Update WindowsRegistry.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10633/files
  - new: https://git.openjdk.org/jdk/pull/10633/files/8afaf85d..0779d1fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=03-04

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

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


From jwaters at openjdk.org  Mon Oct 17 14:35:32 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 14:35:32 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v4]
In-Reply-To: <ri6EV_458kAizhAbMhhxjl61sZnt8A5hJLODyolkuHk=.b0ee311b-a516-4430-9ca6-3198d05fe584@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
 <ri6EV_458kAizhAbMhhxjl61sZnt8A5hJLODyolkuHk=.b0ee311b-a516-4430-9ca6-3198d05fe584@github.com>
Message-ID: <q0n5fVZ_fV97Q5JdJI9Ck9Oype80Zuy0mVLJq4MkbVc=.6788d427-8f9c-46f9-9529-87e71be67803@github.com>

On Mon, 17 Oct 2022 14:31:46 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.
>
> Julian Waters has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Update WinSysInfo.cpp
>  - Update WinApp.cpp
>  - Update MsiUtils.cpp
>  - Update MsiDb.cpp
>  - Update MsiCA.cpp

Thanks all for the reviews, I placed comments where the pragmas used to be detailing the library required by the source file to address David's concerns

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

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


From jwaters at openjdk.org  Mon Oct 17 14:41:06 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 14:41:06 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v6]
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <XPviQLGDwrC6qQ-y7NXybMk2S6vUDS9QrqZ6oXI2tBU=.7832f416-03a0-43fd-a271-23727ef28033@github.com>

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Formatting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10633/files
  - new: https://git.openjdk.org/jdk/pull/10633/files/0779d1fa..4eb2eb7b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=04-05

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

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


From shade at openjdk.org  Mon Oct 17 15:53:51 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 17 Oct 2022 15:53:51 GMT
Subject: RFR: 8295417: Pass $AR to binutils cross-build
Message-ID: <6HtpKnR8ifzpqzv5bPIMdNLSkR5YlpB5etkIm1-oBBk=.2556a9b2-6fb0-475d-a9f3-fc334128a136@github.com>

While adapting my CI to build hsdis automatically, I realized that sometimes we miss the proper $AR for binutils cross-build. Configure would then fail like:


$ CXX=aarch64-linux-gnu-g++ CC=aarch64-linux-gnu-gcc sh ./configure --with-debug-level=fastdebug --openjdk-target=aarch64-linux-gnu --with-sysroot=/chroots/arm64 --with-boot-jdk=/home/shade/Install/jdk19u-ea --with-hsdis=binutils --with-binutils-src=binutils-2.38
...

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

Commit messages:
 - Fix

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

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


From asemenyuk at openjdk.org  Mon Oct 17 17:19:59 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 17 Oct 2022 17:19:59 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v6]
In-Reply-To: <XPviQLGDwrC6qQ-y7NXybMk2S6vUDS9QrqZ6oXI2tBU=.7832f416-03a0-43fd-a271-23727ef28033@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
 <XPviQLGDwrC6qQ-y7NXybMk2S6vUDS9QrqZ6oXI2tBU=.7832f416-03a0-43fd-a271-23727ef28033@github.com>
Message-ID: <DXV4QjDHeuDBU7-RvbGkriTesUom6izi4S3bzg3RmYg=.9f496acd-e29b-436a-ad21-465752a4a56b@github.com>

On Mon, 17 Oct 2022 14:41:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Formatting

The change looks harmless. Howevere I don't understand how searching for the standard Windows libs can then become frustrating.

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

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


From erikj at openjdk.org  Mon Oct 17 17:32:57 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 17 Oct 2022 17:32:57 GMT
Subject: RFR: 8295417: Pass $AR to binutils cross-build
In-Reply-To: <6HtpKnR8ifzpqzv5bPIMdNLSkR5YlpB5etkIm1-oBBk=.2556a9b2-6fb0-475d-a9f3-fc334128a136@github.com>
References: <6HtpKnR8ifzpqzv5bPIMdNLSkR5YlpB5etkIm1-oBBk=.2556a9b2-6fb0-475d-a9f3-fc334128a136@github.com>
Message-ID: <DKiASA1nP1KlO4r9Lv4KJOvHAyOuTVpa37VzFajhb24=.b9fe3a94-6b1e-444a-88b4-80a9bdbc0151@github.com>

On Mon, 17 Oct 2022 15:46:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> While adapting my CI to build hsdis automatically, I realized that sometimes we miss the proper $AR for binutils cross-build. Configure would then fail like:
> 
> 
> $ CXX=aarch64-linux-gnu-g++ CC=aarch64-linux-gnu-gcc sh ./configure --with-debug-level=fastdebug --openjdk-target=aarch64-linux-gnu --with-sysroot=/chroots/arm64 --with-boot-jdk=/home/shade/Install/jdk19u-ea --with-hsdis=binutils --with-binutils-src=binutils-2.38
> ...

Marked as reviewed by erikj (Reviewer).

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

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


From erikj at openjdk.org  Mon Oct 17 17:35:59 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 17 Oct 2022 17:35:59 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v6]
In-Reply-To: <XPviQLGDwrC6qQ-y7NXybMk2S6vUDS9QrqZ6oXI2tBU=.7832f416-03a0-43fd-a271-23727ef28033@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
 <XPviQLGDwrC6qQ-y7NXybMk2S6vUDS9QrqZ6oXI2tBU=.7832f416-03a0-43fd-a271-23727ef28033@github.com>
Message-ID: <r0umuBwCmFWWe9qkQRYTFlfbkyddQ7m8s13CN2geicM=.5af8a5c4-74b1-4a13-b54a-f596a67d7e6c@github.com>

On Mon, 17 Oct 2022 14:41:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Formatting

Marked as reviewed by erikj (Reviewer).

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

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


From erikj at openjdk.org  Mon Oct 17 17:41:07 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 17 Oct 2022 17:41:07 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v6]
In-Reply-To: <DXV4QjDHeuDBU7-RvbGkriTesUom6izi4S3bzg3RmYg=.9f496acd-e29b-436a-ad21-465752a4a56b@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
 <XPviQLGDwrC6qQ-y7NXybMk2S6vUDS9QrqZ6oXI2tBU=.7832f416-03a0-43fd-a271-23727ef28033@github.com>
 <DXV4QjDHeuDBU7-RvbGkriTesUom6izi4S3bzg3RmYg=.9f496acd-e29b-436a-ad21-465752a4a56b@github.com>
Message-ID: <t0BhQQWaUJzEKpnh6J_6Du5tu_T_8yiZwDiYteIGMDA=.e10b48bb-b804-40c4-8fa3-28e1e045c4fe@github.com>

On Mon, 17 Oct 2022 17:16:21 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> The change looks harmless. Howevere I don't understand how searching for the standard Windows libs can then become frustrating.

I believe this is part of the effort for https://bugs.openjdk.org/browse/JDK-8288293.

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

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


From asemenyuk at openjdk.org  Mon Oct 17 17:46:04 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 17 Oct 2022 17:46:04 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v6]
In-Reply-To: <t0BhQQWaUJzEKpnh6J_6Du5tu_T_8yiZwDiYteIGMDA=.e10b48bb-b804-40c4-8fa3-28e1e045c4fe@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
 <XPviQLGDwrC6qQ-y7NXybMk2S6vUDS9QrqZ6oXI2tBU=.7832f416-03a0-43fd-a271-23727ef28033@github.com>
 <DXV4QjDHeuDBU7-RvbGkriTesUom6izi4S3bzg3RmYg=.9f496acd-e29b-436a-ad21-465752a4a56b@github.com>
 <t0BhQQWaUJzEKpnh6J_6Du5tu_T_8yiZwDiYteIGMDA=.e10b48bb-b804-40c4-8fa3-28e1e045c4fe@github.com>
Message-ID: <bVlrub4RmKlF4OQ1B7hhwVOSL6wysDgQjLBqKqSfTIU=.89091be9-b6c4-4071-91c9-2e85b268bd68@github.com>

On Mon, 17 Oct 2022 17:37:11 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I believe this is part of the effort for https://bugs.openjdk.org/browse/JDK-8288293.

Agree. I'd prefer to have a different description of the bug though to make it clear that this is necessary for decoupling a compiler and an OS.

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

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


From shade at openjdk.org  Mon Oct 17 18:08:21 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 17 Oct 2022 18:08:21 GMT
Subject: RFR: 8294468: Fix char-subscripts warnings in Hotspot [v2]
In-Reply-To: <yVMMHRt6X8ymbZTqHj-NF94La-RXw53SNrwMWdLPiik=.d83d8fb6-72a0-46d0-a5b0-6909597a2319@github.com>
References: <yVMMHRt6X8ymbZTqHj-NF94La-RXw53SNrwMWdLPiik=.d83d8fb6-72a0-46d0-a5b0-6909597a2319@github.com>
Message-ID: <Vq9vre50I_x_quAwP0TfM9I0lKNF6mdA6S2AaXcpBKo=.b6d37819-0570-4f51-9620-a33d20e9867d@github.com>

> There seem to be the only place in Hotspot where this warning fires, yet the warning is disabled wholesale for Hotspot. This is not good.
> 
> I can trace the addition of char-subscripts exclusion to [JDK-8211029](https://bugs.openjdk.org/browse/JDK-8211029) (Sep 2018). The only place in Hotspot where in fires is present from the initial load (2007).
> 
> The underlying problem that this warning tells us about is that `char` might be signed on some platforms, so we can potentially access the negative index. It is not a bug in our current code, that bounds the value of `k` under `MAXID-1`, which is `19`.
> 
> Additional testing:
>  - [ ] Linux x86_64 fastdebug `tier1`
>  - [x] The build matrix of:
>    - GCC 10
>    - {i686, x86_64, aarch64, powerpc64le, s390x, armhf, riscv64}
>    - {server}
>    - {release, fastdebug}

Aleksey Shipilev 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 JDK-8294468-warning-char-subscripts
 - Fix

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

Changes: https://git.openjdk.org/jdk/pull/10455/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10455&range=01
  Stats: 4 lines in 2 files changed: 1 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10455.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10455/head:pull/10455

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


From shade at openjdk.org  Mon Oct 17 18:08:56 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 17 Oct 2022 18:08:56 GMT
Subject: RFR: 8294591: Fix cast-function-type warning in TemplateTable [v4]
In-Reply-To: <F9kScSH8YZ9kK8XAcl5pPPE6sPrHCBUc_zNriSaP8EU=.d5c7452c-72ed-4f41-9dea-5bd8a7fccbc0@github.com>
References: <F9kScSH8YZ9kK8XAcl5pPPE6sPrHCBUc_zNriSaP8EU=.d5c7452c-72ed-4f41-9dea-5bd8a7fccbc0@github.com>
Message-ID: <2jHTulm9tMRZEq_tFq7UMUJjWwIS7TIoOkfxjVsseG8=.e69ac9a2-cf39-4972-818a-77cdf0ed93d6@github.com>

> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have `templateTable.cpp` excluded with cast-function-type warning. The underlying cause for it is casting functions for `ldc` bytecodes, which take `bool`-typed handlers:

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Fix build failures

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10493/files
  - new: https://git.openjdk.org/jdk/pull/10493/files/5aa7e6b4..def34465

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10493&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10493&range=02-03

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

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


From shade at openjdk.org  Mon Oct 17 18:21:48 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 17 Oct 2022 18:21:48 GMT
Subject: RFR: 8294467: Fix sequence-point warnings in Hotspot [v2]
In-Reply-To: <lcvbaBpvI_ed3tUlZ9urqL_0ud81LJJ2VE8xO_CeI2o=.89deefe3-6a5d-49d8-b0b3-ab61a91770c4@github.com>
References: <lcvbaBpvI_ed3tUlZ9urqL_0ud81LJJ2VE8xO_CeI2o=.89deefe3-6a5d-49d8-b0b3-ab61a91770c4@github.com>
Message-ID: <oX0DTvf22HNXEvXQyLsxjdGqDaykvlxgv2yMvwrjZzo=.6a91b80d-da9c-44b3-8575-bfa5e8bf8d35@github.com>

> There seem to be the only place in Hotspot where this warning fires, yet the warning is disabled wholesale for Hotspot. This is not good.
> 
> I can trace the addition of sequence-point exclusion to [JDK-8211029](https://bugs.openjdk.org/browse/JDK-8211029) (Sep 2018), yet the only place where it triggers introduced by [JDK-8259609](https://bugs.openjdk.org/browse/JDK-8259609) (Oct 2021). It seems other places were fixed meanwhile.
> 
> I believe the fixed place is just a simple leftover. Right, @rwestrel?
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `tier1`
>  - [x]  Linux x86_64 fastdebug `tier2`
>  - [x] The build matrix of:
>    - GCC 10
>    - {i686, x86_64, aarch64, powerpc64le, s390x, armhf, riscv64}
>    - {server}
>    - {release, fastdebug}

Aleksey Shipilev 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 JDK-8294467-warning-sequence-point
 - Fix

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

Changes: https://git.openjdk.org/jdk/pull/10454/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10454&range=01
  Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10454.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10454/head:pull/10454

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


From shade at openjdk.org  Mon Oct 17 18:27:44 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 17 Oct 2022 18:27:44 GMT
Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot [v2]
In-Reply-To: <HD7TvGmoIxJ9QqJyf_LVdutwVXEoxRiWseOWQEe-zpo=.b22712aa-15a3-4702-b160-30df20d72cff@github.com>
References: <HD7TvGmoIxJ9QqJyf_LVdutwVXEoxRiWseOWQEe-zpo=.b22712aa-15a3-4702-b160-30df20d72cff@github.com>
Message-ID: <rttuFnvgSY1hctcjE_de2vwHeRaUsEDmhehUpWZhXF0=.1e352acc-a50a-4f95-b769-8cf1c27320de@github.com>

> There are number of places where misleading-indentation is reported by GCC. Currently, the warning is disabled for the entirety of Hotspot, which is not good.
> 
> C1 does an unusual style here. Changing it globally would touch a lot of lines. Instead of doing that, I fit the existing style while also resolving the warnings. Note this actually solves a bug in `lir_alloc_array`, where `do_temp` are called without a check.
> 
> Build-tested this with product of:
>   - GCC 10
>   - {i686, x86_64, aarch64, powerpc64le, s390x, armhf, riscv64}
>   - {server, zero}
>   - {release, fastdebug}
> 
> Linux x86_64 fastdebug `tier1` is fine.

Aleksey Shipilev 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 JDK-8294438-misleading-indentation
 - Merge branch 'master' into JDK-8294438-misleading-indentation
 - Also javaClasses.cpp
 - Fix

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

Changes: https://git.openjdk.org/jdk/pull/10444/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10444&range=01
  Stats: 56 lines in 5 files changed: 7 ins; 20 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/10444.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10444/head:pull/10444

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


From vlivanov at openjdk.org  Mon Oct 17 19:03:53 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 17 Oct 2022 19:03:53 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
Message-ID: <kqwSqCs6MNEu7Id4LkRnoALJNexFMeLhz9rrXnIAzEE=.1cf027d0-ffe6-41be-8586-bf102cdafb4e@github.com>

On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>> 
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>> 
>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
>> 
>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

FTR I did an exercise in source code archeology and here are my findings.

The origin of `AlwaysRestoreFPU`-related code (both in x86-32 and arm-specific code) can be traced back to [JDK-6487931](https://bugs.openjdk.org/browse/JDK-6487931) and [JDK-6550813](https://bugs.openjdk.org/browse/JDK-6550813). Though both issues manifested as JVM crashes, the underlying problem was identified as FPU control word corruption by native code.

The regression test does trigger the corruption from a JNI call (using either `_FPU_SETCW` [1] or `_controlfp` [2]), but it was deliberately limited to x86-32. 

Based on that, I conclude that the problem with FP environment corruption by native code was known before, but an opt-in solution was chosen. 

(Frankly speaking, I don't know why an opt-in solution was considered sufficient. Maybe because it was erroneously believed it can only lead to a crash at runtime?)

Considering we are now aware about insidious nature of the problem (silent result corruption), I'm inclined to propose either to turn on `AlwaysRestoreFPU` by default (and provide implementation on platforms where it is missed) or, at least, catch FPU control word corruption on native->java transitions and crash the JVM advertising `-XX:+AlwaysRestoreFPU` as a solution.

[1] https://man7.org/linux/man-pages/man3/__setfpucw.3.html
[2] https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/control87-controlfp-control87-2?view=msvc-170

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

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


From kbarrett at openjdk.org  Mon Oct 17 19:45:06 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 17 Oct 2022 19:45:06 GMT
Subject: RFR: 8294468: Fix char-subscripts warnings in Hotspot [v2]
In-Reply-To: <Vq9vre50I_x_quAwP0TfM9I0lKNF6mdA6S2AaXcpBKo=.b6d37819-0570-4f51-9620-a33d20e9867d@github.com>
References: <yVMMHRt6X8ymbZTqHj-NF94La-RXw53SNrwMWdLPiik=.d83d8fb6-72a0-46d0-a5b0-6909597a2319@github.com>
 <Vq9vre50I_x_quAwP0TfM9I0lKNF6mdA6S2AaXcpBKo=.b6d37819-0570-4f51-9620-a33d20e9867d@github.com>
Message-ID: <LD86mUfbQr093xCED5SLisnqboNgA_JPRgSXtmQza4A=.c49c1592-9ac1-426b-b6a0-a732cdcbe94d@github.com>

On Mon, 17 Oct 2022 18:08:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> There seem to be the only place in Hotspot where this warning fires, yet the warning is disabled wholesale for Hotspot. This is not good.
>> 
>> I can trace the addition of char-subscripts exclusion to [JDK-8211029](https://bugs.openjdk.org/browse/JDK-8211029) (Sep 2018). The only place in Hotspot where in fires is present from the initial load (2007).
>> 
>> The underlying problem that this warning tells us about is that `char` might be signed on some platforms, so we can potentially access the negative index. It is not a bug in our current code, that bounds the value of `k` under `MAXID-1`, which is `19`.
>> 
>> Additional testing:
>>  - [ ] Linux x86_64 fastdebug `tier1`
>>  - [x] The build matrix of:
>>    - GCC 10
>>    - {i686, x86_64, aarch64, powerpc64le, s390x, armhf, riscv64}
>>    - {server}
>>    - {release, fastdebug}
>
> Aleksey Shipilev 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 JDK-8294468-warning-char-subscripts
>  - Fix

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From jwaters at openjdk.org  Mon Oct 17 21:00:10 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 21:00:10 GMT
Subject: Integrated: 8295231: Move all linking of native libraries to make
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <LJqNsfDg8OzA5tusYcYOBxXZnvR0HQH1dmryNmNTJnM=.c6e7c7fa-efd1-4f09-a3cf-02689ce58e20@github.com>

On Mon, 10 Oct 2022 14:15:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

This pull request has now been integrated.

Changeset: 8d751de3
Author:    Julian Waters <jwaters at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8d751de3198675b22704cdccafaff2fc0fdd3f59
Stats:     26 lines in 14 files changed: 3 ins; 6 del; 17 mod

8295231: Move all linking of native libraries to make

Reviewed-by: ihse, erikj

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

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


From dholmes at openjdk.org  Mon Oct 17 22:06:08 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 17 Oct 2022 22:06:08 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
Message-ID: <gQkuJhbbesfIs1Y8D0IH9qbAwF39BWXBbtAUiWHqDz8=.901df730-7576-4934-9481-aafb244dbf20@github.com>

On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>> 
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>> 
>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
>> 
>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

None of this seems adequate. If you guard the dlopen this is a race as the thread doing the dlopen could get switched out leading to corruption in other threads. But we can't just simply save/restore across JNI calls either as we may save the bad env if the dlopen just occurred! The pre-existing "fixes" in this area seem similarly inadequate (and my recollection of issues was that this was an opt-in band-aid while people migrated away from using problematic native libraries, or else got them fixed).

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

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


From dholmes at openjdk.org  Tue Oct 18 01:54:45 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Oct 2022 01:54:45 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v3]
In-Reply-To: <wOwAcasbkjXaIE6ke1Yp7cMRXdjbqo2sJspN_CeNm3k=.63b98484-ac36-46de-9887-d2f9e4bb6ede@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <wOwAcasbkjXaIE6ke1Yp7cMRXdjbqo2sJspN_CeNm3k=.63b98484-ac36-46de-9887-d2f9e4bb6ede@github.com>
Message-ID: <cgI4Uv-g3yJfQ7P2v1i5kOCzSVv1mZDRqXUxLhQC6gk=.fc3c2062-d63b-47ce-a602-c0539f748817@github.com>

On Mon, 17 Oct 2022 13:40:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8294594-warning-cast-function-type-signals
>  - Naming
>  - Redo using the proper signatures
>  - Merge branch 'master' into JDK-8294594-warning-cast-function-type-signals
>  - Fix

Marked as reviewed by dholmes (Reviewer).

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

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


From dholmes at openjdk.org  Tue Oct 18 02:03:10 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Oct 2022 02:03:10 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
Message-ID: <v00nWEyEEGO0dPogvadShq7Naa8_4lGweiz6TCIatRo=.c439fe3c-b870-454b-9021-e3e4d744cc08@github.com>

On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>> 
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>> 
>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
>> 
>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

For the benefit of the mailing list my previous comment has been edited/corrected:

Correction: I was under the false impression the FP-state was shared at the process level but I've been told it is per-thread. So the scope of the problem is much narrower.

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

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


From jiefu at openjdk.org  Tue Oct 18 02:43:15 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Tue, 18 Oct 2022 02:43:15 GMT
Subject: RFR: 8295435: Build failure with GCC7 after JDK-8294314 due to
 strict-overflow warnings
Message-ID: <MfpoUz4c28EwXR92TOPiHJ7uDJbxWmQqtEClKKiQCsw=.ea1d7f4d-6b70-4b1b-8e54-6f1c52148cce@github.com>

Hi all,

Let's disable `-Werror=strict-overflow` to get it build with gcc7 on Linux/x86.

bytecodeAssembler.cpp
instanceKlass.cpp
klassVtable.cpp


Thanks.
Best regards,
Jie

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

Commit messages:
 - 8295435: Build failure with GCC7 after JDK-8294314 due to strict-overflow warnings

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

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


From fweimer at openjdk.org  Tue Oct 18 07:49:01 2022
From: fweimer at openjdk.org (Florian Weimer)
Date: Tue, 18 Oct 2022 07:49:01 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
Message-ID: <xxQC1v4HvKMDrFPl5buDM5nhwjTtlmU9bqKyBAmr9ms=.36545a65-a197-4841-bc90-209d48afff70@github.com>

On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>> 
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>> 
>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
>> 
>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

I wonder if something that focuses on diagnostic tools might be better here, particularly if there hasn't been any reported breakage. The `dlopen` protection is of course very incomplete because any JNI call can change the state in unexpected ways.

On the other hand, it seems unlikely that this change breaks some undefined but intended use of the FPU state because if it is changed in `dlopen`, it's not going to be propagated across threads.

src/hotspot/os/linux/os_linux.cpp line 1759:

> 1757:   assert(rtn == 0, "fegetnv must succeed");
> 1758:   void * result = ::dlopen(filename, RTLD_LAZY);
> 1759:   rtn = fesetenv(&curr_fenv);

`fesetenv` in glibc does not unconditionally restore the old FPU control bits, only the non-reserved bits. (The mask is 0xf3f, which seems to cover everything in use today.)  It seems unlikely that more bits are going to be defined in the future. But using `fesetenv` to essentially guard against undefined behavior after the fact is a bit awkward.

MXSCR is passed through unconditionally.

test/hotspot/jtreg/compiler/floatingpoint/libfast-math.c line 24:

> 22:  */
> 23: 
> 24: // This file is intentionally left blank.

This test will silently break (no longer test what's intended) once we change GCC not to link with `crtfastmath.o` for `-shared`. Maybe you should link with `crtfastmath.o` explicitly if it exists, or change the floating point control word directly in an ELF constructor.

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

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


From aph at openjdk.org  Tue Oct 18 08:42:08 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 18 Oct 2022 08:42:08 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <xxQC1v4HvKMDrFPl5buDM5nhwjTtlmU9bqKyBAmr9ms=.36545a65-a197-4841-bc90-209d48afff70@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
 <xxQC1v4HvKMDrFPl5buDM5nhwjTtlmU9bqKyBAmr9ms=.36545a65-a197-4841-bc90-209d48afff70@github.com>
Message-ID: <8t170OCYrgUss1r0NNupyGFe3wD9WXRVbhHXAwi1YBw=.bd10d95f-a87c-46e3-942c-11665041dd32@github.com>

On Tue, 18 Oct 2022 07:43:13 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8295159: DSO created with -ffast-math breaks Java floating-point arithmetic
>
> src/hotspot/os/linux/os_linux.cpp line 1759:
> 
>> 1757:   assert(rtn == 0, "fegetnv must succeed");
>> 1758:   void * result = ::dlopen(filename, RTLD_LAZY);
>> 1759:   rtn = fesetenv(&curr_fenv);
> 
> `fesetenv` in glibc does not unconditionally restore the old FPU control bits, only the non-reserved bits. (The mask is 0xf3f, which seems to cover everything in use today.)  It seems unlikely that more bits are going to be defined in the future. But using `fesetenv` to essentially guard against undefined behavior after the fact is a bit awkward.
> 
> MXSCR is passed through unconditionally.

Mmm, but `fesetenv` is the only portable thing we have (AFAIK). An alternative to using `fesetenv` everywhere would be to use `fesetenv` in generic code and override it in a per-backend way.

> test/hotspot/jtreg/compiler/floatingpoint/libfast-math.c line 24:
> 
>> 22:  */
>> 23: 
>> 24: // This file is intentionally left blank.
> 
> This test will silently break (no longer test what's intended) once we change GCC not to link with `crtfastmath.o` for `-shared`. Maybe you should link with `crtfastmath.o` explicitly if it exists, or change the floating point control word directly in an ELF constructor.

Perhaps so, yes.

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

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


From shade at openjdk.org  Tue Oct 18 08:50:18 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Oct 2022 08:50:18 GMT
Subject: Integrated: 8294594: Fix cast-function-type warnings in signal
 handling code
In-Reply-To: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
Message-ID: <PDWZ1TRaf3PCjbTxrC8vTUpDl4udVa00xKg_Ap_Xt6k=.9dafe0fd-9145-4b90-b4c0-b5c8c19e36a9@github.com>

On Thu, 29 Sep 2022 16:12:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:

This pull request has now been integrated.

Changeset: b06f1b14
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b06f1b149c8f8a49d4e42c4b782a4b3a22aa79f6
Stats:     10 lines in 4 files changed: 0 ins; 2 del; 8 mod

8294594: Fix cast-function-type warnings in signal handling code

Reviewed-by: dholmes, kbarrett

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

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


From shade at openjdk.org  Tue Oct 18 15:24:02 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Oct 2022 15:24:02 GMT
Subject: RFR: 8295435: Build failure with GCC7 after JDK-8294314 due to
 strict-overflow warnings
In-Reply-To: <MfpoUz4c28EwXR92TOPiHJ7uDJbxWmQqtEClKKiQCsw=.ea1d7f4d-6b70-4b1b-8e54-6f1c52148cce@github.com>
References: <MfpoUz4c28EwXR92TOPiHJ7uDJbxWmQqtEClKKiQCsw=.ea1d7f4d-6b70-4b1b-8e54-6f1c52148cce@github.com>
Message-ID: <7GcM69VvZbBRWQ3FFmfWIJHblc1RE_mgMByqosEQy2I=.c9c841be-0d65-4bfd-a641-f238dc9982b4@github.com>

On Tue, 18 Oct 2022 02:35:59 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Let's disable `-Werror=strict-overflow` to get it build with gcc7 on Linux/x86.
> 
> bytecodeAssembler.cpp
> instanceKlass.cpp
> klassVtable.cpp
> 
> 
> Thanks.
> Best regards,
> Jie

My CI reports the mainline failures with GCC 6 in the following configs:


linux-x86_64-server-fastdebug
linux-aarch64-server-fastdebug
linux-arm-server-fastdebug
linux-ppc64le-server-fastdebug
linux-s390x-server-fastdebug
linux-ppc64-server-fastdebug


This PR solves part of the failures, but some require more work:


diff --git a/make/hotspot/lib/CompileJvm.gmk b/make/hotspot/lib/CompileJvm.gmk
index 77d1ff6e21c..816eb4d9996 100644
--- a/make/hotspot/lib/CompileJvm.gmk
+++ b/make/hotspot/lib/CompileJvm.gmk
@@ -166,2 +166,3 @@ $(eval $(call SetupJdkLibrary, BUILD_LIBJVM, \
     DISABLED_WARNINGS_gcc_loopnode.cpp := sequence-point, \
+    DISABLED_WARNINGS_gcc_objArrayKlass.cpp := strict-overflow, \
     DISABLED_WARNINGS_gcc_postaloc.cpp := address, \


Since the warning seems to be caused by the popular header, it is likely to break some other platforms/files through the different include paths from the different compilation units. The warning also looks fairly dubious, and probably is GCC bug, as it does not trigger with higher GCCs? Because of this, I suggest we add `strict-overflow` back to the global warning exclusion list:


diff --git a/make/hotspot/lib/CompileJvm.gmk b/make/hotspot/lib/CompileJvm.gmk
index 6d4e01d1aed..534c50cc77a 100644
--- a/make/hotspot/lib/CompileJvm.gmk
+++ b/make/hotspot/lib/CompileJvm.gmk
@@ -94,6 +94,8 @@ DISABLED_WARNINGS_clang := ignored-qualifiers sometimes-uninitialized \
 ifneq ($(DEBUG_LEVEL), release)
   # Assert macro gives warning
   DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare
+  # Some reasonable asserts produce warnings on GCC <= 7
+  DISABLED_WARNINGS_gcc += strict-overflow
 endif
 
 DISABLED_WARNINGS_xlc := tautological-compare shift-negative-value

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

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


From chagedorn at openjdk.org  Tue Oct 18 15:24:04 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 18 Oct 2022 15:24:04 GMT
Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed [v4]
In-Reply-To: <jx2kU4A0gxp4YCjuO5EP-nxww4wpHTc-vAZd9pJ__TE=.2b87d2e4-8fc8-4bbf-837c-0bac60362121@github.com>
References: <Cuo-hZ2dmp5Su2aMvYe3k_w_rEuzCk7F8wpeCsQuyMA=.911a0412-42c0-44a1-8863-e94e5a7970e7@github.com>
 <jx2kU4A0gxp4YCjuO5EP-nxww4wpHTc-vAZd9pJ__TE=.2b87d2e4-8fc8-4bbf-837c-0bac60362121@github.com>
Message-ID: <OG6PBKDNftaAF-ybH8jebIjEs5qcomgL90FAcuxg5AU=.640a50d1-3617-4c86-8959-491226b5346a@github.com>

On Tue, 11 Oct 2022 08:18:08 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> The DWARF debugging symbols emitted by Clang is different from what GCC is emitting. While GCC produces a complete `.debug_aranges` section (which is required in the DWARF parser), Clang does not. As a result, the DWARF parser cannot find the necessary information to proceed and create the line number information:
>> 
>> The `.debug_aranges` section contains address range to compilation unit offset mappings. The parsing algorithm can just walk through all these entries to find the correct address range that contains the library offset of the current pc. This gives us the compilation unit offset into the `.debug_info` section from where we can proceed to parse the line number information.
>> 
>> Without a complete `.debug_aranges` section, we fail with an assertion that we could not find the correct entry. Since [JDK-8293402](https://bugs.openjdk.org/browse/JDK-8293402), we will still get the complete stack trace at least. Nevertheless, we should still fix this assertion failure of course. But that would require a different parsing approach. We need to parse the entire `.debug_info` section instead to get to the correct compilation unit. This, however, would require a lot more work. 
>> 
>> I therefore suggest to disable DWARF parsing for Clang for now and file an RFE to support Clang in the future with a different parsing approach. I'm using the `__clang__` `ifdef` to bail out in `get_source_info()` and disable the `gtests`. I've noticed that we are currently running the `gtests` with `NOT PRODUCT` which I think is not necessary - the gtests should also work fine with product builds. I've corrected this as well but that could also be done separately.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn 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 six additional commits since the last revision:
> 
>  - Always read full filename and strip prefix path and only then cut filename to fit output buffer
>  - Merge branch 'master' into JDK-8293422
>  - Merge branch 'master' into JDK-8293422
>  - Review comments from Thomas
>  - Change old bailout fix to only apply to Clang versions older than 5.0 and add new fix with -gdwarf-aranges + -gdwarf-4 for Clang 5.0+
>  - 8293422: DWARF emitted by Clang cannot be parsed

Thanks Magnus for your review of the build changes! 

May a get a second review of the DWARF parser code changes?

Thanks,
Christian

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

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


From vlivanov at openjdk.org  Tue Oct 18 17:51:30 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 18 Oct 2022 17:51:30 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
Message-ID: <aJOuhR78rfj6YbTLzHvIsVtvSpv6M1szyuEFQLgDLuQ=.317a2d2a-6239-4407-8825-a2523d2835e2@github.com>

On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>> 
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>> 
>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
>> 
>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

Some additional info to consider: the library modifies only MXCSR register and `-XX:+RestoreMXCSROnJNICalls` makes the test to pass. 


$ objdump -D libfast-math.so
...
0000000000000560 <set_fast_math>:
 560:   f3 0f 1e fa             endbr64
 564:   0f ae 5c 24 fc          stmxcsr -0x4(%rsp)
 569:   81 4c 24 fc 40 80 00    orl    $0x8040,-0x4(%rsp)
 570:   00
 571:   0f ae 54 24 fc          ldmxcsr -0x4(%rsp)
 576:   c3                      ret

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

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


From vlivanov at openjdk.org  Tue Oct 18 18:02:10 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 18 Oct 2022 18:02:10 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
Message-ID: <Z-rx5hRupWoTtwSdG2oeUd6PrwYSXB-n6s0dyRYvlt4=.70ff582d-b27c-49ab-9bb2-0194ee0744ba@github.com>

On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>> 
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>> 
>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
>> 
>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

On non-windows x86-64 the JVM saves/restores (and adjusts if needed) MXCSR inside call stub as mandated by the ABI:
https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#L262-L273

x87 is not used in x86-64-specific code anymore, so x87-specific part of FP environment (FPSR and FPCS registers) is not relevant to JVM anymore there.

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

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


From vlivanov at openjdk.org  Tue Oct 18 18:34:27 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 18 Oct 2022 18:34:27 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
Message-ID: <3_cE2VNWa47otWcHuc-OG5CxNWp_O_CSswd1pcFlJ9I=.e17801eb-ba0d-41bb-b405-27a405295aec@github.com>

On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>> 
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>> 
>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
>> 
>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

So, IMO the discussion boils down to how we want a misbehaving native library to be handled by the JVM.

The ABI lists MXCSR as a callee-saved register, so there's nothing wrong on JVM side from that perspective.

>From a quality of implementation perspective though, JVM could do a better job at catching broken libraries. Of course, there are numerous ways for a native code to break the JVM, but in this particular case, it looks trivial to catch the problem. The question is how much overhead we can afford to introduce for that. Whether it should be an opt-in solution (e.g., `-Xcheck:jni` or `-XX:+AlwaysRestoreFPU`/`-XX:+RestoreMXCSROnJNICalls`), opt-out (unconditionally recover or report an error when FP env is corrupted, optionally providing a way to turn it off), or apply a band-aid fix just to fix the immediate problem with GCC's fast-math mode.

I'd like to dissuade from going with just a band-aid fix (we already went through that multiple times with different level of success) and try to improve the overall experience JVM provides. It feels like just pushing the problem further away and it would be very unfortunate to repeat the very same exercise in the future. 

My preferred solution would be to automatically detect the corruption and restore MXCSR register across a JNI call, but if it turns out to be too expensive, JVM could check for MXCSR register corruption after every JNI call and crash issuing a message with diagnostic details about where corruption happened (info about library and entry) offering to turn on  `-XX:+AlwaysRestoreFPU`/`-XX:+RestoreMXCSROnJNICalls` as a stop-the-gap solution. It would send users a clear signal there's something wrong with their code/environment, but still giving them an option to workaround the problem while fixing the issue. 

Saying that, I'd like to stress that I'm perfectly fine with addressing the general issue of misbehaving native libraries separately (if we agree it's worth it) and I trust @dholmes-ora and @theRealAph to choose the most appropriate fix for this particular bug.

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

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


From ihse at openjdk.org  Tue Oct 18 22:24:39 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 18 Oct 2022 22:24:39 GMT
Subject: RFR: 8294466: Minimize disabled warnings in java.desktop
Message-ID: <P3ypBcY4pLz6ruMi5FIS6dZDO959LJ7nvW0BePnzyqQ=.958cf136-95bc-4715-8b6e-e9c110761539@github.com>

After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.desktop native libraries.

Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.

Some warnings didn't trigger in any file anymore, and could just be removed.

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

Commit messages:
 - Merge branch 'master' into java.desktop-warnings-per-file
 - Fix java.desktop-static-libs
 - 8295419: JFR: Change name of jdk.JitRestart
 - 8295517: Fix stutter typo in JDK-8294539
 - 8295029: runtime/cds/appcds/LotsOfClasses.java fail with jfx
 - 8284614: on macOS "spindump" should be run from failure_handler as root
 - 8285306: Fix typos in java.desktop
 - 6924219: (fc spec) FileChannel.write(ByteBuffer, position) behavior when file opened for append not specified
 - 8295457: Make the signatures of write barrier methods consistent
 - 8295469: S390X: Optimized builds are broken
 - ... and 286 more: https://git.openjdk.org/jdk/compare/ecfb6bce...1c855e42

Changes: https://git.openjdk.org/jdk/pull/10453/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10453&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294466
  Stats: 100 lines in 2 files changed: 43 ins; 18 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/10453.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10453/head:pull/10453

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


From jiefu at openjdk.org  Wed Oct 19 01:51:32 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 19 Oct 2022 01:51:32 GMT
Subject: RFR: 8295435: Build failure with GCC7 after JDK-8294314 due to
 strict-overflow warnings [v2]
In-Reply-To: <MfpoUz4c28EwXR92TOPiHJ7uDJbxWmQqtEClKKiQCsw=.ea1d7f4d-6b70-4b1b-8e54-6f1c52148cce@github.com>
References: <MfpoUz4c28EwXR92TOPiHJ7uDJbxWmQqtEClKKiQCsw=.ea1d7f4d-6b70-4b1b-8e54-6f1c52148cce@github.com>
Message-ID: <LPx1Ffia3Alf3qSjLVbkW2vDH1msopZXtznczxKtoG8=.41cfb193-4d49-47ce-8622-1bf79313d40f@github.com>

> Hi all,
> 
> Let's disable `-Werror=strict-overflow` to get it build with gcc7 on Linux/x86.
> 
> bytecodeAssembler.cpp
> instanceKlass.cpp
> klassVtable.cpp
> 
> 
> Thanks.
> Best regards,
> Jie

Jie Fu has updated the pull request incrementally with one additional commit since the last revision:

  Disable strict-overflow warnings globally

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10738/files
  - new: https://git.openjdk.org/jdk/pull/10738/files/dcf8c0c0..b354a646

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10738&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10738&range=00-01

  Stats: 5 lines in 1 file changed: 2 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10738.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10738/head:pull/10738

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


From jiefu at openjdk.org  Wed Oct 19 01:52:42 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 19 Oct 2022 01:52:42 GMT
Subject: RFR: 8295435: Build failure with GCC7 after JDK-8294314 due to
 strict-overflow warnings [v2]
In-Reply-To: <7GcM69VvZbBRWQ3FFmfWIJHblc1RE_mgMByqosEQy2I=.c9c841be-0d65-4bfd-a641-f238dc9982b4@github.com>
References: <MfpoUz4c28EwXR92TOPiHJ7uDJbxWmQqtEClKKiQCsw=.ea1d7f4d-6b70-4b1b-8e54-6f1c52148cce@github.com>
 <7GcM69VvZbBRWQ3FFmfWIJHblc1RE_mgMByqosEQy2I=.c9c841be-0d65-4bfd-a641-f238dc9982b4@github.com>
Message-ID: <JPMUyEOxhpGyn5UFOZlo6ykQD5C-AjDu_0T7yfUnn3g=.4cfe9bf4-c3a2-4c2a-b46d-e19945a7f0ca@github.com>

On Tue, 18 Oct 2022 15:21:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Since the warning seems to be caused by the popular header, it is likely to break some other platforms/files through the different include paths from the different compilation units. The warning also looks fairly dubious, and probably is GCC bug, as it does not trigger with higher GCCs? Because of this, I suggest we add `strict-overflow` back to the global warning exclusion list

Good suggestion.
Updated.
Thanks.

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

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


From shade at openjdk.org  Wed Oct 19 06:03:20 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Oct 2022 06:03:20 GMT
Subject: RFR: 8295435: Build failure with GCC7 after JDK-8294314 due to
 strict-overflow warnings [v2]
In-Reply-To: <LPx1Ffia3Alf3qSjLVbkW2vDH1msopZXtznczxKtoG8=.41cfb193-4d49-47ce-8622-1bf79313d40f@github.com>
References: <MfpoUz4c28EwXR92TOPiHJ7uDJbxWmQqtEClKKiQCsw=.ea1d7f4d-6b70-4b1b-8e54-6f1c52148cce@github.com>
 <LPx1Ffia3Alf3qSjLVbkW2vDH1msopZXtznczxKtoG8=.41cfb193-4d49-47ce-8622-1bf79313d40f@github.com>
Message-ID: <BemI-fHmtZWP8AdMVT00DnDx6bHdADYxCjLfLzaPf2M=.618f2b32-ae2c-407a-88a6-4b7cc3489f2d@github.com>

On Wed, 19 Oct 2022 01:51:32 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> Let's disable `-Werror=strict-overflow` to get it build with gcc7 on Linux/x86.
>> 
>> bytecodeAssembler.cpp
>> instanceKlass.cpp
>> klassVtable.cpp
>> 
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disable strict-overflow warnings globally

I am good with this. Let's hear from @magicus too.

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

Marked as reviewed by shade (Reviewer).

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


From ihse at openjdk.org  Wed Oct 19 07:38:59 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 19 Oct 2022 07:38:59 GMT
Subject: RFR: 8295435: Build failure with GCC7 after JDK-8294314 due to
 strict-overflow warnings [v2]
In-Reply-To: <LPx1Ffia3Alf3qSjLVbkW2vDH1msopZXtznczxKtoG8=.41cfb193-4d49-47ce-8622-1bf79313d40f@github.com>
References: <MfpoUz4c28EwXR92TOPiHJ7uDJbxWmQqtEClKKiQCsw=.ea1d7f4d-6b70-4b1b-8e54-6f1c52148cce@github.com>
 <LPx1Ffia3Alf3qSjLVbkW2vDH1msopZXtznczxKtoG8=.41cfb193-4d49-47ce-8622-1bf79313d40f@github.com>
Message-ID: <DruNaQTDFmtBl2pVE0XVdHFu_XSq8b8c6ZyaCgJe7sE=.05bf5f89-8cbc-4a9e-96d9-0cc8b94ae4f9@github.com>

On Wed, 19 Oct 2022 01:51:32 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> Let's disable `-Werror=strict-overflow` to get it build with gcc7 on Linux/x86.
>> 
>> bytecodeAssembler.cpp
>> instanceKlass.cpp
>> klassVtable.cpp
>> 
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disable strict-overflow warnings globally

That's fine, I guess. We have no easy mechanism for testing a condition like "gcc 7 or older" in the makefiles. I hope we raise the bar for gcc soon, and then we can go back and remove this.

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

Marked as reviewed by ihse (Reviewer).

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


From jiefu at openjdk.org  Wed Oct 19 07:45:21 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 19 Oct 2022 07:45:21 GMT
Subject: RFR: 8295435: Build failure with GCC7 after JDK-8294314 due to
 strict-overflow warnings [v2]
In-Reply-To: <BemI-fHmtZWP8AdMVT00DnDx6bHdADYxCjLfLzaPf2M=.618f2b32-ae2c-407a-88a6-4b7cc3489f2d@github.com>
References: <MfpoUz4c28EwXR92TOPiHJ7uDJbxWmQqtEClKKiQCsw=.ea1d7f4d-6b70-4b1b-8e54-6f1c52148cce@github.com>
 <LPx1Ffia3Alf3qSjLVbkW2vDH1msopZXtznczxKtoG8=.41cfb193-4d49-47ce-8622-1bf79313d40f@github.com>
 <BemI-fHmtZWP8AdMVT00DnDx6bHdADYxCjLfLzaPf2M=.618f2b32-ae2c-407a-88a6-4b7cc3489f2d@github.com>
Message-ID: <keSTFMRFQ9EPUEJap6wvsihBpslEFOqPRYEgc34w5YU=.462f62b6-f23e-473c-98dd-54719a068084@github.com>

On Wed, 19 Oct 2022 06:00:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disable strict-overflow warnings globally
>
> I am good with this. Let's hear from @magicus too.

Thanks @shipilev and @magicus for the review.

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

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


From jiefu at openjdk.org  Wed Oct 19 07:45:21 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 19 Oct 2022 07:45:21 GMT
Subject: Integrated: 8295435: Build failure with GCC7 after JDK-8294314 due to
 strict-overflow warnings
In-Reply-To: <MfpoUz4c28EwXR92TOPiHJ7uDJbxWmQqtEClKKiQCsw=.ea1d7f4d-6b70-4b1b-8e54-6f1c52148cce@github.com>
References: <MfpoUz4c28EwXR92TOPiHJ7uDJbxWmQqtEClKKiQCsw=.ea1d7f4d-6b70-4b1b-8e54-6f1c52148cce@github.com>
Message-ID: <0IJZ-Pz_m9euViFCznGxFxR8ymhqU25Q5UilYqMo6JI=.de6359c5-9eeb-4127-bdc7-01863e421b68@github.com>

On Tue, 18 Oct 2022 02:35:59 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Let's disable `-Werror=strict-overflow` to get it build with gcc7 on Linux/x86.
> 
> bytecodeAssembler.cpp
> instanceKlass.cpp
> klassVtable.cpp
> 
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: f502ab85
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f502ab85c987be827d36b0a29f77ec5ce5bb3d01
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8295435: Build failure with GCC7 after JDK-8294314 due to strict-overflow warnings

Co-authored-by: Aleksey Shipilev <shade at openjdk.org>
Reviewed-by: shade, ihse

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

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


From shade at openjdk.org  Wed Oct 19 08:48:13 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Oct 2022 08:48:13 GMT
Subject: RFR: 8295417: Pass $AR to binutils cross-build [v2]
In-Reply-To: <6HtpKnR8ifzpqzv5bPIMdNLSkR5YlpB5etkIm1-oBBk=.2556a9b2-6fb0-475d-a9f3-fc334128a136@github.com>
References: <6HtpKnR8ifzpqzv5bPIMdNLSkR5YlpB5etkIm1-oBBk=.2556a9b2-6fb0-475d-a9f3-fc334128a136@github.com>
Message-ID: <C8Ocu-RmxHvuc2MnUaZdZvcdg6Ia3D4vcgGjOVhSXPc=.9b4c9d61-f1a7-4751-b6ed-27bb4046b2d6@github.com>

> While adapting my CI to build hsdis automatically, I realized that sometimes we miss the proper $AR for binutils cross-build. Configure would then fail like:
> 
> 
> $ CXX=aarch64-linux-gnu-g++ CC=aarch64-linux-gnu-gcc sh ./configure --with-debug-level=fastdebug --openjdk-target=aarch64-linux-gnu --with-sysroot=/chroots/arm64 --with-boot-jdk=/home/shade/Install/jdk19u-ea --with-hsdis=binutils --with-binutils-src=binutils-2.38
> ...

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-8295417-hsdis-ar
 - Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10729/files
  - new: https://git.openjdk.org/jdk/pull/10729/files/65291606..ed1b26af

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10729&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10729&range=00-01

  Stats: 5518 lines in 636 files changed: 2705 ins; 1089 del; 1724 mod
  Patch: https://git.openjdk.org/jdk/pull/10729.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10729/head:pull/10729

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


From shade at openjdk.org  Wed Oct 19 08:48:14 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Oct 2022 08:48:14 GMT
Subject: RFR: 8295417: Pass $AR to binutils cross-build
In-Reply-To: <6HtpKnR8ifzpqzv5bPIMdNLSkR5YlpB5etkIm1-oBBk=.2556a9b2-6fb0-475d-a9f3-fc334128a136@github.com>
References: <6HtpKnR8ifzpqzv5bPIMdNLSkR5YlpB5etkIm1-oBBk=.2556a9b2-6fb0-475d-a9f3-fc334128a136@github.com>
Message-ID: <rfns6Wcax0WGJMcqnUmSYabYyaNdJ2hEkhRTSU524U8=.d4f5e1e0-c1da-4dd0-9a39-776b1dbf00e2@github.com>

On Mon, 17 Oct 2022 15:46:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> While adapting my CI to build hsdis automatically, I realized that sometimes we miss the proper $AR for binutils cross-build. Configure would then fail like:
> 
> 
> $ CXX=aarch64-linux-gnu-g++ CC=aarch64-linux-gnu-gcc sh ./configure --with-debug-level=fastdebug --openjdk-target=aarch64-linux-gnu --with-sysroot=/chroots/arm64 --with-boot-jdk=/home/shade/Install/jdk19u-ea --with-hsdis=binutils --with-binutils-src=binutils-2.38
> ...

@magicus  -- you good with this?

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

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


From ihse at openjdk.org  Wed Oct 19 09:06:05 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 19 Oct 2022 09:06:05 GMT
Subject: RFR: 8295417: Pass $AR to binutils cross-build [v2]
In-Reply-To: <C8Ocu-RmxHvuc2MnUaZdZvcdg6Ia3D4vcgGjOVhSXPc=.9b4c9d61-f1a7-4751-b6ed-27bb4046b2d6@github.com>
References: <6HtpKnR8ifzpqzv5bPIMdNLSkR5YlpB5etkIm1-oBBk=.2556a9b2-6fb0-475d-a9f3-fc334128a136@github.com>
 <C8Ocu-RmxHvuc2MnUaZdZvcdg6Ia3D4vcgGjOVhSXPc=.9b4c9d61-f1a7-4751-b6ed-27bb4046b2d6@github.com>
Message-ID: <VsRGE2tBY9NYp2xoDu0uVQAtt-A9BR1zhXEOotRCv34=.853dae0d-a167-49f6-8c0b-a93dc7830e49@github.com>

On Wed, 19 Oct 2022 08:48:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> While adapting my CI to build hsdis automatically, I realized that sometimes we miss the proper $AR for binutils cross-build. Configure would then fail like:
>> 
>> 
>> $ CXX=aarch64-linux-gnu-g++ CC=aarch64-linux-gnu-gcc sh ./configure --with-debug-level=fastdebug --openjdk-target=aarch64-linux-gnu --with-sysroot=/chroots/arm64 --with-boot-jdk=/home/shade/Install/jdk19u-ea --with-hsdis=binutils --with-binutils-src=binutils-2.38
>> ...
>
> 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-8295417-hsdis-ar
>  - Fix

I am. Sorry, must have missed it among all other notifications.

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

Marked as reviewed by ihse (Reviewer).

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


From magnus.ihse.bursie at oracle.com  Wed Oct 19 10:12:20 2022
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 19 Oct 2022 12:12:20 +0200
Subject: Fwd: GNU make 4.3.91 release candidate available
In-Reply-To: <0a31d3c3630097befee71c4e7b6cf811415ccf28.camel@gnu.org>
References: <0a31d3c3630097befee71c4e7b6cf811415ccf28.camel@gnu.org>
Message-ID: <2d861417-66c3-2e10-6bfd-3563cccee3a5@oracle.com>

FYI: GNU Make 4.4 is coming closer, and it will bring along an 
unprecedented set of incompatible changes (for make; that is, a product 
that has been unchanged for like 20 years). Most won't affect us, but 
some likely will. At the moment, I recommend users to stay at GNU Make 
4.2.x for building the JDK. In some not-too-distant future, we will have 
to check what breaks with make 4.3/4.4 and fix it.

/Magnus

-------- Forwarded Message --------
Subject: 	GNU make 4.3.91 release candidate available
Date: 	Tue, 18 Oct 2022 16:45:48 -0400
From: 	Paul Smith <psmith at gnu.org>
Reply-To: 	psmith at gnu.org
Organization: 	GNU's Not UNIX!
To: 	bug-make at gnu.org
CC: 	coordinator at translationproject.org, platform-testers at gnu.org



--------------------------------------------------------------------
GNU make is a tool which controls the generation of executables and
other non-source files of a program from the program's source files.

You can learn more at: https://www.gnu.org/software/make/
--------------------------------------------------------------------

A new release candidate for GNU make 4.4 is available now for download:

4defb3f9cb1f49956cdb28befb3abafb make-4.3.91.tar.lz
6738e93afc158bab8f1e63f053cbebca make-4.3.91.tar.gz

You can obtain a copy from: https://alpha.gnu.org/gnu/make/

- NEWS ----------------------------------------------------------------

Version 4.3.91 (18 Oct 2022)

A complete list of bugs fixed in this version is available here:

https://sv.gnu.org/bugs/index.php?group=make&report_id=111&fix_release_id=109&set=custom

* WARNING: Deprecation!
The following systems are deprecated in this release:
- OS/2 (EMX)
- AmigaOS
- Xenix
- Cray
In the NEXT release of GNU Make, support for these systems will be removed.
If you want to see them continue to be supported, contact 
<bug-make at gnu.org>.

* WARNING: Future backward-incompatibility!
In the NEXT release of GNU Make, pattern rules will implement the same
behavior change for multiple targets as explicit grouped targets, below: if
any target of the rule is needed by the build, the recipe will be invoked if
any target of the rule is missing or out of date. During testing some
makefiles were found to contain pattern rules that do not build all targets;
this can cause issues so we are delaying this change for one release cycle
to allow these makefiles to be updated. GNU Make shows a warning if it
detects this situation: "pattern recipe did not update peer target".

* WARNING: Backward-incompatibility!
GNU Make now uses temporary files in more situations than previous releases.
If your build system sets TMPDIR (or TMP or TEMP on Windows) and deletes the
contents during the build, or uses restrictive permissions, this may cause
problems. You can choose an alternative temporary directory only for use by
GNU Make by setting the new MAKE_TMPDIR environment variable before invoking
make. Note that this value CANNOT be set inside the makefile, since make
needs to find its temporary directory before the makefiles are parsed.

* WARNING: Backward-incompatibility!
Previously each target in a explicit grouped target rule was considered
individually: if the targets needed by the build were not out of date the
recipe was not run even if other targets in the group were out of date. Now
if any of the grouped targets are needed by the build, then if any of the
grouped targets are out of date the recipe is run and all targets in the
group are considered updated.

* WARNING: Backward-incompatibility!
Previously if --no-print-directory was seen anywhere in the environment or
command line it would take precedence over any --print-directory. Now, the
last setting of directory printing options seen will be used, so a command
line such as "--no-print-directory -w" _will_ show directory entry/exits.

* WARNING: Backward-incompatibility!
Previously the order in which makefiles were remade was not explicitly
stated, but it was (roughly) the inverse of the order in which they were
processed by make. In this release, the order in which makefiles are
rebuilt is the same order in which make processed them, and this is defined
to be true in the GNU Make manual.

* WARNING: Backward-incompatibility!
Previously only simple (one-letter) options were added to the MAKEFLAGS
variable that was visible while parsing makefiles. Now, all options are
available in MAKEFLAGS. If you want to check MAKEFLAGS for a one-letter
option, expanding "$(firstword -$(MAKEFLAGS))" is a reliable way to return
the set of one-letter options which can be examined via findstring, etc.

* WARNING: Backward-incompatibility!
Previously makefile variables marked as export were not exported to commands
started by the $(shell ...) function. Now, all exported variables are
exported to $(shell ...). If this leads to recursion during expansion, then
for backward-compatibility the value from the original environment is used.
To detect this change search for 'shell-export' in the .FEATURES variable.

* WARNING: New build requirement
GNU Make utilizes facilities from GNU Gnulib: Gnulib requires certain C99
features in the C compiler and so these features are required by GNU Make:
https://www.gnu.org/software/gnulib/manual/html_node/C99-features-assumed.html
The configure script should verify the compiler has these features.

* New feature: The .WAIT special target
If the .WAIT target appears between two prerequisites of a target, then
GNU Make will wait for all of the targets to the left of .WAIT in the list
to complete before starting any of the targets to the right of .WAIT.
This feature is available in some other versions of make, and it will be
required by an upcoming version of the POSIX standard for make.
Different patches were made by Alexey Neyman <alex.neyman at auriga.ru> (2005)
and Steffen Nurpmeso <steffen at sdaoden.eu> (2020) that were useful but the
result is a different implementation (closer to Alexey's idea).

* New feature: .NOTPARALLEL accepts prerequisites
If the .NOTPARALLEL special target has prerequisites then all prerequisites
of those targets will be run serially (as if .WAIT was specified between
each prerequisite).

* New feature: The .NOTINTERMEDIATE special target
.NOTINTERMEDIATE Disables intermediate behavior for specific files, for all
files built using a pattern, or for the entire makefile.
Implementation provided by Dmitry Goncharov <dgoncharov at users.sf.net>

* New feature: The $(let ...) function
This function allows user-defined functions to define a set of local
variables: values can be assigned to these variables from within the
user-defined function and they will not impact global variable assignments.
Implementation provided by Jouke Witteveen <j.witteveen at gmail.com>

* New feature: The $(intcmp ...) function
This function allows conditional evaluation controlled by a numerical
comparison.
Implementation provided by Jouke Witteveen <j.witteveen at gmail.com>

* New feature: Improved support for -l / --load-average
On systems that provide /proc/loadavg (Linux), GNU Make will use it to
determine the number of runnable jobs and use this as the current load,
avoiding the need for heuristics.
Implementation provided by Sven C. Dack <sdack at gmx.com>

* New feature: The --shuffle command line option
This option reorders goals and prerequisites to simulate non-determinism
that may be seen using parallel build. Shuffle mode allows a form of "fuzz
testing" of parallel builds to verify that all prerequisites are correctly
described in the makefile.
Implementation provided by Sergei Trofimovich <siarheit at google.com>

* New feature: The --jobserver-style command line option and named pipes
A new jobserver method is used on systems where mkfifo(3) is supported.
This solves a number of obscure issues related to using the jobserver
and recursive invocations of GNU Make. This change means that sub-makes
will connect to the jobserver even if they are not marked as recursive.
It also means that other tools that want to participate in the jobserver
will need to be enhanced as described in the GNU Make manual.
You can force GNU Make to use the simple pipe-based jobserver (perhaps if
you are integrating with other tools or older versions of GNU Make) by
adding the '--jobserver-style=pipe' option to the command line of the
top-level invocation of GNU Make, or via MAKEFLAGS or GNUMAKEFLAGS.
To detect this change search for 'jobserver-fifo' in the .FEATURES variable.

* Some POSIX systems (*BSD) do not allow locks to be taken on pipes, which
caused the output sync feature to not work properly there. Also multiple
invocations of make redirecting to the same output file (e.g., /dev/null)
would cause hangs. Instead of locking stdout (which does have some useful
performance characteristics, but is not portable) create a temporary file
and lock that. Windows continues to use a mutex as before.

* GNU Make has sometimes chosen unexpected, and sub-optimal, chains of
implicit rules due to the definition of "ought to exist" in the implicit
rule search algorithm, which considered any prerequisite mentioned in the
makefile as "ought to exist". This algorithm has been modified to prefer
prerequisites mentioned explicitly in the target being built and only if
that results in no matching rule, will GNU Make consider prerequisites
mentioned in other targets as "ought to exist".
Implementation provided by Dmitry Goncharov <dgoncharov at users.sf.net>

* GNU Make was performing secondary expansion of all targets, even targets
which didn't need to be considered during the build. In this release
only targets which are considered will be secondarily expanded.
Implementation provided by Dmitry Goncharov <dgoncharov at users.sf.net>

* If the MAKEFLAGS variable is modified in a makefile, it will be re-parsed
immediately rather than after all makefiles have been read. Note that
although all options are parsed immediately, some special effects won't
appear until after all makefiles are read.

* The -I option accepts an argument "-" (e.g., "-I-") which means "reset the
list of search directories to empty". Among other things this can be used
to prevent GNU Make from searching in its default list of directories.

* New debug option "print" will show the recipe to be run, even when silent
mode is set, and new debug option "why" will show why a target is rebuilt
(which prerequisites caused the target to be considered out of date).
Implementation provided by David Boyce <David.S.Boyce at gmail.com>

* The existing --trace option is made equivalent to --debug=print,why

* Target-specific variables can now be marked "unexport".

* Exporting / unexporting target-specific variables is handled correctly, so
that the attribute of the most specific variable setting is used.

* Special targets like .POSIX are detected upon definition, ensuring 
that any
change in behavior takes effect immediately, before the next line is parsed.

* When the jobserver is enabled and GNU Make decides it is invoking a 
non-make
sub-process and closes the jobserver pipes, it will now add a new option to
the MAKEFLAGS environment variable that disables the jobserver.
This prevents sub-processes that invoke make from accidentally using other
open file descriptors as jobserver pipes. For more information see
https://savannah.gnu.org/bugs/?57242 and 
https://savannah.gnu.org/bugs/?62397

* A long-standing issue with the directory cache has been resolved: changes
made as a side-effect of some other target's recipe are now noticed as
expected.

* GNU Make can now be built for MS-Windows using the Tiny C tcc compiler.
Port provided by Christian Jullien <eligis at orange.fr>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20221019/4d114e91/attachment.htm>

From ihse at openjdk.org  Wed Oct 19 11:27:55 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 19 Oct 2022 11:27:55 GMT
Subject: RFR: 8295653: Add a graph of the sealed class hierarchy for marked
 classes
Message-ID: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>

It would be possible to mark classes with `@sealedGraph` to indicate that the sealed hierarchy should be rendered graphically in the JavaDocs. Classes not marked would be unaffected, creating an opt-in approach.

[Here](https://bugs.openjdk.org/secure/attachment/101126/Screen%20Shot%202022-10-19%20at%2012.47.47%20PM.png) is an example of MemoryLayout class rendering.

This feature has been developed in cooperation with Per Minborg.

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

Commit messages:
 - Update copyright year; remove testing annotations
 - Make sealed graphs look like module graphs
 - Fix failing test after updating css
 - FIx hover etc to match moduleGraph
 - cleanup
 - Fix problem with superclass
 - Change dotted to dashed
 - Add dotted nodes for open classes
 - Actually we *only* need to depend on the dot file...
 - Add dependency to dot file for svg file generation
 - ... and 21 more: https://git.openjdk.org/jdk/compare/fc889577...8627a08e

Changes: https://git.openjdk.org/jdk/pull/10761/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10761&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295653
  Stats: 372 lines in 5 files changed: 324 ins; 0 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/10761.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10761/head:pull/10761

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


From shade at openjdk.org  Wed Oct 19 11:59:59 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Oct 2022 11:59:59 GMT
Subject: RFR: 8295417: Pass $AR to binutils cross-build [v2]
In-Reply-To: <C8Ocu-RmxHvuc2MnUaZdZvcdg6Ia3D4vcgGjOVhSXPc=.9b4c9d61-f1a7-4751-b6ed-27bb4046b2d6@github.com>
References: <6HtpKnR8ifzpqzv5bPIMdNLSkR5YlpB5etkIm1-oBBk=.2556a9b2-6fb0-475d-a9f3-fc334128a136@github.com>
 <C8Ocu-RmxHvuc2MnUaZdZvcdg6Ia3D4vcgGjOVhSXPc=.9b4c9d61-f1a7-4751-b6ed-27bb4046b2d6@github.com>
Message-ID: <y-7tWKXWsYDjhNXBFg8zV2OQpbikoXbxL6H6T2RfTpg=.f22e3cb6-2d1e-46e5-a56c-dc7ce29d790e@github.com>

On Wed, 19 Oct 2022 08:48:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> While adapting my CI to build hsdis automatically, I realized that sometimes we miss the proper $AR for binutils cross-build. Configure would then fail like:
>> 
>> 
>> $ CXX=aarch64-linux-gnu-g++ CC=aarch64-linux-gnu-gcc sh ./configure --with-debug-level=fastdebug --openjdk-target=aarch64-linux-gnu --with-sysroot=/chroots/arm64 --with-boot-jdk=/home/shade/Install/jdk19u-ea --with-hsdis=binutils --with-binutils-src=binutils-2.38
>> ...
>
> 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-8295417-hsdis-ar
>  - Fix

Thanks!

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

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


From shade at openjdk.org  Wed Oct 19 12:01:28 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Oct 2022 12:01:28 GMT
Subject: Integrated: 8295417: Pass $AR to binutils cross-build
In-Reply-To: <6HtpKnR8ifzpqzv5bPIMdNLSkR5YlpB5etkIm1-oBBk=.2556a9b2-6fb0-475d-a9f3-fc334128a136@github.com>
References: <6HtpKnR8ifzpqzv5bPIMdNLSkR5YlpB5etkIm1-oBBk=.2556a9b2-6fb0-475d-a9f3-fc334128a136@github.com>
Message-ID: <SVc_alTQ48eHR4n-icSiuAhRvdkh-4H6_ZYNa8Vg6EE=.af148b35-c544-4406-9a57-01df957cee1a@github.com>

On Mon, 17 Oct 2022 15:46:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> While adapting my CI to build hsdis automatically, I realized that sometimes we miss the proper $AR for binutils cross-build. Configure would then fail like:
> 
> 
> $ CXX=aarch64-linux-gnu-g++ CC=aarch64-linux-gnu-gcc sh ./configure --with-debug-level=fastdebug --openjdk-target=aarch64-linux-gnu --with-sysroot=/chroots/arm64 --with-boot-jdk=/home/shade/Install/jdk19u-ea --with-hsdis=binutils --with-binutils-src=binutils-2.38
> ...

This pull request has now been integrated.

Changeset: 1d883c53
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1d883c5312721980898f91898665b528948a985b
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8295417: Pass $AR to binutils cross-build

Reviewed-by: erikj, ihse

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

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


From lujaniuk at openjdk.org  Wed Oct 19 14:14:47 2022
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Wed, 19 Oct 2022 14:14:47 GMT
Subject: RFR: 8295663 Rephrased introduction to testing
Message-ID: <NYn97U2N6hxYHvAu0esVWTqOai7KCLCtjf_eVWMe5_Y=.a4a07df3-5352-4818-bb4c-e068169174a8@github.com>

Old one made little sense for a new reader

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

Commit messages:
 - ws
 - Rephrased introduction to testing

Changes: https://git.openjdk.org/jdk/pull/10763/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10763&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295663
  Stats: 38 lines in 2 files changed: 20 ins; 3 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/10763.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10763/head:pull/10763

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


From jjg at openjdk.org  Wed Oct 19 18:15:58 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 19 Oct 2022 18:15:58 GMT
Subject: RFR: 8295653: Add a graph of the sealed class hierarchy for marked
 classes
In-Reply-To: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
References: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
Message-ID: <p6MRgjzc5FItSAofLJkBSfJ8Qm1_wVYTIMh_cafSVSY=.d4fb4b2f-a076-4608-b65e-720e42553ae6@github.com>

On Wed, 19 Oct 2022 11:17:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> It would be possible to mark classes with `@sealedGraph` to indicate that the sealed hierarchy should be rendered graphically in the JavaDocs. Classes not marked would be unaffected, creating an opt-in approach.
> 
> [Here](https://bugs.openjdk.org/secure/attachment/101126/Screen%20Shot%202022-10-19%20at%2012.47.47%20PM.png) is an example of MemoryLayout class rendering.
> 
> This feature has been developed in cooperation with Per Minborg.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css line 855:

> 853:     margin: -100px 0 0 100px;
> 854:     z-index: 1;
> 855: }

These lines could be merged with the preceding lines, using the `,` syntax

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

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


From shade at openjdk.org  Wed Oct 19 18:51:03 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Oct 2022 18:51:03 GMT
Subject: RFR: 8294468: Fix char-subscripts warnings in Hotspot [v2]
In-Reply-To: <Vq9vre50I_x_quAwP0TfM9I0lKNF6mdA6S2AaXcpBKo=.b6d37819-0570-4f51-9620-a33d20e9867d@github.com>
References: <yVMMHRt6X8ymbZTqHj-NF94La-RXw53SNrwMWdLPiik=.d83d8fb6-72a0-46d0-a5b0-6909597a2319@github.com>
 <Vq9vre50I_x_quAwP0TfM9I0lKNF6mdA6S2AaXcpBKo=.b6d37819-0570-4f51-9620-a33d20e9867d@github.com>
Message-ID: <g4MEL_pgBQtPEctOKh8IiLi7iay0WnmQegR8AHsXCBI=.10b3a1b2-0f5a-4b86-9a38-5e8cb66bb1f4@github.com>

On Mon, 17 Oct 2022 18:08:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> There seem to be the only place in Hotspot where this warning fires, yet the warning is disabled wholesale for Hotspot. This is not good.
>> 
>> I can trace the addition of char-subscripts exclusion to [JDK-8211029](https://bugs.openjdk.org/browse/JDK-8211029) (Sep 2018). The only place in Hotspot where in fires is present from the initial load (2007).
>> 
>> The underlying problem that this warning tells us about is that `char` might be signed on some platforms, so we can potentially access the negative index. It is not a bug in our current code, that bounds the value of `k` under `MAXID-1`, which is `19`.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug `tier1`
>>  - [x] The build matrix of:
>>    - GCC 10
>>    - {i686, x86_64, aarch64, powerpc64le, s390x, armhf, riscv64}
>>    - {server}
>>    - {release, fastdebug}
>
> Aleksey Shipilev 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 JDK-8294468-warning-char-subscripts
>  - Fix

The GHA failure is unrelated.

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

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


From shade at openjdk.org  Wed Oct 19 18:52:01 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Oct 2022 18:52:01 GMT
Subject: RFR: 8294467: Fix sequence-point warnings in Hotspot [v2]
In-Reply-To: <oX0DTvf22HNXEvXQyLsxjdGqDaykvlxgv2yMvwrjZzo=.6a91b80d-da9c-44b3-8575-bfa5e8bf8d35@github.com>
References: <lcvbaBpvI_ed3tUlZ9urqL_0ud81LJJ2VE8xO_CeI2o=.89deefe3-6a5d-49d8-b0b3-ab61a91770c4@github.com>
 <oX0DTvf22HNXEvXQyLsxjdGqDaykvlxgv2yMvwrjZzo=.6a91b80d-da9c-44b3-8575-bfa5e8bf8d35@github.com>
Message-ID: <I0mrplfEpH0DVO0ghH6FjL9GBPNNHGqLjp7EULN_qZM=.ded5f604-beb8-4fb3-9040-5cd2bbe28469@github.com>

On Mon, 17 Oct 2022 18:21:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> There seem to be the only place in Hotspot where this warning fires, yet the warning is disabled wholesale for Hotspot. This is not good.
>> 
>> I can trace the addition of sequence-point exclusion to [JDK-8211029](https://bugs.openjdk.org/browse/JDK-8211029) (Sep 2018), yet the only place where it triggers introduced by [JDK-8259609](https://bugs.openjdk.org/browse/JDK-8259609) (Oct 2021). It seems other places were fixed meanwhile.
>> 
>> I believe the fixed place is just a simple leftover. Right, @rwestrel?
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug `tier1`
>>  - [x]  Linux x86_64 fastdebug `tier2`
>>  - [x] The build matrix of:
>>    - GCC 10
>>    - {i686, x86_64, aarch64, powerpc64le, s390x, armhf, riscv64}
>>    - {server}
>>    - {release, fastdebug}
>
> Aleksey Shipilev 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 JDK-8294467-warning-sequence-point
>  - Fix

Thank you all!

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

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


From shade at openjdk.org  Wed Oct 19 18:54:21 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Oct 2022 18:54:21 GMT
Subject: Integrated: 8294468: Fix char-subscripts warnings in Hotspot
In-Reply-To: <yVMMHRt6X8ymbZTqHj-NF94La-RXw53SNrwMWdLPiik=.d83d8fb6-72a0-46d0-a5b0-6909597a2319@github.com>
References: <yVMMHRt6X8ymbZTqHj-NF94La-RXw53SNrwMWdLPiik=.d83d8fb6-72a0-46d0-a5b0-6909597a2319@github.com>
Message-ID: <PuC7OgrI3XI4mTTTEHWGsnK1xpjFbmHmCjETSKcIieo=.bf955b0b-0dd4-4149-bea3-d7bed8c2379d@github.com>

On Tue, 27 Sep 2022 17:27:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There seem to be the only place in Hotspot where this warning fires, yet the warning is disabled wholesale for Hotspot. This is not good.
> 
> I can trace the addition of char-subscripts exclusion to [JDK-8211029](https://bugs.openjdk.org/browse/JDK-8211029) (Sep 2018). The only place in Hotspot where in fires is present from the initial load (2007).
> 
> The underlying problem that this warning tells us about is that `char` might be signed on some platforms, so we can potentially access the negative index. It is not a bug in our current code, that bounds the value of `k` under `MAXID-1`, which is `19`.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `tier1`
>  - [x] The build matrix of:
>    - GCC 10
>    - {i686, x86_64, aarch64, powerpc64le, s390x, armhf, riscv64}
>    - {server}
>    - {release, fastdebug}

This pull request has now been integrated.

Changeset: ceb5b089
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ceb5b08964e34dfae3819257e5df460f24f92a78
Stats:     4 lines in 2 files changed: 1 ins; 2 del; 1 mod

8294468: Fix char-subscripts warnings in Hotspot

Reviewed-by: dholmes, kbarrett

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

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


From shade at openjdk.org  Wed Oct 19 18:55:29 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Oct 2022 18:55:29 GMT
Subject: Integrated: 8294467: Fix sequence-point warnings in Hotspot
In-Reply-To: <lcvbaBpvI_ed3tUlZ9urqL_0ud81LJJ2VE8xO_CeI2o=.89deefe3-6a5d-49d8-b0b3-ab61a91770c4@github.com>
References: <lcvbaBpvI_ed3tUlZ9urqL_0ud81LJJ2VE8xO_CeI2o=.89deefe3-6a5d-49d8-b0b3-ab61a91770c4@github.com>
Message-ID: <pxJDO-J2-yN-AkM7sspulbfk-XVyiuQZSdRbFZdGj4g=.6399aaf1-3fa1-4255-9382-57adad7ef439@github.com>

On Tue, 27 Sep 2022 16:34:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There seem to be the only place in Hotspot where this warning fires, yet the warning is disabled wholesale for Hotspot. This is not good.
> 
> I can trace the addition of sequence-point exclusion to [JDK-8211029](https://bugs.openjdk.org/browse/JDK-8211029) (Sep 2018), yet the only place where it triggers introduced by [JDK-8259609](https://bugs.openjdk.org/browse/JDK-8259609) (Oct 2021). It seems other places were fixed meanwhile.
> 
> I believe the fixed place is just a simple leftover. Right, @rwestrel?
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `tier1`
>  - [x]  Linux x86_64 fastdebug `tier2`
>  - [x] The build matrix of:
>    - GCC 10
>    - {i686, x86_64, aarch64, powerpc64le, s390x, armhf, riscv64}
>    - {server}
>    - {release, fastdebug}

This pull request has now been integrated.

Changeset: 388a56e4
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/388a56e4c4278f2a3da31946b15a45f3aee25e58
Stats:     2 lines in 2 files changed: 0 ins; 1 del; 1 mod

8294467: Fix sequence-point warnings in Hotspot

Reviewed-by: dholmes, thartmann, roland

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

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


From shade at openjdk.org  Wed Oct 19 19:11:42 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Oct 2022 19:11:42 GMT
Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot [v3]
In-Reply-To: <HD7TvGmoIxJ9QqJyf_LVdutwVXEoxRiWseOWQEe-zpo=.b22712aa-15a3-4702-b160-30df20d72cff@github.com>
References: <HD7TvGmoIxJ9QqJyf_LVdutwVXEoxRiWseOWQEe-zpo=.b22712aa-15a3-4702-b160-30df20d72cff@github.com>
Message-ID: <AVqhSAwTZxwKkVzPAct8PipvWJEaKvB2Njb5qFpWEao=.ce83f3d7-57dd-4785-8b10-8fcab9f4f50d@github.com>

> There are number of places where misleading-indentation is reported by GCC. Currently, the warning is disabled for the entirety of Hotspot, which is not good.
> 
> C1 does an unusual style here. Changing it globally would touch a lot of lines. Instead of doing that, I fit the existing style while also resolving the warnings. Note this actually solves a bug in `lir_alloc_array`, where `do_temp` are called without a check.
> 
> Build-tested this with product of:
>   - GCC 10
>   - {i686, x86_64, aarch64, powerpc64le, s390x, armhf, riscv64}
>   - {server, zero}
>   - {release, fastdebug}
> 
> Linux x86_64 fastdebug `tier1` is fine.

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

 - Merge branch 'master' into JDK-8294438-misleading-indentation
 - Merge branch 'master' into JDK-8294438-misleading-indentation
 - Merge branch 'master' into JDK-8294438-misleading-indentation
 - Also javaClasses.cpp
 - Fix

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

Changes: https://git.openjdk.org/jdk/pull/10444/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10444&range=02
  Stats: 56 lines in 5 files changed: 7 ins; 20 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/10444.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10444/head:pull/10444

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


From naoto at openjdk.org  Wed Oct 19 19:14:04 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 19 Oct 2022 19:14:04 GMT
Subject: RFR: 8295564: Norwegian Nynorsk Locale is missing formatting
Message-ID: <5P5vg_h-kV7U7EmM2L8Jhv5uycJdjoO-vaa_5hq9yWQ=.41e47f03-82a2-4679-b5d3-3890bc492a3c@github.com>

This is a regression caused by upgrading CLDR to version 39 (JDK-8258794), in which CLDR changed the locale inheritance for Norwegian. Some locale data (including number elements) that were in `nn` locale was moved to `no`. There was a code in CLDRConverter that specially handles `no` locale not to copy its data as parent locale data. That special handling is no longer needed after v39.
It's amazing to see this bug has been lurking unnoticed till now.

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

Commit messages:
 - 8295564: Norwegian Nynorsk Locale is missing formatting

Changes: https://git.openjdk.org/jdk/pull/10774/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10774&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295564
  Stats: 12 lines in 3 files changed: 8 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10774.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10774/head:pull/10774

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


From ihse at openjdk.org  Wed Oct 19 20:43:59 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 19 Oct 2022 20:43:59 GMT
Subject: RFR: 8295653: Add a graph of the sealed class hierarchy for marked
 classes
In-Reply-To: <p6MRgjzc5FItSAofLJkBSfJ8Qm1_wVYTIMh_cafSVSY=.d4fb4b2f-a076-4608-b65e-720e42553ae6@github.com>
References: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
 <p6MRgjzc5FItSAofLJkBSfJ8Qm1_wVYTIMh_cafSVSY=.d4fb4b2f-a076-4608-b65e-720e42553ae6@github.com>
Message-ID: <O5hZlm-8rgWmzKLl3vHk3rAYqwZNSVSGrmGUs711thg=.211fdadc-fbf6-489d-baad-4444a4666c89@github.com>

On Wed, 19 Oct 2022 18:11:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> It would be possible to mark classes with `@sealedGraph` to indicate that the sealed hierarchy should be rendered graphically in the JavaDocs. Classes not marked would be unaffected, creating an opt-in approach.
>> 
>> [Here](https://bugs.openjdk.org/secure/attachment/101126/Screen%20Shot%202022-10-19%20at%2012.47.47%20PM.png) is an example of MemoryLayout class rendering.
>> 
>> This feature has been developed in cooperation with Per Minborg.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css line 855:
> 
>> 853:     margin: -100px 0 0 100px;
>> 854:     z-index: 1;
>> 855: }
> 
> These lines could be merged with the preceding lines, using the `,` syntax

I'm not that familiar with css syntax. Can you be more concrete on how you wish this written?

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

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


From jjg at openjdk.org  Wed Oct 19 21:06:00 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 19 Oct 2022 21:06:00 GMT
Subject: RFR: 8295653: Add a graph of the sealed class hierarchy for marked
 classes
In-Reply-To: <O5hZlm-8rgWmzKLl3vHk3rAYqwZNSVSGrmGUs711thg=.211fdadc-fbf6-489d-baad-4444a4666c89@github.com>
References: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
 <p6MRgjzc5FItSAofLJkBSfJ8Qm1_wVYTIMh_cafSVSY=.d4fb4b2f-a076-4608-b65e-720e42553ae6@github.com>
 <O5hZlm-8rgWmzKLl3vHk3rAYqwZNSVSGrmGUs711thg=.211fdadc-fbf6-489d-baad-4444a4666c89@github.com>
Message-ID: <0IpmpqjlZASLdasJsDqI6ghj9XL703ul8YeDcotTTTM=.6bd10feb-4147-411b-821d-55cb010415dd@github.com>

On Wed, 19 Oct 2022 20:41:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css line 855:
>> 
>>> 853:     margin: -100px 0 0 100px;
>>> 854:     z-index: 1;
>>> 855: }
>> 
>> These lines could be merged with the preceding lines, using the `,` syntax
>
> I'm not that familiar with css syntax. Can you be more concrete on how you wish this written?

I'm suggesting something like the following, although I have not explicitly tested it:


.module-graph span, .sealed-graph span {
    display:none;
    position:absolute;
}
.module-graph:hover span, .sealed-graph:hover span {
    display:block;
     margin: -100px 0 0 100px;
     z-index: 1;
 }

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

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


From serb at openjdk.org  Thu Oct 20 04:53:48 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 20 Oct 2022 04:53:48 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
Message-ID: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>

The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into JDK-8295554
 - 8295554: Move the "sizecalc.h" to the correct location

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

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


From serb at openjdk.org  Thu Oct 20 04:53:49 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 20 Oct 2022 04:53:49 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
Message-ID: <kM7au4SfOdQxSS_s4CvCLxx0U4rqwpbuLPu0-vqunJg=.6e411ab7-bbdc-4d3c-9611-14fb11fd2aaa@github.com>

On Wed, 19 Oct 2022 08:15:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".

make/common/modules/LauncherCommon.gmk line 48:

> 46: LAUNCHER_SRC := $(TOPDIR)/src/java.base/share/native/launcher
> 47: LAUNCHER_CFLAGS += -I$(TOPDIR)/src/java.base/share/native/launcher \
> 48:     -I$(TOPDIR)/src/java.desktop/share/native/include \

This line was added recently, not sure why.

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

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


From shade at openjdk.org  Thu Oct 20 07:16:55 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 20 Oct 2022 07:16:55 GMT
Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot [v3]
In-Reply-To: <AVqhSAwTZxwKkVzPAct8PipvWJEaKvB2Njb5qFpWEao=.ce83f3d7-57dd-4785-8b10-8fcab9f4f50d@github.com>
References: <HD7TvGmoIxJ9QqJyf_LVdutwVXEoxRiWseOWQEe-zpo=.b22712aa-15a3-4702-b160-30df20d72cff@github.com>
 <AVqhSAwTZxwKkVzPAct8PipvWJEaKvB2Njb5qFpWEao=.ce83f3d7-57dd-4785-8b10-8fcab9f4f50d@github.com>
Message-ID: <OYF9UYPDtkyCiMpbd_6QxySYG7PqsvlTQMNOuNeP0mI=.0aeb357e-c3a4-4f4d-a532-deaba7928a02@github.com>

On Wed, 19 Oct 2022 19:11:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> There are number of places where misleading-indentation is reported by GCC. Currently, the warning is disabled for the entirety of Hotspot, which is not good.
>> 
>> C1 does an unusual style here. Changing it globally would touch a lot of lines. Instead of doing that, I fit the existing style while also resolving the warnings. Note this actually solves a bug in `lir_alloc_array`, where `do_temp` are called without a check.
>> 
>> Build-tested this with product of:
>>   - GCC 10
>>   - {i686, x86_64, aarch64, powerpc64le, s390x, armhf, riscv64}
>>   - {server, zero}
>>   - {release, fastdebug}
>> 
>> Linux x86_64 fastdebug `tier1` is fine.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8294438-misleading-indentation
>  - Merge branch 'master' into JDK-8294438-misleading-indentation
>  - Merge branch 'master' into JDK-8294438-misleading-indentation
>  - Also javaClasses.cpp
>  - Fix

Thanks!

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

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


From shade at openjdk.org  Thu Oct 20 07:21:03 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 20 Oct 2022 07:21:03 GMT
Subject: Integrated: 8294438: Fix misleading-indentation warnings in hotspot
In-Reply-To: <HD7TvGmoIxJ9QqJyf_LVdutwVXEoxRiWseOWQEe-zpo=.b22712aa-15a3-4702-b160-30df20d72cff@github.com>
References: <HD7TvGmoIxJ9QqJyf_LVdutwVXEoxRiWseOWQEe-zpo=.b22712aa-15a3-4702-b160-30df20d72cff@github.com>
Message-ID: <JNj2m-VFxxrbJw4D3b6L5v25EPtC0fFqwNt6fF18X9Y=.94fd7ca1-56a2-4d32-af53-df7977f8f42b@github.com>

On Tue, 27 Sep 2022 10:28:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There are number of places where misleading-indentation is reported by GCC. Currently, the warning is disabled for the entirety of Hotspot, which is not good.
> 
> C1 does an unusual style here. Changing it globally would touch a lot of lines. Instead of doing that, I fit the existing style while also resolving the warnings. Note this actually solves a bug in `lir_alloc_array`, where `do_temp` are called without a check.
> 
> Build-tested this with product of:
>   - GCC 10
>   - {i686, x86_64, aarch64, powerpc64le, s390x, armhf, riscv64}
>   - {server, zero}
>   - {release, fastdebug}
> 
> Linux x86_64 fastdebug `tier1` is fine.

This pull request has now been integrated.

Changeset: 545021b1
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/545021b18d6f82ac8013009939ef4e05b8ebf7ce
Stats:     56 lines in 5 files changed: 7 ins; 20 del; 29 mod

8294438: Fix misleading-indentation warnings in hotspot

Reviewed-by: ihse, dholmes, coleenp

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

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


From dholmes at openjdk.org  Thu Oct 20 07:34:00 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Oct 2022 07:34:00 GMT
Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot [v3]
In-Reply-To: <OYF9UYPDtkyCiMpbd_6QxySYG7PqsvlTQMNOuNeP0mI=.0aeb357e-c3a4-4f4d-a532-deaba7928a02@github.com>
References: <HD7TvGmoIxJ9QqJyf_LVdutwVXEoxRiWseOWQEe-zpo=.b22712aa-15a3-4702-b160-30df20d72cff@github.com>
 <AVqhSAwTZxwKkVzPAct8PipvWJEaKvB2Njb5qFpWEao=.ce83f3d7-57dd-4785-8b10-8fcab9f4f50d@github.com>
 <OYF9UYPDtkyCiMpbd_6QxySYG7PqsvlTQMNOuNeP0mI=.0aeb357e-c3a4-4f4d-a532-deaba7928a02@github.com>
Message-ID: <_mUxIObAiNsVdxaC637-8aaIwXyHFc5xaBGu_phRn_0=.b5cf975b-3649-4ad2-82d6-8de11ef09bf8@github.com>

On Thu, 20 Oct 2022 07:14:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge branch 'master' into JDK-8294438-misleading-indentation
>>  - Merge branch 'master' into JDK-8294438-misleading-indentation
>>  - Merge branch 'master' into JDK-8294438-misleading-indentation
>>  - Also javaClasses.cpp
>>  - Fix
>
> Thanks!

@shipilev  this has broken our linux aarch64 builds!

[2022-10-20T07:26:59,542Z] workspace/open/src/hotspot/cpu/aarch64/assembler_aarch64.cpp: In member function 'void Address::lea(MacroAssembler*, Register) const':
[2022-10-20T07:26:59,542Z] workspace/open/src/hotspot/cpu/aarch64/assembler_aarch64.cpp:138:5: error: this 'else' clause does not guard... [-Werror=misleading-indentation]
[2022-10-20T07:26:59,542Z]   138 |     else
[2022-10-20T07:26:59,542Z]       |     ^~~~
[2022-10-20T07:26:59,542Z] workspace/open/src/hotspot/cpu/aarch64/assembler_aarch64.cpp:140:7: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'else'
[2022-10-20T07:26:59,542Z]   140 |       break;
[2022-10-20T07:26:59,542Z]       |       ^~~~~

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

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


From shade at openjdk.org  Thu Oct 20 07:37:13 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 20 Oct 2022 07:37:13 GMT
Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot [v3]
In-Reply-To: <OYF9UYPDtkyCiMpbd_6QxySYG7PqsvlTQMNOuNeP0mI=.0aeb357e-c3a4-4f4d-a532-deaba7928a02@github.com>
References: <HD7TvGmoIxJ9QqJyf_LVdutwVXEoxRiWseOWQEe-zpo=.b22712aa-15a3-4702-b160-30df20d72cff@github.com>
 <AVqhSAwTZxwKkVzPAct8PipvWJEaKvB2Njb5qFpWEao=.ce83f3d7-57dd-4785-8b10-8fcab9f4f50d@github.com>
 <OYF9UYPDtkyCiMpbd_6QxySYG7PqsvlTQMNOuNeP0mI=.0aeb357e-c3a4-4f4d-a532-deaba7928a02@github.com>
Message-ID: <UyN_E7v6dY8RiE3wDMSoLQE0HjEdjI-7UFfnZ-5SWPw=.b0bb7253-fc91-4ada-bcb7-4fe666bd60ef@github.com>

On Thu, 20 Oct 2022 07:14:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge branch 'master' into JDK-8294438-misleading-indentation
>>  - Merge branch 'master' into JDK-8294438-misleading-indentation
>>  - Merge branch 'master' into JDK-8294438-misleading-indentation
>>  - Also javaClasses.cpp
>>  - Fix
>
> Thanks!

> @shipilev this has broken our linux aarch64 builds!

Whoa. Looking.

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

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


From shade at openjdk.org  Thu Oct 20 07:44:03 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 20 Oct 2022 07:44:03 GMT
Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot [v3]
In-Reply-To: <UyN_E7v6dY8RiE3wDMSoLQE0HjEdjI-7UFfnZ-5SWPw=.b0bb7253-fc91-4ada-bcb7-4fe666bd60ef@github.com>
References: <HD7TvGmoIxJ9QqJyf_LVdutwVXEoxRiWseOWQEe-zpo=.b22712aa-15a3-4702-b160-30df20d72cff@github.com>
 <AVqhSAwTZxwKkVzPAct8PipvWJEaKvB2Njb5qFpWEao=.ce83f3d7-57dd-4785-8b10-8fcab9f4f50d@github.com>
 <OYF9UYPDtkyCiMpbd_6QxySYG7PqsvlTQMNOuNeP0mI=.0aeb357e-c3a4-4f4d-a532-deaba7928a02@github.com>
 <UyN_E7v6dY8RiE3wDMSoLQE0HjEdjI-7UFfnZ-5SWPw=.b0bb7253-fc91-4ada-bcb7-4fe666bd60ef@github.com>
Message-ID: <qQKZHMz90Kmid3vWRwcljtJcuLI10HzwSgUk1SV_kzg=.b4b6dfa0-5818-4bd9-8ad7-fd095f521a14@github.com>

On Thu, 20 Oct 2022 07:34:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > @shipilev this has broken our linux aarch64 builds!
> 
> Whoa. Looking.

That would be: #10781

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

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


From tanksherman27 at gmail.com  Thu Oct 20 08:58:46 2022
From: tanksherman27 at gmail.com (Julian Waters)
Date: Thu, 20 Oct 2022 16:58:46 +0800
Subject: fixpath not properly converting Unix paths with print?
Message-ID: <CAP2b4GNQg37AySL+A=tEhpHDhpR2PDR_J1cR6Fm+QFLPushqNg@mail.gmail.com>

Hi all,

On Windows MakeBase contains a utility to extract Windows paths from Unix
style paths:

# FixPath
#
# On Windows, converts a path from cygwin/unix style (e.g. /bin/foo) into
# "mixed mode" (e.g. c:/cygwin/bin/foo). On other platforms, return the path
# unchanged.
# This also converts a colon-separated list of paths to a
semicolon-separated
# list.
# This is normally not needed since we use the FIXPATH prefix for command
lines,
# but might be needed in certain circumstances.

According to the documentation it should be able to handle paths like
/usr/bin or /bin/xxx, but manually invoking the implementation of this
utility from the shell seems to indicate that it can only properly convert
full paths that have environment prefixes and so on, with the "true" Unix
style paths simply expanding into empty strings:

Working usage:

user at LAPTOP-NEMLU0S6:/mnt/d/eclipse/workspace/hotspot/jdk$ fixpath print
/mnt/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1432~1.313/bin/hostx64/x64/cl.exe
c:\progra~1\mib055~1\2022\commun~1\vc\tools\msvc\1432~1.313\bin\hostx64\x64\cl.exe
user at LAPTOP-NEMLU0S6:/mnt/d/eclipse/workspace/hotspot/jdk$

as compared to:

user at LAPTOP-NEMLU0S6:/mnt/d/eclipse/workspace/hotspot/jdk$
/mnt/d/eclipse/workspace/hotspot/jdk/build/windows-x86_64-server-release/fixpath
print /usr/bin/make
vertig0 at LAPTOP-NEMLU0S6:/mnt/d/eclipse/workspace/hotspot/jdk$

I can't quite tell if this is a subtle bug or if it's working as intended,
and the documentation is just a tad outdated/was misinterpreted by me, so I
thought I'd raise it on the list just in case (I first caught this while
using FixPath on a local branch).

best regards,
Julian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20221020/922795ca/attachment.htm>

From djelinski1 at gmail.com  Thu Oct 20 09:27:29 2022
From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=)
Date: Thu, 20 Oct 2022 11:27:29 +0200
Subject: fixpath not properly converting Unix paths with print?
In-Reply-To: <CAP2b4GNQg37AySL+A=tEhpHDhpR2PDR_J1cR6Fm+QFLPushqNg@mail.gmail.com>
References: <CAP2b4GNQg37AySL+A=tEhpHDhpR2PDR_J1cR6Fm+QFLPushqNg@mail.gmail.com>
Message-ID: <CAMrH03+vJm4TZEF7YrNeb663WBfNzdNuB5JmONMSRpf2LaDvWg@mail.gmail.com>

Hi,
Fixpath does not work with WSL paths; historically it was hard to map them
to Windows paths.

This article suggests that it should be easier now:
https://www.howtogeek.com/426749/how-to-access-your-linux-wsl-files-in-windows-10/

I suppose you could give it a try if you're interested.
Regards,
Daniel


czw., 20 pa? 2022 o 10:59 Julian Waters <tanksherman27 at gmail.com>
napisa?(a):

> Hi all,
>
> On Windows MakeBase contains a utility to extract Windows paths from Unix
> style paths:
>
> # FixPath
> #
> # On Windows, converts a path from cygwin/unix style (e.g. /bin/foo) into
> # "mixed mode" (e.g. c:/cygwin/bin/foo). On other platforms, return the
> path
> # unchanged.
> # This also converts a colon-separated list of paths to a
> semicolon-separated
> # list.
> # This is normally not needed since we use the FIXPATH prefix for command
> lines,
> # but might be needed in certain circumstances.
>
> According to the documentation it should be able to handle paths like
> /usr/bin or /bin/xxx, but manually invoking the implementation of this
> utility from the shell seems to indicate that it can only properly convert
> full paths that have environment prefixes and so on, with the "true" Unix
> style paths simply expanding into empty strings:
>
> Working usage:
>
> user at LAPTOP-NEMLU0S6:/mnt/d/eclipse/workspace/hotspot/jdk$ fixpath print
> /mnt/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1432~1.313/bin/hostx64/x64/cl.exe
>
> c:\progra~1\mib055~1\2022\commun~1\vc\tools\msvc\1432~1.313\bin\hostx64\x64\cl.exe
> user at LAPTOP-NEMLU0S6:/mnt/d/eclipse/workspace/hotspot/jdk$
>
> as compared to:
>
> user at LAPTOP-NEMLU0S6:/mnt/d/eclipse/workspace/hotspot/jdk$
> /mnt/d/eclipse/workspace/hotspot/jdk/build/windows-x86_64-server-release/fixpath
> print /usr/bin/make
> vertig0 at LAPTOP-NEMLU0S6:/mnt/d/eclipse/workspace/hotspot/jdk$
>
> I can't quite tell if this is a subtle bug or if it's working as intended,
> and the documentation is just a tad outdated/was misinterpreted by me, so I
> thought I'd raise it on the list just in case (I first caught this while
> using FixPath on a local branch).
>
> best regards,
> Julian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20221020/da0fb2a0/attachment.htm>

From ihse at openjdk.org  Thu Oct 20 10:07:40 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 10:07:40 GMT
Subject: RFR: 8295714: GHA ::set-output is deprecated and will be removed
Message-ID: <lyFuyBCTkIMIZ-Mvd9NHwkRx4EHDJQ0tadSapwESzHk=.1383ea91-4e2f-4283-93cd-82e0bce25ba0@github.com>

We need to transition to use the new `$GITHUB_OUTPUT` method instead. 

This needs to be fixed since it is currently spamming the summary with warnings, and will stop working soon.

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

Commit messages:
 - 8295714: GHA ::set-output is deprecated and will be removed

Changes: https://git.openjdk.org/jdk/pull/10785/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10785&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295714
  Stats: 28 lines in 11 files changed: 1 ins; 0 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/10785.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10785/head:pull/10785

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


From shade at openjdk.org  Thu Oct 20 10:11:54 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 20 Oct 2022 10:11:54 GMT
Subject: RFR: 8295714: GHA ::set-output is deprecated and will be removed
In-Reply-To: <lyFuyBCTkIMIZ-Mvd9NHwkRx4EHDJQ0tadSapwESzHk=.1383ea91-4e2f-4283-93cd-82e0bce25ba0@github.com>
References: <lyFuyBCTkIMIZ-Mvd9NHwkRx4EHDJQ0tadSapwESzHk=.1383ea91-4e2f-4283-93cd-82e0bce25ba0@github.com>
Message-ID: <wfdChbItBfFtpf9kDMcciFLtromkszYRFgULDn288O4=.2ed65245-a883-4c49-abdc-e9ecdb596a52@github.com>

On Thu, 20 Oct 2022 10:00:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We need to transition to use the new `$GITHUB_OUTPUT` method instead. 
> 
> This needs to be fixed since it is currently spamming the summary with warnings, and will stop working soon.

Thanks! Looks fine, provided GHAs are green.

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

Marked as reviewed by shade (Reviewer).

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


From ihse at openjdk.org  Thu Oct 20 10:22:30 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 10:22:30 GMT
Subject: RFR: 8295715: Minimize disabled warnings in serviceability libs
Message-ID: <4SfhafQDgLn2kW9yaU3krIUjNKCyThBnU4uRA8h2bDk=.3322b735-b5d8-4952-9811-837de70aaf2b@github.com>

After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in the serviceability native libraries.

Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.

Some warnings didn't trigger in any file anymore, and could just be removed.

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

Commit messages:
 - 8295715: Minimize disabled warnings in serviceability libs

Changes: https://git.openjdk.org/jdk/pull/10786/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10786&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295715
  Stats: 16 lines in 4 files changed: 4 ins; 2 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10786.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10786/head:pull/10786

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


From ihse at openjdk.org  Thu Oct 20 10:26:26 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 10:26:26 GMT
Subject: RFR: 8295716: Minimize disabled warnings in security libs
Message-ID: <wC6EGLuPyOIwbzXSG_S57RYQtqfLpibn0Eybd8TNio8=.884268ad-51ec-4d6f-aed9-84fa67704faa@github.com>

After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in the security native libraries.

Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.

Some warnings didn't trigger in any file anymore, and could just be removed.

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

Commit messages:
 - 8295716: Minimize disabled warnings in security libs

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

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


From ihse at openjdk.org  Thu Oct 20 10:33:10 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 10:33:10 GMT
Subject: RFR: 8295717: Minimize disabled warnings in accessibility native code
Message-ID: <V7dSEaZRacw4fFXSL61G9iTPJeQIzKWGEVTnRcda0Qw=.9a53defc-8192-4dab-bce3-98042e284858@github.com>

After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in the accessibility native code.

Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.

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

Commit messages:
 - 8295717: Minimize disabled warnings in accessibility native code

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

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


From ihse at openjdk.org  Thu Oct 20 10:35:45 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 10:35:45 GMT
Subject: RFR: 8295719: Remove unneeded disabled warnings in jdk.sctp
Message-ID: <LnNXZg1d7CQlI7pIeqUi3iaIg7185dhA3T2b7hcvWHw=.35a55091-deef-4288-8793-975f59bfbc7e@github.com>

In `libsctp`, there are a couple of `DISABLED_WARNINGS` that are no longer needed to build successfully. These should be removed.

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

Commit messages:
 - 8295719: Remove unneeded disabled warnings in jdk.sctp

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

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


From ihse at openjdk.org  Thu Oct 20 10:37:59 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 10:37:59 GMT
Subject: RFR: 8294466: Minimize disabled warnings in java.desktop
In-Reply-To: <P3ypBcY4pLz6ruMi5FIS6dZDO959LJ7nvW0BePnzyqQ=.958cf136-95bc-4715-8b6e-e9c110761539@github.com>
References: <P3ypBcY4pLz6ruMi5FIS6dZDO959LJ7nvW0BePnzyqQ=.958cf136-95bc-4715-8b6e-e9c110761539@github.com>
Message-ID: <YIYFXrFE7-xAxs_u4TnojiRhmUFlmLPbhK5goo9_jqc=.35dda2fa-8a85-4330-8ecb-a01abf898bf9@github.com>

On Tue, 27 Sep 2022 16:14:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.desktop native libraries.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.

I fouled up with the merge, and this PR got just messy. I'll close this and open a new.

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

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


From ihse at openjdk.org  Thu Oct 20 10:38:00 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 10:38:00 GMT
Subject: Withdrawn: 8294466: Minimize disabled warnings in java.desktop
In-Reply-To: <P3ypBcY4pLz6ruMi5FIS6dZDO959LJ7nvW0BePnzyqQ=.958cf136-95bc-4715-8b6e-e9c110761539@github.com>
References: <P3ypBcY4pLz6ruMi5FIS6dZDO959LJ7nvW0BePnzyqQ=.958cf136-95bc-4715-8b6e-e9c110761539@github.com>
Message-ID: <Z8pTvM7B4Pc4GVK2Sy_Jx_KjuVe4BJIqZkxMBRpcIt0=.f459f4b7-9b6a-4ccb-ad77-750f9d6b0593@github.com>

On Tue, 27 Sep 2022 16:14:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.desktop native libraries.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.

This pull request has been closed without being integrated.

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

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


From ihse at openjdk.org  Thu Oct 20 10:43:19 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 10:43:19 GMT
Subject: RFR: 8294466: Minimize disabled warnings in java.desktop
Message-ID: <yCuRyS186FkEXvCSQJXcCvEa17uq7t9kvlqrCQ3dSoc=.07d5e90d-86b2-4cca-a1c1-baac5bd8651a@github.com>

After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.desktop native libraries.

Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.

Some warnings didn't trigger in any file anymore, and could just be removed.

(This is a reboot of https://github.com/openjdk/jdk/pull/10453)

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

Commit messages:
 - 8294466: Minimize disabled warnings in java.desktop

Changes: https://git.openjdk.org/jdk/pull/10790/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10790&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294466
  Stats: 100 lines in 2 files changed: 43 ins; 18 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/10790.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10790/head:pull/10790

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


From ihse at openjdk.org  Thu Oct 20 11:13:18 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 11:13:18 GMT
Subject: RFR: 8295653: Add a graph of the sealed class hierarchy for marked
 classes [v2]
In-Reply-To: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
References: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
Message-ID: <HesqaFYWAlswM8GiQW0Fn3jZSyP_kTA4UHgX-OjE4uY=.dcab4fe1-c5a0-4265-a65e-476106c0f359@github.com>

> It would be possible to mark classes with `@sealedGraph` to indicate that the sealed hierarchy should be rendered graphically in the JavaDocs. Classes not marked would be unaffected, creating an opt-in approach.
> 
> [Here](https://bugs.openjdk.org/secure/attachment/101126/Screen%20Shot%202022-10-19%20at%2012.47.47%20PM.png) is an example of MemoryLayout class rendering.
> 
> This feature has been developed in cooperation with Per Minborg.

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

  Fix styleheet

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10761/files
  - new: https://git.openjdk.org/jdk/pull/10761/files/8627a08e..0b43e55c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10761&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10761&range=00-01

  Stats: 11 lines in 1 file changed: 0 ins; 9 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10761.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10761/head:pull/10761

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


From ihse at openjdk.org  Thu Oct 20 11:13:19 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 11:13:19 GMT
Subject: RFR: 8295653: Add a graph of the sealed class hierarchy for marked
 classes [v2]
In-Reply-To: <0IpmpqjlZASLdasJsDqI6ghj9XL703ul8YeDcotTTTM=.6bd10feb-4147-411b-821d-55cb010415dd@github.com>
References: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
 <p6MRgjzc5FItSAofLJkBSfJ8Qm1_wVYTIMh_cafSVSY=.d4fb4b2f-a076-4608-b65e-720e42553ae6@github.com>
 <O5hZlm-8rgWmzKLl3vHk3rAYqwZNSVSGrmGUs711thg=.211fdadc-fbf6-489d-baad-4444a4666c89@github.com>
 <0IpmpqjlZASLdasJsDqI6ghj9XL703ul8YeDcotTTTM=.6bd10feb-4147-411b-821d-55cb010415dd@github.com>
Message-ID: <fErncrK5ug3SJh0l86cRaot_99L_GRuWrdLurIvFukA=.682dff77-ca4b-4061-aa3d-15bea5fdf913@github.com>

On Wed, 19 Oct 2022 21:00:06 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> I'm not that familiar with css syntax. Can you be more concrete on how you wish this written?
>
> I'm suggesting something like the following, although I have not explicitly tested it:
> 
> 
> .module-graph span, .sealed-graph span {
>     display:none;
>     position:absolute;
> }
> .module-graph:hover span, .sealed-graph:hover span {
>     display:block;
>      margin: -100px 0 0 100px;
>      z-index: 1;
>  }

Fixed. Thank you for helping me with the CSS syntax. I have verified that it looks good for both existing module graphs and the new sealed graphs.

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

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


From ihse at openjdk.org  Thu Oct 20 12:06:27 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 12:06:27 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
Message-ID: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>

Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.

With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).

The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

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

Commit messages:
 - 8295729: Add jcheck whitespace checking for properties files

Changes: https://git.openjdk.org/jdk/pull/10792/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295729
  Stats: 1105 lines in 368 files changed: 0 ins; 0 del; 1105 mod
  Patch: https://git.openjdk.org/jdk/pull/10792.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10792/head:pull/10792

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


From tanksherman27 at gmail.com  Thu Oct 20 13:59:50 2022
From: tanksherman27 at gmail.com (Julian Waters)
Date: Thu, 20 Oct 2022 21:59:50 +0800
Subject: fixpath not properly converting Unix paths with print?
In-Reply-To: <CAMrH03+vJm4TZEF7YrNeb663WBfNzdNuB5JmONMSRpf2LaDvWg@mail.gmail.com>
References: <CAP2b4GNQg37AySL+A=tEhpHDhpR2PDR_J1cR6Fm+QFLPushqNg@mail.gmail.com>
 <CAMrH03+vJm4TZEF7YrNeb663WBfNzdNuB5JmONMSRpf2LaDvWg@mail.gmail.com>
Message-ID: <CAP2b4GNNED23yd9AsU3vzPZuAjK-m16LMbYoUsKpU92+q5bf8A@mail.gmail.com>

Yep, just tried the same thing on MSYS, worked like a charm

(Path to fixpath was truncated for easier reading)
$ fixpath print /usr/bin/make
C:\msys64\usr\bin\make

This is going to be pretty frustrating, but I'll take a crack at it to see
if I can wrestle WSL into fixpath, thanks for the link

best regards,
Julian

On Thu, Oct 20, 2022 at 5:27 PM Daniel Jeli?ski <djelinski1 at gmail.com>
wrote:

> Hi,
> Fixpath does not work with WSL paths; historically it was hard to map them
> to Windows paths.
>
> This article suggests that it should be easier now:
>
> https://www.howtogeek.com/426749/how-to-access-your-linux-wsl-files-in-windows-10/
>
> I suppose you could give it a try if you're interested.
> Regards,
> Daniel
>
>
> czw., 20 pa? 2022 o 10:59 Julian Waters <tanksherman27 at gmail.com>
> napisa?(a):
>
>> Hi all,
>>
>> On Windows MakeBase contains a utility to extract Windows paths from Unix
>> style paths:
>>
>> # FixPath
>> #
>> # On Windows, converts a path from cygwin/unix style (e.g. /bin/foo) into
>> # "mixed mode" (e.g. c:/cygwin/bin/foo). On other platforms, return the
>> path
>> # unchanged.
>> # This also converts a colon-separated list of paths to a
>> semicolon-separated
>> # list.
>> # This is normally not needed since we use the FIXPATH prefix for command
>> lines,
>> # but might be needed in certain circumstances.
>>
>> According to the documentation it should be able to handle paths like
>> /usr/bin or /bin/xxx, but manually invoking the implementation of this
>> utility from the shell seems to indicate that it can only properly convert
>> full paths that have environment prefixes and so on, with the "true" Unix
>> style paths simply expanding into empty strings:
>>
>> Working usage:
>>
>> user at LAPTOP-NEMLU0S6:/mnt/d/eclipse/workspace/hotspot/jdk$ fixpath print
>> /mnt/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1432~1.313/bin/hostx64/x64/cl.exe
>>
>> c:\progra~1\mib055~1\2022\commun~1\vc\tools\msvc\1432~1.313\bin\hostx64\x64\cl.exe
>> user at LAPTOP-NEMLU0S6:/mnt/d/eclipse/workspace/hotspot/jdk$
>>
>> as compared to:
>>
>> user at LAPTOP-NEMLU0S6:/mnt/d/eclipse/workspace/hotspot/jdk$
>> /mnt/d/eclipse/workspace/hotspot/jdk/build/windows-x86_64-server-release/fixpath
>> print /usr/bin/make
>> vertig0 at LAPTOP-NEMLU0S6:/mnt/d/eclipse/workspace/hotspot/jdk$
>>
>> I can't quite tell if this is a subtle bug or if it's working as
>> intended, and the documentation is just a tad outdated/was misinterpreted
>> by me, so I thought I'd raise it on the list just in case (I first caught
>> this while using FixPath on a local branch).
>>
>> best regards,
>> Julian
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20221020/f5323b8a/attachment.htm>

From magnus.ihse.bursie at oracle.com  Thu Oct 20 15:03:26 2022
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 17:03:26 +0200
Subject: fixpath not properly converting Unix paths with print?
In-Reply-To: <CAP2b4GNQg37AySL+A=tEhpHDhpR2PDR_J1cR6Fm+QFLPushqNg@mail.gmail.com>
References: <CAP2b4GNQg37AySL+A=tEhpHDhpR2PDR_J1cR6Fm+QFLPushqNg@mail.gmail.com>
Message-ID: <ec9cde06-2428-eea6-fc84-3a9c13cdb48b@oracle.com>

The fixpath.sh script has two "modes", one in which it tries to 
autodetect it's environment itself, and one in which the environment 
info is fed into it from the caller.

The latter method is used in all real use cases when it is used in the 
make files.

You are exercising the first case. That is only intended as a 
development tool, and might not work correctly.

I think that is the answer to the oddities you are seeing.

Look in `spec.gmk` to find how fixpath.sh is really called during a 
makefile execution.

/Magnus


On 2022-10-20 10:58, Julian Waters wrote:
> Hi all,
>
> On Windows MakeBase contains a utility to extract Windows paths from 
> Unix style paths:
>
> # FixPath
> #
> # On Windows, converts a path from cygwin/unix style (e.g. /bin/foo) into
> # "mixed mode" (e.g. c:/cygwin/bin/foo). On other platforms, return 
> the path
> # unchanged.
> # This also converts a colon-separated list of paths to a 
> semicolon-separated
> # list.
> # This is normally not needed since we use the FIXPATH prefix for 
> command lines,
> # but might be needed in certain circumstances.
>
> According to the documentation it should be able to handle paths like 
> /usr/bin or /bin/xxx, but manually invoking the implementation of this 
> utility from the shell seems to indicate that it can only properly 
> convert full paths that have environment prefixes and so on, with the 
> "true" Unix style paths simply expanding into empty strings:
>
> Working usage:
>
> user at LAPTOP-NEMLU0S6:/mnt/d/eclipse/workspace/hotspot/jdk$ fixpath 
> print 
> /mnt/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1432~1.313/bin/hostx64/x64/cl.exe 
>
> c:\progra~1\mib055~1\2022\commun~1\vc\tools\msvc\1432~1.313\bin\hostx64\x64\cl.exe
> user at LAPTOP-NEMLU0S6:/mnt/d/eclipse/workspace/hotspot/jdk$
>
> as compared to:
>
> user at LAPTOP-NEMLU0S6:/mnt/d/eclipse/workspace/hotspot/jdk$ 
> /mnt/d/eclipse/workspace/hotspot/jdk/build/windows-x86_64-server-release/fixpath 
> print /usr/bin/make
> vertig0 at LAPTOP-NEMLU0S6:/mnt/d/eclipse/workspace/hotspot/jdk$
>
> I can't quite tell if this is a subtle bug or if it's working as 
> intended, and the documentation is just a tad outdated/was 
> misinterpreted by me, so I thought I'd raise it on the list just in 
> case (I first caught this while using FixPath on a local branch).
>
> best regards,
> Julian


From magnus.ihse.bursie at oracle.com  Thu Oct 20 15:06:42 2022
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 17:06:42 +0200
Subject: fixpath not properly converting Unix paths with print?
In-Reply-To: <ec9cde06-2428-eea6-fc84-3a9c13cdb48b@oracle.com>
References: <CAP2b4GNQg37AySL+A=tEhpHDhpR2PDR_J1cR6Fm+QFLPushqNg@mail.gmail.com>
 <ec9cde06-2428-eea6-fc84-3a9c13cdb48b@oracle.com>
Message-ID: <2fe55798-6dd0-08bd-15ba-8fc1496cc8bc@oracle.com>

To clarify, you need the added

FIXPATH_ARGS="-e $PATHTOOL -p $WINENV_PREFIX_ARG -r 
${WINENV_ROOT//\\/\\\\} -t $WINENV_TEMP_DIR -c $CMD -q"

to be sure to get the correct behavior.

/Magnus

On 2022-10-20 17:03, Magnus Ihse Bursie wrote:
> The fixpath.sh script has two "modes", one in which it tries to 
> autodetect it's environment itself, and one in which the environment 
> info is fed into it from the caller.
>
> The latter method is used in all real use cases when it is used in the 
> make files.
>
> You are exercising the first case. That is only intended as a 
> development tool, and might not work correctly.
>
> I think that is the answer to the oddities you are seeing.
>
> Look in `spec.gmk` to find how fixpath.sh is really called during a 
> makefile execution.
>
> /Magnus
>
>
> On 2022-10-20 10:58, Julian Waters wrote:
>> Hi all,
>>
>> On Windows MakeBase contains a utility to extract Windows paths from 
>> Unix style paths:
>>
>> # FixPath
>> #
>> # On Windows, converts a path from cygwin/unix style (e.g. /bin/foo) 
>> into
>> # "mixed mode" (e.g. c:/cygwin/bin/foo). On other platforms, return 
>> the path
>> # unchanged.
>> # This also converts a colon-separated list of paths to a 
>> semicolon-separated
>> # list.
>> # This is normally not needed since we use the FIXPATH prefix for 
>> command lines,
>> # but might be needed in certain circumstances.
>>
>> According to the documentation it should be able to handle paths like 
>> /usr/bin or /bin/xxx, but manually invoking the implementation of 
>> this utility from the shell seems to indicate that it can only 
>> properly convert full paths that have environment prefixes and so on, 
>> with the "true" Unix style paths simply expanding into empty strings:
>>
>> Working usage:
>>
>> user at LAPTOP-NEMLU0S6:/mnt/d/eclipse/workspace/hotspot/jdk$ fixpath 
>> print 
>> /mnt/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1432~1.313/bin/hostx64/x64/cl.exe 
>>
>> c:\progra~1\mib055~1\2022\commun~1\vc\tools\msvc\1432~1.313\bin\hostx64\x64\cl.exe 
>>
>> user at LAPTOP-NEMLU0S6:/mnt/d/eclipse/workspace/hotspot/jdk$
>>
>> as compared to:
>>
>> user at LAPTOP-NEMLU0S6:/mnt/d/eclipse/workspace/hotspot/jdk$ 
>> /mnt/d/eclipse/workspace/hotspot/jdk/build/windows-x86_64-server-release/fixpath 
>> print /usr/bin/make
>> vertig0 at LAPTOP-NEMLU0S6:/mnt/d/eclipse/workspace/hotspot/jdk$
>>
>> I can't quite tell if this is a subtle bug or if it's working as 
>> intended, and the documentation is just a tad outdated/was 
>> misinterpreted by me, so I thought I'd raise it on the list just in 
>> case (I first caught this while using FixPath on a local branch).
>>
>> best regards,
>> Julian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20221020/d9f3f776/attachment.htm>

From aph at openjdk.org  Thu Oct 20 17:43:49 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 20 Oct 2022 17:43:49 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
Message-ID: <LSOu3yLgfIEqJ7d8He1fPrhHw7CC-A8wzn2oEBJoECw=.2a0ae44e-5601-44c1-8959-5dccdeabcfd3@github.com>

On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>> 
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>> 
>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
>> 
>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

So here's a thought:

Reading and writing floating-point control flags can be expensive because they're serializing operations. However, we can discover whether the processor has been put into an "odd" rounding mode with just a few floating-point instructions, so we can do:


if (epsilon + epsilon == 0) {
      rtn = fesetenv(&default_fenv)
    }


which ends up as


	movsd  xmm1,QWORD PTR [epsilon]
	pxor   xmm4,xmm4
	addsd  xmm1,xmm1
	ucomisd xmm0,xmm4
	jnp    ...



We'd need a bit more fiddling to detect changes of rounding mode as well, if we wanted to do that.

That might well be chap enough that we could do it on JNI calls. Do you think it would be worth my while doing some timings?

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

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


From cjplummer at openjdk.org  Thu Oct 20 17:56:55 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 20 Oct 2022 17:56:55 GMT
Subject: RFR: 8295715: Minimize disabled warnings in serviceability libs
In-Reply-To: <4SfhafQDgLn2kW9yaU3krIUjNKCyThBnU4uRA8h2bDk=.3322b735-b5d8-4952-9811-837de70aaf2b@github.com>
References: <4SfhafQDgLn2kW9yaU3krIUjNKCyThBnU4uRA8h2bDk=.3322b735-b5d8-4952-9811-837de70aaf2b@github.com>
Message-ID: <qeYyTuqKh_W_jgaLioTXwg9rq7WGbOMU63OXWD3d5yo=.ec097cc0-f249-42df-b435-a255d0ac8ef9@github.com>

On Thu, 20 Oct 2022 10:15:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in the serviceability native libraries.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.

Changes look good.

Is there any desire to clean up these warnings? I see back in 2015 there were a bunch of "Resolve disabled warnings for libXXX" bugs that you fixed. Any plans to make another pass. Seems like some of these warnings might be hiding real bugs.

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

Marked as reviewed by cjplummer (Reviewer).

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


From erikj at openjdk.org  Thu Oct 20 18:03:48 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 18:03:48 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
Message-ID: <cxLfmrrBUYs-PYK-SznAJbeViJPKV89s3mw2wsQ646E=.8bd5438a-3dd5-4404-9840-ad493da21fa5@github.com>

On Wed, 19 Oct 2022 08:15:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".

Marked as reviewed by erikj (Reviewer).

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

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


From erikj at openjdk.org  Thu Oct 20 18:06:01 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 18:06:01 GMT
Subject: RFR: 8295716: Minimize disabled warnings in security libs
In-Reply-To: <wC6EGLuPyOIwbzXSG_S57RYQtqfLpibn0Eybd8TNio8=.884268ad-51ec-4d6f-aed9-84fa67704faa@github.com>
References: <wC6EGLuPyOIwbzXSG_S57RYQtqfLpibn0Eybd8TNio8=.884268ad-51ec-4d6f-aed9-84fa67704faa@github.com>
Message-ID: <C_hTNhozwawu9AmPdvWJoKbfNDoh6omJ7XuOHNMC8pM=.f3e0f2cd-75ff-427e-91bb-822155f39d4b@github.com>

On Thu, 20 Oct 2022 10:19:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in the security native libraries.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.

Marked as reviewed by erikj (Reviewer).

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

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


From erikj at openjdk.org  Thu Oct 20 18:09:16 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 18:09:16 GMT
Subject: RFR: 8295717: Minimize disabled warnings in accessibility native
 code
In-Reply-To: <V7dSEaZRacw4fFXSL61G9iTPJeQIzKWGEVTnRcda0Qw=.9a53defc-8192-4dab-bce3-98042e284858@github.com>
References: <V7dSEaZRacw4fFXSL61G9iTPJeQIzKWGEVTnRcda0Qw=.9a53defc-8192-4dab-bce3-98042e284858@github.com>
Message-ID: <ce7zx48PfM_s8PbgHd7AEdYQ3O4mhBcovYe37HMGMkI=.24f69caf-f657-4740-84be-3ebde04cf487@github.com>

On Thu, 20 Oct 2022 10:24:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in the accessibility native code.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.

make/modules/jdk.accessibility/Launcher.gmk line 46:

> 44:           -analyze- -Od -Gd -D_WINDOWS \
> 45:           -D_UNICODE -DUNICODE -RTC1 -EHsc, \
> 46:       DISABLED_WARNINGS_microsoft_jabswitch.cpp := 4267 4996, \

This lib only has one cpp file, so this change doesn't seem that useful.

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

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


From erikj at openjdk.org  Thu Oct 20 18:09:48 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 18:09:48 GMT
Subject: RFR: 8295719: Remove unneeded disabled warnings in jdk.sctp
In-Reply-To: <LnNXZg1d7CQlI7pIeqUi3iaIg7185dhA3T2b7hcvWHw=.35a55091-deef-4288-8793-975f59bfbc7e@github.com>
References: <LnNXZg1d7CQlI7pIeqUi3iaIg7185dhA3T2b7hcvWHw=.35a55091-deef-4288-8793-975f59bfbc7e@github.com>
Message-ID: <6Qc43PjAdkHMmM0aLFC0A3WTiSAlJZqNBKyPtGSJTAY=.5eceb518-f8ea-424f-acef-910da954d3aa@github.com>

On Thu, 20 Oct 2022 10:28:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In `libsctp`, there are a couple of `DISABLED_WARNINGS` that are no longer needed to build successfully. These should be removed.

Marked as reviewed by erikj (Reviewer).

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

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


From erikj at openjdk.org  Thu Oct 20 18:16:52 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 18:16:52 GMT
Subject: RFR: 8294466: Minimize disabled warnings in java.desktop
In-Reply-To: <yCuRyS186FkEXvCSQJXcCvEa17uq7t9kvlqrCQ3dSoc=.07d5e90d-86b2-4cca-a1c1-baac5bd8651a@github.com>
References: <yCuRyS186FkEXvCSQJXcCvEa17uq7t9kvlqrCQ3dSoc=.07d5e90d-86b2-4cca-a1c1-baac5bd8651a@github.com>
Message-ID: <somtlyJyxdK432gQ2H51CalLnjdhjN1LFerqxdKx4ys=.fd12fb37-dc0e-469f-ad7f-cc2e4689dd3c@github.com>

On Thu, 20 Oct 2022 10:36:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.desktop native libraries.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.
> 
> (This is a reboot of https://github.com/openjdk/jdk/pull/10453)

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 222:

> 220:     endif
> 221: 
> 222:     ifeq ($(TOOLCHAIN_TYPE), gcc)

How did you solve this?

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

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


From erikj at openjdk.org  Thu Oct 20 18:24:50 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 18:24:50 GMT
Subject: RFR: 8295653: Add a graph of the sealed class hierarchy for marked
 classes [v2]
In-Reply-To: <HesqaFYWAlswM8GiQW0Fn3jZSyP_kTA4UHgX-OjE4uY=.dcab4fe1-c5a0-4265-a65e-476106c0f359@github.com>
References: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
 <HesqaFYWAlswM8GiQW0Fn3jZSyP_kTA4UHgX-OjE4uY=.dcab4fe1-c5a0-4265-a65e-476106c0f359@github.com>
Message-ID: <eCX2boAhfcGkEiXaBjOvYtdgIlvfvATGoK5TU9zynTk=.0bafa2c7-bc83-4622-a7a0-e276e426311d@github.com>

On Thu, 20 Oct 2022 11:13:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> It would be possible to mark classes with `@sealedGraph` to indicate that the sealed hierarchy should be rendered graphically in the JavaDocs. Classes not marked would be unaffected, creating an opt-in approach.
>> 
>> [Here](https://bugs.openjdk.org/secure/attachment/101126/Screen%20Shot%202022-10-19%20at%2012.47.47%20PM.png) is an example of MemoryLayout class rendering.
>> 
>> This feature has been developed in cooperation with Per Minborg.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix styleheet

Marked as reviewed by erikj (Reviewer).

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

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


From erikj at openjdk.org  Thu Oct 20 18:26:46 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 18:26:46 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <NObZDn88VUQ8fHaLhcrqe0wkth0EfVAwjWA7K4eAY2k=.0c70399e-f307-4ca4-a637-e2f1ebedf960@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Nice job!

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

Marked as reviewed by erikj (Reviewer).

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


From erikj at openjdk.org  Thu Oct 20 18:28:52 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 18:28:52 GMT
Subject: RFR: 8295715: Minimize disabled warnings in serviceability libs
In-Reply-To: <4SfhafQDgLn2kW9yaU3krIUjNKCyThBnU4uRA8h2bDk=.3322b735-b5d8-4952-9811-837de70aaf2b@github.com>
References: <4SfhafQDgLn2kW9yaU3krIUjNKCyThBnU4uRA8h2bDk=.3322b735-b5d8-4952-9811-837de70aaf2b@github.com>
Message-ID: <wIgglL7-jgMc9PS5RB3W4X2h2VfFQwdyPj1PKxNmo48=.73996954-4b68-4e08-a322-e7dca69684b7@github.com>

On Thu, 20 Oct 2022 10:15:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in the serviceability native libraries.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.

Marked as reviewed by erikj (Reviewer).

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

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


From dfuchs at openjdk.org  Thu Oct 20 18:29:54 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Oct 2022 18:29:54 GMT
Subject: RFR: 8295719: Remove unneeded disabled warnings in jdk.sctp
In-Reply-To: <LnNXZg1d7CQlI7pIeqUi3iaIg7185dhA3T2b7hcvWHw=.35a55091-deef-4288-8793-975f59bfbc7e@github.com>
References: <LnNXZg1d7CQlI7pIeqUi3iaIg7185dhA3T2b7hcvWHw=.35a55091-deef-4288-8793-975f59bfbc7e@github.com>
Message-ID: <zUglEuoAr1xofCVZJk6t2f7BWN12_A3q0N-vDpXnPyw=.d59fcd7d-e9cb-49a9-a18e-58681f24d568@github.com>

On Thu, 20 Oct 2022 10:28:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In `libsctp`, there are a couple of `DISABLED_WARNINGS` that are no longer needed to build successfully. These should be removed.

If everything still builds then LGTM too.

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

Marked as reviewed by dfuchs (Reviewer).

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


From naoto at openjdk.org  Thu Oct 20 18:33:47 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Oct 2022 18:33:47 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <0VhVC2dpGOdpE3OL1278r0iCVXO1Jd_83Q4kszfikjY=.fecfe4ed-9a48-4fe4-827a-7ab1bc2defa2@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

LGTM. Haven't looked at all the l10n files.

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

Marked as reviewed by naoto (Reviewer).

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


From angorya at openjdk.org  Thu Oct 20 18:40:47 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Oct 2022 18:40:47 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

I would vote against this change.  Per java properties spec
https://github.com/openjdk/jdk/pull/10792


White space following the property value is not ignored, and is treated as part of the property value.


This change might break localization or messages where trailing whitespace is important (example: "Label: ")

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

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


From ihse at openjdk.org  Thu Oct 20 18:48:17 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 18:48:17 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
Message-ID: <j6FxMycN-ld3OS68tZbfSgemu4x6DcYb7Y8yt5_GWmk=.50161e23-1c85-4f68-930b-214fb4825950@github.com>

On Thu, 20 Oct 2022 18:38:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> I would vote against this change.  Per java properties spec
> https://github.com/openjdk/jdk/pull/10792
> 
> 
> White space following the property value is not ignored, and is treated as part of the property value.
> 
> 
> This change might break localization or messages where trailing whitespace is important (example: "Label: ")
> 
> edit: sorry, the link above is not a spec.  looking at the Properties.load(Reader) javadoc:
> https://docs.oracle.com/javase/10/docs/api/java/util/Properties.html#load(java.io.Reader)
> 
> 
> Any white space after the key is skipped; if the first non-white space character after the key is '=' or ':', then it is ignored and any white space characters after it are also skipped. All remaining characters on the line become part of the associated element string;

@andy-goryachev-oracle Oh, I did not know that. Is this really how it is implemented, or is there a discrepancy between the spec and the implementation? The haphazard placement of trailing spaces seems to indicate that they are ignored.

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

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


From ihse at openjdk.org  Thu Oct 20 18:51:55 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 18:51:55 GMT
Subject: Integrated: 8295719: Remove unneeded disabled warnings in jdk.sctp
In-Reply-To: <LnNXZg1d7CQlI7pIeqUi3iaIg7185dhA3T2b7hcvWHw=.35a55091-deef-4288-8793-975f59bfbc7e@github.com>
References: <LnNXZg1d7CQlI7pIeqUi3iaIg7185dhA3T2b7hcvWHw=.35a55091-deef-4288-8793-975f59bfbc7e@github.com>
Message-ID: <rtRQ1ctjWOFEldkbxoMvx5IAd8JeBlHq1p_OZf0nwOU=.01e3c45b-3bf2-4e1f-9f3b-41459facfe77@github.com>

On Thu, 20 Oct 2022 10:28:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In `libsctp`, there are a couple of `DISABLED_WARNINGS` that are no longer needed to build successfully. These should be removed.

This pull request has now been integrated.

Changeset: de1e0c57
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/de1e0c57a75efee0b171f7ad341ce8db24c5507f
Stats:     3 lines in 1 file changed: 0 ins; 2 del; 1 mod

8295719: Remove unneeded disabled warnings in jdk.sctp

Reviewed-by: erikj, dfuchs

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

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


From ihse at openjdk.org  Thu Oct 20 18:52:17 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 18:52:17 GMT
Subject: RFR: 8295715: Minimize disabled warnings in serviceability libs
In-Reply-To: <qeYyTuqKh_W_jgaLioTXwg9rq7WGbOMU63OXWD3d5yo=.ec097cc0-f249-42df-b435-a255d0ac8ef9@github.com>
References: <4SfhafQDgLn2kW9yaU3krIUjNKCyThBnU4uRA8h2bDk=.3322b735-b5d8-4952-9811-837de70aaf2b@github.com>
 <qeYyTuqKh_W_jgaLioTXwg9rq7WGbOMU63OXWD3d5yo=.ec097cc0-f249-42df-b435-a255d0ac8ef9@github.com>
Message-ID: <lLtaJDaiGcQ1ApjcPBVXZlZMlyZnAgpel3P7Fbk_a44=.0a3401fd-ce30-456f-99d6-1b0f8483b561@github.com>

On Thu, 20 Oct 2022 17:54:51 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in the serviceability native libraries.
>> 
>> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
>> 
>> Some warnings didn't trigger in any file anymore, and could just be removed.
>
> Is there any desire to clean up these warnings? I see back in 2015 there were a bunch of "Resolve disabled warnings for libXXX" bugs that you fixed. Any plans to make another pass. Seems like some of these warnings might be hiding real bugs.

@plummercj I agree that it could very well be that these warnings are signs of real bugs. And yes, I plan to open new bugs requesting for these warnings to be fixed, if possible, if not someone else beats me to it. 

However, it is mostly out of scope for me to fix, since domain knowledge by the respective component teams are usually required. And the old "Resolve disabled warnings for libXXX" JBS issues were created by me, but not fixed by me (in general).

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

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


From erikj at openjdk.org  Thu Oct 20 18:53:49 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 18:53:49 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <qf8daMUSgSlaXN3bROLfbFbpzrDJh5wSJdnTYQdol64=.df762075-9646-4aab-ab95-ead96e45936a@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Given that trailing whitespace may be part of a property value, then I take back my review.

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

Changes requested by erikj (Reviewer).

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


From cjplummer at openjdk.org  Thu Oct 20 18:53:50 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 20 Oct 2022 18:53:50 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
Message-ID: <uNs096Y7_C0U9CTifzO1PL71uAgKv0RwAxTfOuL5LGw=.e8e725f6-3fac-4b54-b406-111628923ae8@github.com>

On Thu, 20 Oct 2022 18:38:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> `White space following the property value is not ignored, and is treated as part of the property value.`

Although I didn't know this was in the spec, I suspected it might be the case. When looking at the jdk.management.agent changes, it looked like the extra space was actually a typo and was copied into all the localized versions (and not actually localized for unicode locales). In this case removing the white space is the right thing to do. It is in fact fixing an actual bug.

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

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


From angorya at openjdk.org  Thu Oct 20 18:53:51 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Oct 2022 18:53:51 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <j6FxMycN-ld3OS68tZbfSgemu4x6DcYb7Y8yt5_GWmk=.50161e23-1c85-4f68-930b-214fb4825950@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
 <j6FxMycN-ld3OS68tZbfSgemu4x6DcYb7Y8yt5_GWmk=.50161e23-1c85-4f68-930b-214fb4825950@github.com>
Message-ID: <HJm4YG5tr3dJ4SeXPS58BEpkBqzUEk7QwX6Cmf5x8JA=.7076b0a9-6fe2-4e0a-99f9-d3ca8a828a5a@github.com>

On Thu, 20 Oct 2022 18:46:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I would vote against this change.  Per java properties spec
>> https://github.com/openjdk/jdk/pull/10792
>> 
>> 
>> White space following the property value is not ignored, and is treated as part of the property value.
>> 
>> 
>> This change might break localization or messages where trailing whitespace is important (example: "Label: ")
>> 
>> edit: sorry, the link above is not a spec.  looking at the Properties.load(Reader) javadoc:
>> https://docs.oracle.com/javase/10/docs/api/java/util/Properties.html#load(java.io.Reader)
>> 
>> 
>> Any white space after the key is skipped; if the first non-white space character after the key is '=' or ':', then it is ignored and any white space characters after it are also skipped. All remaining characters on the line become part of the associated element string;
>
> @andy-goryachev-oracle Oh, I did not know that. Is this really how it is implemented, or is there a discrepancy between the spec and the implementation? The haphazard placement of trailing spaces seems to indicate that they are ignored.

@magicus  : 
no, this is how Properties were working from day one.


package goryachev.research;

import java.io.IOException;
import java.io.StringReader;
import java.util.Properties;

public class TestProperties {
    public static void main(String[] args) throws IOException {
        String text = "key= value ";
        Properties p = new Properties();
        p.load(new StringReader(text));
        System.out.println("value=["  +p.getProperty("key") + "]");
    }
}


outputs:

value=[value ]

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

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


From ihse at openjdk.org  Thu Oct 20 18:55:27 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 18:55:27 GMT
Subject: Integrated: 8295715: Minimize disabled warnings in serviceability libs
In-Reply-To: <4SfhafQDgLn2kW9yaU3krIUjNKCyThBnU4uRA8h2bDk=.3322b735-b5d8-4952-9811-837de70aaf2b@github.com>
References: <4SfhafQDgLn2kW9yaU3krIUjNKCyThBnU4uRA8h2bDk=.3322b735-b5d8-4952-9811-837de70aaf2b@github.com>
Message-ID: <krE81JuS08pbD22XilwzTVBYoehDwvG08WxI4i5uihI=.288e359d-cb20-4785-b862-1090e16956b2@github.com>

On Thu, 20 Oct 2022 10:15:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in the serviceability native libraries.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.

This pull request has now been integrated.

Changeset: faa6b662
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/faa6b662577a24eeb726ba525303b68b87269869
Stats:     16 lines in 4 files changed: 4 ins; 2 del; 10 mod

8295715: Minimize disabled warnings in serviceability libs

Reviewed-by: cjplummer, erikj

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

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


From ihse at openjdk.org  Thu Oct 20 18:55:55 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 18:55:55 GMT
Subject: RFR: 8294466: Minimize disabled warnings in java.desktop
In-Reply-To: <somtlyJyxdK432gQ2H51CalLnjdhjN1LFerqxdKx4ys=.fd12fb37-dc0e-469f-ad7f-cc2e4689dd3c@github.com>
References: <yCuRyS186FkEXvCSQJXcCvEa17uq7t9kvlqrCQ3dSoc=.07d5e90d-86b2-4cca-a1c1-baac5bd8651a@github.com>
 <somtlyJyxdK432gQ2H51CalLnjdhjN1LFerqxdKx4ys=.fd12fb37-dc0e-469f-ad7f-cc2e4689dd3c@github.com>
Message-ID: <mNm0cbDTRz4IRpaejMIOGqXzcnLbXvzzE7N2c5WZvw8=.b039cb42-0741-4a04-a72a-d09045bba75d@github.com>

On Thu, 20 Oct 2022 18:14:45 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.desktop native libraries.
>> 
>> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
>> 
>> Some warnings didn't trigger in any file anymore, and could just be removed.
>> 
>> (This is a reboot of https://github.com/openjdk/jdk/pull/10453)
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 222:
> 
>> 220:     endif
>> 221: 
>> 222:     ifeq ($(TOOLCHAIN_TYPE), gcc)
> 
> How did you solve this?

I did not solve anything. Apparently the code has changed so the warnings is no longer triggered. Or that's at least what I assume, just as for other warnings that were no longer needed.

It might be that it also triggered only for older versions of gcc. I've tested with a couple of different versions, but I have not done an extensive test of all possible gcc version. The worst thing that can happen is that some specific, old version of gcc will still trigger these (or any other removed) warning(s). If that happens, the speedy workaround is to run with `--disable-warnings-as-error`, and then I'll restore the warning, possibly with a version check.

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

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


From ihse at openjdk.org  Thu Oct 20 19:01:02 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 19:01:02 GMT
Subject: RFR: 8295717: Minimize disabled warnings in accessibility native
 code
In-Reply-To: <ce7zx48PfM_s8PbgHd7AEdYQ3O4mhBcovYe37HMGMkI=.24f69caf-f657-4740-84be-3ebde04cf487@github.com>
References: <V7dSEaZRacw4fFXSL61G9iTPJeQIzKWGEVTnRcda0Qw=.9a53defc-8192-4dab-bce3-98042e284858@github.com>
 <ce7zx48PfM_s8PbgHd7AEdYQ3O4mhBcovYe37HMGMkI=.24f69caf-f657-4740-84be-3ebde04cf487@github.com>
Message-ID: <c9QBA0xrPmEhinXsbjBFoys3OA3xzsXHXjRm345RObM=.a1a76b72-1c48-4826-9a78-f42d2cc1b133@github.com>

On Thu, 20 Oct 2022 18:06:09 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in the accessibility native code.
>> 
>> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
>
> make/modules/jdk.accessibility/Launcher.gmk line 46:
> 
>> 44:           -analyze- -Od -Gd -D_WINDOWS \
>> 45:           -D_UNICODE -DUNICODE -RTC1 -EHsc, \
>> 46:       DISABLED_WARNINGS_microsoft_jabswitch.cpp := 4267 4996, \
> 
> This lib only has one cpp file, so this change doesn't seem that useful.

Heh, I did not notice that.

I'd still argue that this is a useful change. If some other file were ever to be added, it will not be covered by the blanked disabled warnings, and -- perhaps more important -- it is clear that these warnings can be addressed just by looking at a single file. This information has drastically increased the likelihood that a developer picks up the issue and actually resolves the warnings, as we have seen in other areas where I've done this "warnings-per-file" transition.

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

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


From ihse at openjdk.org  Thu Oct 20 19:07:52 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 19:07:52 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <vN85_fh3ocln38nEOKYh1GBwW5xzb3nIo_jYOQYqiLY=.6e65e099-3d3c-40fe-8cfa-1acf25fdd0a7@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Okay. That definitely rules out adding .properties to the whitespace jcheck verification.

However, I think that instead opens up a ton of more individual problems, since I think most (if perhaps not all) of these trailing whitespaces are incidental, and thus might be bugs. Perhaps no-one really noticed a double whitespace where it were not supposed to be, etc, especially not if it was just for a translated language.

I'm thinking I should redirect this PR to skip the jcheck requirement, and revert all changes to property values, but keep the part of the patch that removes trailing spaces in `#` comment lines. That seems to account for a majority of the changes.

For the remaining properties files with trailing spaces in the actual values, I'll make a sanity check if it seems correct or not, and if it looks fishy, I'll open bugs on the respective component teams to verify that their property values are indeed correct.

Does that sound reasonable?

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

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


From naoto at openjdk.org  Thu Oct 20 19:29:51 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Oct 2022 19:29:51 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <iu-qPLbaWYYTSq2jVgsGXDGt8Weqq2RVuoaHyuI0YRg=.f4131b5a-9685-4246-bbac-85b776fee6e3@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Retracting my approval too. Thanks for the catch, Andy!
That sounds reasonable > Magnus

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

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


From naoto at openjdk.org  Thu Oct 20 19:40:55 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Oct 2022 19:40:55 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <eJ0YaIIkCYOV7stEG2AEVx05evyYix9H9Zp2eAlJsjA=.2e14e322-75f6-4651-bb96-c24cf2f10391@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

(retracting approval)

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

Changes requested by naoto (Reviewer).

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


From erikj at openjdk.org  Thu Oct 20 19:53:47 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 19:53:47 GMT
Subject: RFR: 8294466: Minimize disabled warnings in java.desktop
In-Reply-To: <yCuRyS186FkEXvCSQJXcCvEa17uq7t9kvlqrCQ3dSoc=.07d5e90d-86b2-4cca-a1c1-baac5bd8651a@github.com>
References: <yCuRyS186FkEXvCSQJXcCvEa17uq7t9kvlqrCQ3dSoc=.07d5e90d-86b2-4cca-a1c1-baac5bd8651a@github.com>
Message-ID: <J-a_PiAp2DQh_Z_43k8vqsZheKUnYv25354mVDz5Q54=.72fb1eae-de69-430f-afe9-2889d761499e@github.com>

On Thu, 20 Oct 2022 10:36:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.desktop native libraries.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.
> 
> (This is a reboot of https://github.com/openjdk/jdk/pull/10453)

Marked as reviewed by erikj (Reviewer).

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

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


From erikj at openjdk.org  Thu Oct 20 19:54:47 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 19:54:47 GMT
Subject: RFR: 8295717: Minimize disabled warnings in accessibility native
 code
In-Reply-To: <V7dSEaZRacw4fFXSL61G9iTPJeQIzKWGEVTnRcda0Qw=.9a53defc-8192-4dab-bce3-98042e284858@github.com>
References: <V7dSEaZRacw4fFXSL61G9iTPJeQIzKWGEVTnRcda0Qw=.9a53defc-8192-4dab-bce3-98042e284858@github.com>
Message-ID: <E-uDnAHrmrIXe7qWW-bQPKoLv1n0v4dSz1ArwFj50vo=.fd857699-3cbb-47f5-beec-d6d92bf7e6f2@github.com>

On Thu, 20 Oct 2022 10:24:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in the accessibility native code.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.

Marked as reviewed by erikj (Reviewer).

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

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


From joe.darcy at oracle.com  Thu Oct 20 20:05:52 2022
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 20 Oct 2022 13:05:52 -0700
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <LSOu3yLgfIEqJ7d8He1fPrhHw7CC-A8wzn2oEBJoECw=.2a0ae44e-5601-44c1-8959-5dccdeabcfd3@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
 <LSOu3yLgfIEqJ7d8He1fPrhHw7CC-A8wzn2oEBJoECw=.2a0ae44e-5601-44c1-8959-5dccdeabcfd3@github.com>
Message-ID: <7ae4f3c8-2ad9-e670-c7f6-85e1f24c2d8a@oracle.com>


On 10/20/2022 10:43 AM, Andrew Haley wrote:
> On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley <aph at openjdk.org> wrote:
>
>>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>>>
>>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>>>
>>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now.
>>>
>>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    8295159: DSO created with -ffast-math breaks Java floating-point arithmetic
> So here's a thought:
>
> Reading and writing floating-point control flags can be expensive because they're serializing operations. However, we can discover whether the processor has been put into an "odd" rounding mode with just a few floating-point instructions, so we can do:
>
>
> if (epsilon + epsilon == 0) {
>        rtn = fesetenv(&default_fenv)
>      }
>
Assuming the rounding mode could be one of the four classic rounding 
modes (to nearest even, to +infinity, to -infinity, to zero), two 
calculations are needed to determine if the mode is set to nearest even, 
as required by the JVM.

Candidate calculations are

1.0 + ROUND_THRESH == 1.0
-1.0 - ROUND_THRESH == -1.0

with the decoding

false false??? => to nearest
false true??? => to positive infinity
true false??? => to negative infinity
true true ??? => to zero

For double, the double rounding threshold is 2^?53 + 2^?105 ? 
1.1102230246251568e ?16. An analogous constant can be derived for float, 
if desired

HTH,

-Joe



From joe.darcy at oracle.com  Thu Oct 20 20:18:13 2022
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 20 Oct 2022 13:18:13 -0700
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <7ae4f3c8-2ad9-e670-c7f6-85e1f24c2d8a@oracle.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
 <LSOu3yLgfIEqJ7d8He1fPrhHw7CC-A8wzn2oEBJoECw=.2a0ae44e-5601-44c1-8959-5dccdeabcfd3@github.com>
 <7ae4f3c8-2ad9-e670-c7f6-85e1f24c2d8a@oracle.com>
Message-ID: <571980c0-7c79-b0d1-f527-6862b6dfa0e8@oracle.com>

PS And additional expressions could be crashed to rule out 
flush-to-zero, treating all subnormals and zero, and other non-compliant 
modes of operation.

-Joe

On 10/20/2022 1:05 PM, Joseph D. Darcy wrote:
>
> On 10/20/2022 10:43 AM, Andrew Haley wrote:
>> On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley <aph at openjdk.org> wrote:
>>
>>>> A bug in GCC causes shared libraries linked with -ffast-math to 
>>>> disable denormal arithmetic. This breaks Java's floating-point 
>>>> semantics.
>>>>
>>>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>>>>
>>>> One solution is to save and restore the floating-point control word 
>>>> around System.loadLibrary(). This isn't perfect, because some 
>>>> shared library might load another shared library at runtime, but 
>>>> it's a lot better than what we do now.
>>>>
>>>> However, this fix is not complete. `dlopen()` is called from many 
>>>> places in the JDK. I guess the best thing to do is find and wrap 
>>>> them all. I'd like to hear people's opinions.
>>> Andrew Haley has updated the pull request incrementally with one 
>>> additional commit since the last revision:
>>>
>>> ?? 8295159: DSO created with -ffast-math breaks Java floating-point 
>>> arithmetic
>> So here's a thought:
>>
>> Reading and writing floating-point control flags can be expensive 
>> because they're serializing operations. However, we can discover 
>> whether the processor has been put into an "odd" rounding mode with 
>> just a few floating-point instructions, so we can do:
>>
>>
>> if (epsilon + epsilon == 0) {
>> ?????? rtn = fesetenv(&default_fenv)
>> ???? }
>>
> Assuming the rounding mode could be one of the four classic rounding 
> modes (to nearest even, to +infinity, to -infinity, to zero), two 
> calculations are needed to determine if the mode is set to nearest 
> even, as required by the JVM.
>
> Candidate calculations are
>
> 1.0 + ROUND_THRESH == 1.0
> -1.0 - ROUND_THRESH == -1.0
>
> with the decoding
>
> false false??? => to nearest
> false true??? => to positive infinity
> true false??? => to negative infinity
> true true ??? => to zero
>
> For double, the double rounding threshold is 2^?53 + 2^?105 ? 
> 1.1102230246251568e ?16. An analogous constant can be derived for 
> float, if desired
>
> HTH,
>
> -Joe
>


From vlivanov at openjdk.org  Thu Oct 20 20:30:13 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 20 Oct 2022 20:30:13 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
Message-ID: <BDA7SSW43tdWnrU2b44ntWews7s7ZCH5E9vgC2Qeu4A=.cf1bd3ad-c452-44b2-b3f2-da61d68feeb7@github.com>

On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>> 
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>> 
>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
>> 
>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

That sounds like a very interesting idea. 

It would be very helpful to get an understanding how much overhead `STMXCSR` plus a branch adds in JNI stub to decide whether it's worth optimizing for.

Call stub already employs an optimization to save on writing to MXCSR:

    Label skip_ldmx;
    __ stmxcsr(mxcsr_save);
    __ movl(rax, mxcsr_save);
    __ andl(rax, 0xFFC0); // Mask out any pending exceptions (only check control and mask bits)
    ExternalAddress mxcsr_std(StubRoutines::x86::addr_mxcsr_std());
    __ cmp32(rax, mxcsr_std, rscratch1);
    __ jcc(Assembler::equal, skip_ldmx);
    __ ldmxcsr(mxcsr_std, rscratch1);
    __ bind(skip_ldmx);

According to [uops.info](https://uops.info/html-instr/STMXCSR_M32.html), latencies for `STMXCSR` vary from 7-12 cycles on Intel to up to 20 on AMD. I haven't found any details about the actual implementations in silicon (can't confirm it serializes the execution), so I'm curious how much branch prediction can hide the latency in this particular case.

If it turns out to be worth optimizing `STMXCSR` away, I see other problematic cases:


StubRoutines::x86::_mxcsr_std = 0x1F80;

// MXCSR.b  10987654321098765432109876543210
// 0xFFC0   00000000000000001111111111000000 // mask
// 0x1F80   00000000000000000001111110000000 // MXCSR value used by JVM
// 0x8040   00000000000000001000000001000000 // the bits -ffast-math mode unconditionally sets

// MXCSR bits:
// 15    FTZ Flush to Zero                       0 = 1
// 14:13 RC  Rounding Control                   00
// 12    PM  Precision Exception Mask            1
// 11    UM  Underflow Exception Mask            1
// 10    OM  Overflow Exception Mask             1
// 9     ZM  Zero-Divide Exception Mask          1
// 8     DM  Denormalized-Operand Exception Mask 1
// 7     IM  Invalid-Operation Exception Mask    1
// 6     DAZ Denormals Are Zeros                 0 = 1


The GCC bugs with `-ffast-math` only corrupts `FTZ` and `DAZ`. 

But `RC` and exception masks may be corrupted as well the same way and I believe the consequences are be similar (silent divergence in results during FP computations).

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

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


From erikj at openjdk.org  Thu Oct 20 21:56:40 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 21:56:40 GMT
Subject: RFR: 8287754: Update jib GNU make dependency on Windows to latest
 cygwin build
Message-ID: <oYCgCpczrN2XziQtYlk4fa2RldjtWauzUnfg_1bFnkA=.67c9b89c-3aca-49c2-85c8-e7d273c6803a@github.com>

For Oracle internal builds we control the version of GNU Make (currently fixed at 4.0). In Cygwin this is causing problems as the now rather dated GNU Make binary we use isn't compatible with Cygwin.dll version 3.3 or later. To work around this, I'm making the dependency dynamic on the version of Cygwin. If the currently running Cygwin is new enough, the dependency will be on GNU make 4.3.

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

Commit messages:
 - JDK-8287754

Changes: https://git.openjdk.org/jdk/pull/10805/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10805&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287754
  Stats: 26 lines in 1 file changed: 15 ins; 6 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10805.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10805/head:pull/10805

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


From ihse at openjdk.org  Fri Oct 21 07:39:51 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Oct 2022 07:39:51 GMT
Subject: RFR: 8295714: GHA ::set-output is deprecated and will be removed
In-Reply-To: <lyFuyBCTkIMIZ-Mvd9NHwkRx4EHDJQ0tadSapwESzHk=.1383ea91-4e2f-4283-93cd-82e0bce25ba0@github.com>
References: <lyFuyBCTkIMIZ-Mvd9NHwkRx4EHDJQ0tadSapwESzHk=.1383ea91-4e2f-4283-93cd-82e0bce25ba0@github.com>
Message-ID: <J_ZWvVnlqS8ypEtWxCJyYGcK8bEXFC9xyEplijMbhpE=.cc0376c4-22d1-4d0a-9dd6-0760bb9e5096@github.com>

On Thu, 20 Oct 2022 10:00:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We need to transition to use the new `$GITHUB_OUTPUT` method instead. 
> 
> This needs to be fixed since it is currently spamming the summary with warnings, and will stop working soon.

My fixes were green, but all of the annoying log spam was not gone. After some digging, it turned out that GitHub's own `download-artifact at v3` was not clean, so I've upgraded it to `download-artifact at v3.0.1` which was released just hours (!) ago. (Luckily I did not try to research this yesterday...)

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

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


From ihse at openjdk.org  Fri Oct 21 07:39:49 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Oct 2022 07:39:49 GMT
Subject: RFR: 8295714: GHA ::set-output is deprecated and will be removed
 [v2]
In-Reply-To: <lyFuyBCTkIMIZ-Mvd9NHwkRx4EHDJQ0tadSapwESzHk=.1383ea91-4e2f-4283-93cd-82e0bce25ba0@github.com>
References: <lyFuyBCTkIMIZ-Mvd9NHwkRx4EHDJQ0tadSapwESzHk=.1383ea91-4e2f-4283-93cd-82e0bce25ba0@github.com>
Message-ID: <KXcZ7R4HjuqoKi2aVw0NZ2v9L9aVCsiEuBM6N1l43T4=.72d89110-ad09-4626-a1b2-a1b9b69ce184@github.com>

> We need to transition to use the new `$GITHUB_OUTPUT` method instead. 
> 
> This needs to be fixed since it is currently spamming the summary with warnings, and will stop working soon.

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

  Upgrade to download-artifact at v3.0.1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10785/files
  - new: https://git.openjdk.org/jdk/pull/10785/files/9d51fadf..9c65693e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10785&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10785&range=00-01

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

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


From djelinski at openjdk.org  Fri Oct 21 07:50:09 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 21 Oct 2022 07:50:09 GMT
Subject: RFR: 8287754: Update jib GNU make dependency on Windows to latest
 cygwin build
In-Reply-To: <oYCgCpczrN2XziQtYlk4fa2RldjtWauzUnfg_1bFnkA=.67c9b89c-3aca-49c2-85c8-e7d273c6803a@github.com>
References: <oYCgCpczrN2XziQtYlk4fa2RldjtWauzUnfg_1bFnkA=.67c9b89c-3aca-49c2-85c8-e7d273c6803a@github.com>
Message-ID: <QKAnmrmZmwq3IE2P1fN1SLhuapJiyibVIzyEwWwfhNs=.c3dd22ad-dff5-4d35-8cb0-08709328a087@github.com>

On Thu, 20 Oct 2022 21:49:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> For Oracle internal builds we control the version of GNU Make (currently fixed at 4.0). In Cygwin this is causing problems as the now rather dated GNU Make binary we use isn't compatible with Cygwin.dll version 3.3 or later. To work around this, I'm making the dependency dynamic on the version of Cygwin. If the currently running Cygwin is new enough, the dependency will be on GNU make 4.3.

I can confirm that with these changes the build is using make 4.3, and is using all cores as expected.

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

Marked as reviewed by djelinski (Committer).

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


From shade at openjdk.org  Fri Oct 21 07:52:47 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 21 Oct 2022 07:52:47 GMT
Subject: RFR: 8295714: GHA ::set-output is deprecated and will be removed
In-Reply-To: <J_ZWvVnlqS8ypEtWxCJyYGcK8bEXFC9xyEplijMbhpE=.cc0376c4-22d1-4d0a-9dd6-0760bb9e5096@github.com>
References: <lyFuyBCTkIMIZ-Mvd9NHwkRx4EHDJQ0tadSapwESzHk=.1383ea91-4e2f-4283-93cd-82e0bce25ba0@github.com>
 <J_ZWvVnlqS8ypEtWxCJyYGcK8bEXFC9xyEplijMbhpE=.cc0376c4-22d1-4d0a-9dd6-0760bb9e5096@github.com>
Message-ID: <PtQI7Cb9AglFwlsetGRUT3A12u-AjF5eK6m9LmvVBJI=.0ac8f61b-71a3-4870-97a7-289a0feda673@github.com>

On Fri, 21 Oct 2022 07:35:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> My fixes were green, but all of the annoying log spam was not gone. After some digging, it turned out that GitHub's own `download-artifact at v3` was not clean, so I've upgraded it to `download-artifact at v3.0.1` which was released just hours (!) ago. (Luckily I did not try to research this yesterday...)

Hah, DevOps goes brrrrr.

I would then wait for `@v3` to catch up with the latest version, instead of sticking the `@v3.0.1` that would keep us at outdated version as newer versions appear. We can try to re-test this PR next week, maybe?

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

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


From ihse at openjdk.org  Fri Oct 21 08:17:46 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Oct 2022 08:17:46 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v2]
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Remove check for .properties from jcheck
 - Restore trailing whitespace for property values

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10792/files
  - new: https://git.openjdk.org/jdk/pull/10792/files/e33c0765..c91fdaa1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=00-01

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

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


From ihse at openjdk.org  Fri Oct 21 08:21:15 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Oct 2022 08:21:15 GMT
Subject: RFR: 8295714: GHA ::set-output is deprecated and will be removed
 [v2]
In-Reply-To: <KXcZ7R4HjuqoKi2aVw0NZ2v9L9aVCsiEuBM6N1l43T4=.72d89110-ad09-4626-a1b2-a1b9b69ce184@github.com>
References: <lyFuyBCTkIMIZ-Mvd9NHwkRx4EHDJQ0tadSapwESzHk=.1383ea91-4e2f-4283-93cd-82e0bce25ba0@github.com>
 <KXcZ7R4HjuqoKi2aVw0NZ2v9L9aVCsiEuBM6N1l43T4=.72d89110-ad09-4626-a1b2-a1b9b69ce184@github.com>
Message-ID: <3tkpBaujC07tVZfWF4k2o10ea_uJ8gHZSMJcveJ6dFs=.640724af-1491-4726-b77f-85cdca95c212@github.com>

On Fri, 21 Oct 2022 07:39:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> We need to transition to use the new `$GITHUB_OUTPUT` method instead. 
>> 
>> This needs to be fixed since it is currently spamming the summary with warnings, and will stop working soon.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Upgrade to download-artifact at v3.0.1

*digging some more* 

Actually, the `v3` tag is already identical to `v3.0.1`, so there's probably just some caching at work here. I'll revert the latest commit, and then I say we're good to go. The upload-artifact issue will resolve itself, eventually, and we do not need to delay this fix awaiting that.

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

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


From shade at openjdk.org  Fri Oct 21 08:21:16 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 21 Oct 2022 08:21:16 GMT
Subject: RFR: 8295714: GHA ::set-output is deprecated and will be removed
 [v2]
In-Reply-To: <KXcZ7R4HjuqoKi2aVw0NZ2v9L9aVCsiEuBM6N1l43T4=.72d89110-ad09-4626-a1b2-a1b9b69ce184@github.com>
References: <lyFuyBCTkIMIZ-Mvd9NHwkRx4EHDJQ0tadSapwESzHk=.1383ea91-4e2f-4283-93cd-82e0bce25ba0@github.com>
 <KXcZ7R4HjuqoKi2aVw0NZ2v9L9aVCsiEuBM6N1l43T4=.72d89110-ad09-4626-a1b2-a1b9b69ce184@github.com>
Message-ID: <OrNdb2EkguAZujWmbwGQU8kmM6c1l1nq0THKvyZ2Gcw=.601297e0-349c-473d-860d-537b5c576dfa@github.com>

On Fri, 21 Oct 2022 07:39:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> We need to transition to use the new `$GITHUB_OUTPUT` method instead. 
>> 
>> This needs to be fixed since it is currently spamming the summary with warnings, and will stop working soon.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Upgrade to download-artifact at v3.0.1

Fine by me.

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

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


From ihse at openjdk.org  Fri Oct 21 08:25:12 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Oct 2022 08:25:12 GMT
Subject: RFR: 8295714: GHA ::set-output is deprecated and will be removed
 [v3]
In-Reply-To: <lyFuyBCTkIMIZ-Mvd9NHwkRx4EHDJQ0tadSapwESzHk=.1383ea91-4e2f-4283-93cd-82e0bce25ba0@github.com>
References: <lyFuyBCTkIMIZ-Mvd9NHwkRx4EHDJQ0tadSapwESzHk=.1383ea91-4e2f-4283-93cd-82e0bce25ba0@github.com>
Message-ID: <0E8aunuipiwsUo2nFrigK4IXP7yvmfxR9Uq6mZCuTSo=.900a49cd-b302-4cfe-95ec-31d24bb33d14@github.com>

> We need to transition to use the new `$GITHUB_OUTPUT` method instead. 
> 
> This needs to be fixed since it is currently spamming the summary with warnings, and will stop working soon.

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

  Revert "Upgrade to download-artifact at v3.0.1"
  
  This reverts commit 9c65693e42b934481159dcfdcea5df535dff0e9c.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10785/files
  - new: https://git.openjdk.org/jdk/pull/10785/files/9c65693e..974fc045

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10785&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10785&range=01-02

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

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


From ihse at openjdk.org  Fri Oct 21 08:26:47 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Oct 2022 08:26:47 GMT
Subject: Integrated: 8295714: GHA ::set-output is deprecated and will be
 removed
In-Reply-To: <lyFuyBCTkIMIZ-Mvd9NHwkRx4EHDJQ0tadSapwESzHk=.1383ea91-4e2f-4283-93cd-82e0bce25ba0@github.com>
References: <lyFuyBCTkIMIZ-Mvd9NHwkRx4EHDJQ0tadSapwESzHk=.1383ea91-4e2f-4283-93cd-82e0bce25ba0@github.com>
Message-ID: <cn_WeGDU4dSukmTAPf3fGpcCEwBLDF-sMi8I_bC4CNk=.a4096d13-250b-4026-9d04-e8ffe115d5d4@github.com>

On Thu, 20 Oct 2022 10:00:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We need to transition to use the new `$GITHUB_OUTPUT` method instead. 
> 
> This needs to be fixed since it is currently spamming the summary with warnings, and will stop working soon.

This pull request has now been integrated.

Changeset: b35922be
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b35922be6de7b848a2982d6a278dbd205fc39e6a
Stats:     28 lines in 11 files changed: 1 ins; 0 del; 27 mod

8295714: GHA ::set-output is deprecated and will be removed

Reviewed-by: shade

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

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


From aph at openjdk.org  Fri Oct 21 08:30:44 2022
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 21 Oct 2022 08:30:44 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <BDA7SSW43tdWnrU2b44ntWews7s7ZCH5E9vgC2Qeu4A=.cf1bd3ad-c452-44b2-b3f2-da61d68feeb7@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
 <BDA7SSW43tdWnrU2b44ntWews7s7ZCH5E9vgC2Qeu4A=.cf1bd3ad-c452-44b2-b3f2-da61d68feeb7@github.com>
Message-ID: <4xSGTUVOSKQtJT61dcmi3ORP987OgOT6dvjxWDZhsbg=.a5049926-7471-4b80-9b7a-1a6908298b6c@github.com>

On Thu, 20 Oct 2022 20:26:47 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> That sounds like a very interesting idea.
> 
> It would be very helpful to get an understanding how much overhead `STMXCSR` plus a branch adds in JNI stub to decide whether it's worth optimizing for.

It's not just Intel's implementation of x86, though. Apple M1 takes a big hit when writing the FPCR: It seems to me to wait for all instructions in progress to retire. Given that there are 600 entries in the M1 reorder buffer (!) that's a lot. Of course they could rename the FPCR like anything else, but I guess they don't.

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

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


From ihse at openjdk.org  Fri Oct 21 08:31:59 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Oct 2022 08:31:59 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <1mu65mMxl2Nf-mwa4iZczOBqJbPdutKpL6dE_3vMWcg=.c03430ed-70df-40fa-994e-700080b7b8fa@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

Ok, I repurposed this PR to deal only with trailing space on non-value lines (comments and empty lines). This should be trivial, and will reduce the trailing spaces to only the value lines.

I believe most, but perhaps not all, trailing spaces in the value lines are actually bugs, but that will need further scrutiny by the owners of the properties files. Expect follow up bugs on this.

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

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


From ihse at openjdk.org  Fri Oct 21 10:20:50 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Oct 2022 10:20:50 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
Message-ID: <ugwrZd3SjXfR7U6fVWnGCxcOUjsX_XvoKwqjFgHcBPU=.47f5b4d8-0ce5-4633-8a3a-7db0801d6338@github.com>

On Wed, 19 Oct 2022 08:15:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".

Can you please refrain from integrating this while I investigate while this was originally moved?

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

Changes requested by ihse (Reviewer).

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


From erikj at openjdk.org  Fri Oct 21 12:59:48 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 21 Oct 2022 12:59:48 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <AoFGXlCHPgwZa3u0Kwp6W-h5k-I_Malb2gWa3tSxSbw=.500a110c-0c73-4205-9a2e-e281bfb3a730@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

Marked as reviewed by erikj (Reviewer).

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

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


From shade at openjdk.org  Fri Oct 21 15:33:35 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 21 Oct 2022 15:33:35 GMT
Subject: RFR: 8295795: hsdis does not build with binutils 2.39+
Message-ID: <o80LXEVHj7Lu90MgJHvqwXlx8uxzrJMewc6tFfOlx6o=.11412d16-8bcc-44b8-adbb-4e5b39092074@github.com>

Fails like this:


$ sh ./configure --with-boot-jdk=jdk19u-ea --with-hsdis=binutils --with-binutils-src=binutils-2.39
$ make clean build-hsdis

=== Output from failing command(s) repeated here ===
* For target support_hsdis_hsdis-binutils.o:

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

Commit messages:
 - Fix

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

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


From shade at openjdk.org  Fri Oct 21 15:36:19 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 21 Oct 2022 15:36:19 GMT
Subject: RFR: 8295795: hsdis does not build with binutils 2.39+
In-Reply-To: <o80LXEVHj7Lu90MgJHvqwXlx8uxzrJMewc6tFfOlx6o=.11412d16-8bcc-44b8-adbb-4e5b39092074@github.com>
References: <o80LXEVHj7Lu90MgJHvqwXlx8uxzrJMewc6tFfOlx6o=.11412d16-8bcc-44b8-adbb-4e5b39092074@github.com>
Message-ID: <HEJNXjoKxmnHkecjqSd10jslYx6KvwVMqCpchJFQIZk=.c7e7485c-2f42-47d7-8290-c32a6e08785c@github.com>

On Fri, 21 Oct 2022 15:26:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Fails like this:
> 
> 
> $ sh ./configure --with-boot-jdk=jdk19u-ea --with-hsdis=binutils --with-binutils-src=binutils-2.39
> $ make clean build-hsdis
> 
> === Output from failing command(s) repeated here ===
> * For target support_hsdis_hsdis-binutils.o:

Oh no, this does not work, hsdis SEGVs. Let me try and fix it.

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

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


From djelinski at openjdk.org  Fri Oct 21 16:00:07 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 21 Oct 2022 16:00:07 GMT
Subject: RFR: 8295792: Clean up old async close code
Message-ID: <5-CnyJPjJxGM6oDpCDRSxfxmFsrmy8o5LefMsCy7KWc=.bb5043ed-518d-47bc-87c1-9e9d0a9bc564@github.com>

Please review this PR that removes the remains of old fdTable-based socket close synchronization.

Verified that tier1-3 tests continue to pass on Linux, MacOS and Windows. Did not verify AIX.

Also removed one slow test for an issue in fdtable implementation; as far as I could tell, it is no longer relevant.

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

Commit messages:
 - Clean up after old async close

Changes: https://git.openjdk.org/jdk/pull/10816/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10816&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295792
  Stats: 1159 lines in 12 files changed: 0 ins; 1155 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10816.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10816/head:pull/10816

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


From alanb at openjdk.org  Fri Oct 21 16:06:49 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Oct 2022 16:06:49 GMT
Subject: RFR: 8295792: Clean up old async close code
In-Reply-To: <5-CnyJPjJxGM6oDpCDRSxfxmFsrmy8o5LefMsCy7KWc=.bb5043ed-518d-47bc-87c1-9e9d0a9bc564@github.com>
References: <5-CnyJPjJxGM6oDpCDRSxfxmFsrmy8o5LefMsCy7KWc=.bb5043ed-518d-47bc-87c1-9e9d0a9bc564@github.com>
Message-ID: <-3jZJ7yBwycOAg2aL8V_M1ToNmcYCl10p_oNztnhgis=.223f5af1-d205-4f5a-8b1d-15a3c07ebb5c@github.com>

On Fri, 21 Oct 2022 14:28:02 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this PR that removes the remains of old fdTable-based socket close synchronization.
> 
> Verified that tier1-3 tests continue to pass on Linux, MacOS and Windows. Did not verify AIX.
> 
> Also removed one slow test for an issue in fdtable implementation; as far as I could tell, it is no longer relevant.

src/java.base/unix/native/libnet/net_util_md.c line 703:

> 701: 
> 702:         errno = 0;
> 703:         read_rv = poll(&pfd, 1, nanoTimeout / NET_NSEC_PER_MSEC);

I suspect this one will need to handle EINTR like the original code.

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

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


From naoto at openjdk.org  Fri Oct 21 16:09:28 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Oct 2022 16:09:28 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <IKSqEfLnlAuM7MsEUUJCb5SGC_SpzMgs3qQ0UVfnBx4=.b25cc081-262b-40e7-bf0b-a2b173f2674a@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

One possible solution to this is to replace those dangling white spaces with explicit Unicode escapes, i.e. "\u0009" and "\u0020".  This way jcheck can safely be enabled to detect future unwanted trailing spaces, and possibly existing ones can be visually recognizable by the engineers to correct them.

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

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


From angorya at openjdk.org  Fri Oct 21 16:09:29 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 21 Oct 2022 16:09:29 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v2]
In-Reply-To: <IKSqEfLnlAuM7MsEUUJCb5SGC_SpzMgs3qQ0UVfnBx4=.b25cc081-262b-40e7-bf0b-a2b173f2674a@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
 <IKSqEfLnlAuM7MsEUUJCb5SGC_SpzMgs3qQ0UVfnBx4=.b25cc081-262b-40e7-bf0b-a2b173f2674a@github.com>
Message-ID: <khuIARsEyKMyIfUxBD69kijyjnwDFCzAra51YwctMyY=.71b00eb7-1312-4db9-a6a5-ff85f7635132@github.com>

On Fri, 21 Oct 2022 16:04:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> replace those dangling white spaces with explicit Unicode escapes

this is a *very good* idea.

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

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


From naoto at openjdk.org  Fri Oct 21 17:03:15 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Oct 2022 17:03:15 GMT
Subject: RFR: 8284840: Update CLDR to Version 42.0
Message-ID: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>

This is to update the CLDR data from version 41 to version 42. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments to those upstream changes:

https://unicode-org.atlassian.net/browse/CLDR-14032 (" at " is no longer used for standard date/time format)
https://unicode-org.atlassian.net/browse/CLDR-14831 (NBSP prefixed to `a`, instead of a normal space )
https://unicode-org.atlassian.net/browse/CLDR-11510 (Fix first day of week info for China (CN))
https://unicode-org.atlassian.net/browse/CLDR-15966 (Japanese: Support numbers up to 9999?)

Here is the link to CLDR v42's release notes: https://cldr.unicode.org/index/downloads/cldr-42

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

Commit messages:
 - Merge branch 'master' into cldr+
 - 8284840: Update CLDR to Version 42.0
 - CLDR v42 release
 - v42 beta5
 - v42 beta3
 - v42 beta1
 - v42 alpha
 - alpha1b
 - v42 alpha1b
 - cldr v42 alpha1
 - ... and 3 more: https://git.openjdk.org/jdk/compare/9612cf99...2d86b3c8

Changes: https://git.openjdk.org/jdk/pull/10820/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10820&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8284840
  Stats: 99164 lines in 377 files changed: 68223 ins; 2820 del; 28121 mod
  Patch: https://git.openjdk.org/jdk/pull/10820.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10820/head:pull/10820

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


From djelinski at openjdk.org  Fri Oct 21 17:11:48 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 21 Oct 2022 17:11:48 GMT
Subject: RFR: 8295792: Clean up old async close code
In-Reply-To: <-3jZJ7yBwycOAg2aL8V_M1ToNmcYCl10p_oNztnhgis=.223f5af1-d205-4f5a-8b1d-15a3c07ebb5c@github.com>
References: <5-CnyJPjJxGM6oDpCDRSxfxmFsrmy8o5LefMsCy7KWc=.bb5043ed-518d-47bc-87c1-9e9d0a9bc564@github.com>
 <-3jZJ7yBwycOAg2aL8V_M1ToNmcYCl10p_oNztnhgis=.223f5af1-d205-4f5a-8b1d-15a3c07ebb5c@github.com>
Message-ID: <r9O6qyte-NOlWMdrg_PvYoqpcKmqne4tvwjQ32embg8=.0b1ec05a-83aa-432b-92a1-13d632464c61@github.com>

On Fri, 21 Oct 2022 16:04:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review this PR that removes the remains of old fdTable-based socket close synchronization.
>> 
>> Verified that tier1-3 tests continue to pass on Linux, MacOS and Windows. Did not verify AIX.
>> 
>> Also removed one slow test for an issue in fdtable implementation; as far as I could tell, it is no longer relevant.
>
> src/java.base/unix/native/libnet/net_util_md.c line 703:
> 
>> 701: 
>> 702:         errno = 0;
>> 703:         read_rv = poll(&pfd, 1, nanoTimeout / NET_NSEC_PER_MSEC);
> 
> I suspect this one will need to handle EINTR like the original code.

as far as I can tell, this method retries all poll failures regardless of errno until timeout expires; NET_Poll retried EINTR, so I think we're good here. Or am I missing something?

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

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


From alanb at openjdk.org  Fri Oct 21 17:15:50 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Oct 2022 17:15:50 GMT
Subject: RFR: 8295792: Clean up old async close code
In-Reply-To: <r9O6qyte-NOlWMdrg_PvYoqpcKmqne4tvwjQ32embg8=.0b1ec05a-83aa-432b-92a1-13d632464c61@github.com>
References: <5-CnyJPjJxGM6oDpCDRSxfxmFsrmy8o5LefMsCy7KWc=.bb5043ed-518d-47bc-87c1-9e9d0a9bc564@github.com>
 <-3jZJ7yBwycOAg2aL8V_M1ToNmcYCl10p_oNztnhgis=.223f5af1-d205-4f5a-8b1d-15a3c07ebb5c@github.com>
 <r9O6qyte-NOlWMdrg_PvYoqpcKmqne4tvwjQ32embg8=.0b1ec05a-83aa-432b-92a1-13d632464c61@github.com>
Message-ID: <-SFkot3YayLpzKRC4ia-jE30CpWkpTiqxLNAU9TaNN8=.c33c78d0-ea07-427c-9d93-36aef21216f4@github.com>

On Fri, 21 Oct 2022 17:08:07 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> src/java.base/unix/native/libnet/net_util_md.c line 703:
>> 
>>> 701: 
>>> 702:         errno = 0;
>>> 703:         read_rv = poll(&pfd, 1, nanoTimeout / NET_NSEC_PER_MSEC);
>> 
>> I suspect this one will need to handle EINTR like the original code.
>
> as far as I can tell, this method retries all poll failures regardless of errno until timeout expires; NET_Poll retried EINTR, so I think we're good here. Or am I missing something?

I think you are right, it's ignoring all errors so will continue to loop if interrupted.

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

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


From erikj at openjdk.org  Fri Oct 21 17:36:26 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 21 Oct 2022 17:36:26 GMT
Subject: RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
Message-ID: <zBQjCxYhczKsyNq1Pxy9QWV5FHvqUUWc4jl8-lpHOpI=.9c78ed55-cff6-412c-a765-fccef81e4282@github.com>

On Fri, 21 Oct 2022 16:55:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to update the CLDR data from version 41 to version 42. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments to those upstream changes:
> 
> https://unicode-org.atlassian.net/browse/CLDR-14032 (" at " is no longer used for standard date/time format)
> https://unicode-org.atlassian.net/browse/CLDR-14831 (NBSP prefixed to `a`, instead of a normal space )
> https://unicode-org.atlassian.net/browse/CLDR-11510 (Fix first day of week info for China (CN))
> https://unicode-org.atlassian.net/browse/CLDR-15966 (Japanese: Support numbers up to 9999?)
> 
> Here is the link to CLDR v42's release notes: https://cldr.unicode.org/index/downloads/cldr-42

Marked as reviewed by erikj (Reviewer).

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

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


From iris at openjdk.org  Fri Oct 21 19:02:53 2022
From: iris at openjdk.org (Iris Clark)
Date: Fri, 21 Oct 2022 19:02:53 GMT
Subject: RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
Message-ID: <OwWUFy4vsIhZhu3c10e5ICNeQn8m3gDld0Hq9hni5z8=.a5f4a70b-b501-4a86-ade8-6c907fe9a777@github.com>

On Fri, 21 Oct 2022 16:55:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to update the CLDR data from version 41 to version 42. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments to those upstream changes:
> 
> https://unicode-org.atlassian.net/browse/CLDR-14032 (" at " is no longer used for standard date/time format)
> https://unicode-org.atlassian.net/browse/CLDR-14831 (NBSP prefixed to `a`, instead of a normal space )
> https://unicode-org.atlassian.net/browse/CLDR-11510 (Fix first day of week info for China (CN))
> https://unicode-org.atlassian.net/browse/CLDR-15966 (Japanese: Support numbers up to 9999?)
> 
> Here is the link to CLDR v42's release notes: https://cldr.unicode.org/index/downloads/cldr-42

Marked as reviewed by iris (Reviewer).

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

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


From serb at openjdk.org  Fri Oct 21 19:09:52 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Oct 2022 19:09:52 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <ugwrZd3SjXfR7U6fVWnGCxcOUjsX_XvoKwqjFgHcBPU=.47f5b4d8-0ce5-4633-8a3a-7db0801d6338@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
 <ugwrZd3SjXfR7U6fVWnGCxcOUjsX_XvoKwqjFgHcBPU=.47f5b4d8-0ce5-4633-8a3a-7db0801d6338@github.com>
Message-ID: <2G8pjhPykplr0Bx7-g8L6F2VMU6TbR_bBwCSotImpNo=.97454d13-1afe-49c9-8441-63cbf1f96496@github.com>

On Fri, 21 Oct 2022 10:18:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Can you please refrain from integrating this while I investigate while this was originally moved?

sure.

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

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


From joehw at openjdk.org  Fri Oct 21 19:20:52 2022
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 21 Oct 2022 19:20:52 GMT
Subject: RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
Message-ID: <mFFAfK2xvTNWv4yeXZOOQCreE9XK57JO0V6yktINOP0=.3a6cc963-94b9-4f8d-8d6b-fb945bef0c0a@github.com>

On Fri, 21 Oct 2022 16:55:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to update the CLDR data from version 41 to version 42. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments to those upstream changes:
> 
> https://unicode-org.atlassian.net/browse/CLDR-14032 (" at " is no longer used for standard date/time format)
> https://unicode-org.atlassian.net/browse/CLDR-14831 (NBSP prefixed to `a`, instead of a normal space )
> https://unicode-org.atlassian.net/browse/CLDR-11510 (Fix first day of week info for China (CN))
> https://unicode-org.atlassian.net/browse/CLDR-15966 (Japanese: Support numbers up to 9999?)
> 
> Here is the link to CLDR v42's release notes: https://cldr.unicode.org/index/downloads/cldr-42

Are the first two items (CLDR-14032, CLDR-14831) considered a behavior change (e.g. the format string will be different) that could use a CSR or the release notes to document it? I see the later points to the CLDR release notes, but maybe a statement in our release notes could be clearer?

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

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


From naoto at openjdk.org  Fri Oct 21 19:48:48 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Oct 2022 19:48:48 GMT
Subject: RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <mFFAfK2xvTNWv4yeXZOOQCreE9XK57JO0V6yktINOP0=.3a6cc963-94b9-4f8d-8d6b-fb945bef0c0a@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
 <mFFAfK2xvTNWv4yeXZOOQCreE9XK57JO0V6yktINOP0=.3a6cc963-94b9-4f8d-8d6b-fb945bef0c0a@github.com>
Message-ID: <FBXs_pNgtpx4EJw32V5_ZKKvG3lFimSlzFNjYCFtGjw=.cebdc098-ab36-44e4-be6d-65a45c314ca1@github.com>

On Fri, 21 Oct 2022 19:16:57 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Are the first two items (CLDR-14032, CLDR-14831) considered a behavior change (e.g. the format string will be different) that could use a CSR or the release notes to document it? I see the later points to the CLDR release notes, but maybe a statement in our release notes could be clearer?

Yes. These translation changes affect formatting. We don't usually file a CSR for such changes, but cover them in our release notes.

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

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


From naoto at openjdk.org  Fri Oct 21 20:25:51 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Oct 2022 20:25:51 GMT
Subject: RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
Message-ID: <I2D8h7jYM6Ui_dIwrG18ubpDbgCbuWK7z6TMrdzzXM4=.a418362e-8486-406c-941e-915a373d426a@github.com>

On Fri, 21 Oct 2022 16:55:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to update the CLDR data from version 41 to version 42. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments to those upstream changes:
> 
> https://unicode-org.atlassian.net/browse/CLDR-14032 (" at " is no longer used for standard date/time format)
> https://unicode-org.atlassian.net/browse/CLDR-14831 (NBSP prefixed to `a`, instead of a normal space )
> https://unicode-org.atlassian.net/browse/CLDR-11510 (Fix first day of week info for China (CN))
> https://unicode-org.atlassian.net/browse/CLDR-15966 (Japanese: Support numbers up to 9999?)
> 
> Here is the link to CLDR v42's release notes: https://cldr.unicode.org/index/downloads/cldr-42

Draft release notes: https://bugs.openjdk.org/browse/JDK-8284841

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

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


From joehw at openjdk.org  Fri Oct 21 21:20:45 2022
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 21 Oct 2022 21:20:45 GMT
Subject: RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
Message-ID: <ouIQerKy4eztpVMUk81sgJ3S5Pl0dWzZ1YmHBKAWIv4=.17d18acf-61d2-41cc-bbec-e0c3e11621d9@github.com>

On Fri, 21 Oct 2022 16:55:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to update the CLDR data from version 41 to version 42. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments to those upstream changes:
> 
> https://unicode-org.atlassian.net/browse/CLDR-14032 (" at " is no longer used for standard date/time format)
> https://unicode-org.atlassian.net/browse/CLDR-14831 (NBSP prefixed to `a`, instead of a normal space )
> https://unicode-org.atlassian.net/browse/CLDR-11510 (Fix first day of week info for China (CN))
> https://unicode-org.atlassian.net/browse/CLDR-15966 (Japanese: Support numbers up to 9999?)
> 
> Here is the link to CLDR v42's release notes: https://cldr.unicode.org/index/downloads/cldr-42

Release notes look good to me.

-------------

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10820


From duke at openjdk.org  Fri Oct 21 21:25:49 2022
From: duke at openjdk.org (Steven R. Loomis)
Date: Fri, 21 Oct 2022 21:25:49 GMT
Subject: RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
Message-ID: <5wDxwNmRqMrWUBsDY7cqbSpQkBzEObD77phocsEsZSI=.d6461367-1ae8-4506-8cfb-98755c35adaf@github.com>

On Fri, 21 Oct 2022 16:55:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to update the CLDR data from version 41 to version 42. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments to those upstream changes:
> 
> https://unicode-org.atlassian.net/browse/CLDR-14032 (" at " is no longer used for standard date/time format)
> https://unicode-org.atlassian.net/browse/CLDR-14831 (NBSP prefixed to `a`, instead of a normal space )
> https://unicode-org.atlassian.net/browse/CLDR-11510 (Fix first day of week info for China (CN))
> https://unicode-org.atlassian.net/browse/CLDR-15966 (Japanese: Support numbers up to 9999?)
> 
> Here is the link to CLDR v42's release notes: https://cldr.unicode.org/index/downloads/cldr-42

hi folks ? looking good??congats on the quick update!

-------------

PR: https://git.openjdk.org/jdk/pull/10820


From alanb at openjdk.org  Sat Oct 22 06:55:56 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 22 Oct 2022 06:55:56 GMT
Subject: RFR: 8295792: Clean up old async close code
In-Reply-To: <5-CnyJPjJxGM6oDpCDRSxfxmFsrmy8o5LefMsCy7KWc=.bb5043ed-518d-47bc-87c1-9e9d0a9bc564@github.com>
References: <5-CnyJPjJxGM6oDpCDRSxfxmFsrmy8o5LefMsCy7KWc=.bb5043ed-518d-47bc-87c1-9e9d0a9bc564@github.com>
Message-ID: <_oAfJnKqgI3kxl6OH8JRAucyEsrCKSdmbeVnbhe0miQ=.c143333b-409e-4e53-87f5-f8c363a740ee@github.com>

On Fri, 21 Oct 2022 14:28:02 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this PR that removes the remains of old fdTable-based socket close synchronization.
> 
> Verified that tier1-3 tests continue to pass on Linux, MacOS and Windows. Did not verify AIX.
> 
> Also removed one slow test for an issue in fdtable implementation; as far as I could tell, it is no longer relevant.

Good cleanup. At some point I think we should put error handling into NET_Wait but not here.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10816


From alanb at openjdk.org  Sat Oct 22 08:17:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 22 Oct 2022 08:17:34 GMT
Subject: RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <FBXs_pNgtpx4EJw32V5_ZKKvG3lFimSlzFNjYCFtGjw=.cebdc098-ab36-44e4-be6d-65a45c314ca1@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
 <mFFAfK2xvTNWv4yeXZOOQCreE9XK57JO0V6yktINOP0=.3a6cc963-94b9-4f8d-8d6b-fb945bef0c0a@github.com>
 <FBXs_pNgtpx4EJw32V5_ZKKvG3lFimSlzFNjYCFtGjw=.cebdc098-ab36-44e4-be6d-65a45c314ca1@github.com>
Message-ID: <vc7i1nf5msiFXtg0UqmvoEe0naETrkY5nIwBwZAwqwI=.1d728264-425d-4873-a69f-b0648c5eb47c@github.com>

On Fri, 21 Oct 2022 19:46:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Yes. These translation changes affect formatting. We don't usually file a CSR for such changes, but cover them in our release notes.

Indeed and periodically CLDR upgrades do cause breakage somewhere, often it will be a library or application tests that compare some result that is outdated due to changes that impact the formatting.

-------------

PR: https://git.openjdk.org/jdk/pull/10820


From duke at openjdk.org  Sat Oct 22 17:59:48 2022
From: duke at openjdk.org (Steven R. Loomis)
Date: Sat, 22 Oct 2022 17:59:48 GMT
Subject: RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <vc7i1nf5msiFXtg0UqmvoEe0naETrkY5nIwBwZAwqwI=.1d728264-425d-4873-a69f-b0648c5eb47c@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
 <mFFAfK2xvTNWv4yeXZOOQCreE9XK57JO0V6yktINOP0=.3a6cc963-94b9-4f8d-8d6b-fb945bef0c0a@github.com>
 <FBXs_pNgtpx4EJw32V5_ZKKvG3lFimSlzFNjYCFtGjw=.cebdc098-ab36-44e4-be6d-65a45c314ca1@github.com>
 <vc7i1nf5msiFXtg0UqmvoEe0naETrkY5nIwBwZAwqwI=.1d728264-425d-4873-a69f-b0648c5eb47c@github.com>
Message-ID: <3h39a2Y21Xh4WUIRBcmMXobOLrhe98C49Enk7kgsNeQ=.7a052b5b-f434-44cf-ae96-729a2993597a@github.com>

On Sat, 22 Oct 2022 08:14:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Yes. These translation changes affect formatting. We don't usually file a CSR for such changes, but cover them in our release notes.
> 
> Indeed and periodically CLDR upgrades do cause breakage somewhere, often it will be a library or application tests that compare some result that is outdated due to changes that impact the formatting.

Yes, although libraries and tests shouldn't be testing against cultural formatting whose goal is to produce the updated best result, not the same result.  For example we had an internal corporate client which needed to use fixed formatting, instead of culturally sensitive formatting, because they really wanted exactly the same output every time, because the output data was going to be consumed by machine and not just by humans.

-------------

PR: https://git.openjdk.org/jdk/pull/10820


From prr at openjdk.org  Sun Oct 23 00:41:09 2022
From: prr at openjdk.org (Phil Race)
Date: Sun, 23 Oct 2022 00:41:09 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <2G8pjhPykplr0Bx7-g8L6F2VMU6TbR_bBwCSotImpNo=.97454d13-1afe-49c9-8441-63cbf1f96496@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
 <ugwrZd3SjXfR7U6fVWnGCxcOUjsX_XvoKwqjFgHcBPU=.47f5b4d8-0ce5-4633-8a3a-7db0801d6338@github.com>
 <2G8pjhPykplr0Bx7-g8L6F2VMU6TbR_bBwCSotImpNo=.97454d13-1afe-49c9-8441-63cbf1f96496@github.com>
Message-ID: <7Xv3WEWo4oo152yiMpD9bKzhaAKJM3jJLp5HbuE44HE=.da915a24-7441-4bfd-beb0-a2b5fea11f74@github.com>

On Fri, 21 Oct 2022 19:06:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Can you please refrain from integrating this while I investigate while this was originally moved?
> 
> sure.

It was moved because it was designed for use by AWT and SOMEHOW during all the reshuffle for the modular JDK in JDK 9 it ended up in base, which doesn't use it and doesn't want it - it belongs in the desktop module.

-------------

PR: https://git.openjdk.org/jdk/pull/10757


From prr at openjdk.org  Sun Oct 23 00:41:10 2022
From: prr at openjdk.org (Phil Race)
Date: Sun, 23 Oct 2022 00:41:10 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <kM7au4SfOdQxSS_s4CvCLxx0U4rqwpbuLPu0-vqunJg=.6e411ab7-bbdc-4d3c-9611-14fb11fd2aaa@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
 <kM7au4SfOdQxSS_s4CvCLxx0U4rqwpbuLPu0-vqunJg=.6e411ab7-bbdc-4d3c-9611-14fb11fd2aaa@github.com>
Message-ID: <sSHqPUKao0r0CWHr5pYumXydGoEHIK2zFhbGroy1nq4=.a57a53fe-e3ec-4c40-8afd-a5bb9c9cbaf7@github.com>

On Thu, 20 Oct 2022 04:15:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".
>
> make/common/modules/LauncherCommon.gmk line 48:
> 
>> 46: LAUNCHER_SRC := $(TOPDIR)/src/java.base/share/native/launcher
>> 47: LAUNCHER_CFLAGS += -I$(TOPDIR)/src/java.base/share/native/launcher \
>> 48:     -I$(TOPDIR)/src/java.desktop/share/native/include \
> 
> This line was added recently, not sure why.

Hmm .. IIRC Alex Zuev said  there is a (closed) native test and adding this was the only way he could make that test work .. 
Now clearly this location no longer makes sense when the file is moved, but someone will need to do something about the test. It needs Alex to chime in here.

-------------

PR: https://git.openjdk.org/jdk/pull/10757


From prr at openjdk.org  Sun Oct 23 01:26:37 2022
From: prr at openjdk.org (Phil Race)
Date: Sun, 23 Oct 2022 01:26:37 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <sSHqPUKao0r0CWHr5pYumXydGoEHIK2zFhbGroy1nq4=.a57a53fe-e3ec-4c40-8afd-a5bb9c9cbaf7@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
 <kM7au4SfOdQxSS_s4CvCLxx0U4rqwpbuLPu0-vqunJg=.6e411ab7-bbdc-4d3c-9611-14fb11fd2aaa@github.com>
 <sSHqPUKao0r0CWHr5pYumXydGoEHIK2zFhbGroy1nq4=.a57a53fe-e3ec-4c40-8afd-a5bb9c9cbaf7@github.com>
Message-ID: <IuMVFpIBKI-gbjDgXfYvv9ZOansGZiiCJIVeOZeSmps=.dabbaa85-6f11-428d-835e-14e729322f23@github.com>

On Sun, 23 Oct 2022 00:36:11 GMT, Phil Race <prr at openjdk.org> wrote:

>> make/common/modules/LauncherCommon.gmk line 48:
>> 
>>> 46: LAUNCHER_SRC := $(TOPDIR)/src/java.base/share/native/launcher
>>> 47: LAUNCHER_CFLAGS += -I$(TOPDIR)/src/java.base/share/native/launcher \
>>> 48:     -I$(TOPDIR)/src/java.desktop/share/native/include \
>> 
>> This line was added recently, not sure why.
>
> Hmm .. IIRC Alex Zuev said  there is a (closed) native test and adding this was the only way he could make that test work .. 
> Now clearly this location no longer makes sense when the file is moved, but someone will need to do something about the test. It needs Alex to chime in here.

Superficially, it looks like the closed test has a direct pointer to where to get this which would need to be re-adjusted
but now I really do need Alex to explain why the above include dir was needed .. since it isn't for the closed test.

-------------

PR: https://git.openjdk.org/jdk/pull/10757


From prr at openjdk.org  Mon Oct 24 03:47:49 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Oct 2022 03:47:49 GMT
Subject: RFR: 8294466: Minimize disabled warnings in java.desktop
In-Reply-To: <yCuRyS186FkEXvCSQJXcCvEa17uq7t9kvlqrCQ3dSoc=.07d5e90d-86b2-4cca-a1c1-baac5bd8651a@github.com>
References: <yCuRyS186FkEXvCSQJXcCvEa17uq7t9kvlqrCQ3dSoc=.07d5e90d-86b2-4cca-a1c1-baac5bd8651a@github.com>
Message-ID: <kDQN9zmu4zJG-L8dnC2-zDyqlz86q-SwMb8t82EPtLY=.06bd4677-4fa5-4549-abe4-6fc28803fc19@github.com>

On Thu, 20 Oct 2022 10:36:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.desktop native libraries.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.
> 
> (This is a reboot of https://github.com/openjdk/jdk/pull/10453)

Looks OK. I mean it still builds, right ? That's the test here.
The only comment is that you established a sort-of precedent of including the 3rd party libs.
But I don't see the harm in the specific cases as these are ones here are ones we rarely update.
Just let's not try to do this for 3rd party libraries where there are lots of warnings across lots of files that change a lot as we update source and/or compiler.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10790


From prr at openjdk.org  Mon Oct 24 03:54:06 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Oct 2022 03:54:06 GMT
Subject: RFR: 8295717: Minimize disabled warnings in accessibility native
 code
In-Reply-To: <V7dSEaZRacw4fFXSL61G9iTPJeQIzKWGEVTnRcda0Qw=.9a53defc-8192-4dab-bce3-98042e284858@github.com>
References: <V7dSEaZRacw4fFXSL61G9iTPJeQIzKWGEVTnRcda0Qw=.9a53defc-8192-4dab-bce3-98042e284858@github.com>
Message-ID: <g83FVheeVcYhiGmEEN3ArdtVZlJO6jnkTdYDeFcn-Tw=.66bb487f-72b0-44a0-9a54-129f021a72d5@github.com>

On Thu, 20 Oct 2022 10:24:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in the accessibility native code.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10788


From prr at openjdk.org  Mon Oct 24 03:54:07 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Oct 2022 03:54:07 GMT
Subject: RFR: 8295717: Minimize disabled warnings in accessibility native
 code
In-Reply-To: <c9QBA0xrPmEhinXsbjBFoys3OA3xzsXHXjRm345RObM=.a1a76b72-1c48-4826-9a78-f42d2cc1b133@github.com>
References: <V7dSEaZRacw4fFXSL61G9iTPJeQIzKWGEVTnRcda0Qw=.9a53defc-8192-4dab-bce3-98042e284858@github.com>
 <ce7zx48PfM_s8PbgHd7AEdYQ3O4mhBcovYe37HMGMkI=.24f69caf-f657-4740-84be-3ebde04cf487@github.com>
 <c9QBA0xrPmEhinXsbjBFoys3OA3xzsXHXjRm345RObM=.a1a76b72-1c48-4826-9a78-f42d2cc1b133@github.com>
Message-ID: <p-U1J7hO70qNrQT35ippHpnxFVPvxmGs195P4e9504o=.9f0c0722-6631-4ee1-a2ba-2b3e3f4ea37f@github.com>

On Thu, 20 Oct 2022 18:56:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/modules/jdk.accessibility/Launcher.gmk line 46:
>> 
>>> 44:           -analyze- -Od -Gd -D_WINDOWS \
>>> 45:           -D_UNICODE -DUNICODE -RTC1 -EHsc, \
>>> 46:       DISABLED_WARNINGS_microsoft_jabswitch.cpp := 4267 4996, \
>> 
>> This lib only has one cpp file, so this change doesn't seem that useful.
>
> Heh, I did not notice that.
> 
> I'd still argue that this is a useful change. If some other file were ever to be added, it will not be covered by the blanked disabled warnings, and -- perhaps more important -- it is clear that these warnings can be addressed just by looking at a single file. This information has drastically increased the likelihood that a developer picks up the issue and actually resolves the warnings, as we have seen in other areas where I've done this "warnings-per-file" transition.

I suspect there's already a "fix disabled warnings in jdk.accessibility" .. can't we just fix that instead ?
I found it : https://bugs.openjdk.org/browse/JDK-8074847
Let me see what I can do about it.

-------------

PR: https://git.openjdk.org/jdk/pull/10788


From prr at openjdk.org  Mon Oct 24 03:54:07 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Oct 2022 03:54:07 GMT
Subject: RFR: 8295717: Minimize disabled warnings in accessibility native
 code
In-Reply-To: <p-U1J7hO70qNrQT35ippHpnxFVPvxmGs195P4e9504o=.9f0c0722-6631-4ee1-a2ba-2b3e3f4ea37f@github.com>
References: <V7dSEaZRacw4fFXSL61G9iTPJeQIzKWGEVTnRcda0Qw=.9a53defc-8192-4dab-bce3-98042e284858@github.com>
 <ce7zx48PfM_s8PbgHd7AEdYQ3O4mhBcovYe37HMGMkI=.24f69caf-f657-4740-84be-3ebde04cf487@github.com>
 <c9QBA0xrPmEhinXsbjBFoys3OA3xzsXHXjRm345RObM=.a1a76b72-1c48-4826-9a78-f42d2cc1b133@github.com>
 <p-U1J7hO70qNrQT35ippHpnxFVPvxmGs195P4e9504o=.9f0c0722-6631-4ee1-a2ba-2b3e3f4ea37f@github.com>
Message-ID: <H8NXj7UEFVMk1BUTdikcfu3F5360ZQEej2IKfwne83Y=.7af6f382-ee69-4651-9367-f60134a97b87@github.com>

On Mon, 24 Oct 2022 03:49:17 GMT, Phil Race <prr at openjdk.org> wrote:

>> Heh, I did not notice that.
>> 
>> I'd still argue that this is a useful change. If some other file were ever to be added, it will not be covered by the blanked disabled warnings, and -- perhaps more important -- it is clear that these warnings can be addressed just by looking at a single file. This information has drastically increased the likelihood that a developer picks up the issue and actually resolves the warnings, as we have seen in other areas where I've done this "warnings-per-file" transition.
>
> I suspect there's already a "fix disabled warnings in jdk.accessibility" .. can't we just fix that instead ?
> I found it : https://bugs.openjdk.org/browse/JDK-8074847
> Let me see what I can do about it.

but I'll approve this anyway .. no harm

-------------

PR: https://git.openjdk.org/jdk/pull/10788


From prr at openjdk.org  Mon Oct 24 03:55:56 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Oct 2022 03:55:56 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <6Nga-zBIoxnexiDJp-uJqSHjkki2U2n6y5WW9chvPz0=.f389c36c-e6bd-4b32-81a2-0304f23ba6a2@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From prr at openjdk.org  Mon Oct 24 04:14:59 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Oct 2022 04:14:59 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
Message-ID: <axHxt2piKk_7MiZ5-QsQ0dS5LCtZ8gqmH8PEqt5eDbw=.29b721e7-3203-44f7-b82e-73490da7fa15@github.com>

On Wed, 19 Oct 2022 08:15:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10757


From kizune at openjdk.org  Mon Oct 24 07:54:17 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 24 Oct 2022 07:54:17 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
Message-ID: <0Gi5fB1CY1d8JmqfK4CFAbgUVR2hnZU6HzB6dTXWKcA=.43008757-c999-4916-b9d6-a08d158787ea@github.com>

On Wed, 19 Oct 2022 08:15:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10757


From kizune at openjdk.org  Mon Oct 24 07:54:17 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 24 Oct 2022 07:54:17 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <IuMVFpIBKI-gbjDgXfYvv9ZOansGZiiCJIVeOZeSmps=.dabbaa85-6f11-428d-835e-14e729322f23@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
 <kM7au4SfOdQxSS_s4CvCLxx0U4rqwpbuLPu0-vqunJg=.6e411ab7-bbdc-4d3c-9611-14fb11fd2aaa@github.com>
 <sSHqPUKao0r0CWHr5pYumXydGoEHIK2zFhbGroy1nq4=.a57a53fe-e3ec-4c40-8afd-a5bb9c9cbaf7@github.com>
 <IuMVFpIBKI-gbjDgXfYvv9ZOansGZiiCJIVeOZeSmps=.dabbaa85-6f11-428d-835e-14e729322f23@github.com>
Message-ID: <5UPlJTdkkTGa39alXzYl1XbkCcEdUhcMxHN56UqfI0Q=.ba6f3139-084d-4c96-ad8c-753ffe046d4c@github.com>

On Sun, 23 Oct 2022 01:22:33 GMT, Phil Race <prr at openjdk.org> wrote:

> Superficially, it looks like the closed test has a direct pointer to where to get this which would need to be re-adjusted

The test has direct link to the include yet i had to add this line so jtreg could find it in the build phase. The fact that it will lead to publishing of this include was not an intentional consequence and it needs to be changed, probably the test should be adjusted later if it will start failing on certain platforms.

-------------

PR: https://git.openjdk.org/jdk/pull/10757


From ihse at openjdk.org  Mon Oct 24 09:56:33 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 09:56:33 GMT
Subject: Integrated: 8294466: Minimize disabled warnings in java.desktop
In-Reply-To: <yCuRyS186FkEXvCSQJXcCvEa17uq7t9kvlqrCQ3dSoc=.07d5e90d-86b2-4cca-a1c1-baac5bd8651a@github.com>
References: <yCuRyS186FkEXvCSQJXcCvEa17uq7t9kvlqrCQ3dSoc=.07d5e90d-86b2-4cca-a1c1-baac5bd8651a@github.com>
Message-ID: <Y3oi5L299DW3b9SDkBFd7lpq7sPpP0tZ9K16lRePWDU=.17a49df9-2013-414b-b742-3a80a1178528@github.com>

On Thu, 20 Oct 2022 10:36:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.desktop native libraries.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.
> 
> (This is a reboot of https://github.com/openjdk/jdk/pull/10453)

This pull request has now been integrated.

Changeset: 74606614
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/74606614e0a2e81dadf27e20028055f6305e2ac4
Stats:     100 lines in 2 files changed: 43 ins; 18 del; 39 mod

8294466: Minimize disabled warnings in java.desktop

Reviewed-by: erikj, prr

-------------

PR: https://git.openjdk.org/jdk/pull/10790


From jwaters at openjdk.org  Mon Oct 24 09:59:45 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 24 Oct 2022 09:59:45 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <7Xv3WEWo4oo152yiMpD9bKzhaAKJM3jJLp5HbuE44HE=.da915a24-7441-4bfd-beb0-a2b5fea11f74@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
 <ugwrZd3SjXfR7U6fVWnGCxcOUjsX_XvoKwqjFgHcBPU=.47f5b4d8-0ce5-4633-8a3a-7db0801d6338@github.com>
 <2G8pjhPykplr0Bx7-g8L6F2VMU6TbR_bBwCSotImpNo=.97454d13-1afe-49c9-8441-63cbf1f96496@github.com>
 <7Xv3WEWo4oo152yiMpD9bKzhaAKJM3jJLp5HbuE44HE=.da915a24-7441-4bfd-beb0-a2b5fea11f74@github.com>
Message-ID: <pB_OwiUeUqvYMEJQjh8yMg0gSSo9t00nJLamm5A9NaQ=.bbaee8b1-fd2a-4fba-a7c7-08e19c8b88bb@github.com>

On Sun, 23 Oct 2022 00:37:55 GMT, Phil Race <prr at openjdk.org> wrote:

> > > Can you please refrain from integrating this while I investigate while this was originally moved?
> > 
> > 
> > sure.
> 
> It was moved because it was designed for use by AWT and SOMEHOW during all the reshuffle for the modular JDK in JDK 9 it ended up in base, which doesn't use it and doesn't want it - it belongs in the desktop module.

I guess that explains why I was so confused when I found this in java.base and thought it was a codebase wide utility, except that I couldn't find it being used anywhere else other than java.desktop :P

-------------

PR: https://git.openjdk.org/jdk/pull/10757


From ihse at openjdk.org  Mon Oct 24 10:05:54 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 10:05:54 GMT
Subject: Integrated: 8295717: Minimize disabled warnings in accessibility
 native code
In-Reply-To: <V7dSEaZRacw4fFXSL61G9iTPJeQIzKWGEVTnRcda0Qw=.9a53defc-8192-4dab-bce3-98042e284858@github.com>
References: <V7dSEaZRacw4fFXSL61G9iTPJeQIzKWGEVTnRcda0Qw=.9a53defc-8192-4dab-bce3-98042e284858@github.com>
Message-ID: <yd-Fa-c09Yg7Bs4rQaO4D9QEuttASSM4KHKgjJ2z8r8=.f650aa21-4e1b-4144-979d-eb371de62957@github.com>

On Thu, 20 Oct 2022 10:24:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in the accessibility native code.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.

This pull request has now been integrated.

Changeset: 7a49c9ba
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7a49c9baa1d4ad7df90e7ca626ec48ba76881822
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8295717: Minimize disabled warnings in accessibility native code

Reviewed-by: erikj, prr

-------------

PR: https://git.openjdk.org/jdk/pull/10788


From aivanov at openjdk.org  Mon Oct 24 10:17:56 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 24 Oct 2022 10:17:56 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
Message-ID: <_lQB8faV1GqMi881H0wr45_2kkYS3j9xQRD3oao2N2k=.4f81ca75-b27c-4c7b-a5fc-c5d378058901@github.com>

On Wed, 19 Oct 2022 08:15:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10757


From djelinski at openjdk.org  Mon Oct 24 15:30:17 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 24 Oct 2022 15:30:17 GMT
Subject: Integrated: 8295792: Clean up old async close code
In-Reply-To: <5-CnyJPjJxGM6oDpCDRSxfxmFsrmy8o5LefMsCy7KWc=.bb5043ed-518d-47bc-87c1-9e9d0a9bc564@github.com>
References: <5-CnyJPjJxGM6oDpCDRSxfxmFsrmy8o5LefMsCy7KWc=.bb5043ed-518d-47bc-87c1-9e9d0a9bc564@github.com>
Message-ID: <xzE3Jqj8bJZktJHFS_KWtl77_vJVCZJBSfMILvBVAoA=.c922722c-2c6c-4be5-91c8-4cc1891a8512@github.com>

On Fri, 21 Oct 2022 14:28:02 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this PR that removes the remains of old fdTable-based socket close synchronization.
> 
> Verified that tier1-3 tests continue to pass on Linux, MacOS and Windows. Did not verify AIX.
> 
> Also removed one slow test for an issue in fdtable implementation; as far as I could tell, it is no longer relevant.

This pull request has now been integrated.

Changeset: 2f3f3b61
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2f3f3b618500b5f112fabca30d4c6780b2a8e723
Stats:     1159 lines in 12 files changed: 0 ins; 1155 del; 4 mod

8295792: Clean up old async close code

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/10816


From naoto at openjdk.org  Mon Oct 24 15:52:38 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Oct 2022 15:52:38 GMT
Subject: Integrated: 8284840: Update CLDR to Version 42.0
In-Reply-To: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
Message-ID: <8rhViPJXiQ9dJKOsX7pQaNU4YbABVGT0vUFbU38vI3o=.a26bd3d6-51d7-4960-bdf0-aaffef5ff474@github.com>

On Fri, 21 Oct 2022 16:55:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to update the CLDR data from version 41 to version 42. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments to those upstream changes:
> 
> https://unicode-org.atlassian.net/browse/CLDR-14032 (" at " is no longer used for standard date/time format)
> https://unicode-org.atlassian.net/browse/CLDR-14831 (NBSP prefixed to `a`, instead of a normal space )
> https://unicode-org.atlassian.net/browse/CLDR-11510 (Fix first day of week info for China (CN))
> https://unicode-org.atlassian.net/browse/CLDR-15966 (Japanese: Support numbers up to 9999?)
> 
> Here is the link to CLDR v42's release notes: https://cldr.unicode.org/index/downloads/cldr-42

This pull request has now been integrated.

Changeset: 5b3de6e1
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5b3de6e143e370272c36383adac3e31f359bc686
Stats:     99164 lines in 377 files changed: 68223 ins; 2820 del; 28121 mod

8284840: Update CLDR to Version 42.0

Reviewed-by: erikj, iris, joehw

-------------

PR: https://git.openjdk.org/jdk/pull/10820


From ihse at openjdk.org  Mon Oct 24 19:21:07 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:21:07 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v3]
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Revert "Remove check for .properties from jcheck"
   
   This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
 - Change trailing space and tab in values to unicode encoding

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10792/files
  - new: https://git.openjdk.org/jdk/pull/10792/files/c91fdaa1..f4f94341

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=01-02

  Stats: 412 lines in 131 files changed: 0 ins; 0 del; 412 mod
  Patch: https://git.openjdk.org/jdk/pull/10792.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10792/head:pull/10792

PR: https://git.openjdk.org/jdk/pull/10792


From angorya at openjdk.org  Mon Oct 24 19:22:38 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:22:38 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <2dP1ZXi79c3PWdvTChCcuX8a4PFkig06K606SgaQDoM=.662f6b1b-a325-4270-84c5-446696faa73f@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

368 files to review!  I wish we had separate PRs for fixing properties and checking for trailing whitespace.  i 'd expect it will take some time to review localization, unless we just keep them as is.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From ihse at openjdk.org  Mon Oct 24 19:25:38 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:25:38 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <yZpwsDUeKIrGQT3tvyGfGHFjIOuQTOBfRyvV7b-uArA=.077497ab-51b8-4346-b67d-9838e3419964@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

I agree, that was an excellent idea Naoto! In my last commit, I have converted all trailing spaces/tabs in value lines into explicit unicode characters. Since that means we have no trailing spaces (from a jcheck perspective), I could also restore the jcheck that was the original driver behind this bug. (And also restore the bug/PR title to show the original intent.)

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From ihse at openjdk.org  Mon Oct 24 19:31:26 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:31:26 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v2]
In-Reply-To: <2dP1ZXi79c3PWdvTChCcuX8a4PFkig06K606SgaQDoM=.662f6b1b-a325-4270-84c5-446696faa73f@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
 <2dP1ZXi79c3PWdvTChCcuX8a4PFkig06K606SgaQDoM=.662f6b1b-a325-4270-84c5-446696faa73f@github.com>
Message-ID: <HmB2uBGv-fQnz3Kn7yEA0yIR4akDfM4tmso3sgA4-aQ=.d84de722-5d04-4aad-8ba3-572eea3cacc1@github.com>

On Mon, 24 Oct 2022 19:20:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove check for .properties from jcheck
>>  - Restore trailing whitespace for property values
>
> 368 files to review!  I wish we had separate PRs for fixing properties and checking for trailing whitespace.  i 'd expect it will take some time to review localization, unless we just keep them as is.

@andy-goryachev-oracle They are all automatically processed. There are two kinds of changes: Non-value lines have their trailing whitespace removed. You can verify that part of the PR by looking here: https://github.com/openjdk/jdk/pull/10792/files/c91fdaa19dc06351598bd1c0614e1af3bfa08ae2

This was the state of the PR as of three days ago. The most numerous number of changed files are here, but you can just scroll through the change and verify quickly that it is trivial.

The second change is the one suggested by Naoti; I have replaced all trailing tabs (there were just one) with `\u0009` and all trailing spaces with `\u0020`. That part was just pushed by me now. You can see that part separately here: https://github.com/openjdk/jdk/pull/10792/commits/a509b90f1b7f833924493fbd28b3cbb1a85c1f21

This affects far fewer files. And once again, it was mechanically generated. You can once again just scroll through and verify that all changes are due to the trailing whitespace being converted to unicode sequences.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From angorya at openjdk.org  Mon Oct 24 19:45:01 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

Started looking at whether certain trailing spaces can be (and/or should be) removed, but it quickly became apparent that we should just keep these properties as is (with the unicode escapes), rather than risk regression.

src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties line 187:

> 185: ### Button Demo ###
> 186: 
> 187: ButtonDemo.accessible_description=ButtonDemo\u3067\u306F\u3001JButton\u3001JRadioButton\u3001JToggleButton\u304A\u3088\u3073JCheckBox\u306E\u4F7F\u7528\u4F8B\u3092\u7D39\u4ECB\u3057\u307E\u3059\u0020

trailing whitespace looks unnecessary (accessible description?)

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Fehler beim Umbenennen von Datei oder Ordner
> 66: FileChooser.renameError.textAndMnemonic={0} kann nicht umbenannt werden
> 67: FileChooser.renameErrorFileExists.textAndMnemonic={0} kann nicht umbenannt werden: Es ist bereits eine Datei mit dem angegebenen Namen vorhanden. Geben Sie einen anderen Dateinamen an.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Error al cambiar el nombre del archivo o carpeta
> 66: FileChooser.renameError.textAndMnemonic=No se puede cambiar el nombre de {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=No se puede cambiar el nombre de {0}: ya existe un archivo con el nombre especificado. Especifique otro nombre de archivo.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Erreur lors du changement de nom du fichier ou du dossier
> 66: FileChooser.renameError.textAndMnemonic=Impossible de renommer {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=Impossible de renommer {0} : il existe d\u00E9j\u00E0 un fichier portant le nom indiqu\u00E9. Indiquez-en un autre.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Errore durante la ridenominazione del file o della cartella
> 66: FileChooser.renameError.textAndMnemonic=Impossibile rinominare {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=Impossibile rinominare {0}: esiste gi\u00E0 un file con il nome specificato. Specificare un altro nome.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=\u30D5\u30A1\u30A4\u30EB\u307E\u305F\u306F\u30D5\u30A9\u30EB\u30C0\u306E\u540D\u524D\u5909\u66F4\u30A8\u30E9\u30FC
> 66: FileChooser.renameError.textAndMnemonic={0}\u306E\u540D\u524D\u3092\u5909\u66F4\u3067\u304D\u307E\u305B\u3093
> 67: FileChooser.renameErrorFileExists.textAndMnemonic={0}\u306E\u540D\u524D\u3092\u5909\u66F4\u3067\u304D\u307E\u305B\u3093: \u6307\u5B9A\u3057\u305F\u540D\u524D\u306E\u30D5\u30A1\u30A4\u30EB\u306F\u3059\u3067\u306B\u5B58\u5728\u3057\u307E\u3059\u3002\u5225\u306E\u30D5\u30A1\u30A4\u30EB\u540D\u3092\u6307\u5B9A\u3057\u3066\u304F\u3060\u3055\u3044\u3002\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Ett fel intr\u00E4ffade vid f\u00F6rs\u00F6k att \u00E4ndra namn p\u00E5 fil eller mapp
> 66: FileChooser.renameError.textAndMnemonic=Kan inte namn\u00E4ndra {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=Kan inte namn\u00E4ndra {0}: En fil med angivet namn finns redan. Ange ett annat filnamn.\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 44:

> 42: cachedrowsetimpl.floatfail = getFloat failed on value ( {0} ) in column {1}
> 43: cachedrowsetimpl.doublefail = getDouble failed on value ( {0} ) in column {1}
> 44: cachedrowsetimpl.dtypemismt = Data Type Mismatch\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 73:

> 71: cachedrowsetimpl.numrows = Number of rows is less than zero or less than fetch size
> 72: cachedrowsetimpl.startpos = Start position cannot be negative
> 73: cachedrowsetimpl.nextpage = Populate data before calling\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 87:

> 85: 
> 86: #FilteredRowSetImpl exceptions
> 87: filteredrowsetimpl.relative = relative : Invalid cursor operation\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 128:

> 126: crswriter.params1 = Value of params1 : {0}\u0020
> 127: crswriter.params2 = Value of params2 : {0}\u0020
> 128: crswriter.conflictsno =  conflicts while synchronizing\u0020

this is tricky.  if this value is a part of a sentence (i.e. something like "5 conflicts..."), the localization is likely to be wrong.  it's hard to tell without looking further into the code.

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 134:

> 132: 
> 133: #SyncResolverImpl exceptions
> 134: syncrsimpl.indexval = Index value out of range\u0020\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 44:

> 42: cachedrowsetimpl.floatfail = getFloat bei Wert ( {0} ) in Spalte {1} nicht erfolgreich
> 43: cachedrowsetimpl.doublefail = getDouble bei Wert ( {0} ) in Spalte {1} nicht erfolgreich
> 44: cachedrowsetimpl.dtypemismt = Keine Datentyp\u00FCbereinstimmung\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 73:

> 71: cachedrowsetimpl.numrows = Zeilenanzahl ist kleiner als null oder kleiner als Abrufgr\u00F6\u00DFe
> 72: cachedrowsetimpl.startpos = Startposition darf keinen Negativwert aufweisen
> 73: cachedrowsetimpl.nextpage = Daten m\u00FCssen vor dem Aufruf ausgef\u00FCllt werden\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 87:

> 85: 
> 86: #FilteredRowSetImpl exceptions
> 87: filteredrowsetimpl.relative = relative: Ung\u00FCltiger Cursorvorgang\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 134:

> 132: 
> 133: #SyncResolverImpl exceptions
> 134: syncrsimpl.indexval = Indexwert liegt au\u00DFerhalb des Bereichs\u0020\u0020

prob. unnecessary

-------------

Marked as reviewed by angorya (no project role).

PR: https://git.openjdk.org/jdk/pull/10792


From ihse at openjdk.org  Mon Oct 24 19:45:01 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <Htn9EBt6AF3tlWd7t1gt23Li4UwB2P5haoCA4hfFD3g=.601d90e0-c4ec-43e1-9828-beaf4943f00c@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

For the files which have trailing "whitespace" (now as unicode sequences), I will file follow-up bugs on the respective components to verify if this is indeed correct, or a bug that should be fixed. I did not think it was a good idea to hold this PR, waiting for component teams to do the whitespace check first, for two reasons:

1) Now the trailing whitespace will be obvious, and any intended whitespace will not be accidentally stripped by an editor, so it will be easier for engineers to fix any problems.

2) I know from experience that this kind of cleaning-up has a very low priority for many engineers. If this PR were dependent on all JDK groups going through their properties files, it would basically never be closed.

And finally: Here is a complete list of the files which has trailing "unicode whitespace" in values. I will try to figure out to which components these belongs and open corresponding bugs.


src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties
src/demo/share/jfc/SwingSet2/resources/swingset_zh_CN.properties
src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_zh_CN.properties
src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_zh_TW.properties
src/java.desktop/share/classes/com/sun/imageio/plugins/common/iio-plugin.properties
src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_CN.properties
src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_it.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_CN.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_TW.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_CN.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_TW.properties
src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties
src/java.desktop/share/classes/sun/print/resources/serviceui_zh_TW.properties
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_TW.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_TW.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_CN.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_de.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_ja.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_zh_CN.properties
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_ja.properties
src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_de.properties
src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties
src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_de.properties
src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_ja.properties
src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_zh_CN.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_ja.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_zh_CN.properties
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_ja.properties
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_zh_CN.properties
src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_de.properties
src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_sv.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_de.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_es.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_fr.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_it.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ja.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_pt_BR.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_sv.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_CN.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_TW.properties
test/jdk/javax/net/ssl/Stapling/TEST.properties
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filechooser/resources/FileChooserDemo.properties
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/TableDemo.properties
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/togglebutton/resources/ToggleButtonDemo.properties
test/jdk/tools/jmod/src/foo/jdk/test/foo/resources/foo.properties

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From jjg at openjdk.org  Mon Oct 24 19:45:01 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <NfKRwZk2cASJZIeh2KYBJMAy7FTuIm87YyXzt8CT0X4=.767db538-3861-4555-b621-4e65c68e26ef@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

I think it would be better to try and remove incidental trailing whitespace first, before encoding any remaining whitespace. Hiding the trailing whitespace as a Unicode escape seems like a bad idea, equivalent to sweeping the issue under the rug. While I agree with the goals of improving the check, I think this is going about it the wrong way, or at least in the wrong order.

Maybe it would be a good idea to first validate the default/English files, checking for incidental whitespace there, then check localized versions of each property against the English version.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From angorya at openjdk.org  Mon Oct 24 19:45:01 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <Htn9EBt6AF3tlWd7t1gt23Li4UwB2P5haoCA4hfFD3g=.601d90e0-c4ec-43e1-9828-beaf4943f00c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <Htn9EBt6AF3tlWd7t1gt23Li4UwB2P5haoCA4hfFD3g=.601d90e0-c4ec-43e1-9828-beaf4943f00c@github.com>
Message-ID: <cuJYgquzi3I4fULUZZz_G_ZjmEd_wDsUPw2mzCceM_w=.ad366bc4-db7f-48ad-9d3f-a8d0ba9e1820@github.com>

On Mon, 24 Oct 2022 19:34:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> For the files which have trailing "whitespace" (now as unicode sequences), I will file follow-up bugs on the respective components to verify if this is indeed correct, or a bug that should be fixed.

probably not needed - if nobody noticed anything until now we have no problem.  the solution to escape whitespace in values is the right solution, solves both the jcheck and WS visibility issues.

good job!

(and we can ignore my "prob. unnecessary" comments)

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From angorya at openjdk.org  Mon Oct 24 19:45:02 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:45:02 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
Message-ID: <cRpIep8vLpUKvRQH3e_vwTIqVChg5uSLhFH4sSCbmOQ=.9c8e6492-c665-4666-bba9-4947cd6059b1@github.com>

On Mon, 24 Oct 2022 19:23:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert "Remove check for .properties from jcheck"
>>    
>>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>>  - Change trailing space and tab in values to unicode encoding
>
> src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties line 187:
> 
>> 185: ### Button Demo ###
>> 186: 
>> 187: ButtonDemo.accessible_description=ButtonDemo\u3067\u306F\u3001JButton\u3001JRadioButton\u3001JToggleButton\u304A\u3088\u3073JCheckBox\u306E\u4F7F\u7528\u4F8B\u3092\u7D39\u4ECB\u3057\u307E\u3059\u0020
> 
> trailing whitespace looks unnecessary (accessible description?)

although this is in demo...

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From jjg at openjdk.org  Mon Oct 24 19:50:43 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 24 Oct 2022 19:50:43 GMT
Subject: RFR: 8295653: Add a graph of the sealed class hierarchy for marked
 classes [v2]
In-Reply-To: <HesqaFYWAlswM8GiQW0Fn3jZSyP_kTA4UHgX-OjE4uY=.dcab4fe1-c5a0-4265-a65e-476106c0f359@github.com>
References: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
 <HesqaFYWAlswM8GiQW0Fn3jZSyP_kTA4UHgX-OjE4uY=.dcab4fe1-c5a0-4265-a65e-476106c0f359@github.com>
Message-ID: <c71H7ExP19TmUr0eLKfiWvVQzDiNqahjcs4zW_XMBkQ=.19535b75-2ace-487c-8b7a-67eae38ab0d4@github.com>

On Thu, 20 Oct 2022 11:13:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> It would be possible to mark classes with `@sealedGraph` to indicate that the sealed hierarchy should be rendered graphically in the JavaDocs. Classes not marked would be unaffected, creating an opt-in approach.
>> 
>> [Here](https://bugs.openjdk.org/secure/attachment/101126/Screen%20Shot%202022-10-19%20at%2012.47.47%20PM.png) is an example of MemoryLayout class rendering.
>> 
>> This feature has been developed in cooperation with Per Minborg.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix styleheet

make/jdk/src/classes/build/tools/taglet/SealedGraph.java line 49:

> 47: public final class SealedGraph implements Taglet {
> 48:     private static final String sealedGraphDotPath =
> 49:             System.getProperty("sealedGraphDotPath");

Generally, there is strong correlation between the module graph support and the sealed graph support, which is good, and helpful.   This system property is an outlier. For consistency with the world of module graphs, it should be `enableSealedGraph` or something like that.  Related: a change in the property name here will require a corresponding update in the makefiles.

-------------

PR: https://git.openjdk.org/jdk/pull/10761


From jjg at openjdk.org  Mon Oct 24 19:56:09 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 24 Oct 2022 19:56:09 GMT
Subject: RFR: 8295653: Add a graph of the sealed class hierarchy for marked
 classes [v2]
In-Reply-To: <HesqaFYWAlswM8GiQW0Fn3jZSyP_kTA4UHgX-OjE4uY=.dcab4fe1-c5a0-4265-a65e-476106c0f359@github.com>
References: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
 <HesqaFYWAlswM8GiQW0Fn3jZSyP_kTA4UHgX-OjE4uY=.dcab4fe1-c5a0-4265-a65e-476106c0f359@github.com>
Message-ID: <VgEFVA8-3Utr5v6riagGntzmcjy85Nf1PP8qaJ_dIQE=.e613d929-0bce-4dbe-8fad-a19a362c0b67@github.com>

On Thu, 20 Oct 2022 11:13:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> It would be possible to mark classes with `@sealedGraph` to indicate that the sealed hierarchy should be rendered graphically in the JavaDocs. Classes not marked would be unaffected, creating an opt-in approach.
>> 
>> [Here](https://bugs.openjdk.org/secure/attachment/101126/Screen%20Shot%202022-10-19%20at%2012.47.47%20PM.png) is an example of MemoryLayout class rendering.
>> 
>> This feature has been developed in cooperation with Per Minborg.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix styleheet

make/jdk/src/classes/build/tools/taglet/SealedGraph.java line 93:

> 91:                 .map(ModuleElement.ExportsDirective.class::cast)
> 92:                 // Only include packages that are globally exported (i.e. no "to" exports)
> 93:                 .filter(me -> me.getTargetModules() == null)

The lambda parameter here is an `ExportsDirective`, not a `ModuleElement`, suggesting that the name here should be `ed` instead of `me`.

make/jdk/src/classes/build/tools/taglet/SealedGraph.java line 182:

> 180:                         .append(lineSeparator())
> 181:                         .append("  rankdir=\"BT\";")
> 182:                         .append(lineSeparator());

Note to future selves: if we come up with Yet Another Kind of Graph, we should consider creating a `DotBuilder` class to share/simplify the code.

-------------

PR: https://git.openjdk.org/jdk/pull/10761


From naoto at openjdk.org  Mon Oct 24 20:02:54 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Oct 2022 20:02:54 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

The problem here is that all those (unnecessary) trailing spaces are appended by the external translators, who are not aware those spaces should not be at the end. I think what we can do is check the original English properties values that the engineers provided, and if there is no trailing spaces there, we can safely remove trailing spaces in localized bundles.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From jjg at openjdk.org  Mon Oct 24 20:09:05 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 24 Oct 2022 20:09:05 GMT
Subject: RFR: 8295653: Add a graph of the sealed class hierarchy for marked
 classes [v2]
In-Reply-To: <HesqaFYWAlswM8GiQW0Fn3jZSyP_kTA4UHgX-OjE4uY=.dcab4fe1-c5a0-4265-a65e-476106c0f359@github.com>
References: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
 <HesqaFYWAlswM8GiQW0Fn3jZSyP_kTA4UHgX-OjE4uY=.dcab4fe1-c5a0-4265-a65e-476106c0f359@github.com>
Message-ID: <e2O24eRPqrl1KIUVq9jmx157bLzRp2mWNl1GXXgM8m4=.3ecad4fa-58b4-49a0-b5b0-c4581cc0a50b@github.com>

On Thu, 20 Oct 2022 11:13:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> It would be possible to mark classes with `@sealedGraph` to indicate that the sealed hierarchy should be rendered graphically in the JavaDocs. Classes not marked would be unaffected, creating an opt-in approach.
>> 
>> [Here](https://bugs.openjdk.org/secure/attachment/101126/Screen%20Shot%202022-10-19%20at%2012.47.47%20PM.png) is an example of MemoryLayout class rendering.
>> 
>> This feature has been developed in cooperation with Per Minborg.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix styleheet

make/jdk/src/classes/build/tools/taglet/SealedGraph.java line 49:

> 47: public final class SealedGraph implements Taglet {
> 48:     private static final String sealedGraphDotPath =
> 49:             System.getProperty("sealedGraphDotPath");

The naming and use is slightly off here.

1. It names the _directory_ in which the graph `.dot` file will be placed. It's not a path for the `.dot` file itself.
2. it does double-duty as the equivalent of `enableModuleGraph` in the module graphs world.

make/jdk/src/classes/build/tools/taglet/SealedGraph.java line 86:

> 84: 
> 85:         ModuleElement module = docletEnvironment.getElementUtils().getModuleOf(element);
> 86:         File dotFile = new File(sealedGraphDotPath,

These days, it is preferable to use  NIO, so use `Path` instead of `File`.

-------------

PR: https://git.openjdk.org/jdk/pull/10761


From ihse at openjdk.org  Mon Oct 24 20:09:50 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 20:09:50 GMT
Subject: RFR: 8295663 Rephrased introduction to testing
In-Reply-To: <NYn97U2N6hxYHvAu0esVWTqOai7KCLCtjf_eVWMe5_Y=.a4a07df3-5352-4818-bb4c-e068169174a8@github.com>
References: <NYn97U2N6hxYHvAu0esVWTqOai7KCLCtjf_eVWMe5_Y=.a4a07df3-5352-4818-bb4c-e068169174a8@github.com>
Message-ID: <9uaHVpCEgHXXD9Bf9abXpF2cAS5L1G1mGFP5FU6P0CE=.1e4f88cf-1cb8-419a-a9cb-06597da32525@github.com>

On Wed, 19 Oct 2022 13:57:59 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> Old one made little sense for a new reader

Looks good. Thank you!

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10763


From ihse at openjdk.org  Mon Oct 24 20:09:54 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 20:09:54 GMT
Subject: RFR: 8287754: Update jib GNU make dependency on Windows to latest
 cygwin build
In-Reply-To: <oYCgCpczrN2XziQtYlk4fa2RldjtWauzUnfg_1bFnkA=.67c9b89c-3aca-49c2-85c8-e7d273c6803a@github.com>
References: <oYCgCpczrN2XziQtYlk4fa2RldjtWauzUnfg_1bFnkA=.67c9b89c-3aca-49c2-85c8-e7d273c6803a@github.com>
Message-ID: <hubFTHx_K4CO8qC3EhxpVtwMecEC872AQsjfPdKsdxU=.713f3a50-ac8a-46b3-abe9-906feb7d2b0a@github.com>

On Thu, 20 Oct 2022 21:49:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> For Oracle internal builds we control the version of GNU Make (currently fixed at 4.0). In Cygwin this is causing problems as the now rather dated GNU Make binary we use isn't compatible with Cygwin.dll version 3.3 or later. To work around this, I'm making the dependency dynamic on the version of Cygwin. If the currently running Cygwin is new enough, the dependency will be on GNU make 4.3.

Thanks for fixing this!

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10805


From ihse at openjdk.org  Mon Oct 24 20:10:37 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 20:10:37 GMT
Subject: RFR: 8295847: slow debug build error after JDK-8294466
Message-ID: <VULVvQOFDUv8pyKsFSyKAt6oREnekM8nYok3cDFvM8s=.d1efbd0d-81ad-421b-beb2-fe6519ef1944@github.com>

[JDK-8294466](https://bugs.openjdk.org/browse/JDK-8294466) trimmed down the set of disabled warnings. Unfortunately it turned out that running slowdebug on linux on Oracle's CI triggered yet another warning in libsplashscreen.

-------------

Commit messages:
 - 8295847: slow debug build error after JDK-8294466

Changes: https://git.openjdk.org/jdk/pull/10840/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10840&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295847
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10840.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10840/head:pull/10840

PR: https://git.openjdk.org/jdk/pull/10840


From angorya at openjdk.org  Mon Oct 24 20:12:02 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 20:12:02 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>
Message-ID: <UGwHhd4Lxgkb_fq1J0eFrNEIfXB8or2LRrWrfOBiuh0=.2266fe08-f382-4bb0-9c2c-fd80a2e2ae26@github.com>

On Mon, 24 Oct 2022 19:58:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> I think what we can do is check the original English properties values that the engineers provided, and if there is no trailing spaces there, we can safely remove trailing spaces in localized bundles.

Good idea! I wonder if this should be done as a unit test.  go through all the bundles and check leading/trailing whitespace.

in my experience, the translators also (unintentionally) change the quotes and other symbols, sometimes breaking the code.  I assume the JDK has been exhaustively tested and we have no such problems.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From serb at openjdk.org  Mon Oct 24 20:13:56 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 24 Oct 2022 20:13:56 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
Message-ID: <ycafUWpULayyM3u5G4rWqfUNbqlVJlHErqaL174ZsZE=.6e8de870-8781-480e-acb1-fb2eb4c9b62d@github.com>

On Wed, 19 Oct 2022 08:15:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".

I suggest to disable that test, if it builds during the jdk build as part of test bundle it may cause the whole jdk build to fail in mach5.

-------------

PR: https://git.openjdk.org/jdk/pull/10757


From ihse at openjdk.org  Mon Oct 24 20:14:04 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 20:14:04 GMT
Subject: RFR: 8295653: Add a graph of the sealed class hierarchy for marked
 classes [v2]
In-Reply-To: <e2O24eRPqrl1KIUVq9jmx157bLzRp2mWNl1GXXgM8m4=.3ecad4fa-58b4-49a0-b5b0-c4581cc0a50b@github.com>
References: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
 <HesqaFYWAlswM8GiQW0Fn3jZSyP_kTA4UHgX-OjE4uY=.dcab4fe1-c5a0-4265-a65e-476106c0f359@github.com>
 <e2O24eRPqrl1KIUVq9jmx157bLzRp2mWNl1GXXgM8m4=.3ecad4fa-58b4-49a0-b5b0-c4581cc0a50b@github.com>
Message-ID: <S5Evu0OCSGvDVV3rumCM6IDB3dBt6fIBDiRmc3UI2lg=.cbf7bd09-b2e7-43cd-a0cd-785e589e56d4@github.com>

On Mon, 24 Oct 2022 20:05:51 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix styleheet
>
> make/jdk/src/classes/build/tools/taglet/SealedGraph.java line 49:
> 
>> 47: public final class SealedGraph implements Taglet {
>> 48:     private static final String sealedGraphDotPath =
>> 49:             System.getProperty("sealedGraphDotPath");
> 
> The naming and use is slightly off here.
> 
> 1. It names the _directory_ in which the graph `.dot` file will be placed. It's not a path for the `.dot` file itself.
> 2. it does double-duty as the equivalent of `enableModuleGraph` in the module graphs world.

Would `sealedDotOutputDir` be ok? I think 2. will kind of follow from the fact that it is specified. Otherwise we could do like `enableSealedDotOutputInDir` but I think that's getting too verbose. And having two different properties just because of naming makes no sense, since then we need to start checking that they are consistent.

> make/jdk/src/classes/build/tools/taglet/SealedGraph.java line 182:
> 
>> 180:                         .append(lineSeparator())
>> 181:                         .append("  rankdir=\"BT\";")
>> 182:                         .append(lineSeparator());
> 
> Note to future selves: if we come up with Yet Another Kind of Graph, we should consider creating a `DotBuilder` class to share/simplify the code.

There is a dot-build for the ModuleGraph, but it makes a lot of assumptions about what kind of graph it is generating. I tried using that instead first, but it led to too much cludgy code, or too wide refactorings.

-------------

PR: https://git.openjdk.org/jdk/pull/10761


From naoto at openjdk.org  Mon Oct 24 20:16:56 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Oct 2022 20:16:56 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <UGwHhd4Lxgkb_fq1J0eFrNEIfXB8or2LRrWrfOBiuh0=.2266fe08-f382-4bb0-9c2c-fd80a2e2ae26@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>
 <UGwHhd4Lxgkb_fq1J0eFrNEIfXB8or2LRrWrfOBiuh0=.2266fe08-f382-4bb0-9c2c-fd80a2e2ae26@github.com>
Message-ID: <go6bwGp8ro_LeVwOJyBes4PXwMBEGNyPvq43vxGmmLU=.ed6bfa15-4664-41ab-87a9-51609382b9cf@github.com>

On Mon, 24 Oct 2022 20:08:02 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Good idea! I wonder if this should be done as a unit test. go through all the bundles and check leading/trailing whitespace.

Right. Definitely not a job for `jcheck`, but it should be considered somewhere in the l10n process.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From erikj at openjdk.org  Mon Oct 24 20:20:58 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 24 Oct 2022 20:20:58 GMT
Subject: RFR: 8295847: slow debug build error after JDK-8294466
In-Reply-To: <VULVvQOFDUv8pyKsFSyKAt6oREnekM8nYok3cDFvM8s=.d1efbd0d-81ad-421b-beb2-fe6519ef1944@github.com>
References: <VULVvQOFDUv8pyKsFSyKAt6oREnekM8nYok3cDFvM8s=.d1efbd0d-81ad-421b-beb2-fe6519ef1944@github.com>
Message-ID: <OahuneiEPxvykhKOspYH6VTgNvvQa9armHvAOl34Ajk=.541a6a0f-b488-4360-b3bf-c0db456ce397@github.com>

On Mon, 24 Oct 2022 20:01:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8294466](https://bugs.openjdk.org/browse/JDK-8294466) trimmed down the set of disabled warnings. Unfortunately it turned out that running slowdebug on linux on Oracle's CI triggered yet another warning in libsplashscreen.

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10840


From dcubed at openjdk.org  Mon Oct 24 20:20:58 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 24 Oct 2022 20:20:58 GMT
Subject: RFR: 8295847: slow debug build error after JDK-8294466
In-Reply-To: <VULVvQOFDUv8pyKsFSyKAt6oREnekM8nYok3cDFvM8s=.d1efbd0d-81ad-421b-beb2-fe6519ef1944@github.com>
References: <VULVvQOFDUv8pyKsFSyKAt6oREnekM8nYok3cDFvM8s=.d1efbd0d-81ad-421b-beb2-fe6519ef1944@github.com>
Message-ID: <fqR_eIlJQpQHtmRTQqUNrRxak0WejFYbE7TvlsXrfUs=.de887f6f-986f-437e-a367-569ada77fd12@github.com>

On Mon, 24 Oct 2022 20:01:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8294466](https://bugs.openjdk.org/browse/JDK-8294466) trimmed down the set of disabled warnings. Unfortunately it turned out that running slowdebug on linux on Oracle's CI triggered yet another warning in libsplashscreen.

Thumbs up. This is a trivial fix.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10840


From ihse at openjdk.org  Mon Oct 24 20:29:29 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 20:29:29 GMT
Subject: RFR: 8295653: Add a graph of the sealed class hierarchy for marked
 classes [v3]
In-Reply-To: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
References: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
Message-ID: <IYBLMjFSIlMyGItTqDO76THJqd494IICRWtB3Ej0Iz8=.f2bfb177-664e-4c3f-9145-c045da3c3253@github.com>

> It would be possible to mark classes with `@sealedGraph` to indicate that the sealed hierarchy should be rendered graphically in the JavaDocs. Classes not marked would be unaffected, creating an opt-in approach.
> 
> [Here](https://bugs.openjdk.org/secure/attachment/101126/Screen%20Shot%202022-10-19%20at%2012.47.47%20PM.png) is an example of MemoryLayout class rendering.
> 
> This feature has been developed in cooperation with Per Minborg.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Use Path instead of File
 - Rename lambda argument to match type

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10761/files
  - new: https://git.openjdk.org/jdk/pull/10761/files/0b43e55c..f6da8c4c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10761&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10761&range=01-02

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10761.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10761/head:pull/10761

PR: https://git.openjdk.org/jdk/pull/10761


From ihse at openjdk.org  Mon Oct 24 20:29:34 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 20:29:34 GMT
Subject: RFR: 8295653: Add a graph of the sealed class hierarchy for marked
 classes [v2]
In-Reply-To: <e2O24eRPqrl1KIUVq9jmx157bLzRp2mWNl1GXXgM8m4=.3ecad4fa-58b4-49a0-b5b0-c4581cc0a50b@github.com>
References: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
 <HesqaFYWAlswM8GiQW0Fn3jZSyP_kTA4UHgX-OjE4uY=.dcab4fe1-c5a0-4265-a65e-476106c0f359@github.com>
 <e2O24eRPqrl1KIUVq9jmx157bLzRp2mWNl1GXXgM8m4=.3ecad4fa-58b4-49a0-b5b0-c4581cc0a50b@github.com>
Message-ID: <8NfyOjBXPmYc0hTdWMHuMz2h-O3HqCrZKXFX0G7QNNM=.8bff36d4-38d6-423d-86bb-1c80487f6cf3@github.com>

On Mon, 24 Oct 2022 20:06:58 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix styleheet
>
> make/jdk/src/classes/build/tools/taglet/SealedGraph.java line 86:
> 
>> 84: 
>> 85:         ModuleElement module = docletEnvironment.getElementUtils().getModuleOf(element);
>> 86:         File dotFile = new File(sealedGraphDotPath,
> 
> These days, it is preferable to use  NIO, so use `Path` instead of `File`.

Fixed.

> make/jdk/src/classes/build/tools/taglet/SealedGraph.java line 93:
> 
>> 91:                 .map(ModuleElement.ExportsDirective.class::cast)
>> 92:                 // Only include packages that are globally exported (i.e. no "to" exports)
>> 93:                 .filter(me -> me.getTargetModules() == null)
> 
> The lambda parameter here is an `ExportsDirective`, not a `ModuleElement`, suggesting that the name here should be `ed` instead of `me`.

Fixed.

-------------

PR: https://git.openjdk.org/jdk/pull/10761


From erikj at openjdk.org  Mon Oct 24 20:32:53 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 24 Oct 2022 20:32:53 GMT
Subject: RFR: 8295663 Rephrased introduction to testing
In-Reply-To: <NYn97U2N6hxYHvAu0esVWTqOai7KCLCtjf_eVWMe5_Y=.a4a07df3-5352-4818-bb4c-e068169174a8@github.com>
References: <NYn97U2N6hxYHvAu0esVWTqOai7KCLCtjf_eVWMe5_Y=.a4a07df3-5352-4818-bb4c-e068169174a8@github.com>
Message-ID: <WrjplpUyO33hpP-MxNe9OXIn710E2Fvnz7fMuvsAYaY=.e39659d7-76a0-47ca-857a-1091e87a6778@github.com>

On Wed, 19 Oct 2022 13:57:59 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> Old one made little sense for a new reader

Could you tidy up the formatting of the markdown version? The line lengths are rather uneven.

-------------

PR: https://git.openjdk.org/jdk/pull/10763


From ihse at openjdk.org  Mon Oct 24 20:36:28 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 20:36:28 GMT
Subject: Integrated: 8295847: slow debug build error after JDK-8294466
In-Reply-To: <VULVvQOFDUv8pyKsFSyKAt6oREnekM8nYok3cDFvM8s=.d1efbd0d-81ad-421b-beb2-fe6519ef1944@github.com>
References: <VULVvQOFDUv8pyKsFSyKAt6oREnekM8nYok3cDFvM8s=.d1efbd0d-81ad-421b-beb2-fe6519ef1944@github.com>
Message-ID: <pFJrBbU11AVF22fQCKF68NHFYZ9sh5JDiZladv4sD_w=.56f3d4ea-c5d5-4907-8d52-443770e01090@github.com>

On Mon, 24 Oct 2022 20:01:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8294466](https://bugs.openjdk.org/browse/JDK-8294466) trimmed down the set of disabled warnings. Unfortunately it turned out that running slowdebug on linux on Oracle's CI triggered yet another warning in libsplashscreen.

This pull request has now been integrated.

Changeset: 8c86e925
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8c86e92535afa52c4d454a3b8cc59ee5f8bb6477
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8295847: slow debug build error after JDK-8294466

Reviewed-by: erikj, dcubed

-------------

PR: https://git.openjdk.org/jdk/pull/10840


From ihse at openjdk.org  Mon Oct 24 20:39:57 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 20:39:57 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <NfKRwZk2cASJZIeh2KYBJMAy7FTuIm87YyXzt8CT0X4=.767db538-3861-4555-b621-4e65c68e26ef@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <NfKRwZk2cASJZIeh2KYBJMAy7FTuIm87YyXzt8CT0X4=.767db538-3861-4555-b621-4e65c68e26ef@github.com>
Message-ID: <HMdFi0RZ9_Jhobfq_DLpJY4wycMf6qXcIHo90U8sq80=.4a035bff-b633-400b-bbf4-c3e7111385f3@github.com>

On Mon, 24 Oct 2022 19:39:21 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> I think it would be better to try and remove incidental trailing whitespace first, before encoding any remaining whitespace. Hiding the trailing whitespace as a Unicode escape seems like a bad idea, equivalent to sweeping the issue under the rug. While I agree with the goals of improving the check, I think this is going about it the wrong way, or at least in the wrong order.

I respectfully disagree. I think changing a trailing " " into a "\u0020" is the opposite of hiding it; it is making it plainly visible. In fact, I believe most of these trailing spaces are the result of them not being visible enough (and the tooling not warning).

Secondly, there are a lot of definitely unintentional trailing spaces, in comments and blank lines. I'd say there is factor 10:1 more of these. Getting these out of the way allows developers to focus more clearly on the trailing whitespace that matters: those in the key-value pairs.

And as I said, I intend to file follow-up issues for all files where there is a trailing unicode-sequence whitespace, so it will definitely not be lost on the respective component teams that they have something they need to address.

> Maybe it would be a good idea to first validate the default/English files, checking for incidental whitespace there, then check localized versions of each property against the English version.

That's probably a good idea, but I think we should leave that to each respective team. Just like Andy's and Naoto's suggestion of improving i18n tooling to detect issues like this earlier on. Good idea, but I'd like to see that implemented separated from this PR. This PR is already large. The only reason it makes sense is because all changes (except the one to jcheck) are automatically generated and trivial to verify correctness of. If we were to start adding individual, manual changes into this PR, it would be just a huge mess.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From prr at openjdk.org  Mon Oct 24 20:43:56 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Oct 2022 20:43:56 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <_lQB8faV1GqMi881H0wr45_2kkYS3j9xQRD3oao2N2k=.4f81ca75-b27c-4c7b-a5fc-c5d378058901@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
 <_lQB8faV1GqMi881H0wr45_2kkYS3j9xQRD3oao2N2k=.4f81ca75-b27c-4c7b-a5fc-c5d378058901@github.com>
Message-ID: <uJ8FpaN9cfXAspUsvs1ljSXIm6XgBJHOpp3X1NnQE6Q=.82c3cb2e-7d59-4a24-bee7-9628ade26674@github.com>

On Mon, 24 Oct 2022 10:15:53 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".
>
> Marked as reviewed by aivanov (Reviewer).

@aivanov-jdk has prepared a patch which will be pushed to fix this up but I agree the timing needs to be perfect to be safe here ..  if you can't co-ordinate a time with him then he would need to disable it now and re-enable it later.

-------------

PR: https://git.openjdk.org/jdk/pull/10757


From ihse at openjdk.org  Mon Oct 24 20:44:08 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 20:44:08 GMT
Subject: RFR: 8295653: Add a graph of the sealed class hierarchy for marked
 classes [v4]
In-Reply-To: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
References: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
Message-ID: <wewvGmw-sDeZIq9i1rKObXQAzjJ6P6yAb_Pd8dODTFY=.0add705a-48b3-4b43-b94e-8e4c74f756d7@github.com>

> It would be possible to mark classes with `@sealedGraph` to indicate that the sealed hierarchy should be rendered graphically in the JavaDocs. Classes not marked would be unaffected, creating an opt-in approach.
> 
> [Here](https://bugs.openjdk.org/secure/attachment/101126/Screen%20Shot%202022-10-19%20at%2012.47.47%20PM.png) is an example of MemoryLayout class rendering.
> 
> This feature has been developed in cooperation with Per Minborg.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Rename sealedGraphDotPath to sealedDotOutputDir

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10761/files
  - new: https://git.openjdk.org/jdk/pull/10761/files/f6da8c4c..b0f9087c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10761&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10761&range=02-03

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10761.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10761/head:pull/10761

PR: https://git.openjdk.org/jdk/pull/10761


From ihse at openjdk.org  Mon Oct 24 20:44:08 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 20:44:08 GMT
Subject: RFR: 8295653: Add a graph of the sealed class hierarchy for marked
 classes [v2]
In-Reply-To: <S5Evu0OCSGvDVV3rumCM6IDB3dBt6fIBDiRmc3UI2lg=.cbf7bd09-b2e7-43cd-a0cd-785e589e56d4@github.com>
References: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
 <HesqaFYWAlswM8GiQW0Fn3jZSyP_kTA4UHgX-OjE4uY=.dcab4fe1-c5a0-4265-a65e-476106c0f359@github.com>
 <e2O24eRPqrl1KIUVq9jmx157bLzRp2mWNl1GXXgM8m4=.3ecad4fa-58b4-49a0-b5b0-c4581cc0a50b@github.com>
 <S5Evu0OCSGvDVV3rumCM6IDB3dBt6fIBDiRmc3UI2lg=.cbf7bd09-b2e7-43cd-a0cd-785e589e56d4@github.com>
Message-ID: <0aW9agwnm48VDneIVFn_CNaY7nO-Ss5ujs664nieUf0=.c3b1774f-91ff-4be2-be99-e2eacb5f8e16@github.com>

On Mon, 24 Oct 2022 20:11:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/jdk/src/classes/build/tools/taglet/SealedGraph.java line 49:
>> 
>>> 47: public final class SealedGraph implements Taglet {
>>> 48:     private static final String sealedGraphDotPath =
>>> 49:             System.getProperty("sealedGraphDotPath");
>> 
>> The naming and use is slightly off here.
>> 
>> 1. It names the _directory_ in which the graph `.dot` file will be placed. It's not a path for the `.dot` file itself.
>> 2. it does double-duty as the equivalent of `enableModuleGraph` in the module graphs world.
>
> Would `sealedDotOutputDir` be ok? I think 2. will kind of follow from the fact that it is specified. Otherwise we could do like `enableSealedDotOutputInDir` but I think that's getting too verbose. And having two different properties just because of naming makes no sense, since then we need to start checking that they are consistent.

I went with `sealedDotOutputDir`. Hope it's okay.

-------------

PR: https://git.openjdk.org/jdk/pull/10761


From ihse at openjdk.org  Mon Oct 24 20:47:56 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 20:47:56 GMT
Subject: RFR: 8295663 Rephrased introduction to testing
In-Reply-To: <NYn97U2N6hxYHvAu0esVWTqOai7KCLCtjf_eVWMe5_Y=.a4a07df3-5352-4818-bb4c-e068169174a8@github.com>
References: <NYn97U2N6hxYHvAu0esVWTqOai7KCLCtjf_eVWMe5_Y=.a4a07df3-5352-4818-bb4c-e068169174a8@github.com>
Message-ID: <_xwr3JmFpA_c1Op59NmyAXTE6dkQt2RG3_mCq-uVlt0=.b311d79a-2b1b-46a8-a24d-2007543c4e13@github.com>

On Wed, 19 Oct 2022 13:57:59 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> Old one made little sense for a new reader

Good point; I didn't notice. We try to keep the line length of markdown files below 79, if possible, so that they can be properly viewed on a 80-wide viewport.

Many editors have a "reflow lines" or similar function, that can help you.

-------------

PR: https://git.openjdk.org/jdk/pull/10763


From ihse at openjdk.org  Mon Oct 24 20:51:56 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 20:51:56 GMT
Subject: Integrated: 8295716: Minimize disabled warnings in security libs
In-Reply-To: <wC6EGLuPyOIwbzXSG_S57RYQtqfLpibn0Eybd8TNio8=.884268ad-51ec-4d6f-aed9-84fa67704faa@github.com>
References: <wC6EGLuPyOIwbzXSG_S57RYQtqfLpibn0Eybd8TNio8=.884268ad-51ec-4d6f-aed9-84fa67704faa@github.com>
Message-ID: <eYSApZrPglwwThWP6k79a6COZTBORZdpb8afMLG-yB0=.00971739-47b0-4fa3-bf00-23c5deba0f1c@github.com>

On Thu, 20 Oct 2022 10:19:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After JDK-8294281, it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in the security native libraries.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.

This pull request has now been integrated.

Changeset: 1d15e5cd
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1d15e5cdd698045ab9c285c92b96126ed0666ac5
Stats:     4 lines in 2 files changed: 0 ins; 1 del; 3 mod

8295716: Minimize disabled warnings in security libs

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/jdk/pull/10787


From ihse at openjdk.org  Mon Oct 24 20:53:54 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 20:53:54 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
Message-ID: <9qWFsNtQRgE6Darx7iMV5vWtKPwVf5TV3455NEau7sQ=.2deebcb6-ed17-4c18-86bc-800e0a347a69@github.com>

On Wed, 19 Oct 2022 08:15:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".

Thank you for waiting while we sorted out the details. This looks good to push. However, as prrace says, we have a corresponding closed part that needs to go in at the same time. One way to solve this is that you give the `/integrate defer` PR command. Then any jdk committer can *actually* integrate the PR later, and make sure it is coordinated with our closed counterpart.

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10757


From mikael at openjdk.org  Mon Oct 24 21:01:51 2022
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Mon, 24 Oct 2022 21:01:51 GMT
Subject: RFR: 8287754: Update jib GNU make dependency on Windows to latest
 cygwin build
In-Reply-To: <oYCgCpczrN2XziQtYlk4fa2RldjtWauzUnfg_1bFnkA=.67c9b89c-3aca-49c2-85c8-e7d273c6803a@github.com>
References: <oYCgCpczrN2XziQtYlk4fa2RldjtWauzUnfg_1bFnkA=.67c9b89c-3aca-49c2-85c8-e7d273c6803a@github.com>
Message-ID: <Aw2XUOOJi11aixdUOIuRSrGPaO79YfZ7sE0ysk87Nf8=.6aaa0550-dbd7-42d5-951f-c522cc4854bc@github.com>

On Thu, 20 Oct 2022 21:49:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> For Oracle internal builds we control the version of GNU Make (currently fixed at 4.0). In Cygwin this is causing problems as the now rather dated GNU Make binary we use isn't compatible with Cygwin.dll version 3.3 or later. To work around this, I'm making the dependency dynamic on the version of Cygwin. If the currently running Cygwin is new enough, the dependency will be on GNU make 4.3.

Marked as reviewed by mikael (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10805


From cjplummer at openjdk.org  Tue Oct 25 03:16:49 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 25 Oct 2022 03:16:49 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <qb_ryMLGem495x0rBbOxd4vVGYPmnRiOkynx6AmvZVE=.5c5d3ee8-8498-4d6d-bfec-04a075ab085c@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

Changes requested by cjplummer (Reviewer).

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent.properties line 27:

> 25: 
> 26: agent.err.error			   = Error
> 27: agent.err.exception                = Exception thrown by the agent\u0020

I believe this space was just a typo and should be removed. Same for `agent.err.agentclass.failed` below and in all the other management property files.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From aturbanov at openjdk.org  Tue Oct 25 09:35:39 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 25 Oct 2022 09:35:39 GMT
Subject: RFR: 8295653: Add a graph of the sealed class hierarchy for marked
 classes [v4]
In-Reply-To: <wewvGmw-sDeZIq9i1rKObXQAzjJ6P6yAb_Pd8dODTFY=.0add705a-48b3-4b43-b94e-8e4c74f756d7@github.com>
References: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
 <wewvGmw-sDeZIq9i1rKObXQAzjJ6P6yAb_Pd8dODTFY=.0add705a-48b3-4b43-b94e-8e4c74f756d7@github.com>
Message-ID: <VjAmDDr6hF2BeukHqdh2VdMEUw3FPaPAnagYil1tdrg=.65da5ff6-84a7-4476-9f2b-c6375f9e9268@github.com>

On Mon, 24 Oct 2022 20:44:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> It would be possible to mark classes with `@sealedGraph` to indicate that the sealed hierarchy should be rendered graphically in the JavaDocs. Classes not marked would be unaffected, creating an opt-in approach.
>> 
>> [Here](https://bugs.openjdk.org/secure/attachment/101126/Screen%20Shot%202022-10-19%20at%2012.47.47%20PM.png) is an example of MemoryLayout class rendering.
>> 
>> This feature has been developed in cooperation with Per Minborg.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename sealedGraphDotPath to sealedDotOutputDir

make/jdk/src/classes/build/tools/taglet/SealedGraph.java line 102:

> 100:         String dotContent = Renderer.graph(typeElement, exports);
> 101: 
> 102:         try (PrintWriter pw = new PrintWriter(dotFile.toFile())) {

Can `Files.writeString` be used instead?

-------------

PR: https://git.openjdk.org/jdk/pull/10761


From serb at openjdk.org  Tue Oct 25 09:49:57 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 25 Oct 2022 09:49:57 GMT
Subject: Integrated: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
Message-ID: <GJxA0j9dhKofslUGNSXAwm9FkBFlCzwegbw0vU5vNco=.cc88f358-72c4-4070-a8d9-ed0243b2f7a9@github.com>

On Wed, 19 Oct 2022 08:15:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".

This pull request has now been integrated.

Changeset: 6673cd85
Author:    Sergey Bylokhov <serb at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6673cd857722d117b108590ba7f7c02f8622fc3b
Stats:     7 lines in 3 files changed: 3 ins; 3 del; 1 mod

8295554: Move the "sizecalc.h" to the correct location

Reviewed-by: erikj, ihse, prr, kizune, aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/10757


From shade at openjdk.org  Tue Oct 25 10:49:32 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 25 Oct 2022 10:49:32 GMT
Subject: RFR: 8295868: 32-bit Windows build failures after JDK-8294466
Message-ID: <RfMXMt16m2IYqJjUkKvciC8oTPFLRoTiZaDQOBnGxNY=.fcab2e1c-b813-4480-80a1-1201c088f06b@github.com>

Fails like this:


* For target support_native_java.desktop_libsplashscreen_splashscreen_impl.obj:
splashscreen_impl.c
c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(443): error C2220: the following warning is treated as an error
c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(443): warning C4018: '>': signed/unsigned mismatch
c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(444): warning C4018: '>': signed/unsigned mismatch
c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(466): warning C4018: '>': signed/unsigned mismatch
c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(467): warning C4018: '>': signed/unsigned mismatch
``` 

I just added the disabled warning for that file. 

Additional testing:
 - [x] Windows x86_32 release (now builds)
 - [ ] Windows x86_32 fastdebug (now builds)
 - [ ] Windows x86_32 slowdebug (now builds)

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/10848/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10848&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295868
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10848.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10848/head:pull/10848

PR: https://git.openjdk.org/jdk/pull/10848


From erikj at openjdk.org  Tue Oct 25 12:48:53 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 25 Oct 2022 12:48:53 GMT
Subject: RFR: 8295868: 32-bit Windows build failures after JDK-8294466
In-Reply-To: <RfMXMt16m2IYqJjUkKvciC8oTPFLRoTiZaDQOBnGxNY=.fcab2e1c-b813-4480-80a1-1201c088f06b@github.com>
References: <RfMXMt16m2IYqJjUkKvciC8oTPFLRoTiZaDQOBnGxNY=.fcab2e1c-b813-4480-80a1-1201c088f06b@github.com>
Message-ID: <aHolgcC9noS7_3404mYCdRXRwM5pJRhssghlCLb1m3E=.bdaeb45c-4b87-4917-9701-46bd3e6be990@github.com>

On Tue, 25 Oct 2022 10:40:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Fails like this:
> 
> 
> * For target support_native_java.desktop_libsplashscreen_splashscreen_impl.obj:
> splashscreen_impl.c
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(443): error C2220: the following warning is treated as an error
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(443): warning C4018: '>': signed/unsigned mismatch
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(444): warning C4018: '>': signed/unsigned mismatch
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(466): warning C4018: '>': signed/unsigned mismatch
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(467): warning C4018: '>': signed/unsigned mismatch
> ``` 
> 
> I just added the disabled warning for that file. 
> 
> Additional testing:
>  - [x] Windows x86_32 release (now builds)
>  - [x] Windows x86_32 fastdebug (now builds)
>  - [x] Windows x86_32 slowdebug (now builds)

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10848


From erikj at openjdk.org  Tue Oct 25 12:49:33 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 25 Oct 2022 12:49:33 GMT
Subject: Integrated: 8287754: Update jib GNU make dependency on Windows to
 latest cygwin build
In-Reply-To: <oYCgCpczrN2XziQtYlk4fa2RldjtWauzUnfg_1bFnkA=.67c9b89c-3aca-49c2-85c8-e7d273c6803a@github.com>
References: <oYCgCpczrN2XziQtYlk4fa2RldjtWauzUnfg_1bFnkA=.67c9b89c-3aca-49c2-85c8-e7d273c6803a@github.com>
Message-ID: <nTgq1vcFZqEzv0iBuRQquUt-oym6m1uCKZ9a0-b2iQk=.d2baf5e5-5806-4231-8b72-b520ef6b415e@github.com>

On Thu, 20 Oct 2022 21:49:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> For Oracle internal builds we control the version of GNU Make (currently fixed at 4.0). In Cygwin this is causing problems as the now rather dated GNU Make binary we use isn't compatible with Cygwin.dll version 3.3 or later. To work around this, I'm making the dependency dynamic on the version of Cygwin. If the currently running Cygwin is new enough, the dependency will be on GNU make 4.3.

This pull request has now been integrated.

Changeset: af2de975
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/af2de975cbc46ad91c736b110a2212cd32ba60a7
Stats:     26 lines in 1 file changed: 15 ins; 6 del; 5 mod

8287754: Update jib GNU make dependency on Windows to latest cygwin build

Reviewed-by: djelinski, ihse, mikael

-------------

PR: https://git.openjdk.org/jdk/pull/10805


From weijun at openjdk.org  Tue Oct 25 13:30:53 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 25 Oct 2022 13:30:53 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <c28cQxkcVp8YCkAe0wDP4b7cUvb424JsH9ls5bR3m48=.31cad672-bef6-4d55-983d-2cb32a0cafea@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

test/jdk/javax/net/ssl/Stapling/TEST.properties line 5:

> 3:     java.base/sun.security.util \
> 4:     java.base/sun.security.validator \
> 5:     java.base/sun.security.x509\u0020

I'm quite sure this space can be safely removed.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From aph at openjdk.org  Tue Oct 25 13:33:56 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 25 Oct 2022 13:33:56 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
Message-ID: <fKOG6_MUoWYj1_BVnyVQLoLxHmU1YKYjbbx1Rek6_50=.b22b2a8e-3590-4893-9054-9de170cfb694@github.com>

On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>> 
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>> 
>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
>> 
>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

I now have some performance results. `java.lang.foreign.CallOverheadConstant` is the test that I used to measure JNI overhead.

At present, without `-XX:+RestoreMXCSROnJNICalls`, it looks like this:


Benchmark                          Mode  Cnt  Score   Error  Units
CallOverheadConstant.jni_blank     avgt   40  9.968 ? 0.037  ns/op
CallOverheadConstant.panama_blank  avgt   40  8.745 ? 0.012  ns/op


Enabling `-XX:+RestoreMXCSROnJNICalls` makes the overhead much worse:


Benchmark                          Mode  Cnt   Score   Error  Units
CallOverheadConstant.jni_blank     avgt   40  14.741 ? 0.031  ns/op
CallOverheadConstant.panama_blank  avgt   40  14.620 ? 0.022  ns/op


and with JMH perfasm we can see why:


                0x00007f9f43d5698d:   sub    rsp,0x8
   1.56%        0x00007f9f43d56991:   vstmxcsr DWORD PTR [rsp]
  25.01%        0x00007f9f43d56996:   mov    eax,DWORD PTR [rsp]
  11.09%        0x00007f9f43d56999:   and    eax,0xffc0
                0x00007f9f43d5699e:   cmp    eax,DWORD PTR [rip+0xe02d234]        # 0x00007f9f51d83bd8


That adds 50% to the total JNI overhead. 70% to the Panama overhead.
25% of the total elapsed time is MXCSR! Reading MXCSR is expensive. So we don't do that.

So, after a lot of head scratching, I've invented an instruction sequence which doesn't read MXCSR but does a little arithmetic, and `-XX:+RestoreMXCSROnJNICalls` is:


CallOverheadConstant.jni_blank     avgt   40  10.675 ? 0.100  ns/op
CallOverheadConstant.panama_blank  avgt   40  10.284 ? 0.018  ns/op



Which is 7% added overhead for JNI, 17% for Panama. 1ns is 3.5 machine cycles: that's a bit less than the latency of a load from L1 cache.

I'm wondering if I could get away with fixing `RestoreMXCSROnJNICalls` and turning it on by default.

-------------

PR: https://git.openjdk.org/jdk/pull/10661


From duke at openjdk.org  Tue Oct 25 13:34:34 2022
From: duke at openjdk.org (Zixian Cai)
Date: Tue, 25 Oct 2022 13:34:34 GMT
Subject: RFR: 8295885: GHA: Bump gcc versions
Message-ID: <4UHQhc1gSrFTmqN2410N2UvPyw9eNvkyHOZ29MqlYoI=.6698a83d-b082-47a9-9cfa-cf9f884bc655@github.com>

Recent PRs have to start to fail due to failed gcc installations. For example, #10850 has [linux-x86 / build (release)](https://github.com/tschatzl/jdk/actions/runs/3319164391/jobs/5483988905) and [linux-cross-compile / build (riscv64)](https://github.com/tschatzl/jdk/actions/runs/3319164391/jobs/5484657183) failing.

Ubuntu 22.04 has bumped gcc to `10.4.0-4ubuntu1~22.04` for amd64. See https://packages.ubuntu.com/jammy/gcc-10

-------------

Commit messages:
 - GHA: Bump gcc versions

Changes: https://git.openjdk.org/jdk/pull/10852/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10852&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295885
  Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/10852.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10852/head:pull/10852

PR: https://git.openjdk.org/jdk/pull/10852


From shade at openjdk.org  Tue Oct 25 13:34:35 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 25 Oct 2022 13:34:35 GMT
Subject: RFR: 8295885: GHA: Bump gcc versions
In-Reply-To: <4UHQhc1gSrFTmqN2410N2UvPyw9eNvkyHOZ29MqlYoI=.6698a83d-b082-47a9-9cfa-cf9f884bc655@github.com>
References: <4UHQhc1gSrFTmqN2410N2UvPyw9eNvkyHOZ29MqlYoI=.6698a83d-b082-47a9-9cfa-cf9f884bc655@github.com>
Message-ID: <2aVjDNRZJ2v4K0YyzRdzYfP8RXlNfurDhBw6p94hCl0=.7ae860e5-d210-4317-8d96-bf2b1c03d317@github.com>

On Tue, 25 Oct 2022 12:50:02 GMT, Zixian Cai <duke at openjdk.org> wrote:

> Recent PRs have to start to fail due to failed gcc installations. For example, #10850 has [linux-x86 / build (release)](https://github.com/tschatzl/jdk/actions/runs/3319164391/jobs/5483988905) and [linux-cross-compile / build (riscv64)](https://github.com/tschatzl/jdk/actions/runs/3319164391/jobs/5484657183) failing.
> 
> Ubuntu 22.04 has bumped gcc to `10.4.0-4ubuntu1~22.04` for amd64. See https://packages.ubuntu.com/jammy/gcc-10

Submitted the bug for this: https://bugs.openjdk.org/browse/JDK-8295885

-------------

PR: https://git.openjdk.org/jdk/pull/10852


From weijun at openjdk.org  Tue Oct 25 13:47:02 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 25 Oct 2022 13:47:02 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <BDbRiYAxlM0zHt3mTYNyT58TmpoUMzvMZRFOiDNYu3w=.4baf9ec2-c392-41f4-8de2-c9021b4c6e2c@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

I noticed another problem. In some English properties files (Ex: `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`), `\u0020` is already used today but it turns into a whitespace in the translated files. It looks like the translation tool (most likely written in Java) decoded it while reading the English file but was not able to encode it back in a translation. I wonder if this means even if we get everything right now the tool might add trailing spaces again later.

I suggest we focus on the English files this time and file a bug to the translation tool.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From jwaters at openjdk.org  Tue Oct 25 14:09:27 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 25 Oct 2022 14:09:27 GMT
Subject: RFR: 8295884: Support for development with the Eclipse IDE
Message-ID: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>

Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make and Ant integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK.

This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the JVM's sources, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory.

Indexing capabilities utilizing the enhancement:
<img width="960" alt="java" src="https://user-images.githubusercontent.com/32636402/197784819-67ec7de4-7e27-4f33-b738-59b75a9e4403.PNG">
<img width="787" alt="escape" src="https://user-images.githubusercontent.com/32636402/197784843-df8621a8-7b0a-42da-86f4-3afb92de0f71.PNG">

-------------

Commit messages:
 - Formatting
 - Whitespace
 - Carriage Returns
 - Documentation
 - Implement Eclipse support

Changes: https://git.openjdk.org/jdk/pull/10853/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295884
  Stats: 448 lines in 4 files changed: 448 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10853.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10853/head:pull/10853

PR: https://git.openjdk.org/jdk/pull/10853


From aph at openjdk.org  Tue Oct 25 14:27:31 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 25 Oct 2022 14:27:31 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <BDA7SSW43tdWnrU2b44ntWews7s7ZCH5E9vgC2Qeu4A=.cf1bd3ad-c452-44b2-b3f2-da61d68feeb7@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
 <BDA7SSW43tdWnrU2b44ntWews7s7ZCH5E9vgC2Qeu4A=.cf1bd3ad-c452-44b2-b3f2-da61d68feeb7@github.com>
Message-ID: <hrK9xz3FgxuqUlZNLWQuRpmw1Xzh_r9jVrtBRtlIinU=.d96d7349-fbbd-4026-9817-e009e9066701@github.com>

On Thu, 20 Oct 2022 20:26:47 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> The GCC bugs with `-ffast-math` only corrupts `FTZ` and `DAZ`.
> 
> But `RC` and exception masks may be corrupted as well the same way and I believe the consequences are be similar (silent divergence in results during FP computations).

I think we can catch the things that are likely, and will result in silent corruption. We should limit this, I think, to rounding modes and denormals-to-zero. I don't think we should bother with exception masks.

-------------

PR: https://git.openjdk.org/jdk/pull/10661


From aph at openjdk.org  Tue Oct 25 14:35:34 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 25 Oct 2022 14:35:34 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <fKOG6_MUoWYj1_BVnyVQLoLxHmU1YKYjbbx1Rek6_50=.b22b2a8e-3590-4893-9054-9de170cfb694@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
 <fKOG6_MUoWYj1_BVnyVQLoLxHmU1YKYjbbx1Rek6_50=.b22b2a8e-3590-4893-9054-9de170cfb694@github.com>
Message-ID: <b6iP5I73dXDINqFyDM_cfcidblU9ycfQAIsBgihdfuI=.301b4509-1293-487a-b42b-5d21cf11e367@github.com>

On Tue, 25 Oct 2022 13:29:52 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Enabling `-XX:+RestoreMXCSROnJNICalls` makes the overhead much worse:
> 
> ```
> Benchmark                          Mode  Cnt   Score   Error  Units
> CallOverheadConstant.jni_blank     avgt   40  14.741 ? 0.031  ns/op
> CallOverheadConstant.panama_blank  avgt   40  14.620 ? 0.022  ns/op
> ```

This is Zen+, by the way: Latency of stmxcsr ?18. Better than some x86_64, worse than others.

-------------

PR: https://git.openjdk.org/jdk/pull/10661


From fweimer at openjdk.org  Tue Oct 25 14:50:51 2022
From: fweimer at openjdk.org (Florian Weimer)
Date: Tue, 25 Oct 2022 14:50:51 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
Message-ID: <JFSj1UbAyaOcXwhG-sRW8h28l5TFSaR88r00nKLGU-U=.5f582141-7da0-4fee-918b-5da33ab2e9ad@github.com>

On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>> 
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>> 
>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
>> 
>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

Sorry, I feel like this has gone a bit off track. It started as some hardening for `loadLibrary`, but now it's about making all JNI calls a bit slower? Is there any data to suggest that this is necessary?

Would it be possible to capture some FPU state evidence in crash dumps, as an alternative?

-------------

PR: https://git.openjdk.org/jdk/pull/10661


From aph at openjdk.org  Tue Oct 25 15:02:48 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 25 Oct 2022 15:02:48 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <JFSj1UbAyaOcXwhG-sRW8h28l5TFSaR88r00nKLGU-U=.5f582141-7da0-4fee-918b-5da33ab2e9ad@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
 <JFSj1UbAyaOcXwhG-sRW8h28l5TFSaR88r00nKLGU-U=.5f582141-7da0-4fee-918b-5da33ab2e9ad@github.com>
Message-ID: <0qwgnGBvOdE2FUIyQpm_XOfwrN5vcR__ttweS3M7PeI=.df954f56-7c6a-4c5b-9db2-d02d1ddb5042@github.com>

On Tue, 25 Oct 2022 14:46:57 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

> Sorry, I feel like this has gone a bit off track. It started as some hardening for `loadLibrary`, but now it's about making all JNI calls a bit slower? Is there any data to suggest that this is necessary?
> 
> Would it be possible to capture some FPU state evidence in crash dumps, as an alternative?

Really? The problem is that when certain libraries are loaded, we get silently corrupted results. Vladimir Ivanov pointed out that the weakness applies to any JNI call, and we wondered if it might be possible to make the workaround so cheap that we could leave it on by default. IMVHO we probably could: the additional overhead is about 1-1.5ns. The only way to measure it is carefully written tests against a JNI call that does nothing.

-------------

PR: https://git.openjdk.org/jdk/pull/10661


From aph at openjdk.org  Tue Oct 25 15:10:46 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 25 Oct 2022 15:10:46 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
Message-ID: <zmG6QWwTzPMaZvQ6dQ5QVlzBudjBGt3G1cJhCXJPA5M=.cddadd01-fe0e-4057-8a08-4302d5da3f3e@github.com>

On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>> 
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>> 
>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
>> 
>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

And this is Xeon CPU E5-2430 (Ivy Bridge-EN) @ 2.20GHz, with my `-XX:+RestoreMXCSROnJNICalls` code:


Benchmark                          Mode  Cnt   Score   Error  Units
CallOverheadConstant.jni_blank     avgt   40  16.669 ? 0.011  ns/op
CallOverheadConstant.panama_blank  avgt   40  15.262 ? 0.052  ns/op



Benchmark                          Mode  Cnt   Score   Error  Units
CallOverheadConstant.jni_blank     avgt   40  18.015 ? 1.671  ns/op
CallOverheadConstant.panama_blank  avgt   40  16.658 ? 0.566  ns/op

-------------

PR: https://git.openjdk.org/jdk/pull/10661


From aph at openjdk.org  Tue Oct 25 15:10:47 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 25 Oct 2022 15:10:47 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <xxQC1v4HvKMDrFPl5buDM5nhwjTtlmU9bqKyBAmr9ms=.36545a65-a197-4841-bc90-209d48afff70@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
 <xxQC1v4HvKMDrFPl5buDM5nhwjTtlmU9bqKyBAmr9ms=.36545a65-a197-4841-bc90-209d48afff70@github.com>
Message-ID: <6lFJnHoENcGxQteeh2YMUl3C97dmey32CR7rrX52T0Q=.43bb9040-097f-44c1-9b9a-12ff997575e0@github.com>

On Tue, 18 Oct 2022 07:46:35 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

> I wonder if something that focuses on diagnostic tools might be better here, particularly if there hasn't been any reported breakage. The `dlopen` protection is of course very incomplete because any JNI call can change the state in unexpected ways.
> 
> On the other hand, it seems unlikely that this change breaks some undefined but intended use of the FPU state because if it is changed in `dlopen`, it's not going to be propagated across threads.

Why is that unlikely? `System.loadLibrary` runs on a Java thread. That kinda makes it worse, because arithmetic results are different depending on which thread is in use.

-------------

PR: https://git.openjdk.org/jdk/pull/10661


From aivanov at openjdk.org  Tue Oct 25 15:40:57 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 25 Oct 2022 15:40:57 GMT
Subject: RFR: 8295554: Move the "sizecalc.h" to the correct location
In-Reply-To: <9qWFsNtQRgE6Darx7iMV5vWtKPwVf5TV3455NEau7sQ=.2deebcb6-ed17-4c18-86bc-800e0a347a69@github.com>
References: <lptrAKiyj7rCcLpNVNriLS2zdzW-0hgyLqKyWXgWgbw=.a05a306e-2428-43c5-b867-97edb9b64bc1@github.com>
 <9qWFsNtQRgE6Darx7iMV5vWtKPwVf5TV3455NEau7sQ=.2deebcb6-ed17-4c18-86bc-800e0a347a69@github.com>
Message-ID: <YBum-IgeUsA5lZIbOG0vnTos_MeBC92k-0ilLKEwOGM=.a6479662-fde6-4896-ac7f-e8c9a808cfaf@github.com>

On Mon, 24 Oct 2022 20:50:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The "sizecalc.h" file is moved out from java.desktop/share/native/include, the files in that folder appear in the jdk bundle after installation like the "jawt.h".
>
> Thank you for waiting while we sorted out the details. This looks good to push. However, as prrace says, we have a corresponding closed part that needs to go in at the same time. One way to solve this is that you give the `/integrate defer` PR command. Then any jdk committer can *actually* integrate the PR later, and make sure it is coordinated with our closed counterpart.

Thanks, @magicus, for the suggestion of using `/integrate defer`, it worked like a charm. Both changes went into the same build.

Thanks, @mrserb, for catching and resolving the issue and for cooperating.

-------------

PR: https://git.openjdk.org/jdk/pull/10757


From shade at openjdk.org  Tue Oct 25 17:04:31 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 25 Oct 2022 17:04:31 GMT
Subject: RFR: 8295885: GHA: Bump gcc versions
In-Reply-To: <4UHQhc1gSrFTmqN2410N2UvPyw9eNvkyHOZ29MqlYoI=.6698a83d-b082-47a9-9cfa-cf9f884bc655@github.com>
References: <4UHQhc1gSrFTmqN2410N2UvPyw9eNvkyHOZ29MqlYoI=.6698a83d-b082-47a9-9cfa-cf9f884bc655@github.com>
Message-ID: <rp9xUMumWK0uT1VvhyD1GFy1O28L6HwmzmmrpvJLMB0=.df3d2ba3-166a-4397-829f-041e04f4d2a2@github.com>

On Tue, 25 Oct 2022 12:50:02 GMT, Zixian Cai <duke at openjdk.org> wrote:

> Recent PRs have to start to fail due to failed gcc installations. For example, #10850 has [linux-x86 / build (release)](https://github.com/tschatzl/jdk/actions/runs/3319164391/jobs/5483988905) and [linux-cross-compile / build (riscv64)](https://github.com/tschatzl/jdk/actions/runs/3319164391/jobs/5484657183) failing.
> 
> Ubuntu 22.04 has bumped gcc to `10.4.0-4ubuntu1~22.04` for amd64. See https://packages.ubuntu.com/jammy/gcc-10

Looks fine. I think it covers all places. Two test failures are unrelated to toolchain update.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10852


From naoto at openjdk.org  Tue Oct 25 17:31:52 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 25 Oct 2022 17:31:52 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <BDbRiYAxlM0zHt3mTYNyT58TmpoUMzvMZRFOiDNYu3w=.4baf9ec2-c392-41f4-8de2-c9021b4c6e2c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <BDbRiYAxlM0zHt3mTYNyT58TmpoUMzvMZRFOiDNYu3w=.4baf9ec2-c392-41f4-8de2-c9021b4c6e2c@github.com>
Message-ID: <CWhtHdVfwiBt9m16ZvVgfFbu-h9bRwVLYmwORiLTSVA=.210b4cf3-7f67-4f32-9983-b9fe54bd1571@github.com>

On Tue, 25 Oct 2022 13:43:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I wonder if this means even if we get everything right now the tool might add trailing spaces again later.

Good catch, Max. Yes, that should be dealt with in the translation process.

> I suggest we focus on the English files this time and file a bug to the translation tool.

Agree.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From erikj at openjdk.org  Tue Oct 25 22:19:53 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 25 Oct 2022 22:19:53 GMT
Subject: RFR: 8295884: Support for development with the Eclipse IDE
In-Reply-To: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
Message-ID: <-460jAwuO1LachCE8nAzm_UsCGX8gyEH5kiU9ZnYSF0=.48af2d71-7e11-4692-88b6-c3fc009df04e@github.com>

On Tue, 25 Oct 2022 13:23:34 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make and Ant integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK.
> 
> This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the JVM's sources, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory.
> 
> Indexing capabilities utilizing the enhancement:
> <img width="960" alt="java" src="https://user-images.githubusercontent.com/32636402/197784819-67ec7de4-7e27-4f33-b738-59b75a9e4403.PNG">
> <img width="787" alt="escape" src="https://user-images.githubusercontent.com/32636402/197784843-df8621a8-7b0a-42da-86f4-3afb92de0f71.PNG">

This looks like nice work.

I'm curious how does this eclipse project figures out preprocessor settings like -D flags from the build to correctly setup the environment for the native code? I know this was a major deal when creating the compile-commands.json for other native IDE integrations. I've heard some IDEs just run the build once and inspect the command lines, but our default log level won't show that. I'm not familiar with eclipse project files, but I couldn't really see anything here that addressed this issue. Can you work with the native code in a meaningful way without it?

make/ide/eclipse/CreateWorkspace.gmk line 79:

> 77:     $(patsubst $(TOPDIR)/%,%,$(call FindModuleNativeDirs, $(module)))))
> 78: 
> 79: EmitEmptyLine = $(file >> $(1),)

Note that using the file macro requires GNU make >=4.0. You probably want to document this requirement and add a fast fail if it's not fulfilled.

-------------

PR: https://git.openjdk.org/jdk/pull/10853


From vlivanov at openjdk.org  Tue Oct 25 23:15:27 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 25 Oct 2022 23:15:27 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
Message-ID: <_5t8ZR59czZvHg5wpsd24vGRiKy_unwr5Po1nrq7hec=.8da78b9f-e55a-40e3-bde3-214df1cffbd8@github.com>

On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>> 
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>> 
>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
>> 
>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

Thanks a lot for the data, Andrew.

I agree with you that the overhead `stmxcsr` introduces makes it almost prohibitive to be unconditionally placed on the hot path on the way back from a JNI call. In contrast, your idea to detect the corruption by checking the result of a carefully chosen FP expression has very modest impact while still being able to catch important types of MXCSR corruption.  I fully support having it turned on by default for JNI calls.

-------------

PR: https://git.openjdk.org/jdk/pull/10661


From david.holmes at oracle.com  Wed Oct 26 01:53:17 2022
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 26 Oct 2022 11:53:17 +1000
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <0qwgnGBvOdE2FUIyQpm_XOfwrN5vcR__ttweS3M7PeI=.df954f56-7c6a-4c5b-9db2-d02d1ddb5042@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
 <JFSj1UbAyaOcXwhG-sRW8h28l5TFSaR88r00nKLGU-U=.5f582141-7da0-4fee-918b-5da33ab2e9ad@github.com>
 <0qwgnGBvOdE2FUIyQpm_XOfwrN5vcR__ttweS3M7PeI=.df954f56-7c6a-4c5b-9db2-d02d1ddb5042@github.com>
Message-ID: <18a7522c-c444-f908-d06d-681a9816cec5@oracle.com>

On 26/10/2022 1:02 am, Andrew Haley wrote:
> On Tue, 25 Oct 2022 14:46:57 GMT, Florian Weimer <fweimer at openjdk.org> wrote:
> 
>> Sorry, I feel like this has gone a bit off track. It started as some hardening for `loadLibrary`, but now it's about making all JNI calls a bit slower? Is there any data to suggest that this is necessary?
>>
>> Would it be possible to capture some FPU state evidence in crash dumps, as an alternative?
> 
> Really? The problem is that when certain libraries are loaded, we get silently corrupted results. Vladimir Ivanov pointed out that the weakness applies to any JNI call, and we wondered if it might be possible to make the workaround so cheap that we could leave it on by default. IMVHO we probably could: the additional overhead is about 1-1.5ns. The only way to measure it is carefully written tests against a JNI call that does nothing.

The loadlibrary issue is a concrete issue with a simple and localised 
solution. The extension to "well this could potentially happen on any 
JNI call if it messed with FP state" is a theoretical problem that has 
always been there. If it were free to fix then sure lets be super 
conservative, but it seems to me we are going to penalize everyone (and 
we just went to some effort to produce extremely fast trivial JNI calls) 
to account for something nobody has any evidence is happening - and if 
it did happen then the library being used should be fixed. I don't see 
why we should make everyone pay for this "just in case". At most an 
expanded -Xcheck:jni check for FP-state manipulation, with an 
enhanced/fixed RestoreMXCSROnJNICalls is in order IMVHO.

YMMV.

Cheers,
David
-----

> -------------
> 
> PR: https://git.openjdk.org/jdk/pull/10661


From jrose at openjdk.org  Wed Oct 26 02:27:29 2022
From: jrose at openjdk.org (John R Rose)
Date: Wed, 26 Oct 2022 02:27:29 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <_5t8ZR59czZvHg5wpsd24vGRiKy_unwr5Po1nrq7hec=.8da78b9f-e55a-40e3-bde3-214df1cffbd8@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
 <_5t8ZR59czZvHg5wpsd24vGRiKy_unwr5Po1nrq7hec=.8da78b9f-e55a-40e3-bde3-214df1cffbd8@github.com>
Message-ID: <X9KMGqhvArg-oz6ItzFGoh8fT-zHY81gRTtrZALVzb4=.2f8321bc-96ad-40c3-b696-7018f4fcbb1a@github.com>

On Tue, 25 Oct 2022 23:13:08 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> ?very modest impact while still being able to catch important types of MXCSR corruption. I fully support having it turned on by default for JNI calls.

I guess I agree.  With the clever test for the bad mode Java cares about, the overhead is small compared to an empty JNI call, and very small compared to any normally non-empty JNI call.

Now I'm curious:  What's this magic code?  Does it multiply a couple of well-chosen constants and test for zero?

I said "I guess" because I'm not clear on (a) the benefit of adding that nanosecond (other than preserving denorms against a rare system fault), nor on (b) what are the remaining faults not checked for, but which a more expensive MSR spill/restore would fix.

-------------

PR: https://git.openjdk.org/jdk/pull/10661


From zcai at openjdk.org  Wed Oct 26 08:05:30 2022
From: zcai at openjdk.org (Zixian Cai)
Date: Wed, 26 Oct 2022 08:05:30 GMT
Subject: Integrated: 8295885: GHA: Bump gcc versions
In-Reply-To: <4UHQhc1gSrFTmqN2410N2UvPyw9eNvkyHOZ29MqlYoI=.6698a83d-b082-47a9-9cfa-cf9f884bc655@github.com>
References: <4UHQhc1gSrFTmqN2410N2UvPyw9eNvkyHOZ29MqlYoI=.6698a83d-b082-47a9-9cfa-cf9f884bc655@github.com>
Message-ID: <F3HFY69A-udOAk15vS9GligTXDzJT529zlzrK8NQ8AQ=.5fd41f45-02b5-40ee-a0a1-1f8ed3271bc3@github.com>

On Tue, 25 Oct 2022 12:50:02 GMT, Zixian Cai <zcai at openjdk.org> wrote:

> Recent PRs have to start to fail due to failed gcc installations. For example, #10850 has [linux-x86 / build (release)](https://github.com/tschatzl/jdk/actions/runs/3319164391/jobs/5483988905) and [linux-cross-compile / build (riscv64)](https://github.com/tschatzl/jdk/actions/runs/3319164391/jobs/5484657183) failing.
> 
> Ubuntu 22.04 has bumped gcc to `10.4.0-4ubuntu1~22.04` for amd64. See https://packages.ubuntu.com/jammy/gcc-10

This pull request has now been integrated.

Changeset: e173fd79
Author:    Zixian Cai <zcai at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e173fd792216940652efca4c2db26fc8d23931f8
Stats:     8 lines in 1 file changed: 0 ins; 0 del; 8 mod

8295885: GHA: Bump gcc versions

Reviewed-by: shade

-------------

PR: https://git.openjdk.org/jdk/pull/10852


From shade at openjdk.org  Wed Oct 26 08:11:23 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Oct 2022 08:11:23 GMT
Subject: RFR: 8295868: 32-bit Windows build failures after JDK-8294466
In-Reply-To: <RfMXMt16m2IYqJjUkKvciC8oTPFLRoTiZaDQOBnGxNY=.fcab2e1c-b813-4480-80a1-1201c088f06b@github.com>
References: <RfMXMt16m2IYqJjUkKvciC8oTPFLRoTiZaDQOBnGxNY=.fcab2e1c-b813-4480-80a1-1201c088f06b@github.com>
Message-ID: <yqA6CQT-Qlnq9uAjJxeQHp3B5juKcEnfanuul52_mZ0=.a3d82a13-821f-460a-9bb4-e7af234b4af1@github.com>

On Tue, 25 Oct 2022 10:40:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Fails like this:
> 
> 
> * For target support_native_java.desktop_libsplashscreen_splashscreen_impl.obj:
> splashscreen_impl.c
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(443): error C2220: the following warning is treated as an error
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(443): warning C4018: '>': signed/unsigned mismatch
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(444): warning C4018: '>': signed/unsigned mismatch
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(466): warning C4018: '>': signed/unsigned mismatch
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(467): warning C4018: '>': signed/unsigned mismatch
> ``` 
> 
> I just added the disabled warning for that file. 
> 
> Additional testing:
>  - [x] Windows x86_32 release (now builds)
>  - [x] Windows x86_32 fastdebug (now builds)
>  - [x] Windows x86_32 slowdebug (now builds)

Thanks, I am going to integrate to unbreak my CI.

-------------

PR: https://git.openjdk.org/jdk/pull/10848


From shade at openjdk.org  Wed Oct 26 08:14:25 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Oct 2022 08:14:25 GMT
Subject: Integrated: 8295868: 32-bit Windows build failures after JDK-8294466
In-Reply-To: <RfMXMt16m2IYqJjUkKvciC8oTPFLRoTiZaDQOBnGxNY=.fcab2e1c-b813-4480-80a1-1201c088f06b@github.com>
References: <RfMXMt16m2IYqJjUkKvciC8oTPFLRoTiZaDQOBnGxNY=.fcab2e1c-b813-4480-80a1-1201c088f06b@github.com>
Message-ID: <nqGYEIH5n0BInxVl06jAUJKV7CFdByZ1xXwr-sLc5Mg=.bb88f236-9487-40f6-8f0b-597986d4d872@github.com>

On Tue, 25 Oct 2022 10:40:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Fails like this:
> 
> 
> * For target support_native_java.desktop_libsplashscreen_splashscreen_impl.obj:
> splashscreen_impl.c
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(443): error C2220: the following warning is treated as an error
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(443): warning C4018: '>': signed/unsigned mismatch
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(444): warning C4018: '>': signed/unsigned mismatch
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(466): warning C4018: '>': signed/unsigned mismatch
> c:\buildbot\worker\build-jdkx-windows\build\src\java.desktop\share\native\libsplashscreen\splashscreen_impl.c(467): warning C4018: '>': signed/unsigned mismatch
> ``` 
> 
> I just added the disabled warning for that file. 
> 
> Additional testing:
>  - [x] Windows x86_32 release (now builds)
>  - [x] Windows x86_32 fastdebug (now builds)
>  - [x] Windows x86_32 slowdebug (now builds)

This pull request has now been integrated.

Changeset: 772be2e0
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/772be2e02b7bb1089116c0debb514154489cfa81
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8295868: 32-bit Windows build failures after JDK-8294466

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/jdk/pull/10848


From aph at openjdk.org  Wed Oct 26 09:41:23 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 26 Oct 2022 09:41:23 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
Message-ID: <6kmxPAm1gTiXlFfR2fL4WUh2bdFMCRBbGy1btd1-3Dc=.04a52b3e-b931-4448-8529-8df7d7529436@github.com>

On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>> 
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>> 
>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
>> 
>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

On 10/26/22 03:24, John Rose wrote:
> Now I'm curious:  What's this magic code?  Does it multiply a couple of well-chosen constants and test for zero?

static const double unity = 0x1.0p-1020;
static const volatile double thresh = 0x0.0000000000003p-1022;

  if (unity + (thresh) == unity || -unity - (thresh) == -unity) {
    ... fix the badness

Here, thresh is the smallest denormal number that has two bits set. Unity
is a number such that, when thresh is added it it, must be rounded
according to the mode. These two tests detect the rounding mode in use.
If denormals are turned off (i.e. denormals-are-zero) it looks like round-
to-zero mode is in use.

This is essentially the same test that Joe Darcy posted earlier in this
thread, but scaled to make thresh so small that it is denormal.

> I said "I guess" because I'm not clear on (a) the benefit of adding that nanosecond (other than preserving denorms against a rare system fault), nor on (b) what are the remaining faults not checked for, but which a more expensive MSR spill/restore would fix.

If someone turned on flush-denormal-results-to-zero but didn't also turn
on denormals-are-zero I guess we'd miss that. Otherwise it doesn't matter.

I'd like the JVM to be protected against the GCC -ffast-math bug because the
resulting JVM fault silently produces incorrect results. We can do that with
a test after each dlopen(). But that doesn't work in a robust way: if we call
some native code that itself dlopen()s a library compiled with -ffast-math we
still lose.
Hmm, I guess I could scale the operands a bit more to detect that too... What fun!

-------------

PR: https://git.openjdk.org/jdk/pull/10661


From jwaters at openjdk.org  Wed Oct 26 10:03:00 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 26 Oct 2022 10:03:00 GMT
Subject: RFR: 8295884: Support for development with the Eclipse IDE
In-Reply-To: <-460jAwuO1LachCE8nAzm_UsCGX8gyEH5kiU9ZnYSF0=.48af2d71-7e11-4692-88b6-c3fc009df04e@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
 <-460jAwuO1LachCE8nAzm_UsCGX8gyEH5kiU9ZnYSF0=.48af2d71-7e11-4692-88b6-c3fc009df04e@github.com>
Message-ID: <lLj8IMK9kmpFa7GFgmtsdQgCHHiWaJBxLyqC9OzA_B4=.c71f87cc-e933-47ea-bc30-dd83d12c8a50@github.com>

On Tue, 25 Oct 2022 22:17:25 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This looks like nice work.
> 
> I'm curious how does this eclipse project figures out preprocessor settings like -D flags from the build to correctly setup the environment for the native code? I know this was a major deal when creating the compile-commands.json for other native IDE integrations. I've heard some IDEs just run the build once and inspect the command lines, but our default log level won't show that. I'm not familiar with eclipse project files, but I couldn't really see anything here that addressed this issue. Can you work with the native code in a meaningful way without it?

You're right, it seems I forgot to also include the preprocessor defines in the generated workspace :P
I'll add them in the next commit, thanks for catching that. Eclipse does work very well with native code even without those defines and flags from the build for the most part though, just that utilities which require them (For instance something like PRODUCT_ONLY and NOT_PRODUCT in HotSpot) wouldn't properly work with the indexer, which would be annoying, but it's more of a mild inconvenience than anything.

> make/ide/eclipse/CreateWorkspace.gmk line 79:
> 
>> 77:     $(patsubst $(TOPDIR)/%,%,$(call FindModuleNativeDirs, $(module)))))
>> 78: 
>> 79: EmitEmptyLine = $(file >> $(1),)
> 
> Note that using the file macro requires GNU make >=4.0. You probably want to document this requirement and add a fast fail if it's not fulfilled.

I think it would be better if I looked for something that the make system already has and used that instead of something that's tied to a specific version and GNU specific now that I'm revisiting this, thanks for the catch

-------------

PR: https://git.openjdk.org/jdk/pull/10853


From jwaters at openjdk.org  Wed Oct 26 10:07:12 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 26 Oct 2022 10:07:12 GMT
Subject: RFR: 8295884: Support for development with the Eclipse IDE [v2]
In-Reply-To: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
Message-ID: <FGkHCCt3eKdkBgKtRlen1kRD2n6BJkymHXAR7UOFcHM=.255440c6-8870-4092-a41d-45d1d6bf1bdd@github.com>

> Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make and Ant integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK.
> 
> This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the JVM's sources, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory.
> 
> Indexing capabilities utilizing the enhancement:
> <img width="960" alt="java" src="https://user-images.githubusercontent.com/32636402/197784819-67ec7de4-7e27-4f33-b738-59b75a9e4403.PNG">
> <img width="787" alt="escape" src="https://user-images.githubusercontent.com/32636402/197784843-df8621a8-7b0a-42da-86f4-3afb92de0f71.PNG">

Julian Waters 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 six additional commits since the last revision:

 - Merge
 - Formatting
 - Whitespace
 - Carriage Returns
 - Documentation
 - Implement Eclipse support

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10853/files
  - new: https://git.openjdk.org/jdk/pull/10853/files/a1d02f78..839db0b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=00-01

  Stats: 24760 lines in 318 files changed: 1044 ins; 23454 del; 262 mod
  Patch: https://git.openjdk.org/jdk/pull/10853.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10853/head:pull/10853

PR: https://git.openjdk.org/jdk/pull/10853


From stuefe at openjdk.org  Wed Oct 26 10:17:24 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 26 Oct 2022 10:17:24 GMT
Subject: RFR: 8295884: Support for development with the Eclipse IDE [v2]
In-Reply-To: <FGkHCCt3eKdkBgKtRlen1kRD2n6BJkymHXAR7UOFcHM=.255440c6-8870-4092-a41d-45d1d6bf1bdd@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
 <FGkHCCt3eKdkBgKtRlen1kRD2n6BJkymHXAR7UOFcHM=.255440c6-8870-4092-a41d-45d1d6bf1bdd@github.com>
Message-ID: <dvZJRNqzZ3m2Iyzc8f0B5a-B4EbsKaSAvHrb2Mwv_5M=.39339c3d-f67c-49e1-a56f-eac1ddb9cf89@github.com>

On Wed, 26 Oct 2022 10:07:12 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make and Ant integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK.
>> 
>> This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the JVM's sources, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory.
>> 
>> Indexing capabilities utilizing the enhancement:
>> <img width="960" alt="java" src="https://user-images.githubusercontent.com/32636402/197784819-67ec7de4-7e27-4f33-b738-59b75a9e4403.PNG">
>> <img width="787" alt="escape" src="https://user-images.githubusercontent.com/32636402/197784843-df8621a8-7b0a-42da-86f4-3afb92de0f71.PNG">
>
> Julian Waters 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 six additional commits since the last revision:
> 
>  - Merge
>  - Formatting
>  - Whitespace
>  - Carriage Returns
>  - Documentation
>  - Implement Eclipse support

Will this work with jtreg test sources too? At least on Intellij those require a brittle intellij plugin.

-------------

PR: https://git.openjdk.org/jdk/pull/10853


From jwaters at openjdk.org  Wed Oct 26 10:58:38 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 26 Oct 2022 10:58:38 GMT
Subject: RFR: 8295884: Support for development with the Eclipse IDE [v3]
In-Reply-To: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
Message-ID: <mavxyRQOGiPABzj5QIiqgpRtDlsasgXSIHVjNBUkiZ0=.40c91008-d96e-4bf2-a24b-cdf133f3bffd@github.com>

> Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make and Ant integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK.
> 
> This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the JVM's sources, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory.
> 
> Indexing capabilities utilizing the enhancement:
> <img width="960" alt="java" src="https://user-images.githubusercontent.com/32636402/197784819-67ec7de4-7e27-4f33-b738-59b75a9e4403.PNG">
> <img width="787" alt="escape" src="https://user-images.githubusercontent.com/32636402/197784843-df8621a8-7b0a-42da-86f4-3afb92de0f71.PNG">

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  File operations should use MakeIO.gmk

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10853/files
  - new: https://git.openjdk.org/jdk/pull/10853/files/839db0b3..42278c7b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=01-02

  Stats: 105 lines in 4 files changed: 1 ins; 0 del; 104 mod
  Patch: https://git.openjdk.org/jdk/pull/10853.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10853/head:pull/10853

PR: https://git.openjdk.org/jdk/pull/10853


From jwaters at openjdk.org  Wed Oct 26 11:13:29 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 26 Oct 2022 11:13:29 GMT
Subject: RFR: 8295884: Support for development with the Eclipse IDE [v4]
In-Reply-To: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
Message-ID: <4bGbNcXekWWFkvB0Or2sm87EWYQcLxE6H2IvgzZ6HEA=.18961eeb-3174-4966-95de-a75fc91832c9@github.com>

> Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make and Ant integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK.
> 
> This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the JVM's sources, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory.
> 
> Indexing capabilities utilizing the enhancement:
> <img width="960" alt="java" src="https://user-images.githubusercontent.com/32636402/197784819-67ec7de4-7e27-4f33-b738-59b75a9e4403.PNG">
> <img width="787" alt="escape" src="https://user-images.githubusercontent.com/32636402/197784843-df8621a8-7b0a-42da-86f4-3afb92de0f71.PNG">

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Squash issue with commas

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10853/files
  - new: https://git.openjdk.org/jdk/pull/10853/files/42278c7b..58913981

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10853.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10853/head:pull/10853

PR: https://git.openjdk.org/jdk/pull/10853


From lujaniuk at openjdk.org  Wed Oct 26 13:02:41 2022
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Wed, 26 Oct 2022 13:02:41 GMT
Subject: RFR: 8295663 Rephrased introduction to testing [v2]
In-Reply-To: <NYn97U2N6hxYHvAu0esVWTqOai7KCLCtjf_eVWMe5_Y=.a4a07df3-5352-4818-bb4c-e068169174a8@github.com>
References: <NYn97U2N6hxYHvAu0esVWTqOai7KCLCtjf_eVWMe5_Y=.a4a07df3-5352-4818-bb4c-e068169174a8@github.com>
Message-ID: <9TATzQxqQMn9tTHYFht7K5kBQMgP1rcHchmD-CDf8L4=.3a983daf-28ec-4d5a-bc12-912cbcdb3f23@github.com>

> Old one made little sense for a new reader

Ludvig Janiuk has updated the pull request incrementally with one additional commit since the last revision:

  reflow

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10763/files
  - new: https://git.openjdk.org/jdk/pull/10763/files/34142667..e80d40e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10763&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10763&range=00-01

  Stats: 67 lines in 2 files changed: 11 ins; 0 del; 56 mod
  Patch: https://git.openjdk.org/jdk/pull/10763.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10763/head:pull/10763

PR: https://git.openjdk.org/jdk/pull/10763


From lujaniuk at openjdk.org  Wed Oct 26 13:02:41 2022
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Wed, 26 Oct 2022 13:02:41 GMT
Subject: RFR: 8295663 Rephrased introduction to testing
In-Reply-To: <NYn97U2N6hxYHvAu0esVWTqOai7KCLCtjf_eVWMe5_Y=.a4a07df3-5352-4818-bb4c-e068169174a8@github.com>
References: <NYn97U2N6hxYHvAu0esVWTqOai7KCLCtjf_eVWMe5_Y=.a4a07df3-5352-4818-bb4c-e068169174a8@github.com>
Message-ID: <RAg6Qp2Glz2TflwlKcMSgonHSKw9ZXR2Hd76GtgPwMg=.82a3c0ec-9da8-4134-99b0-117b8bdeb260@github.com>

On Wed, 19 Oct 2022 13:57:59 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> Old one made little sense for a new reader

Sure thing, done.

-------------

PR: https://git.openjdk.org/jdk/pull/10763


From erikj at openjdk.org  Wed Oct 26 13:12:18 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 26 Oct 2022 13:12:18 GMT
Subject: RFR: 8295663 Rephrased introduction to testing [v2]
In-Reply-To: <9TATzQxqQMn9tTHYFht7K5kBQMgP1rcHchmD-CDf8L4=.3a983daf-28ec-4d5a-bc12-912cbcdb3f23@github.com>
References: <NYn97U2N6hxYHvAu0esVWTqOai7KCLCtjf_eVWMe5_Y=.a4a07df3-5352-4818-bb4c-e068169174a8@github.com>
 <9TATzQxqQMn9tTHYFht7K5kBQMgP1rcHchmD-CDf8L4=.3a983daf-28ec-4d5a-bc12-912cbcdb3f23@github.com>
Message-ID: <a6rf4krXaAlBhqSgTtFqGPKsBpURAa1KHTJBa55i7C0=.cc119952-1662-43f2-91ea-8a622d115274@github.com>

On Wed, 26 Oct 2022 13:02:41 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

>> Old one made little sense for a new reader
>
> Ludvig Janiuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflow

Thanks, looks good!

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10763


From jwaters at openjdk.org  Wed Oct 26 14:29:23 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 26 Oct 2022 14:29:23 GMT
Subject: RFR: 8295884: Support for development with the Eclipse IDE [v2]
In-Reply-To: <dvZJRNqzZ3m2Iyzc8f0B5a-B4EbsKaSAvHrb2Mwv_5M=.39339c3d-f67c-49e1-a56f-eac1ddb9cf89@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
 <FGkHCCt3eKdkBgKtRlen1kRD2n6BJkymHXAR7UOFcHM=.255440c6-8870-4092-a41d-45d1d6bf1bdd@github.com>
 <dvZJRNqzZ3m2Iyzc8f0B5a-B4EbsKaSAvHrb2Mwv_5M=.39339c3d-f67c-49e1-a56f-eac1ddb9cf89@github.com>
Message-ID: <ZmReBvKgt2UaGT8YRaU1j8j_yYy9uluP4UEAA_yOKxk=.a2ab92a2-56bb-47f3-b6e9-a9b986553ff0@github.com>

On Wed, 26 Oct 2022 10:15:10 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Will this work with jtreg test sources too? At least on Intellij those require a brittle intellij plugin.

I didn't think of adding them to the indexing list if you're referring to the code in the /test/ directory, but I can do that if that's necessary. So long as they're able to be built using make (doesn't matter which Makefile they use), Eclipse shouldn't have much of an issue with them when it comes to compiling them, or require extra/special support to work properly

-------------

PR: https://git.openjdk.org/jdk/pull/10853


From vlivanov at openjdk.org  Wed Oct 26 17:55:24 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 26 Oct 2022 17:55:24 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic
In-Reply-To: <18a7522c-c444-f908-d06d-681a9816cec5@oracle.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <18a7522c-c444-f908-d06d-681a9816cec5@oracle.com>
Message-ID: <P9oGMrB1Ja45lzu6F4SEmw8p3SwpR126xLmTbGHKsJ4=.9917eaf9-b544-47a7-81a1-187a41c89715@github.com>

On Wed, 26 Oct 2022 17:10:00 GMT, David Holmes <david.holmes at oracle.com> wrote:

> At most an expanded -Xcheck:jni check for FP-state manipulation, with an
enhanced/fixed RestoreMXCSROnJNICalls is in order IMVHO.

FTR both `-Xcheck:jni` and `-XX:+RestoreMXCSROnJNICalls` already catch the problematic case being discussed.


$ .../jdk/bin/java ... compiler/floatingpoint/TestDenormalDouble
Exception in thread "main" java.lang.AssertionError: TEST FAILED: 0.0
        at compiler.floatingpoint.TestDenormalDouble.testDoubles(TestDenormalDouble.java:42)
        at compiler.floatingpoint.TestDenormalDouble.main(TestDenormalDouble.java:52)


$ .../jdk/bin/java ... -Xcheck:jni compiler/floatingpoint/TestDenormalDouble
Loading libfast-math.so
Java HotSpot(TM) 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall
Test passed.


$ .../jdk/bin/java ... -XX:+RestoreMXCSROnJNICalls compiler/floatingpoint/TestDenormalDouble
Loading libfast-math.so
Test passed.

-------------

PR: https://git.openjdk.org/jdk/pull/10661


From vlivanov at openjdk.org  Wed Oct 26 18:07:26 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 26 Oct 2022 18:07:26 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
Message-ID: <MGULzM7zcoT7QGa2lD3v1TPLDhwVlovH_5dk7VYxaTI=.bae9d777-2944-4809-8744-89b1c1164f40@github.com>

On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>> 
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>> 
>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
>> 
>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

There's another option to consider: check MXCSR register consistency at safepoints. It's already too late to fix the corruption (the damage could be already done and the only way to proceed is to initiate a JVM crash), but it should pretty reliably catch the corruption in a prompt manner (so far, by default JVM checks and adjusts MXCSR on x86-64 only during upcalls into Java). 

Also, looks like it should mix well with the fast approximate check on JNI calls (which should be able to catch & heal some of the possible corruptions).

-------------

PR: https://git.openjdk.org/jdk/pull/10661


From jvernee at openjdk.org  Wed Oct 26 20:57:44 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 26 Oct 2022 20:57:44 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
Message-ID: <ijRr6HMGva0A67apmkJuP1eGenWM1NXLpXFUDzvRplQ=.a30dafd2-8969-44b5-ba1b-83e5c9b82a3e@github.com>

On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>> 
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>> 
>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
>> 
>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

I agree with David. Unconditionally doing a check on every call seems to be overkill, since it's a mostly theoretical problem at this point, and in general I think we should be able to assume that foreign code respects the ABI.

There are other things that can go wrong as well, such as foreign code installing a signal handler, which can break implicit null checks. Other things like the foreign code returning with corrupted register state, which then leads to further corruption, is also a possibility. i.e. there seem to be many more things that can go wrong if we expect native code to violate the ABI.

Even though the check can be pretty fast, we've seen that people watch the performance in this area closely, and care about every nanosecond spent here. On my own box, the `panama_blank` benchmark takes just 3.4ns, so the relative overhead could be larger depending on the machine, it seems. There was also recently a flag added to speed up native calls, namely `-XX:+UseSystemMemoryBarrier`. This could further make the relative overhead of a check larger.

All in all, I think `-Xcheck:jni` is a better place to test this kind of stuff, and encourage people to run tests with `-Xcheck:jni` before deploying to production.

But, at the same time, loading libraries is a known problematic situation, and there the performance matters far less. I'd say always checking and restoring the FPU control state, and perhaps emitting a warning message to spur people on to fix the issue in the long term, seems like a good solution to me.

-------------

PR: https://git.openjdk.org/jdk/pull/10661


From jwaters at openjdk.org  Thu Oct 27 02:32:44 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 27 Oct 2022 02:32:44 GMT
Subject: RFR: 8295884: Implement IDE support for Eclipse [v5]
In-Reply-To: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
Message-ID: <L9vC2KSOsminjXkdYoAAfUPs1W0duzzikJd_Xh3_S2Q=.faf877fa-292d-4bc7-8d8d-4682d495e373@github.com>

> Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make and Ant integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK.
> 
> This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the JVM's sources, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory.
> 
> Indexing capabilities utilizing the enhancement:
> <img width="960" alt="java" src="https://user-images.githubusercontent.com/32636402/197784819-67ec7de4-7e27-4f33-b738-59b75a9e4403.PNG">
> <img width="787" alt="escape" src="https://user-images.githubusercontent.com/32636402/197784843-df8621a8-7b0a-42da-86f4-3afb92de0f71.PNG">

Julian Waters 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 ten additional commits since the last revision:

 - Merge
 - Squash issue with commas
 - File operations should use MakeIO.gmk
 - Merge
 - Formatting
 - Whitespace
 - Carriage Returns
 - Documentation
 - Implement Eclipse support

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10853/files
  - new: https://git.openjdk.org/jdk/pull/10853/files/58913981..d35062e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=03-04

  Stats: 580 lines in 31 files changed: 264 ins; 168 del; 148 mod
  Patch: https://git.openjdk.org/jdk/pull/10853.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10853/head:pull/10853

PR: https://git.openjdk.org/jdk/pull/10853


From jwaters at openjdk.org  Thu Oct 27 02:53:23 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 27 Oct 2022 02:53:23 GMT
Subject: RFR: 8295884: Implement IDE support for Eclipse [v5]
In-Reply-To: <lLj8IMK9kmpFa7GFgmtsdQgCHHiWaJBxLyqC9OzA_B4=.c71f87cc-e933-47ea-bc30-dd83d12c8a50@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
 <-460jAwuO1LachCE8nAzm_UsCGX8gyEH5kiU9ZnYSF0=.48af2d71-7e11-4692-88b6-c3fc009df04e@github.com>
 <lLj8IMK9kmpFa7GFgmtsdQgCHHiWaJBxLyqC9OzA_B4=.c71f87cc-e933-47ea-bc30-dd83d12c8a50@github.com>
Message-ID: <CLG5WzBjUamqfuKHApKoupUeM8zuvJ2MptscY-D7AJQ=.c8ceb342-b3bf-4731-9212-901733ac2310@github.com>

On Wed, 26 Oct 2022 09:59:13 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> I've heard some IDEs just run the build once and inspect the command lines, but our default log level won't show that.

I also forgot to mention that CDT does come with an integrated Build Output Parser that can do just that, but I do want to avoid using it, if possible, since it's much more convenient to be able to start working on code the moment configure completes instead of having to wait for the build to finish once

-------------

PR: https://git.openjdk.org/jdk/pull/10853


From jwaters at openjdk.org  Thu Oct 27 03:34:45 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 27 Oct 2022 03:34:45 GMT
Subject: RFR: 8295884: Implement IDE support for Eclipse [v6]
In-Reply-To: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
Message-ID: <OPMu2JAmVibGeKYhX9SlKWXIULndumk6yZj74b3h7DE=.26fe78dd-7777-499a-82eb-37ef28dd39e5@github.com>

> Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make and Ant integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK.
> 
> This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the JVM's sources, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory.
> 
> Indexing capabilities utilizing the enhancement:
> <img width="960" alt="java" src="https://user-images.githubusercontent.com/32636402/197784819-67ec7de4-7e27-4f33-b738-59b75a9e4403.PNG">
> <img width="787" alt="escape" src="https://user-images.githubusercontent.com/32636402/197784843-df8621a8-7b0a-42da-86f4-3afb92de0f71.PNG">

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Prevent Eclipse from automatically attaching binary parsers to workspaces including native code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10853/files
  - new: https://git.openjdk.org/jdk/pull/10853/files/d35062e1..2dca7cae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=04-05

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10853.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10853/head:pull/10853

PR: https://git.openjdk.org/jdk/pull/10853


From jwaters at openjdk.org  Thu Oct 27 05:13:36 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 27 Oct 2022 05:13:36 GMT
Subject: RFR: 8295884: Implement IDE support for Eclipse [v7]
In-Reply-To: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
Message-ID: <v23TQGWaWFUS_NZ5oR1pTyfXu30RkcCL1EfZrELZUJ8=.150d5ad6-a9ac-4978-8e25-6459d8343309@github.com>

> Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make and Ant integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK.
> 
> This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the JVM's sources, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory.
> 
> Indexing capabilities utilizing the enhancement:
> <img width="960" alt="java" src="https://user-images.githubusercontent.com/32636402/197784819-67ec7de4-7e27-4f33-b738-59b75a9e4403.PNG">
> <img width="787" alt="escape" src="https://user-images.githubusercontent.com/32636402/197784843-df8621a8-7b0a-42da-86f4-3afb92de0f71.PNG">

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Initial support for Language Settings Providers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10853/files
  - new: https://git.openjdk.org/jdk/pull/10853/files/2dca7cae..8402431e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=05-06

  Stats: 96 lines in 1 file changed: 85 ins; 3 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/10853.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10853/head:pull/10853

PR: https://git.openjdk.org/jdk/pull/10853


From jwaters at openjdk.org  Thu Oct 27 05:16:40 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 27 Oct 2022 05:16:40 GMT
Subject: RFR: 8295884: Implement IDE support for Eclipse [v8]
In-Reply-To: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
Message-ID: <u8pZeIWcaK3X8BlKRuAMx4vus6H5pZypCO95A1hPfRo=.35abab59-1afb-4171-80fa-720c6c978f0a@github.com>

> Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make and Ant integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK.
> 
> This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the JVM's sources, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory.
> 
> Indexing capabilities utilizing the enhancement:
> <img width="960" alt="java" src="https://user-images.githubusercontent.com/32636402/197784819-67ec7de4-7e27-4f33-b738-59b75a9e4403.PNG">
> <img width="787" alt="escape" src="https://user-images.githubusercontent.com/32636402/197784843-df8621a8-7b0a-42da-86f4-3afb92de0f71.PNG">

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Nuke accidental comment not meant to be added

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10853/files
  - new: https://git.openjdk.org/jdk/pull/10853/files/8402431e..e6674919

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=06-07

  Stats: 27 lines in 1 file changed: 0 ins; 27 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10853.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10853/head:pull/10853

PR: https://git.openjdk.org/jdk/pull/10853


From jwaters at openjdk.org  Thu Oct 27 05:28:44 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 27 Oct 2022 05:28:44 GMT
Subject: RFR: 8295884: Implement IDE support for Eclipse [v9]
In-Reply-To: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
Message-ID: <foSjj3gkkwh05ZHMhdf6jEGG0xazlLd8ZRzk3sPSuEs=.adda53cd-32e3-4902-b698-2b61657810c3@github.com>

> Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make and Ant integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK.
> 
> This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the JVM's sources, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory.
> 
> Indexing capabilities utilizing the enhancement:
> <img width="960" alt="java" src="https://user-images.githubusercontent.com/32636402/197784819-67ec7de4-7e27-4f33-b738-59b75a9e4403.PNG">
> <img width="787" alt="escape" src="https://user-images.githubusercontent.com/32636402/197784843-df8621a8-7b0a-42da-86f4-3afb92de0f71.PNG">

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  SINGLE_DOLLAR is not required

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10853/files
  - new: https://git.openjdk.org/jdk/pull/10853/files/e6674919..4e468aad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=07-08

  Stats: 10 lines in 1 file changed: 0 ins; 5 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10853.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10853/head:pull/10853

PR: https://git.openjdk.org/jdk/pull/10853


From jiefu at openjdk.org  Thu Oct 27 06:03:11 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Thu, 27 Oct 2022 06:03:11 GMT
Subject: RFR: 8295970: Add jdk_vector tests in GHA
Message-ID: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>

Hi all,

As discussed here https://github.com/openjdk/jdk/pull/10807#pullrequestreview-1150314487 , it would be better to add the vector api tests in GHA.

Thanks.
Best regards,
Jie

-------------

Commit messages:
 - 8295970: Add jdk_vector tests in GHA

Changes: https://git.openjdk.org/jdk/pull/10879/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10879&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295970
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10879.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10879/head:pull/10879

PR: https://git.openjdk.org/jdk/pull/10879


From shade at openjdk.org  Thu Oct 27 06:15:22 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 27 Oct 2022 06:15:22 GMT
Subject: RFR: 8295970: Add jdk_vector tests in GHA
In-Reply-To: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
Message-ID: <vMVZYP2W90yOl1Rvmp22PSV6DGhlFPXUZxOlM3tlGxY=.c04c8aae-0344-48f7-ac49-bfed5a9af89e@github.com>

On Thu, 27 Oct 2022 03:53:13 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> As discussed here https://github.com/openjdk/jdk/pull/10807#pullrequestreview-1150314487 , it would be better to add the vector api tests in GHA.
> 
> Thanks.
> Best regards,
> Jie

Sorry, but I don't think this is a good idea. If there are tests that are important for pre-integration testing, they should just be in `tier1`.

-------------

Changes requested by shade (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10879


From jiefu at openjdk.org  Thu Oct 27 06:45:27 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Thu, 27 Oct 2022 06:45:27 GMT
Subject: RFR: 8295970: Add jdk_vector tests in GHA
In-Reply-To: <vMVZYP2W90yOl1Rvmp22PSV6DGhlFPXUZxOlM3tlGxY=.c04c8aae-0344-48f7-ac49-bfed5a9af89e@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
 <vMVZYP2W90yOl1Rvmp22PSV6DGhlFPXUZxOlM3tlGxY=.c04c8aae-0344-48f7-ac49-bfed5a9af89e@github.com>
Message-ID: <pJiVfgKWGlWQyEbQnKet2JuYLEIVNLNy5wtrDnRPqow=.8043e541-9e39-4289-81bb-d257436f5273@github.com>

On Thu, 27 Oct 2022 06:13:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Sorry, but I don't think this is a good idea. If there are tests that are important for pre-integration testing, they should just be in `tier1`.

Since vector api is still in incubation, I'm not sure if it's OK to go into tier1.
I'm fine to add it in tier1 if there is no objection.
Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10879


From jwaters at openjdk.org  Thu Oct 27 06:59:31 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 27 Oct 2022 06:59:31 GMT
Subject: RFR: 8295884: Implement IDE support for Eclipse [v10]
In-Reply-To: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
Message-ID: <cPpSa0qh4pNrpqHB9URZWfY2h3b_3AAPPvLs4W7N8CM=.503e2a2d-7b27-4e8d-aad8-a15361535e7e@github.com>

> Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make and Ant integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK.
> 
> This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the JVM's sources, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory.
> 
> Indexing capabilities utilizing the enhancement:
> <img width="960" alt="java" src="https://user-images.githubusercontent.com/32636402/197784819-67ec7de4-7e27-4f33-b738-59b75a9e4403.PNG">
> <img width="787" alt="escape" src="https://user-images.githubusercontent.com/32636402/197784843-df8621a8-7b0a-42da-86f4-3afb92de0f71.PNG">

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Include extra directories required by HotSpot in HotSpot only workspaces

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10853/files
  - new: https://git.openjdk.org/jdk/pull/10853/files/4e468aad..2a591cb5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=08-09

  Stats: 13 lines in 1 file changed: 12 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10853.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10853/head:pull/10853

PR: https://git.openjdk.org/jdk/pull/10853


From serb at openjdk.org  Thu Oct 27 07:28:26 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 27 Oct 2022 07:28:26 GMT
Subject: RFR: 8295970: Add jdk_vector tests in GHA
In-Reply-To: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
Message-ID: <pBaDcDPQ_MxjLRcXCfFZIRaZKNnWlyCP6IZyzIDuLME=.8d4bc1e6-66db-45b9-9a3d-e314343c8826@github.com>

On Thu, 27 Oct 2022 03:53:13 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> As discussed here https://github.com/openjdk/jdk/pull/10807#pullrequestreview-1150314487 , it would be better to add the vector api tests in GHA.
> 
> Thanks.
> Best regards,
> Jie

Probably it will be possible to select an additional tests dynamically based on changed module? Using the same logic as the labels in the PR?

-------------

PR: https://git.openjdk.org/jdk/pull/10879


From jiefu at openjdk.org  Thu Oct 27 09:35:32 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Thu, 27 Oct 2022 09:35:32 GMT
Subject: RFR: 8295970: Add jdk_vector tests in GHA
In-Reply-To: <pBaDcDPQ_MxjLRcXCfFZIRaZKNnWlyCP6IZyzIDuLME=.8d4bc1e6-66db-45b9-9a3d-e314343c8826@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
 <pBaDcDPQ_MxjLRcXCfFZIRaZKNnWlyCP6IZyzIDuLME=.8d4bc1e6-66db-45b9-9a3d-e314343c8826@github.com>
Message-ID: <dwGRvHDTjkjpTu8s9dVSzBRJL7mS2eeDfDnd16OxYOo=.58a2aced-a862-4e57-b829-296444c025cb@github.com>

On Thu, 27 Oct 2022 07:24:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Probably it will be possible to select an additional tests dynamically based on changed module? Using the same logic as the labels in the PR?

Thanks @mrserb for your suggestion.

Dynamical testing configuration would increase the GHA complexity, which seems not worth it for jdk_vector.
This is because all 3 tier1_part* and jdk_vector took about 5 min to run according to Oracle's internal testing times.

So I think it's fine to add it in GHA directly.
Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10879


From erikj at openjdk.org  Thu Oct 27 14:01:27 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 27 Oct 2022 14:01:27 GMT
Subject: RFR: 8295970: Add jdk_vector tests in GHA
In-Reply-To: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
Message-ID: <DF5pLP7nSoMxJ_pwvFyyJAJZuS0nkqeVYA9HaDxtVRQ=.aa16537c-6d94-4ea7-bb0e-96cf8cc8ac48@github.com>

On Thu, 27 Oct 2022 03:53:13 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> As discussed here https://github.com/openjdk/jdk/pull/10807#pullrequestreview-1150314487 , it would be better to add the vector api tests in GHA.
> 
> Thanks.
> Best regards,
> Jie

The default set of tests included in GHA is currently defined to be exactly tier1. That is the set of tests that we have collectively agreed on represents a reasonably sized set that gives the best coverage for the time spent (at least that's the intention of tier1). The time spent here is probably the most important variable, as whatever we put here, everyone runs all the time in their PRs and PFs. Adding 5 minutes may not seem like much, but multiplied with platforms and all the users and PRs it adds up to a lot. Also imagine if more components would want to add to the set, pointing to this change as a precedent ,adding another 5 minutes, and then another 5 minutes, eventually the reasonable size of the test set becomes completely unreasonable.

My point is that we can't just add more and more to GHA on a whim. The current agreement is for it to be exactly tier1. If you can't motivate that your tests should be part of tier1, then I find it pretty hard to motivate that it should be part of GHA. I don't know enough about these tests to know if they should fit in tier1/GHA or not, I'm just pointing out that we need to keep a pretty high bar to avoid bloating the set.

For this particular issue, would it be possible to define a minimal set of vector api tests that would have discovered the problem in https://github.com/openjdk/jdk/pull/10807 without taking 5 minutes? Perhaps the better solution here would be to allow a single or very few specific tests into tier1?

-------------

PR: https://git.openjdk.org/jdk/pull/10879


From jiefu at openjdk.org  Thu Oct 27 14:34:27 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Thu, 27 Oct 2022 14:34:27 GMT
Subject: RFR: 8295970: Add jdk_vector tests in GHA
In-Reply-To: <DF5pLP7nSoMxJ_pwvFyyJAJZuS0nkqeVYA9HaDxtVRQ=.aa16537c-6d94-4ea7-bb0e-96cf8cc8ac48@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
 <DF5pLP7nSoMxJ_pwvFyyJAJZuS0nkqeVYA9HaDxtVRQ=.aa16537c-6d94-4ea7-bb0e-96cf8cc8ac48@github.com>
Message-ID: <5HAVWxC1EGAsZQv-I3onnGDDh7JCvd9Tfo3JUZqpqSY=.d1ab9b5b-8042-4700-b16f-971f8fc1223c@github.com>

On Thu, 27 Oct 2022 13:57:47 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The default set of tests included in GHA is currently defined to be exactly tier1. That is the set of tests that we have collectively agreed on represents a reasonably sized set that gives the best coverage for the time spent (at least that's the intention of tier1). The time spent here is probably the most important variable, as whatever we put here, everyone runs all the time in their PRs and PFs. Adding 5 minutes may not seem like much, but multiplied with platforms and all the users and PRs it adds up to a lot. Also imagine if more components would want to add to the set, pointing to this change as a precedent ,adding another 5 minutes, and then another 5 minutes, eventually the reasonable size of the test set becomes completely unreasonable.
> 
> My point is that we can't just add more and more to GHA on a whim. The current agreement is for it to be exactly tier1. If you can't motivate that your tests should be part of tier1, then I find it pretty hard to motivate that it should be part of GHA. I don't know enough about these tests to know if they should fit in tier1/GHA or not, I'm just pointing out that we need to keep a pretty high bar to avoid bloating the set.

Okay.
I got your point.
So only tier1 tests can be tested in GHA.

> 
> For this particular issue, would it be possible to define a minimal set of vector api tests that would have discovered the problem in #10807 without taking 5 minutes? Perhaps the better solution here would be to allow a single or very few specific tests into tier1?

I'm afraid it's hard to prevent bugs like https://github.com/openjdk/jdk/pull/10807 by just adding a single or very few specific tests into tier1.

So can we add jdk_vector (which is still in incubation) into jdk/tier1 group?  @vnkozlov

-------------

PR: https://git.openjdk.org/jdk/pull/10879


From aph at openjdk.org  Thu Oct 27 15:34:29 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 27 Oct 2022 15:34:29 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
Message-ID: <mONTltwdZAxBicODkKzFC8_2aspIJNJubU1NekApPGk=.75db6050-43b5-4010-9935-fd960565f2cc@github.com>

On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>> 
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>> 
>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
>> 
>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

Thanks everyone for your contributions.

I think we have a good solution:
1. Add my "fast" alternative RestoreMXCSR code, and use =1 and =2 levels of checking, as suggested by John Rose. Don't enable RestoreMXCSR by default: it should be 0 (no check).
2. Warn and restore the MXCSR at safepoints. This could be a hard error rather than a warning; not sure. At least we wouldn't have silent corruption.
Everyone happy?

-------------

PR: https://git.openjdk.org/jdk/pull/10661


From kvn at openjdk.org  Thu Oct 27 17:03:30 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 27 Oct 2022 17:03:30 GMT
Subject: RFR: 8295970: Add jdk_vector tests in GHA
In-Reply-To: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
Message-ID: <cDsvdrqT0X5dXPyOyQ6j21MmSZzOx9I2Y2NCn9DfZ2Q=.0aee78af-1541-49af-9bd6-35145a3afc95@github.com>

On Thu, 27 Oct 2022 03:53:13 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> As discussed here https://github.com/openjdk/jdk/pull/10807#pullrequestreview-1150314487 , it would be better to add the vector api tests in GHA.
> 
> Thanks.
> Best regards,
> Jie

I think we can meet all requests by adding `jdk_vector_sanity` subset of vector tests similar to existing `jdk_svc_sanity`.
The motivation for that is to catch obvious bugs in vector code generation on 32-bit platforms and aarch64 very early.
We, in Oracle, help to test 64 bits but it is not enough I think.
Vector API is stable enough already and I think we can have some sanity checks for it in tier1.
The only issue is to find subset of tests.

-------------

PR: https://git.openjdk.org/jdk/pull/10879


From jjg at openjdk.org  Thu Oct 27 21:08:53 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 27 Oct 2022 21:08:53 GMT
Subject: RFR: JDK-8295914: Add a header to generated HTML files in specs
Message-ID: <eUpFTOdX0nYRxTURyfZC0F-FwqWM5PQbvUaGZ4QjABI=.75fb4ee7-b6e5-4c22-a555-e98d9a7d03e1@github.com>

Please review some updates to the parts of the build system related to building the documentation.

-------------

Commit messages:
 - JDK-8295914: Add a header to generated HTML files in specs

Changes: https://git.openjdk.org/jdk/pull/10891/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10891&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295914
  Stats: 144 lines in 3 files changed: 139 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10891.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10891/head:pull/10891

PR: https://git.openjdk.org/jdk/pull/10891


From serb at openjdk.org  Thu Oct 27 22:24:17 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 27 Oct 2022 22:24:17 GMT
Subject: RFR: 8295812: Skip the "half float" support in LittleCMS during the
 build
Message-ID: <F9XVuZZYovezop61nzuHLN6OKXlzp4hv4cme84f2aRg=.7966ac12-b6a3-49d1-bbfc-0fefccb5ba90@github.com>

The Java2d do not use "half" float in the image layouts, so we can disable it in the LittleCMS library during the build. It is possible to do using [this](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/liblcms/lcms2.h#L85) public option:


// Uncomment to get rid of the tables for "half" float support
// #define CMS_NO_HALF_SUPPORT 1


This change cuts not only the unused by java2d functions but also [such](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.desktop/share/native/liblcms/cmshalf.c#L63) tables.

The size of liblcms decreased by 20 kB on Linux(536024 vs 515152) and 15 kB on windows(246784 vs 231424). On macOS the  win is only 300 bytes.

-------------

Commit messages:
 - 8295812: Skip the "half float" support in LittleCMS during the build

Changes: https://git.openjdk.org/jdk/pull/10830/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10830&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295812
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10830.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10830/head:pull/10830

PR: https://git.openjdk.org/jdk/pull/10830


From jiefu at openjdk.org  Fri Oct 28 07:19:31 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 28 Oct 2022 07:19:31 GMT
Subject: RFR: 8295970: Add jdk_vector tests in GHA [v2]
In-Reply-To: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
Message-ID: <8uMsheGwjIBbgf1nJeYkCR4Pt_ddbnq4WVKMRPwS7C0=.c59b10eb-67e1-439c-936e-857c8430c520@github.com>

> Hi all,
> 
> As discussed here https://github.com/openjdk/jdk/pull/10807#pullrequestreview-1150314487 , it would be better to add the vector api tests in GHA.
> 
> Thanks.
> Best regards,
> Jie

Jie Fu 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 four additional commits since the last revision:

 - Add jdk_vector_sanity test group
 - Merge branch 'master' into JDK-8295970
 - Revert changes in test.yml
 - 8295970: Add jdk_vector tests in GHA

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10879/files
  - new: https://git.openjdk.org/jdk/pull/10879/files/a44b43e8..f901b907

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10879&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10879&range=00-01

  Stats: 994 lines in 50 files changed: 687 ins; 138 del; 169 mod
  Patch: https://git.openjdk.org/jdk/pull/10879.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10879/head:pull/10879

PR: https://git.openjdk.org/jdk/pull/10879


From jiefu at openjdk.org  Fri Oct 28 07:25:27 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 28 Oct 2022 07:25:27 GMT
Subject: RFR: 8295970: Add jdk_vector tests in GHA
In-Reply-To: <cDsvdrqT0X5dXPyOyQ6j21MmSZzOx9I2Y2NCn9DfZ2Q=.0aee78af-1541-49af-9bd6-35145a3afc95@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
 <cDsvdrqT0X5dXPyOyQ6j21MmSZzOx9I2Y2NCn9DfZ2Q=.0aee78af-1541-49af-9bd6-35145a3afc95@github.com>
Message-ID: <qii389Hknfxf1NLNTj4D7Tqef0WC_tens2e8UrJWxu0=.34de9779-e874-4e53-bc89-6391101652b3@github.com>

On Thu, 27 Oct 2022 17:01:12 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I think we can meet all requests by adding `jdk_vector_sanity` subset of vector tests similar to existing `jdk_svc_sanity`. The motivation for that is to catch obvious bugs in vector code generation on 32-bit platforms and aarch64 very early. We, in Oracle, help to test 64 bits but it is not enough I think. Vector API is stable enough already and I think we can have some sanity checks for it in tier1. The only issue is to find subset of tests.

Good suggestion!
And the `jdk_vector_sanity` test group had been added.

The subset is selected as in the following picture (red in the picture).
The XMaxVector tests are selected because they will be 512 vectors on x86/AVX512 and 256 vectors on x86/AVX2.
And for most cases, people would like to use the max length vectors.
Thanks.

<img width="310" alt="image" src="https://user-images.githubusercontent.com/19923746/198526855-f1adb163-f6cf-4f38-b76b-c35c06337174.png">

-------------

PR: https://git.openjdk.org/jdk/pull/10879


From erikj at openjdk.org  Fri Oct 28 13:45:30 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 28 Oct 2022 13:45:30 GMT
Subject: RFR: 8295970: Add jdk_vector tests in GHA [v2]
In-Reply-To: <8uMsheGwjIBbgf1nJeYkCR4Pt_ddbnq4WVKMRPwS7C0=.c59b10eb-67e1-439c-936e-857c8430c520@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
 <8uMsheGwjIBbgf1nJeYkCR4Pt_ddbnq4WVKMRPwS7C0=.c59b10eb-67e1-439c-936e-857c8430c520@github.com>
Message-ID: <v87rbwRSX4_39wqbvRXaWhg0Vwol0Z1Yw6w73UiAzLo=.bf225c55-8873-4bbf-9b17-0890c9b0f7d4@github.com>

On Fri, 28 Oct 2022 07:19:31 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> As discussed here https://github.com/openjdk/jdk/pull/10807#pullrequestreview-1150314487 , it would be better to add the vector api tests in GHA.
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu 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 four additional commits since the last revision:
> 
>  - Add jdk_vector_sanity test group
>  - Merge branch 'master' into JDK-8295970
>  - Revert changes in test.yml
>  - 8295970: Add jdk_vector tests in GHA

I think you need to add at least one other label than `build` to this now to make sure the right people can have a say in the change.

-------------

PR: https://git.openjdk.org/jdk/pull/10879


From erikj at openjdk.org  Fri Oct 28 13:46:25 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 28 Oct 2022 13:46:25 GMT
Subject: RFR: 8295812: Skip the "half float" support in LittleCMS during
 the build
In-Reply-To: <F9XVuZZYovezop61nzuHLN6OKXlzp4hv4cme84f2aRg=.7966ac12-b6a3-49d1-bbfc-0fefccb5ba90@github.com>
References: <F9XVuZZYovezop61nzuHLN6OKXlzp4hv4cme84f2aRg=.7966ac12-b6a3-49d1-bbfc-0fefccb5ba90@github.com>
Message-ID: <fzPiKkEBnm3Kuq7-txl6edDTKjclS6W6_-ps92w9MHk=.d6c456ad-051a-4a04-9170-b4f73b8c3379@github.com>

On Sun, 23 Oct 2022 20:10:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The Java2d do not use "half" float in the image layouts, so we can disable it in the LittleCMS library during the build. It is possible to do using [this](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/liblcms/lcms2.h#L85) public option:
> 
> 
> // Uncomment to get rid of the tables for "half" float support
> // #define CMS_NO_HALF_SUPPORT 1
> 
> 
> This change cuts not only the unused by java2d functions but also [such](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.desktop/share/native/liblcms/cmshalf.c#L63) tables.
> 
> The size of liblcms decreased by 20 kB on Linux(536024 vs 515152) and 15 kB on windows(246784 vs 231424). On macOS the  win is only 300 bytes.

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10830


From jwaters at openjdk.org  Fri Oct 28 13:55:10 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 28 Oct 2022 13:55:10 GMT
Subject: RFR: 8295990: Improve setting of strip flags in make
Message-ID: <KzCsmQL1zGCgtc0FaQgGBWCCVW3DmIl_Vw5Zz8FwmTQ=.b25575dd-474a-4950-af89-0c3078b5d3c4@github.com>

Strip currently has its flags set by guessing based on the OS, it would be more appropriate to instead set them based on properly checking the strip binary instead of speculating what the correct flags are based on the compiler and OS.

-------------

Commit messages:
 - Merge branch 'openjdk:master' into patch-1
 - Add more documentation
 - Replace with the actual new check
 - Little documentation doesn't hurt
 - Prepare for actual changes
 - Update flags-other.m4
 - This is getting annoying
 - -V doesn't work with MacOS strip
 - Get output from strip to search for useful information
 - Update flags-other.m4
 - ... and 2 more: https://git.openjdk.org/jdk/compare/823fd4a9...e572f95f

Changes: https://git.openjdk.org/jdk/pull/10882/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10882&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295990
  Stats: 27 lines in 2 files changed: 19 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10882.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10882/head:pull/10882

PR: https://git.openjdk.org/jdk/pull/10882


From erikj at openjdk.org  Fri Oct 28 13:57:32 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 28 Oct 2022 13:57:32 GMT
Subject: RFR: JDK-8295914: Add a header to generated HTML files in specs
In-Reply-To: <eUpFTOdX0nYRxTURyfZC0F-FwqWM5PQbvUaGZ4QjABI=.75fb4ee7-b6e5-4c22-a555-e98d9a7d03e1@github.com>
References: <eUpFTOdX0nYRxTURyfZC0F-FwqWM5PQbvUaGZ4QjABI=.75fb4ee7-b6e5-4c22-a555-e98d9a7d03e1@github.com>
Message-ID: <ZjV6RVlNxs-vai4yshsuzLjOcqwnDxkZ3-PXHIYDVVA=.d5530901-843d-4984-a434-36a558fb9eb3@github.com>

On Thu, 27 Oct 2022 20:50:04 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some updates to the parts of the build system related to building the documentation.

Build changes look fine in general.

make/Docs.gmk line 598:

> 596:   # Unset the following to suppress the link to the tool guides
> 597:   NAV_LINK_GUIDES = --nav-link-guides
> 598:   HEADER_RIGHT_SIDE_INFO = '<strong>$(subst &amp;,&,$(JDK_SHORT_NAME))$(DRAFT_MARKER_STR)</strong>'

I think these assignments should just be `:=` unless you specifically need them to be lazy evaluated. We avoid the `=` lazy evaluation unless we specifically need it. I don't see a reason for that to be needed here though. Both JDK_SHORT_NAME and DRAFT_MARKER_STR are defined when these lines are reached.

-------------

PR: https://git.openjdk.org/jdk/pull/10891


From jiefu at openjdk.org  Fri Oct 28 13:57:36 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 28 Oct 2022 13:57:36 GMT
Subject: RFR: 8295970: Add jdk_vector tests in GHA [v2]
In-Reply-To: <v87rbwRSX4_39wqbvRXaWhg0Vwol0Z1Yw6w73UiAzLo=.bf225c55-8873-4bbf-9b17-0890c9b0f7d4@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
 <8uMsheGwjIBbgf1nJeYkCR4Pt_ddbnq4WVKMRPwS7C0=.c59b10eb-67e1-439c-936e-857c8430c520@github.com>
 <v87rbwRSX4_39wqbvRXaWhg0Vwol0Z1Yw6w73UiAzLo=.bf225c55-8873-4bbf-9b17-0890c9b0f7d4@github.com>
Message-ID: <Okdrw9P0k-bavhqMSxNjbQHK_kS9NXm4DsMtsMOKZIY=.e75806a0-2cf6-4dc3-8a8f-1289bac02a31@github.com>

On Fri, 28 Oct 2022 13:41:28 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I think you need to add at least one other label than `build` to this now to make sure the right people can have a say in the change.

Done.
Thanks @erikj79 .

-------------

PR: https://git.openjdk.org/jdk/pull/10879


From erikj at openjdk.org  Fri Oct 28 17:04:22 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 28 Oct 2022 17:04:22 GMT
Subject: RFR: 8295990: Improve make handling of strip flags
In-Reply-To: <KzCsmQL1zGCgtc0FaQgGBWCCVW3DmIl_Vw5Zz8FwmTQ=.b25575dd-474a-4950-af89-0c3078b5d3c4@github.com>
References: <KzCsmQL1zGCgtc0FaQgGBWCCVW3DmIl_Vw5Zz8FwmTQ=.b25575dd-474a-4950-af89-0c3078b5d3c4@github.com>
Message-ID: <m2M3fzHhR1s_S6som_iHTNaERyL40OpQuqQsJZqXWZo=.992272b1-630d-4fed-8dcd-db1ff36508ef@github.com>

On Thu, 27 Oct 2022 13:38:04 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Strip currently has its flags set by guessing based on the OS, it would be more appropriate to instead set them based on properly checking the strip binary instead of speculating what the correct flags are based on the compiler and OS.

This looks good assuming you have verified that it works on all the affected platforms.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10882


From jjg at openjdk.org  Sat Oct 29 00:18:24 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Sat, 29 Oct 2022 00:18:24 GMT
Subject: RFR: 8295653: Add a graph of the sealed class hierarchy for marked
 classes [v4]
In-Reply-To: <wewvGmw-sDeZIq9i1rKObXQAzjJ6P6yAb_Pd8dODTFY=.0add705a-48b3-4b43-b94e-8e4c74f756d7@github.com>
References: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
 <wewvGmw-sDeZIq9i1rKObXQAzjJ6P6yAb_Pd8dODTFY=.0add705a-48b3-4b43-b94e-8e4c74f756d7@github.com>
Message-ID: <GNO4nsqmRbYS27vaalBtocBMn2zqkRv_XG3NEZ7o_lE=.a9fd2596-676b-4fbd-b74e-c1e049863a54@github.com>

On Mon, 24 Oct 2022 20:44:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> It would be possible to mark classes with `@sealedGraph` to indicate that the sealed hierarchy should be rendered graphically in the JavaDocs. Classes not marked would be unaffected, creating an opt-in approach.
>> 
>> [Here](https://bugs.openjdk.org/secure/attachment/101126/Screen%20Shot%202022-10-19%20at%2012.47.47%20PM.png) is an example of MemoryLayout class rendering.
>> 
>> This feature has been developed in cooperation with Per Minborg.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename sealedGraphDotPath to sealedDotOutputDir

Some minor comments, but generally OK

make/Main.gmk line 1114:

> 1112:   docs-reference-api: docs-reference-api-graphs
> 1113: 
> 1114:   # We must generated javadoc first so we know what graphs are needed

grammar: `generated` -> `generate`

make/jdk/src/classes/build/tools/taglet/SealedGraph.java line 40:

> 38: import java.util.*;
> 39: import java.util.stream.Collectors;
> 40: 

Weirdly-sorted imports.  It is common practice to put `java.*` and `java.*` imports first.

make/jdk/src/classes/build/tools/taglet/SealedGraph.java line 106:

> 104:         } catch (FileNotFoundException e) {
> 105:             throw new RuntimeException(e);
> 106:         }

It's certainly unusual for a taglet `.toString` call to have this sort of side effect.   It would not the a showstopper, but have you checked whether this code is just executed once or multiple times?

-------------

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10761


From prr at openjdk.org  Sat Oct 29 01:24:30 2022
From: prr at openjdk.org (Phil Race)
Date: Sat, 29 Oct 2022 01:24:30 GMT
Subject: RFR: 8295812: Skip the "half float" support in LittleCMS during
 the build
In-Reply-To: <F9XVuZZYovezop61nzuHLN6OKXlzp4hv4cme84f2aRg=.7966ac12-b6a3-49d1-bbfc-0fefccb5ba90@github.com>
References: <F9XVuZZYovezop61nzuHLN6OKXlzp4hv4cme84f2aRg=.7966ac12-b6a3-49d1-bbfc-0fefccb5ba90@github.com>
Message-ID: <5UbDD-wSvZrHljXyriangpq6bHln-qdNtTucLF2omA0=.fdde0d6e-7377-4813-92b3-37fe67cb06dd@github.com>

On Sun, 23 Oct 2022 20:10:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The Java2d do not use "half" float in the image layouts, so we can disable it in the LittleCMS library during the build. It is possible to do using [this](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/liblcms/lcms2.h#L85) public option:
> 
> 
> // Uncomment to get rid of the tables for "half" float support
> // #define CMS_NO_HALF_SUPPORT 1
> 
> 
> This change cuts not only the unused by java2d functions but also [such](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.desktop/share/native/liblcms/cmshalf.c#L63) tables.
> 
> The size of liblcms decreased by 20 kB on Linux(536024 vs 515152) and 15 kB on windows(246784 vs 231424). On macOS the  win is only 300 bytes.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10830


From jwaters at openjdk.org  Sat Oct 29 07:12:40 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 29 Oct 2022 07:12:40 GMT
Subject: RFR: 8295990: Improve make handling of strip flags [v2]
In-Reply-To: <KzCsmQL1zGCgtc0FaQgGBWCCVW3DmIl_Vw5Zz8FwmTQ=.b25575dd-474a-4950-af89-0c3078b5d3c4@github.com>
References: <KzCsmQL1zGCgtc0FaQgGBWCCVW3DmIl_Vw5Zz8FwmTQ=.b25575dd-474a-4950-af89-0c3078b5d3c4@github.com>
Message-ID: <IV36fTfBIpyRGJOpnkYeAE8nf_ROyXz4m47j6Cul9L4=.b59f154d-223b-45f4-b624-d9ffd7c0c698@github.com>

> Strip currently has its flags set by guessing based on the OS, it would be more appropriate to instead set them based on properly checking the strip binary instead of speculating what the correct flags are based on the compiler and OS.

Julian Waters 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 13 additional commits since the last revision:

 - Merge branch 'openjdk:master' into patch-1
 - Merge branch 'openjdk:master' into patch-1
 - Add more documentation
 - Replace with the actual new check
 - Little documentation doesn't hurt
 - Prepare for actual changes
 - Update flags-other.m4
 - This is getting annoying
 - -V doesn't work with MacOS strip
 - Get output from strip to search for useful information
 - ... and 3 more: https://git.openjdk.org/jdk/compare/4a1577da...43f615d4

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10882/files
  - new: https://git.openjdk.org/jdk/pull/10882/files/e572f95f..43f615d4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10882&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10882&range=00-01

  Stats: 69 lines in 8 files changed: 18 ins; 36 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/10882.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10882/head:pull/10882

PR: https://git.openjdk.org/jdk/pull/10882


From jwaters at openjdk.org  Sat Oct 29 07:37:38 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 29 Oct 2022 07:37:38 GMT
Subject: RFR: 8295884: Implement IDE support for Eclipse [v11]
In-Reply-To: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
Message-ID: <BVkLbleZJbxHVWY3SVfljyXrJ81d-wg15aXMUWpoAgU=.a559b543-dc94-45ea-94b6-a2cdf1c64d6e@github.com>

> Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make and Ant integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK.
> 
> This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the JVM's sources, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory.
> 
> Indexing capabilities utilizing the enhancement:
> <img width="960" alt="java" src="https://user-images.githubusercontent.com/32636402/197784819-67ec7de4-7e27-4f33-b738-59b75a9e4403.PNG">
> <img width="787" alt="escape" src="https://user-images.githubusercontent.com/32636402/197784843-df8621a8-7b0a-42da-86f4-3afb92de0f71.PNG">

Julian Waters 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 15 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into eclipse
 - Include extra directories required by HotSpot in HotSpot only workspaces
 - SINGLE_DOLLAR is not required
 - Nuke accidental comment not meant to be added
 - Initial support for Language Settings Providers
 - Prevent Eclipse from automatically attaching binary parsers to workspaces including native code
 - Merge
 - Squash issue with commas
 - File operations should use MakeIO.gmk
 - Merge
 - ... and 5 more: https://git.openjdk.org/jdk/compare/4732a8f7...90a7d061

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10853/files
  - new: https://git.openjdk.org/jdk/pull/10853/files/2a591cb5..90a7d061

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=09-10

  Stats: 1353 lines in 72 files changed: 975 ins; 174 del; 204 mod
  Patch: https://git.openjdk.org/jdk/pull/10853.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10853/head:pull/10853

PR: https://git.openjdk.org/jdk/pull/10853


From alanb at openjdk.org  Sat Oct 29 08:02:20 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 29 Oct 2022 08:02:20 GMT
Subject: RFR: 8295970: Add jdk_vector tests in GHA
In-Reply-To: <qii389Hknfxf1NLNTj4D7Tqef0WC_tens2e8UrJWxu0=.34de9779-e874-4e53-bc89-6391101652b3@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
 <cDsvdrqT0X5dXPyOyQ6j21MmSZzOx9I2Y2NCn9DfZ2Q=.0aee78af-1541-49af-9bd6-35145a3afc95@github.com>
 <qii389Hknfxf1NLNTj4D7Tqef0WC_tens2e8UrJWxu0=.34de9779-e874-4e53-bc89-6391101652b3@github.com>
Message-ID: <-48VMcPym9w9jDnxkf2UTy7qFEDZwCR4PWgwtlroIiI=.bb3f67f1-e912-4e59-aaa5-25b32c062763@github.com>

On Fri, 28 Oct 2022 07:21:05 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Good suggestion!
> And the `jdk_vector_sanity` test group had been added.

In general, running a few fast sanity tests from several areas in tier1 seems a good idea. Having test lists in the TEST.group files isn't very appealing as they easily get out of the sync with the tests in the tree. I realise there are already some test lists in both the hotspot and jdk TEST.groups but it feels like it needs something better so that RunTests.gmk/jtreg can select the sanity tests to run. This is not an objection to this change proposed here, just a comment that this type of configuration is annoying to maintain.

-------------

PR: https://git.openjdk.org/jdk/pull/10879


From aivanov at openjdk.org  Sat Oct 29 12:14:25 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sat, 29 Oct 2022 12:14:25 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
Message-ID: <rzIw7fkMmSiQ4HJygtWh3SxVIIZg4QY0nvByxOYUyGs=.b878366e-a60f-410f-94ae-47b486f4e7b5@github.com>

On Mon, 24 Oct 2022 19:29:41 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert "Remove check for .properties from jcheck"
>>    
>>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>>  - Change trailing space and tab in values to unicode encoding
>
> src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 134:
> 
>> 132: 
>> 133: #SyncResolverImpl exceptions
>> 134: syncrsimpl.indexval = Index value out of range\u0020\u0020
> 
> prob. unnecessary

This case is similar the one you mentioned below. If this value is used in a string template or concatenation, the trailing white-space could be necessary; however, one space is probably enough.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From aivanov at openjdk.org  Sat Oct 29 13:22:09 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sat, 29 Oct 2022 13:22:09 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <4Npxj4pEaiqkJ2UBTsYb3xTHYseNBoj_3yshwocOIxw=.c701af52-62db-40c2-b3a3-90e47c44ed76@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

Trailing spaces in `LocaleNames_*` are only in two files:

- `src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_de.properties`
- `src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_sv.properties`

It is very unlikely these spaces are part of a country or language name. The former file contains a few trailing spaces, the latter ? only one.

src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_de.properties line 238:

> 236: cpp=Kreolisch-Portugiesische Sprache
> 237: crh=Krimtatarisch
> 238: crp=Kreolische Sprache\u0020

I'm pretty sure locale names shouldn't contain trailing spaces.

-------------

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10792


From jwaters at openjdk.org  Sat Oct 29 15:31:29 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 29 Oct 2022 15:31:29 GMT
Subject: RFR: 8295990: Improve make handling of strip flags [v2]
In-Reply-To: <IV36fTfBIpyRGJOpnkYeAE8nf_ROyXz4m47j6Cul9L4=.b59f154d-223b-45f4-b624-d9ffd7c0c698@github.com>
References: <KzCsmQL1zGCgtc0FaQgGBWCCVW3DmIl_Vw5Zz8FwmTQ=.b25575dd-474a-4950-af89-0c3078b5d3c4@github.com>
 <IV36fTfBIpyRGJOpnkYeAE8nf_ROyXz4m47j6Cul9L4=.b59f154d-223b-45f4-b624-d9ffd7c0c698@github.com>
Message-ID: <Lb5KNi5L-cC_LxsWXGQc_tMEbwV5e4EJYYGLEyDnzFQ=.726940d0-ba29-41b3-a4a3-531da3b7e2e0@github.com>

On Sat, 29 Oct 2022 07:12:40 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Strip currently has its flags set by guessing based on the OS, it would be more appropriate to instead set them based on properly checking the strip binary instead of speculating what the correct flags are based on the compiler and OS.
>
> Julian Waters 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 13 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-1
>  - Merge branch 'openjdk:master' into patch-1
>  - Add more documentation
>  - Replace with the actual new check
>  - Little documentation doesn't hurt
>  - Prepare for actual changes
>  - Update flags-other.m4
>  - This is getting annoying
>  - -V doesn't work with MacOS strip
>  - Get output from strip to search for useful information
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/633a3ca9...43f615d4

Tested successfully on Linux with gcc and clang, also with the platform specific strip utils targeting MacOS. Windows with Visual C++ (but importantly only with Visual C++) correctly does not perform the check since the toolchain never sets strip. This change seems to have unintentionally split the strip version from the toolchain type as well, instead categorizing it into 3 independent groups: GNU-like, IBM, and Xcode, which may be helpful in the future should any changes to strip be desired

-------------

PR: https://git.openjdk.org/jdk/pull/10882


From jwaters at openjdk.org  Sat Oct 29 15:33:52 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 29 Oct 2022 15:33:52 GMT
Subject: RFR: 8295990: Improve make handling of strip flags [v3]
In-Reply-To: <KzCsmQL1zGCgtc0FaQgGBWCCVW3DmIl_Vw5Zz8FwmTQ=.b25575dd-474a-4950-af89-0c3078b5d3c4@github.com>
References: <KzCsmQL1zGCgtc0FaQgGBWCCVW3DmIl_Vw5Zz8FwmTQ=.b25575dd-474a-4950-af89-0c3078b5d3c4@github.com>
Message-ID: <lcJ-F1lbdw-R8LJCbrmPTkPBgWc5zfXpaTBa5KukM_4=.be7239f9-6590-49f4-aa57-5f1dc76923e4@github.com>

> Strip currently has its flags set by guessing based on the OS, it would be more appropriate to instead set them based on properly checking the strip binary instead of speculating what the correct flags are based on the compiler and OS.

Julian Waters 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 14 additional commits since the last revision:

 - Merge branch 'openjdk:master' into patch-1
 - Merge branch 'openjdk:master' into patch-1
 - Merge branch 'openjdk:master' into patch-1
 - Add more documentation
 - Replace with the actual new check
 - Little documentation doesn't hurt
 - Prepare for actual changes
 - Update flags-other.m4
 - This is getting annoying
 - -V doesn't work with MacOS strip
 - ... and 4 more: https://git.openjdk.org/jdk/compare/ddcee269...a940c741

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10882/files
  - new: https://git.openjdk.org/jdk/pull/10882/files/43f615d4..a940c741

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10882&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10882&range=01-02

  Stats: 201 lines in 8 files changed: 163 ins; 20 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/10882.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10882/head:pull/10882

PR: https://git.openjdk.org/jdk/pull/10882


From jwaters at openjdk.org  Sat Oct 29 15:36:42 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 29 Oct 2022 15:36:42 GMT
Subject: RFR: 8295990: Improve make handling of strip flags [v4]
In-Reply-To: <KzCsmQL1zGCgtc0FaQgGBWCCVW3DmIl_Vw5Zz8FwmTQ=.b25575dd-474a-4950-af89-0c3078b5d3c4@github.com>
References: <KzCsmQL1zGCgtc0FaQgGBWCCVW3DmIl_Vw5Zz8FwmTQ=.b25575dd-474a-4950-af89-0c3078b5d3c4@github.com>
Message-ID: <l6chb4cTGsHUoHETDQ_St57OvySzHCKUweXJn6rRLWg=.62c62ecc-1002-4edb-9b8b-9ff6b8adc092@github.com>

> Strip currently has its flags set by guessing based on the OS, it would be more appropriate to instead set them based on properly checking the strip binary instead of speculating what the correct flags are based on the compiler and OS.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Comment can be made more accurate

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10882/files
  - new: https://git.openjdk.org/jdk/pull/10882/files/a940c741..d831ca59

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10882&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10882&range=02-03

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10882.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10882/head:pull/10882

PR: https://git.openjdk.org/jdk/pull/10882


From serb at openjdk.org  Sat Oct 29 23:12:25 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 29 Oct 2022 23:12:25 GMT
Subject: RFR: 8295970: Add jdk_vector tests in GHA [v2]
In-Reply-To: <8uMsheGwjIBbgf1nJeYkCR4Pt_ddbnq4WVKMRPwS7C0=.c59b10eb-67e1-439c-936e-857c8430c520@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
 <8uMsheGwjIBbgf1nJeYkCR4Pt_ddbnq4WVKMRPwS7C0=.c59b10eb-67e1-439c-936e-857c8430c520@github.com>
Message-ID: <1INzCtXMkzWk2GmbTkXaoP1CAeCgNLdvsWtfwBdcES0=.3b35c7d1-32c0-4422-82a9-e38790b3db3a@github.com>

On Fri, 28 Oct 2022 07:19:31 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> As discussed here https://github.com/openjdk/jdk/pull/10807#pullrequestreview-1150314487 , it would be better to add the vector api tests in GHA.
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu 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 four additional commits since the last revision:
> 
>  - Add jdk_vector_sanity test group
>  - Merge branch 'master' into JDK-8295970
>  - Revert changes in test.yml
>  - 8295970: Add jdk_vector tests in GHA

What about possibility to run additional group of the test by passing somehow the name of group to the GA, via label or via /test cmd, or via parameter to the specific task in GA?

-------------

PR: https://git.openjdk.org/jdk/pull/10879


From jiefu at openjdk.org  Sun Oct 30 12:07:25 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Sun, 30 Oct 2022 12:07:25 GMT
Subject: RFR: 8295970: Add jdk_vector tests in GHA
In-Reply-To: <-48VMcPym9w9jDnxkf2UTy7qFEDZwCR4PWgwtlroIiI=.bb3f67f1-e912-4e59-aaa5-25b32c062763@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
 <cDsvdrqT0X5dXPyOyQ6j21MmSZzOx9I2Y2NCn9DfZ2Q=.0aee78af-1541-49af-9bd6-35145a3afc95@github.com>
 <qii389Hknfxf1NLNTj4D7Tqef0WC_tens2e8UrJWxu0=.34de9779-e874-4e53-bc89-6391101652b3@github.com>
 <-48VMcPym9w9jDnxkf2UTy7qFEDZwCR4PWgwtlroIiI=.bb3f67f1-e912-4e59-aaa5-25b32c062763@github.com>
Message-ID: <oNKudcYJnA7jZYGUe1jBNtwsfkOIdw3aNjBSda-FmEc=.c7511871-a2dc-4da7-ae3c-5c82c46a843c@github.com>

On Sat, 29 Oct 2022 07:58:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I realise there are already some test lists in both the hotspot and jdk TEST.groups but it feels like it needs something better so that RunTests.gmk/jtreg can select the sanity tests to run.

Thanks @AlanBateman for this comment.
Is there an existing example to follow?
Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10879


From jiefu at openjdk.org  Sun Oct 30 12:19:34 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Sun, 30 Oct 2022 12:19:34 GMT
Subject: RFR: 8295970: Add jdk_vector tests in GHA [v2]
In-Reply-To: <1INzCtXMkzWk2GmbTkXaoP1CAeCgNLdvsWtfwBdcES0=.3b35c7d1-32c0-4422-82a9-e38790b3db3a@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
 <8uMsheGwjIBbgf1nJeYkCR4Pt_ddbnq4WVKMRPwS7C0=.c59b10eb-67e1-439c-936e-857c8430c520@github.com>
 <1INzCtXMkzWk2GmbTkXaoP1CAeCgNLdvsWtfwBdcES0=.3b35c7d1-32c0-4422-82a9-e38790b3db3a@github.com>
Message-ID: <yv2VWqHf32GaRecTlMUZ5PFuoFs8bdrysCQkt78hROI=.5035e8e6-59a8-4ec0-a745-e068d59628d3@github.com>

On Sat, 29 Oct 2022 23:08:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> What about possibility to run additional group of the test by passing somehow the name of group to the GA, via label or via /test cmd, or via parameter to the specific task in GA?

Well, it sounds good to run specific tests via label or /test cmd.
However, if the vector api tests are OK to be added in tier1 I think it's fine to run them in GHA directly.

Maybe, we can implement this feature in the future not only for vector api tests but also for other tests too.

-------------

PR: https://git.openjdk.org/jdk/pull/10879


From jwaters at openjdk.org  Mon Oct 31 03:30:12 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 31 Oct 2022 03:30:12 GMT
Subject: RFR: 8296115: Allow for compiling the JDK with strict standards
 conformance
Message-ID: <yaKDZVxxdPLeOt-Z2Mw9Mjknb9q1tg3Pp2PRYfHihiQ=.d7c3320f-a9ae-4779-9bd5-00a9366a8bce@github.com>

[JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499) proposes to set the -permissive- flag for the Microsoft Visual C++ compiler, to enforce strict standards conformance during compilation, making native code behave more strictly. While adding it to default builds is likely not practical given how much testing is required, as an option it can prove helpful in finding areas of native code that are not conformant to the standard. Instead of applying this to just one compiler, we can also include this for every compiler that has support for such a strict mode, which this change does.

-------------

Commit messages:
 - Format
 - Keep docs up to date
 - New --enable-conforming-compilation option

Changes: https://git.openjdk.org/jdk/pull/10912/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10912&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296115
  Stats: 43 lines in 5 files changed: 41 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10912.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10912/head:pull/10912

PR: https://git.openjdk.org/jdk/pull/10912


From jwaters at openjdk.org  Mon Oct 31 06:27:08 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 31 Oct 2022 06:27:08 GMT
Subject: RFR: 8295990: Improve make handling of strip flags [v5]
In-Reply-To: <KzCsmQL1zGCgtc0FaQgGBWCCVW3DmIl_Vw5Zz8FwmTQ=.b25575dd-474a-4950-af89-0c3078b5d3c4@github.com>
References: <KzCsmQL1zGCgtc0FaQgGBWCCVW3DmIl_Vw5Zz8FwmTQ=.b25575dd-474a-4950-af89-0c3078b5d3c4@github.com>
Message-ID: <aLahwUV9tlGm3zKttjcMzgzSJh_6i9TpHgcXTn9sTcI=.48d6a0a0-883c-425d-9a83-9ca75f6e5d22@github.com>

> Strip currently has its flags set by guessing based on the OS, it would be more appropriate to instead set them based on properly checking the strip binary instead of speculating what the correct flags are based on the compiler and OS.

Julian Waters 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 16 additional commits since the last revision:

 - Merge branch 'openjdk:master' into patch-1
 - Comment can be made more accurate
 - Merge branch 'openjdk:master' into patch-1
 - Merge branch 'openjdk:master' into patch-1
 - Merge branch 'openjdk:master' into patch-1
 - Add more documentation
 - Replace with the actual new check
 - Little documentation doesn't hurt
 - Prepare for actual changes
 - Update flags-other.m4
 - ... and 6 more: https://git.openjdk.org/jdk/compare/3e5e6e0e...df46df9d

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10882/files
  - new: https://git.openjdk.org/jdk/pull/10882/files/d831ca59..df46df9d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10882&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10882&range=03-04

  Stats: 173 lines in 11 files changed: 89 ins; 33 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/10882.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10882/head:pull/10882

PR: https://git.openjdk.org/jdk/pull/10882


From erikj at openjdk.org  Mon Oct 31 13:00:34 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 31 Oct 2022 13:00:34 GMT
Subject: RFR: 8295990: Improve make handling of strip flags [v5]
In-Reply-To: <aLahwUV9tlGm3zKttjcMzgzSJh_6i9TpHgcXTn9sTcI=.48d6a0a0-883c-425d-9a83-9ca75f6e5d22@github.com>
References: <KzCsmQL1zGCgtc0FaQgGBWCCVW3DmIl_Vw5Zz8FwmTQ=.b25575dd-474a-4950-af89-0c3078b5d3c4@github.com>
 <aLahwUV9tlGm3zKttjcMzgzSJh_6i9TpHgcXTn9sTcI=.48d6a0a0-883c-425d-9a83-9ca75f6e5d22@github.com>
Message-ID: <qzQOeWditVp_fVxL9kKU3leA6SYpFjGyQyWPtz2wY9k=.55e2cc05-4ca5-4b4a-b022-8da6b22753a7@github.com>

On Mon, 31 Oct 2022 06:27:08 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Strip currently has its flags set by guessing based on the OS, it would be more appropriate to instead set them based on properly checking the strip binary instead of speculating what the correct flags are based on the compiler and OS.
>
> Julian Waters 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 16 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-1
>  - Comment can be made more accurate
>  - Merge branch 'openjdk:master' into patch-1
>  - Merge branch 'openjdk:master' into patch-1
>  - Merge branch 'openjdk:master' into patch-1
>  - Add more documentation
>  - Replace with the actual new check
>  - Little documentation doesn't hurt
>  - Prepare for actual changes
>  - Update flags-other.m4
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/028804e4...df46df9d

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10882


From erikj at openjdk.org  Mon Oct 31 13:06:27 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 31 Oct 2022 13:06:27 GMT
Subject: RFR: 8296115: Allow for compiling the JDK with strict standards
 conformance
In-Reply-To: <yaKDZVxxdPLeOt-Z2Mw9Mjknb9q1tg3Pp2PRYfHihiQ=.d7c3320f-a9ae-4779-9bd5-00a9366a8bce@github.com>
References: <yaKDZVxxdPLeOt-Z2Mw9Mjknb9q1tg3Pp2PRYfHihiQ=.d7c3320f-a9ae-4779-9bd5-00a9366a8bce@github.com>
Message-ID: <UlPDVRzWZiKwADWi157HV2xvMEjusjDDO7KTs9ikIjU=.24903a4b-650c-4af4-8e2a-024b5960bfce@github.com>

On Mon, 31 Oct 2022 03:22:32 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499) proposes to set the -permissive- flag for the Microsoft Visual C++ compiler, to enforce strict standards conformance during compilation, making native code behave more strictly. While adding it to default builds is likely not practical given how much testing is required, as an option it can prove helpful in finding areas of native code that are not conformant to the standard. Instead of applying this to just one compiler, we can also include this for every compiler that has support for such a strict mode, which this change does.

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10912


From joe.darcy at oracle.com  Mon Oct 31 15:49:34 2022
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 31 Oct 2022 08:49:34 -0700
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <hrK9xz3FgxuqUlZNLWQuRpmw1Xzh_r9jVrtBRtlIinU=.d96d7349-fbbd-4026-9817-e009e9066701@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
 <BDA7SSW43tdWnrU2b44ntWews7s7ZCH5E9vgC2Qeu4A=.cf1bd3ad-c452-44b2-b3f2-da61d68feeb7@github.com>
 <hrK9xz3FgxuqUlZNLWQuRpmw1Xzh_r9jVrtBRtlIinU=.d96d7349-fbbd-4026-9817-e009e9066701@github.com>
Message-ID: <4e1bf2e9-592c-62b5-cb0a-43dc1b70b94a@oracle.com>

On 10/25/2022 7:27 AM, Andrew Haley wrote:
> On Thu, 20 Oct 2022 20:26:47 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:
>
>> The GCC bugs with `-ffast-math` only corrupts `FTZ` and `DAZ`.
>>
>> But `RC` and exception masks may be corrupted as well the same way and I believe the consequences are be similar (silent divergence in results during FP computations).
> I think we can catch the things that are likely, and will result in silent corruption. We should limit this, I think, to rounding modes and denormals-to-zero. I don't think we should bother with exception masks.
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/10661


In terms of the overhead of using floating-point expression evaluation 
as a guard, are there still platforms where operating on subnormal 
values is pathologically slower? Some generations of SPARC chips had 
that behavior where a subnormal multiply would take, say 10,000 cycles, 
rather than 3 or 4 since the subnormal operations were implemented via 
trap handling.

-Joe



From iris at openjdk.org  Mon Oct 31 17:16:24 2022
From: iris at openjdk.org (Iris Clark)
Date: Mon, 31 Oct 2022 17:16:24 GMT
Subject: RFR: JDK-8295914: Add a header to generated HTML files in specs
In-Reply-To: <eUpFTOdX0nYRxTURyfZC0F-FwqWM5PQbvUaGZ4QjABI=.75fb4ee7-b6e5-4c22-a555-e98d9a7d03e1@github.com>
References: <eUpFTOdX0nYRxTURyfZC0F-FwqWM5PQbvUaGZ4QjABI=.75fb4ee7-b6e5-4c22-a555-e98d9a7d03e1@github.com>
Message-ID: <kMenJtA-UwHzlLCwL6IuO2NQDeF26WKG3TcTaRK8n58=.1caefdb4-b423-4b3a-ad79-09029be53548@github.com>

On Thu, 27 Oct 2022 20:50:04 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some updates to the parts of the build system related to building the documentation.

Your changes look good!  Can't wait to see this in a promotion.

-------------

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10891


From aph-open at littlepinkcloud.com  Mon Oct 31 17:33:06 2022
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Mon, 31 Oct 2022 17:33:06 +0000
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <4e1bf2e9-592c-62b5-cb0a-43dc1b70b94a@oracle.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
 <BDA7SSW43tdWnrU2b44ntWews7s7ZCH5E9vgC2Qeu4A=.cf1bd3ad-c452-44b2-b3f2-da61d68feeb7@github.com>
 <hrK9xz3FgxuqUlZNLWQuRpmw1Xzh_r9jVrtBRtlIinU=.d96d7349-fbbd-4026-9817-e009e9066701@github.com>
 <4e1bf2e9-592c-62b5-cb0a-43dc1b70b94a@oracle.com>
Message-ID: <421d3cd4-3197-8041-e051-8b4cee5f1083@littlepinkcloud.com>

On 10/31/22 15:49, Joe Darcy wrote:
> In terms of the overhead of using floating-point expression evaluation
> as a guard, are there still platforms where operating on subnormal
> values is pathologically slower? Some generations of SPARC chips had
> that behavior where a subnormal multiply would take, say 10,000 cycles,
> rather than 3 or 4 since the subnormal operations were implemented via
> trap handling.

That's a very interesting point. I know it used to be the case that denormals
were handled by trapping to microcode, but there are good hardware algorithms
since Schwarz et al, 2003 [1]. This paper showed how with a little hardware,
such numbers can be handled close to the speed of normalized numbers.

I deliberately ran my tests on a ten-year-old CPU, but I guess I'd have to go
further back to find a bad case.

Anyway, I plan to

a. Restore the FPU CR after calls to dlopen(3).
b. Detect FPU CR corruption at safepoints, and print a warning. At least
    the user might find out that something is wrong.

I think this will avoid most cases of badness. I guess I'll need a CSR for
this?


[1] Hardware implementations of denormalized numbers, DOI:10.1109/ARITH.2003.1207662
Conference: Computer Arithmetic, 2003. Proceedings. 16th IEEE Symposium on

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671



From aph at openjdk.org  Mon Oct 31 17:48:17 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 31 Oct 2022 17:48:17 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
Message-ID: <_23f45GgIwXcJmH_ROBzCNrIEiwk_ho5Ic5IRoLOoZQ=.69e2715b-cea3-43e2-8569-4fb74416b86d@github.com>

On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>> 
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>> 
>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
>> 
>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

On 10/31/22 15:49, Joe Darcy wrote:
> In terms of the overhead of using floating-point expression evaluation
> as a guard, are there still platforms where operating on subnormal
> values is pathologically slower? Some generations of SPARC chips had
> that behavior where a subnormal multiply would take, say 10,000 cycles,
> rather than 3 or 4 since the subnormal operations were implemented via
> trap handling.

That's a very interesting point. I know it used to be the case that denormals
were handled by trapping to microcode, but there are good hardware algorithms
since Schwarz et al, 2003 [1]. This paper showed how with a little hardware,
such numbers can be handled close to the speed of normalized numbers.

I deliberately ran my tests on a ten-year-old CPU, but I guess I'd have to go
further back to find a bad case.

Anyway, I plan to

a. Restore the FPU CR after calls to dlopen(3).
b. Detect FPU CR corruption at safepoints, and print a warning. At least
    the user might find out that something is wrong.

I think this will avoid most cases of badness. I guess I'll need a CSR for
this?


[1] Hardware implementations of denormalized numbers, DOI:10.1109/ARITH.2003.1207662
Conference: Computer Arithmetic, 2003. Proceedings. 16th IEEE Symposium on

-------------

PR: https://git.openjdk.org/jdk/pull/10661


From jvernee at openjdk.org  Mon Oct 31 18:28:29 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 31 Oct 2022 18:28:29 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <_23f45GgIwXcJmH_ROBzCNrIEiwk_ho5Ic5IRoLOoZQ=.69e2715b-cea3-43e2-8569-4fb74416b86d@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
 <_23f45GgIwXcJmH_ROBzCNrIEiwk_ho5Ic5IRoLOoZQ=.69e2715b-cea3-43e2-8569-4fb74416b86d@github.com>
Message-ID: <jwj2pd5xfwZyMY9wup52Ve1FwwAazfAJdNPX_AyrG90=.f4a20605-e73a-4b88-9231-83bedd4880ff@github.com>

On Mon, 31 Oct 2022 17:44:07 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Anyway, I plan to
> 
> a. Restore the FPU CR after calls to dlopen(3).
> b. Detect FPU CR corruption at safepoints, and print a warning. At least
> the user might find out that something is wrong.

Doing (a) seems good. I can't say for sure whether (b) is a good idea. I guess you just have some call to verify the FPU, e.g. in `ParallelCleanupTask`? I assume you don't mean to change the code for polling safepoints.

CSR seems like a good idea, since it could be a change in observable behavior. (nice to leave a paper trail I think)

-------------

PR: https://git.openjdk.org/jdk/pull/10661


From aph at openjdk.org  Mon Oct 31 18:53:21 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 31 Oct 2022 18:53:21 GMT
Subject: RFR: 8295159: DSO created with -ffast-math breaks Java
 floating-point arithmetic [v7]
In-Reply-To: <jwj2pd5xfwZyMY9wup52Ve1FwwAazfAJdNPX_AyrG90=.f4a20605-e73a-4b88-9231-83bedd4880ff@github.com>
References: <5D-3Gy3hU2M8MhKgY2z_NwurLe6mnu9gi3Z08C3Tp-s=.a4d7662f-8ccf-4bc5-8712-4269f9f569a0@github.com>
 <bSqaxaEIoBnFzpZSkO_GEgh-3Z1zDVCKuOujzvYoN3g=.852b9244-7101-4431-9d5c-b10d25290a54@github.com>
 <_23f45GgIwXcJmH_ROBzCNrIEiwk_ho5Ic5IRoLOoZQ=.69e2715b-cea3-43e2-8569-4fb74416b86d@github.com>
 <jwj2pd5xfwZyMY9wup52Ve1FwwAazfAJdNPX_AyrG90=.f4a20605-e73a-4b88-9231-83bedd4880ff@github.com>
Message-ID: <zj3Sm_pYdAEJrT7ZK44KHs4HnCmno72RGZZFBjaA7kQ=.1c8567a5-fe0a-4ae1-8ab8-db4971f79e0c@github.com>

On Mon, 31 Oct 2022 18:25:57 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> > Anyway, I plan to
> > a. Restore the FPU CR after calls to dlopen(3).
> > b. Detect FPU CR corruption at safepoints, and print a warning. At least
> > the user might find out that something is wrong.
> 
> Doing (a) seems good. I can't say for sure whether (b) is a good idea. I guess you just have some call to verify the FPU, e.g. in `ParallelCleanupTask`? I assume you don't mean to change the code for polling safepoints.

My intention is only to do the FPU CR  check when there is an expensive operation such as moving to s safepoint. That we we won't see a significant slowdown. But we are pretty much guaranteed that the user won't get incorrect results without some sort of diagnostic.

> CSR seems like a good idea, since it could be a change in observable behavior. (nice to leave a paper trail I think)

Yep.

-------------

PR: https://git.openjdk.org/jdk/pull/10661


From mduigou at openjdk.org  Mon Oct 31 19:20:27 2022
From: mduigou at openjdk.org (Mike Duigou)
Date: Mon, 31 Oct 2022 19:20:27 GMT
Subject: RFR: 8294549: configure script should detect unsupported path
In-Reply-To: <INSePlc55Rszv4HetLtZS6-BnsZ2irY5hSeNTiipxwE=.55a00ecc-3f61-4615-96fd-7198a7b4ac63@github.com>
References: <INSePlc55Rszv4HetLtZS6-BnsZ2irY5hSeNTiipxwE=.55a00ecc-3f61-4615-96fd-7198a7b4ac63@github.com>
Message-ID: <F86KV8nPKQLzChM4MDG5Kqjs1xEnqW9wmNi91SHULy8=.c23e17de-e100-4a67-9084-b8d750ce4fd6@github.com>

On Thu, 29 Sep 2022 00:09:37 GMT, Mike Duigou <mduigou at openjdk.org> wrote:

> The OpenJDK build system does not support building when the source code resides on a path that contains a space. This requirement is documented in the build instructions but not enforced by the configure script.
> 
> This change adds an explicit checks to the wrapper `configure` script that fail the build if the source code to be built is located in a directory who's path contains a space character or the build path cannot be determined.
> 
> Includes some idiom modernization and shell scripting best practices changes.

My apologies for delay in responding. I had opted to make these changes to this file because I could isolate the changes to a single file. In order to implement the same logic in the "real" configure file at least some changes would be needed to this file in order to correctly pass a path containing spaces. I will look at moving the path check to the real configure file.

-------------

PR: https://git.openjdk.org/jdk/pull/10477


From jjg at openjdk.org  Mon Oct 31 22:56:25 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 31 Oct 2022 22:56:25 GMT
Subject: RFR: JDK-8295914: Add a header to generated HTML files in specs
In-Reply-To: <ZjV6RVlNxs-vai4yshsuzLjOcqwnDxkZ3-PXHIYDVVA=.d5530901-843d-4984-a434-36a558fb9eb3@github.com>
References: <eUpFTOdX0nYRxTURyfZC0F-FwqWM5PQbvUaGZ4QjABI=.75fb4ee7-b6e5-4c22-a555-e98d9a7d03e1@github.com>
 <ZjV6RVlNxs-vai4yshsuzLjOcqwnDxkZ3-PXHIYDVVA=.d5530901-843d-4984-a434-36a558fb9eb3@github.com>
Message-ID: <Yq7TSv5B9VaSqB6U16PPUzPXFIhJstQMH06C-9oL1ZY=.098f1f18-e472-4726-905a-97e83840a501@github.com>

On Fri, 28 Oct 2022 13:46:27 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Please review some updates to the parts of the build system related to building the documentation.
>
> make/Docs.gmk line 598:
> 
>> 596:   # Unset the following to suppress the link to the tool guides
>> 597:   NAV_LINK_GUIDES = --nav-link-guides
>> 598:   HEADER_RIGHT_SIDE_INFO = '<strong>$(subst &amp;,&,$(JDK_SHORT_NAME))$(DRAFT_MARKER_STR)</strong>'
> 
> I think these assignments should just be `:=` unless you specifically need them to be lazy evaluated. We avoid the `=` lazy evaluation unless we specifically need it. I don't see a reason for that to be needed here though. Both JDK_SHORT_NAME and DRAFT_MARKER_STR are defined when these lines are reached.

Thanks for the tip and style guideline

-------------

PR: https://git.openjdk.org/jdk/pull/10891


From jjg at openjdk.org  Mon Oct 31 23:23:44 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 31 Oct 2022 23:23:44 GMT
Subject: RFR: JDK-8295914: Add a header to generated HTML files in specs
 [v2]
In-Reply-To: <eUpFTOdX0nYRxTURyfZC0F-FwqWM5PQbvUaGZ4QjABI=.75fb4ee7-b6e5-4c22-a555-e98d9a7d03e1@github.com>
References: <eUpFTOdX0nYRxTURyfZC0F-FwqWM5PQbvUaGZ4QjABI=.75fb4ee7-b6e5-4c22-a555-e98d9a7d03e1@github.com>
Message-ID: <TaM0iyi9t0gf5tj26swGNMc5r4378p369PqHqjCSMgg=.31facc27-7e68-4f93-9f8a-960e354ed42f@github.com>

> Please review some updates to the parts of the build system related to building the documentation.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into 8295914.spec-headers
 - Address review feedback
 - JDK-8295914: Add a header to generated HTML files in specs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10891/files
  - new: https://git.openjdk.org/jdk/pull/10891/files/c5e567fd..6a1fdfc9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10891&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10891&range=00-01

  Stats: 3212 lines in 138 files changed: 2247 ins; 376 del; 589 mod
  Patch: https://git.openjdk.org/jdk/pull/10891.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10891/head:pull/10891

PR: https://git.openjdk.org/jdk/pull/10891


From CharlieMerrell75 at outlook.com  Fri Oct 28 12:11:23 2022
From: CharlieMerrell75 at outlook.com (Charlie Merrell)
Date: Fri, 28 Oct 2022 12:11:23 +0000
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
Message-ID: <DM4PR20MB467435829465272E4E5B87CECB329@DM4PR20MB4674.namprd20.prod.outlook.com>



Get Outlook for Android<https://aka.ms/AAb9ysg>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20221028/ee7dca84/attachment.htm>