From jwaters at openjdk.org  Tue Nov  1 00:10:27 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 1 Nov 2022 00:10:27 GMT
Subject: RFR: 8295884: Implement IDE support for Eclipse [v12]
In-Reply-To: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
Message-ID: <EX3L6QT0_Osw0klp5THiR-bPW9bxQbwRj2RySl3KGkI=.aa2e023c-eb0d-4a6b-8e54-35cb08cca7f6@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 16 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into eclipse
 - 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
 - ... and 6 more: https://git.openjdk.org/jdk/compare/807a1ba8...db0e248e

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10853/files
  - new: https://git.openjdk.org/jdk/pull/10853/files/90a7d061..db0e248e

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

  Stats: 2403 lines in 87 files changed: 1666 ins; 300 del; 437 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  Tue Nov  1 00:12:00 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 1 Nov 2022 00:12:00 GMT
Subject: RFR: 8296115: Allow for compiling the JDK with strict standards
 conformance [v2]
In-Reply-To: <yaKDZVxxdPLeOt-Z2Mw9Mjknb9q1tg3Pp2PRYfHihiQ=.d7c3320f-a9ae-4779-9bd5-00a9366a8bce@github.com>
References: <yaKDZVxxdPLeOt-Z2Mw9Mjknb9q1tg3Pp2PRYfHihiQ=.d7c3320f-a9ae-4779-9bd5-00a9366a8bce@github.com>
Message-ID: <vY0vW1_mCFv0ad_JK04yf7_16IhBaAtF7oeKJxxuPHI=.7afd2e03-cf57-4d1c-999a-8e8243d6c42f@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.

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

 - Merge remote-tracking branch 'upstream/master' into permissive
 - Format
 - Keep docs up to date
 - New --enable-conforming-compilation option

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10912/files
  - new: https://git.openjdk.org/jdk/pull/10912/files/08aae161..7a527bc8

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

  Stats: 2196 lines in 78 files changed: 1497 ins; 280 del; 419 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  Tue Nov  1 00:12:06 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 1 Nov 2022 00:12:06 GMT
Subject: RFR: 8295990: Improve make handling of strip flags [v6]
In-Reply-To: <KzCsmQL1zGCgtc0FaQgGBWCCVW3DmIl_Vw5Zz8FwmTQ=.b25575dd-474a-4950-af89-0c3078b5d3c4@github.com>
References: <KzCsmQL1zGCgtc0FaQgGBWCCVW3DmIl_Vw5Zz8FwmTQ=.b25575dd-474a-4950-af89-0c3078b5d3c4@github.com>
Message-ID: <OX26R_-2mP0bXeqQJ4gkGYuKmoi0ArbzOswrqlxf3Sc=.a9d89bec-61cf-4500-b6a6-587b87a0caa4@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 17 additional commits since the last revision:

 - Merge branch 'openjdk:master' into patch-1
 - 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
 - ... and 7 more: https://git.openjdk.org/jdk/compare/c45090f7...5f97c5c7

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10882/files
  - new: https://git.openjdk.org/jdk/pull/10882/files/df46df9d..5f97c5c7

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

  Stats: 2029 lines in 70 files changed: 1414 ins; 247 del; 368 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 jiefu at openjdk.org  Tue Nov  1 07:28:19 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Tue, 1 Nov 2022 07:28:19 GMT
Subject: RFR: 8295970: Add vector api sanity tests in tier1 [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: <iSrQCUf5hBwY31OP5My3Q15PHI4kXJlHNIdfafrq8w0=.a999c11e-148c-48d6-a0a0-0a25ee147bc8@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

Hi all,

I changed the JBS title as `Add vector api sanity tests in tier1`.
And the added `jdk_vector_sanity` tests can be run in less than 2min on my testing box.
Any comments?

Thanks.

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

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


From ihse at openjdk.org  Tue Nov  1 11:50:30 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 1 Nov 2022 11:50:30 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: <ZWKxvWlvtrLSj1dgiqvrsmosx7rpmEa9LE3Btnbsx1U=.25d5ff1c-ca3b-437e-b296-39370bc05d72@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

Marked as reviewed by ihse (Reviewer).

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

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


From dfuchs at openjdk.org  Tue Nov  1 12:21:13 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Nov 2022 12:21:13 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: <A4qnEed0y9IwAfcxrUtVyXLkcuaHKUlwps8MVVFUAyw=.042a86fd-8c9c-498d-8172-606712c83849@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 to java (resp sun) .util.logging tests and javax.management tests look good to me.

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

Marked as reviewed by dfuchs (Reviewer).

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


From erikj at openjdk.org  Tue Nov  1 12:44:33 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 1 Nov 2022 12:44:33 GMT
Subject: RFR: JDK-8295914: Add a header to generated HTML files in specs
 [v2]
In-Reply-To: <TaM0iyi9t0gf5tj26swGNMc5r4378p369PqHqjCSMgg=.31facc27-7e68-4f93-9f8a-960e354ed42f@github.com>
References: <eUpFTOdX0nYRxTURyfZC0F-FwqWM5PQbvUaGZ4QjABI=.75fb4ee7-b6e5-4c22-a555-e98d9a7d03e1@github.com>
 <TaM0iyi9t0gf5tj26swGNMc5r4378p369PqHqjCSMgg=.31facc27-7e68-4f93-9f8a-960e354ed42f@github.com>
Message-ID: <iQu6gs1TgWx8jO9dI0W_B5th4aUT6YZCIJEe_bMOG8M=.c40638d2-45d4-400c-946f-999f951491d0@github.com>

On Mon, 31 Oct 2022 23:23:44 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> 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

Marked as reviewed by erikj (Reviewer).

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

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


From erikj at openjdk.org  Tue Nov  1 12:47:29 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 1 Nov 2022 12:47:29 GMT
Subject: RFR: 8295970: Add vector api sanity tests in tier1 [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: <JUHlDjn0E16CLdq4waNteQstY_dOPC72FU-AqhGZrf4=.2ebae856-4292-4678-9593-d9c00cae2346@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

This looks good to me. The group tier1_part3 looks like it's currently the fastest of the 3, so it's the right one to add to.

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

Marked as reviewed by erikj (Reviewer).

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


From apavlyutkin at azul.com  Tue Nov  1 07:48:38 2022
From: apavlyutkin at azul.com (Alexey Pavlyutkin)
Date: Tue, 1 Nov 2022 07:48:38 +0000
Subject: [jdk8u-dev] RFR: 8197859: VS2017 Complains about UINTPTR_MAX
 definition in globalDefinitions_VisCPP.hpp
Message-ID: <PH0PR11MB5625B5D15BF52D77DBF2DD66C9369@PH0PR11MB5625.namprd11.prod.outlook.com>

Hello guys!

Can I ask you to review

https://github.com/openjdk/jdk8u-dev/pull/77

This is one of the seria of backports required to add support of MSVS2019 to jdk-8 and it blocks the further activities. Thank you

Regards,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20221101/dadeda84/attachment.htm>

From kvn at openjdk.org  Tue Nov  1 16:15:24 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 1 Nov 2022 16:15:24 GMT
Subject: RFR: 8295970: Add vector api sanity tests in tier1 [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: <4W4-SzCjMp5ML_70PyjaweJPxaBaBZuT728K3OS4sJc=.5d1b3fec-051d-4b12-bd30-b839f2368c5c@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

Good.

I think we need review from @shipilev too since he had strong opinion about this.

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

Marked as reviewed by kvn (Reviewer).

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


From jjg at openjdk.org  Tue Nov  1 18:42:27 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 1 Nov 2022 18:42:27 GMT
Subject: Integrated: 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: <tzNiBpIIA-YS37pUKEKBkNuqB_7_drGnpjcMKypJQIY=.c81b1a9c-6c67-4780-a1f8-424063599451@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.

This pull request has now been integrated.

Changeset: d17bf51f
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d17bf51f91371072a758e775136af946192e771b
Stats:     144 lines in 3 files changed: 139 ins; 1 del; 4 mod

8295914: Add a header to generated HTML files in specs

Reviewed-by: erikj, iris

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

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


From jiefu at openjdk.org  Wed Nov  2 01:28:07 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 2 Nov 2022 01:28:07 GMT
Subject: RFR: 8295970: Add vector api sanity tests in tier1 [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: <r_DwLplt-C0QArfmQKNEWuTcQWRwaeEDCXKMNWU4sr0=.cb201d2b-80c8-4ccb-b07b-ad729386cde5@github.com>

On Fri, 28 Oct 2022 13:41:28 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> 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.

Thanks @erikj79 and @vnkozlov for the review.
So @shipilev , are you fine with this change?
Thanks.

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

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


From jwaters at openjdk.org  Wed Nov  2 10:23:46 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 2 Nov 2022 10:23:46 GMT
Subject: RFR: 8295990: Improve make handling of strip flags [v7]
In-Reply-To: <KzCsmQL1zGCgtc0FaQgGBWCCVW3DmIl_Vw5Zz8FwmTQ=.b25575dd-474a-4950-af89-0c3078b5d3c4@github.com>
References: <KzCsmQL1zGCgtc0FaQgGBWCCVW3DmIl_Vw5Zz8FwmTQ=.b25575dd-474a-4950-af89-0c3078b5d3c4@github.com>
Message-ID: <UjwCoP8QkpR51QfnUiFfopmRsexQuXmsTdkptrB1ROk=.5a954511-7792-4be4-aa4b-2761152bd6a0@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 18 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
 - 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
 - ... and 8 more: https://git.openjdk.org/jdk/compare/d4b0fa17...25bb4a3c

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10882/files
  - new: https://git.openjdk.org/jdk/pull/10882/files/5f97c5c7..25bb4a3c

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

  Stats: 10848 lines in 221 files changed: 8133 ins; 1765 del; 950 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  Wed Nov  2 10:26:37 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 2 Nov 2022 10:26:37 GMT
Subject: RFR: 8295990: Improve make handling of strip flags [v5]
In-Reply-To: <qzQOeWditVp_fVxL9kKU3leA6SYpFjGyQyWPtz2wY9k=.55e2cc05-4ca5-4b4a-b022-8da6b22753a7@github.com>
References: <KzCsmQL1zGCgtc0FaQgGBWCCVW3DmIl_Vw5Zz8FwmTQ=.b25575dd-474a-4950-af89-0c3078b5d3c4@github.com>
 <aLahwUV9tlGm3zKttjcMzgzSJh_6i9TpHgcXTn9sTcI=.48d6a0a0-883c-425d-9a83-9ca75f6e5d22@github.com>
 <qzQOeWditVp_fVxL9kKU3leA6SYpFjGyQyWPtz2wY9k=.55e2cc05-4ca5-4b4a-b022-8da6b22753a7@github.com>
Message-ID: <QZFyy7mv29rrmdwpE6DEs4F8yOLxNZdskk0T3H1MZB0=.cf5a1425-f2fa-4498-98b8-2311ae22f3d2@github.com>

On Mon, 31 Oct 2022 12:58:17 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> 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/bbd65afa...df46df9d
>
> Marked as reviewed by erikj (Reviewer).

@erikj79 Could i trouble you for a sponsor? Thanks!

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

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


From jwaters at openjdk.org  Wed Nov  2 11:55:34 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 2 Nov 2022 11:55:34 GMT
Subject: RFR: 8296115: Allow for compiling the JDK with strict standards
 conformance [v3]
In-Reply-To: <yaKDZVxxdPLeOt-Z2Mw9Mjknb9q1tg3Pp2PRYfHihiQ=.d7c3320f-a9ae-4779-9bd5-00a9366a8bce@github.com>
References: <yaKDZVxxdPLeOt-Z2Mw9Mjknb9q1tg3Pp2PRYfHihiQ=.d7c3320f-a9ae-4779-9bd5-00a9366a8bce@github.com>
Message-ID: <kXqPoJGycjONjIGklBkKRnHV5Kz5NMlLx0rwnWOt2EE=.03f9e5d1-2a8f-4026-806e-88e17958b5bc@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.

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

 - Merge remote-tracking branch 'upstream/master' into permissive
 - Merge remote-tracking branch 'upstream/master' into permissive
 - Format
 - Keep docs up to date
 - New --enable-conforming-compilation option

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10912/files
  - new: https://git.openjdk.org/jdk/pull/10912/files/7a527bc8..de41a935

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

  Stats: 11094 lines in 228 files changed: 8335 ins; 1792 del; 967 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  Wed Nov  2 11:56:47 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 2 Nov 2022 11:56:47 GMT
Subject: RFR: 8295884: Implement IDE support for Eclipse [v13]
In-Reply-To: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
Message-ID: <hK2pRJXeqJVKb3fjCkaFGWSbpQIED76VVOKoYAweB9Q=.e4c9e29d-2e69-43ca-8c60-60480d421aa3@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 17 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into eclipse
 - Merge remote-tracking branch 'upstream/master' into eclipse
 - 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
 - ... and 7 more: https://git.openjdk.org/jdk/compare/3e3e9c16...065cbea5

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10853/files
  - new: https://git.openjdk.org/jdk/pull/10853/files/db0e248e..065cbea5

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

  Stats: 11094 lines in 228 files changed: 8335 ins; 1792 del; 967 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 Nov  2 11:56:52 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 2 Nov 2022 11:56:52 GMT
Subject: RFR: 8296115: Allow for compiling the JDK with strict standards
 conformance [v2]
In-Reply-To: <vY0vW1_mCFv0ad_JK04yf7_16IhBaAtF7oeKJxxuPHI=.7afd2e03-cf57-4d1c-999a-8e8243d6c42f@github.com>
References: <yaKDZVxxdPLeOt-Z2Mw9Mjknb9q1tg3Pp2PRYfHihiQ=.d7c3320f-a9ae-4779-9bd5-00a9366a8bce@github.com>
 <vY0vW1_mCFv0ad_JK04yf7_16IhBaAtF7oeKJxxuPHI=.7afd2e03-cf57-4d1c-999a-8e8243d6c42f@github.com>
Message-ID: <bLvblbNJK9t2juRWCMceur_X7r9L3JJBSbZmn1qkgDA=.7540a118-6521-4544-abc6-0bc0eceb45a6@github.com>

On Tue, 1 Nov 2022 00:12:00 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.
>
> 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 four additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into permissive
>  - Format
>  - Keep docs up to date
>  - New --enable-conforming-compilation option

Tagging @magicus as well, sorry for the noise

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

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


From jwaters at openjdk.org  Wed Nov  2 13:11:26 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 2 Nov 2022 13:11:26 GMT
Subject: Integrated: 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: <UwHZPzYfO0o5FW0nQJ-BjvgkDhsw7JtlV7BSxmrVzN4=.804f1da3-eb8b-46e5-a3ae-b116e8777093@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 pull request has now been integrated.

Changeset: dac6ecc8
Author:    Julian Waters <jwaters at openjdk.org>
Committer: Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dac6ecc857c527e9df7af68389b46d452ac59ae0
Stats:     28 lines in 2 files changed: 20 ins; 2 del; 6 mod

8295990: Improve make handling of strip flags

Reviewed-by: erikj

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

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


From shade at openjdk.org  Wed Nov  2 15:14:36 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 2 Nov 2022 15:14:36 GMT
Subject: RFR: 8295970: Add vector api sanity tests in tier1 [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: <r44_hXOoGqaYCKd2WNRqvf6cfSGWcz1iQLo-maG6UpE=.651678bb-31d8-4175-8bf8-be8b777294a1@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 the usual style for these files is to maintain original order/sorting.

test/jdk/TEST.groups line 44:

> 42:     :jdk_vector_sanity \
> 43:     :jdk_svc_sanity \
> 44:     :jdk_foreign \

Suggestion:

    :jdk_math \
    :jdk_svc_sanity \
    :jdk_foreign \
    :jdk_vector_sanity \

test/jdk/TEST.groups line 80:

> 78:     :jdk_svc \
> 79:    -:jdk_vector_sanity \
> 80:    -:jdk_svc_sanity \

Suggestion:

    :jdk_svc \
   -:jdk_svc_sanity \
   -:jdk_vector_sanity \

test/jdk/TEST.groups line 367:

> 365: 
> 366: jdk_vector_sanity = \
> 367:     jdk/incubator/vector/AddTest.java \

These should probably be sorted too.

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

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


From ihse at openjdk.org  Wed Nov  2 15:34:52 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 2 Nov 2022 15:34:52 GMT
Subject: RFR: 8296115: Allow for compiling the JDK with strict standards
 conformance [v3]
In-Reply-To: <kXqPoJGycjONjIGklBkKRnHV5Kz5NMlLx0rwnWOt2EE=.03f9e5d1-2a8f-4026-806e-88e17958b5bc@github.com>
References: <yaKDZVxxdPLeOt-Z2Mw9Mjknb9q1tg3Pp2PRYfHihiQ=.d7c3320f-a9ae-4779-9bd5-00a9366a8bce@github.com>
 <kXqPoJGycjONjIGklBkKRnHV5Kz5NMlLx0rwnWOt2EE=.03f9e5d1-2a8f-4026-806e-88e17958b5bc@github.com>
Message-ID: <QjAjO6tTLSyesJYXtetcENVl3efs3jHMvbyKKqDw4Ow=.3bdd5b25-09b5-46f2-8d37-b2f5de3de2ef@github.com>

On Wed, 2 Nov 2022 11:55:34 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.
>
> 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 five additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into permissive
>  - Merge remote-tracking branch 'upstream/master' into permissive
>  - Format
>  - Keep docs up to date
>  - New --enable-conforming-compilation option

Looks good to me.

Goes the GHA test suite pass with this flag? If so, I think it would make sense to turn it on for our GHA builds. That will help raise the bar for future code coming in, and give this option some real testing.

make/autoconf/spec.gmk.in line 333:

> 331: ENABLE_HEADLESS_ONLY := @ENABLE_HEADLESS_ONLY@
> 332: 
> 333: ENABLE_CONFORMING_COMPILATION := @ENABLE_CONFORMING_COMPILATION@

You don't need to export this in spec.gmk, since it is only checked in the configure script. We try hard to only export here what is strictly necessary for use by makefiles. If you will ever need it in the future, please add it as an export here at that time.

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

Marked as reviewed by ihse (Reviewer).

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


From ihse at openjdk.org  Wed Nov  2 15:38:16 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 2 Nov 2022 15:38:16 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: <wkGViXtTqCPGPUqySN_rR-YPVmzvNxR6c6U1LVkOSE0=.c44af15b-48e9-4d4e-bffd-319b1ee37b10@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 ihse (Reviewer).

Nicely spotted!

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

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


From ihse at openjdk.org  Wed Nov  2 15:39:41 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 2 Nov 2022 15:39:41 GMT
Subject: RFR: 8294591: Fix cast-function-type warning in TemplateTable [v4]
In-Reply-To: <2jHTulm9tMRZEq_tFq7UMUJjWwIS7TIoOkfxjVsseG8=.e69ac9a2-cf39-4972-818a-77cdf0ed93d6@github.com>
References: <F9kScSH8YZ9kK8XAcl5pPPE6sPrHCBUc_zNriSaP8EU=.d5c7452c-72ed-4f41-9dea-5bd8a7fccbc0@github.com>
 <2jHTulm9tMRZEq_tFq7UMUJjWwIS7TIoOkfxjVsseG8=.e69ac9a2-cf39-4972-818a-77cdf0ed93d6@github.com>
Message-ID: <-lSQrZXaxtGjPL-LuHHvroS8HOTvVdWgAx4J2yIAm60=.e932a8fd-8218-4068-96f0-3df02cf1d508@github.com>

On Mon, 17 Oct 2022 18:08:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> 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

Build changes are trivially good. I have not looked at hotspot source code changes.

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

Marked as reviewed by ihse (Reviewer).

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


From coleenp at openjdk.org  Wed Nov  2 16:16:26 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 2 Nov 2022 16:16:26 GMT
Subject: RFR: 8294591: Fix cast-function-type warning in TemplateTable [v4]
In-Reply-To: <2jHTulm9tMRZEq_tFq7UMUJjWwIS7TIoOkfxjVsseG8=.e69ac9a2-cf39-4972-818a-77cdf0ed93d6@github.com>
References: <F9kScSH8YZ9kK8XAcl5pPPE6sPrHCBUc_zNriSaP8EU=.d5c7452c-72ed-4f41-9dea-5bd8a7fccbc0@github.com>
 <2jHTulm9tMRZEq_tFq7UMUJjWwIS7TIoOkfxjVsseG8=.e69ac9a2-cf39-4972-818a-77cdf0ed93d6@github.com>
Message-ID: <jYSBCqpCKMXkMQveFDcwGLvmgII6Rx6UbGRTCv0_8mo=.83fd6377-a70d-46cf-a9cc-082796e1481b@github.com>

On Mon, 17 Oct 2022 18:08:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> 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

Seems ok.

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

Marked as reviewed by coleenp (Reviewer).

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


From jwaters at openjdk.org  Wed Nov  2 16:45:35 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 2 Nov 2022 16:45:35 GMT
Subject: RFR: 8296115: Allow for compiling the JDK with strict standards
 conformance [v4]
In-Reply-To: <yaKDZVxxdPLeOt-Z2Mw9Mjknb9q1tg3Pp2PRYfHihiQ=.d7c3320f-a9ae-4779-9bd5-00a9366a8bce@github.com>
References: <yaKDZVxxdPLeOt-Z2Mw9Mjknb9q1tg3Pp2PRYfHihiQ=.d7c3320f-a9ae-4779-9bd5-00a9366a8bce@github.com>
Message-ID: <RSam1XvDYiyOwOj7I-UtO4SkN026rS-_znurjm5lrWA=.735e341e-7892-4c22-96e1-46c8f589f25b@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.

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

 - Export not required
 - Merge remote-tracking branch 'upstream/master' into permissive
 - Merge remote-tracking branch 'upstream/master' into permissive
 - Merge remote-tracking branch 'upstream/master' into permissive
 - Format
 - Keep docs up to date
 - New --enable-conforming-compilation option

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10912/files
  - new: https://git.openjdk.org/jdk/pull/10912/files/de41a935..1dd9765c

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

  Stats: 1572 lines in 69 files changed: 254 ins; 1196 del; 122 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  Wed Nov  2 16:45:37 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 2 Nov 2022 16:45:37 GMT
Subject: RFR: 8296115: Allow for compiling the JDK with strict standards
 conformance [v3]
In-Reply-To: <QjAjO6tTLSyesJYXtetcENVl3efs3jHMvbyKKqDw4Ow=.3bdd5b25-09b5-46f2-8d37-b2f5de3de2ef@github.com>
References: <yaKDZVxxdPLeOt-Z2Mw9Mjknb9q1tg3Pp2PRYfHihiQ=.d7c3320f-a9ae-4779-9bd5-00a9366a8bce@github.com>
 <kXqPoJGycjONjIGklBkKRnHV5Kz5NMlLx0rwnWOt2EE=.03f9e5d1-2a8f-4026-806e-88e17958b5bc@github.com>
 <QjAjO6tTLSyesJYXtetcENVl3efs3jHMvbyKKqDw4Ow=.3bdd5b25-09b5-46f2-8d37-b2f5de3de2ef@github.com>
Message-ID: <Al2TPdkyrcCYTyEWRjnWkOmOl0GvhCa4mf9LUX2KgHU=.88d60800-0dae-46ee-bb11-687ec55302ef@github.com>

On Wed, 2 Nov 2022 15:31:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> 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 five additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into permissive
>>  - Merge remote-tracking branch 'upstream/master' into permissive
>>  - Format
>>  - Keep docs up to date
>>  - New --enable-conforming-compilation option
>
> make/autoconf/spec.gmk.in line 333:
> 
>> 331: ENABLE_HEADLESS_ONLY := @ENABLE_HEADLESS_ONLY@
>> 332: 
>> 333: ENABLE_CONFORMING_COMPILATION := @ENABLE_CONFORMING_COMPILATION@
> 
> You don't need to export this in spec.gmk, since it is only checked in the configure script. We try hard to only export here what is strictly necessary for use by makefiles. If you will ever need it in the future, please add it as an export here at that time.

Alright, will do

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

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


From erikj at openjdk.org  Wed Nov  2 17:04:18 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 2 Nov 2022 17:04:18 GMT
Subject: RFR: 8296115: Allow for compiling the JDK with strict standards
 conformance [v4]
In-Reply-To: <RSam1XvDYiyOwOj7I-UtO4SkN026rS-_znurjm5lrWA=.735e341e-7892-4c22-96e1-46c8f589f25b@github.com>
References: <yaKDZVxxdPLeOt-Z2Mw9Mjknb9q1tg3Pp2PRYfHihiQ=.d7c3320f-a9ae-4779-9bd5-00a9366a8bce@github.com>
 <RSam1XvDYiyOwOj7I-UtO4SkN026rS-_znurjm5lrWA=.735e341e-7892-4c22-96e1-46c8f589f25b@github.com>
Message-ID: <loPG9J-ISA5PxE0EJihe2RamvIGMXHcJiEF9V4dxJBw=.b1387d7f-801f-4e7a-bdaf-949a2448562e@github.com>

On Wed, 2 Nov 2022 16:45:35 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.
>
> 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 seven additional commits since the last revision:
> 
>  - Export not required
>  - Merge remote-tracking branch 'upstream/master' into permissive
>  - Merge remote-tracking branch 'upstream/master' into permissive
>  - Merge remote-tracking branch 'upstream/master' into permissive
>  - Format
>  - Keep docs up to date
>  - New --enable-conforming-compilation option

Marked as reviewed by erikj (Reviewer).

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

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


From jwaters at openjdk.org  Wed Nov  2 17:04:19 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 2 Nov 2022 17:04:19 GMT
Subject: RFR: 8296115: Allow for compiling the JDK with strict standards
 conformance [v3]
In-Reply-To: <QjAjO6tTLSyesJYXtetcENVl3efs3jHMvbyKKqDw4Ow=.3bdd5b25-09b5-46f2-8d37-b2f5de3de2ef@github.com>
References: <yaKDZVxxdPLeOt-Z2Mw9Mjknb9q1tg3Pp2PRYfHihiQ=.d7c3320f-a9ae-4779-9bd5-00a9366a8bce@github.com>
 <kXqPoJGycjONjIGklBkKRnHV5Kz5NMlLx0rwnWOt2EE=.03f9e5d1-2a8f-4026-806e-88e17958b5bc@github.com>
 <QjAjO6tTLSyesJYXtetcENVl3efs3jHMvbyKKqDw4Ow=.3bdd5b25-09b5-46f2-8d37-b2f5de3de2ef@github.com>
Message-ID: <Bk32whUepgQogtvgLCBhGp8mcwP25lXZ_hmpF5SYkWA=.61df54a0-742d-4015-a868-5be2c4128371@github.com>

On Wed, 2 Nov 2022 15:32:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Goes the GHA test suite pass with this flag? If so, I think it would make sense to turn it on for our GHA builds. That will help raise the bar for future code coming in, and give this option some real testing.

Given my experience with these errors I doubt it will work off the bat with some of the particularly strict compilers, such as gcc for instance. I'll leave the decision to enable this flag to someone else for now

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

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


From jwaters at openjdk.org  Wed Nov  2 17:05:59 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 2 Nov 2022 17:05:59 GMT
Subject: Integrated: 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: <CDrlRUR4JPgNOikqmSzi-VgMXG-oWB9zIFxcTQdtXYw=.5ac2c290-cec7-48de-bde5-56b209390c2b@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.

This pull request has now been integrated.

Changeset: a124d8e0
Author:    Julian Waters <jwaters at openjdk.org>
Committer: Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a124d8e0479f4c59d27c69c6b580542b394fd02f
Stats:     41 lines in 4 files changed: 39 ins; 0 del; 2 mod

8296115: Allow for compiling the JDK with strict standards conformance
8241499: Enable new "permissive-" for standard C++ compliance on Visual Studio if possible

Reviewed-by: erikj, ihse

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

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


From jjg at openjdk.org  Wed Nov  2 19:14:20 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 2 Nov 2022 19:14:20 GMT
Subject: RFR: JDK-8296188: Update style and header in JDWP Protocol spec and
 JVMTI spec
Message-ID: <UPw_VNjmNYf4olvt-h9TVFxSHllUVmJG0ta4VfBaWZY=.c4fae5a3-15f8-43bd-958a-2c2a0b708413@github.com>

Please review a simple makefile-only update to inject the standard stylesheet and navigation header into the two JDK specifications that are generated as HTML files in the `gensrc` directory, to bring these docs in line with the rest of the specs documents.

Generated docs at: 
* http://cr.openjdk.java.net/~jjg/8296188/docs.00/specs/jdwp/jdwp-protocol.html
* http://cr.openjdk.java.net/~jjg/8296188/docs.00/specs/jvmti.html

The JVM TI spec has a list of links at the beginning, in bold. This is not a CSS issue ... it is in the HTML, generated by XSL scripts. Ideally, the list should be in a separate `<nav>` element and the `<b>` tags removed, and maybe the style revised using local CSS. But that is a separate issue.

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

Commit messages:
 - JDK-8296188

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

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


From erikj at openjdk.org  Wed Nov  2 19:54:17 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 2 Nov 2022 19:54:17 GMT
Subject: RFR: JDK-8296188: Update style and header in JDWP Protocol spec
 and JVMTI spec
In-Reply-To: <UPw_VNjmNYf4olvt-h9TVFxSHllUVmJG0ta4VfBaWZY=.c4fae5a3-15f8-43bd-958a-2c2a0b708413@github.com>
References: <UPw_VNjmNYf4olvt-h9TVFxSHllUVmJG0ta4VfBaWZY=.c4fae5a3-15f8-43bd-958a-2c2a0b708413@github.com>
Message-ID: <PcH3h6s2j3oKfc69Gj6_GWWAD63wanCUqcp3J-JDXDQ=.c4ef1432-2e96-4a27-84f3-38596b1e1666@github.com>

On Wed, 2 Nov 2022 19:07:36 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple makefile-only update to inject the standard stylesheet and navigation header into the two JDK specifications that are generated as HTML files in the `gensrc` directory, to bring these docs in line with the rest of the specs documents.
> 
> Generated docs at: 
> * http://cr.openjdk.java.net/~jjg/8296188/docs.00/specs/jdwp/jdwp-protocol.html
> * http://cr.openjdk.java.net/~jjg/8296188/docs.00/specs/jvmti.html
> 
> The JVM TI spec has a list of links at the beginning, in bold. This is not a CSS issue ... it is in the HTML, generated by XSL scripts. Ideally, the list should be in a separate `<nav>` element and the `<b>` tags removed, and maybe the style revised using local CSS. But that is a separate issue.

Marked as reviewed by erikj (Reviewer).

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

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


From jjg at openjdk.org  Wed Nov  2 21:15:24 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 2 Nov 2022 21:15:24 GMT
Subject: Integrated: JDK-8296188: Update style and header in JDWP Protocol spec
 and JVMTI spec
In-Reply-To: <UPw_VNjmNYf4olvt-h9TVFxSHllUVmJG0ta4VfBaWZY=.c4fae5a3-15f8-43bd-958a-2c2a0b708413@github.com>
References: <UPw_VNjmNYf4olvt-h9TVFxSHllUVmJG0ta4VfBaWZY=.c4fae5a3-15f8-43bd-958a-2c2a0b708413@github.com>
Message-ID: <RG8g1YnAvz7_7WRCiXk5jkqCMBvWTOSzoVpHCwXXRTQ=.5c2bb5b5-57d3-4245-a574-03f542333a7f@github.com>

On Wed, 2 Nov 2022 19:07:36 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple makefile-only update to inject the standard stylesheet and navigation header into the two JDK specifications that are generated as HTML files in the `gensrc` directory, to bring these docs in line with the rest of the specs documents.
> 
> Generated docs at: 
> * http://cr.openjdk.java.net/~jjg/8296188/docs.00/specs/jdwp/jdwp-protocol.html
> * http://cr.openjdk.java.net/~jjg/8296188/docs.00/specs/jvmti.html
> 
> The JVM TI spec has a list of links at the beginning, in bold. This is not a CSS issue ... it is in the HTML, generated by XSL scripts. Ideally, the list should be in a separate `<nav>` element and the `<b>` tags removed, and maybe the style revised using local CSS. But that is a separate issue.

This pull request has now been integrated.

Changeset: fd60036a
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fd60036a34b0a8516eb29b698674c8242c4a84c1
Stats:     19 lines in 1 file changed: 14 ins; 0 del; 5 mod

8296188: Update style and header in JDWP Protocol spec and JVMTI spec

Reviewed-by: erikj

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

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


From jiefu at openjdk.org  Thu Nov  3 03:16:30 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Thu, 3 Nov 2022 03:16:30 GMT
Subject: RFR: 8295970: Add vector api sanity tests in tier1 [v3]
In-Reply-To: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
Message-ID: <rjAmMEpLHS1BrC6CQwywF-5qw2NjPmODOlhvyJXuMfU=.182e85b2-f3c8-40b7-8252-d784394f7d08@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 incrementally with two additional commits since the last revision:

 - Update test/jdk/TEST.groups
   
   Co-authored-by: Aleksey Shipil?v <shade at redhat.com>
 - Update test/jdk/TEST.groups
   
   Co-authored-by: Aleksey Shipil?v <shade at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10879/files
  - new: https://git.openjdk.org/jdk/pull/10879/files/f901b907..b0fa749f

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

  Stats: 4 lines in 1 file changed: 2 ins; 2 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 jiefu at openjdk.org  Thu Nov  3 03:31:56 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Thu, 3 Nov 2022 03:31:56 GMT
Subject: RFR: 8295970: Add vector api sanity tests in tier1 [v4]
In-Reply-To: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
Message-ID: <94_J9ooQ7Sdo3Y9_Z2xOWZbzOfZ8szVM6HwqJJxnRI0=.ff557a5c-3a88-488e-8f02-73287fd3363d@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 incrementally with one additional commit since the last revision:

  Sort jdk_vector_sanity tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10879/files
  - new: https://git.openjdk.org/jdk/pull/10879/files/b0fa749f..d353e26f

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

  Stats: 19 lines in 1 file changed: 9 ins; 9 del; 1 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  Thu Nov  3 03:33:22 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Thu, 3 Nov 2022 03:33:22 GMT
Subject: RFR: 8295970: Add vector api sanity tests in tier1 [v2]
In-Reply-To: <r44_hXOoGqaYCKd2WNRqvf6cfSGWcz1iQLo-maG6UpE=.651678bb-31d8-4175-8bf8-be8b777294a1@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
 <8uMsheGwjIBbgf1nJeYkCR4Pt_ddbnq4WVKMRPwS7C0=.c59b10eb-67e1-439c-936e-857c8430c520@github.com>
 <r44_hXOoGqaYCKd2WNRqvf6cfSGWcz1iQLo-maG6UpE=.651678bb-31d8-4175-8bf8-be8b777294a1@github.com>
Message-ID: <CJlDixT05ELRFRsRf4h80SuxczCnpbtIQJgX-oNxN6Q=.0aa1ee05-b550-47a3-9a4a-22570fcd5ed8@github.com>

On Wed, 2 Nov 2022 15:11:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> 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 the usual style for these files is to maintain original order/sorting.

@shipilev , all your comments had been resolved.
Thanks.

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

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


From jwaters at openjdk.org  Thu Nov  3 06:15:46 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 3 Nov 2022 06:15:46 GMT
Subject: RFR: 8295884: Implement IDE support for Eclipse [v14]
In-Reply-To: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
Message-ID: <dXVryNF8VtoldRZr8ix0jFrL56u42-JLHqXO02h0I-w=.052705f6-e608-4ce8-aa44-919dc1dd479f@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 19 additional commits since the last revision:

 - Rename RAnDOM to WORKSPACE_ID
 - Merge remote-tracking branch 'upstream/master' into eclipse
 - Merge remote-tracking branch 'upstream/master' into eclipse
 - Merge remote-tracking branch 'upstream/master' into eclipse
 - 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
 - ... and 9 more: https://git.openjdk.org/jdk/compare/5907c2db...125601f8

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10853/files
  - new: https://git.openjdk.org/jdk/pull/10853/files/065cbea5..125601f8

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

  Stats: 31318 lines in 98 files changed: 1831 ins; 29095 del; 392 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 Nov  3 06:19:20 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 3 Nov 2022 06:19:20 GMT
Subject: RFR: 8295884: Implement IDE support for Eclipse [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: <QAmxAzQhXYEWpn6G8wpx4emnrgW0nygxuItTz2RD2I0=.24d04643-ca91-45f7-bf81-d064df452f3f@github.com>

On Wed, 26 Oct 2022 10:15:10 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> 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.

@tstuefe I'm not entirely sure what you mean by "jtreg test sources", are you referring to IntelliJ's ability to call the different `make test` targets with the help of the jtreg plugin?

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

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


From shade at openjdk.org  Thu Nov  3 11:18:35 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 3 Nov 2022 11:18:35 GMT
Subject: RFR: 8295970: Add vector api sanity tests in tier1 [v4]
In-Reply-To: <94_J9ooQ7Sdo3Y9_Z2xOWZbzOfZ8szVM6HwqJJxnRI0=.ff557a5c-3a88-488e-8f02-73287fd3363d@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
 <94_J9ooQ7Sdo3Y9_Z2xOWZbzOfZ8szVM6HwqJJxnRI0=.ff557a5c-3a88-488e-8f02-73287fd3363d@github.com>
Message-ID: <YMUhhzgm7GE-Fl8eO6Y716OANh-msoywUnxGU5b2-0k=.3014c932-a48a-41f0-9b5f-0dbe1b997fd8@github.com>

On Thu, 3 Nov 2022 03:31:56 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 incrementally with one additional commit since the last revision:
> 
>   Sort jdk_vector_sanity tests

Marked as reviewed by shade (Reviewer).

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

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


From jiefu at openjdk.org  Thu Nov  3 11:18:35 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Thu, 3 Nov 2022 11:18:35 GMT
Subject: RFR: 8295970: Add vector api sanity tests in tier1 [v4]
In-Reply-To: <94_J9ooQ7Sdo3Y9_Z2xOWZbzOfZ8szVM6HwqJJxnRI0=.ff557a5c-3a88-488e-8f02-73287fd3363d@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
 <94_J9ooQ7Sdo3Y9_Z2xOWZbzOfZ8szVM6HwqJJxnRI0=.ff557a5c-3a88-488e-8f02-73287fd3363d@github.com>
Message-ID: <kQsgbWy072kta3prhfcKjd7WXDWavixmXBfsr1VeAzs=.d3bd1c3d-15b8-424d-9a16-00888434a694@github.com>

On Thu, 3 Nov 2022 03:31:56 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 incrementally with one additional commit since the last revision:
> 
>   Sort jdk_vector_sanity tests

Thank you all for the review and comments.

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

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


From jiefu at openjdk.org  Thu Nov  3 12:18:14 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Thu, 3 Nov 2022 12:18:14 GMT
Subject: Integrated: 8295970: Add vector api sanity tests in tier1
In-Reply-To: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
Message-ID: <PW5fg8bHNH7agZAVKX581QlKhw91nfTaM0sm7El-qK4=.369da2bf-111c-4c9a-a01f-ab909eb416e0@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

This pull request has now been integrated.

Changeset: d771abb2
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d771abb2fbc72e02faf02f0724aea301953ac5e8
Stats:     27 lines in 1 file changed: 27 ins; 0 del; 0 mod

8295970: Add vector api sanity tests in tier1

Reviewed-by: shade, erikj, kvn

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

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


From ihse at openjdk.org  Thu Nov  3 14:40:11 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 3 Nov 2022 14:40:11 GMT
Subject: RFR: 8295653: Add a graph of the sealed class hierarchy for marked
 classes [v5]
In-Reply-To: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
References: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
Message-ID: <h47CRL36XnrcR6_vFcOqNoGKjJVo3caVSQIe1Pa8baE=.03521d8d-71f1-4126-b98b-e662cb0a557e@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:

  Use Files.writeString instead

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10761/files
  - new: https://git.openjdk.org/jdk/pull/10761/files/b0f9087c..b63decab

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

  Stats: 4 lines in 1 file changed: 0 ins; 1 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  Thu Nov  3 14:43:10 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 3 Nov 2022 14:43:10 GMT
Subject: RFR: 8295653: Add a graph of the sealed class hierarchy for marked
 classes [v6]
In-Reply-To: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
References: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
Message-ID: <Kag-GlAWBBuIGwM7gDEITbSW4zFyqL7m2yP6jNnJSjw=.45239d69-6611-4f2b-b00a-144daec11dd8@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:

 - Fix imports
 - Fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10761/files
  - new: https://git.openjdk.org/jdk/pull/10761/files/b63decab..053e0e65

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

  Stats: 6 lines in 2 files changed: 2 ins; 1 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  Thu Nov  3 14:48:11 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 3 Nov 2022 14:48:11 GMT
Subject: RFR: 8295653: Add a graph of the sealed class hierarchy for marked
 classes [v4]
In-Reply-To: <GNO4nsqmRbYS27vaalBtocBMn2zqkRv_XG3NEZ7o_lE=.a9fd2596-676b-4fbd-b74e-c1e049863a54@github.com>
References: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
 <wewvGmw-sDeZIq9i1rKObXQAzjJ6P6yAb_Pd8dODTFY=.0add705a-48b3-4b43-b94e-8e4c74f756d7@github.com>
 <GNO4nsqmRbYS27vaalBtocBMn2zqkRv_XG3NEZ7o_lE=.a9fd2596-676b-4fbd-b74e-c1e049863a54@github.com>
Message-ID: <9M3u9EF9V10MOj-paMFa1W1slB19nZZ8rU3ylHh2iVM=.353c3e30-736f-4ece-9464-f0d5b59dae09@github.com>

On Sat, 29 Oct 2022 00:13:05 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:
>> 
>>   Rename sealedGraphDotPath to sealedDotOutputDir
>
> 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?

This is Per's code; I didn't look in detail in it. It does seem to be the correct place, though; it's more like the name of the method is bad, since it overloads the `toString` from `Object`, and gives the wrong impressions of its meaning and usage.

However, it seems we need change some code to be guaranteed by called only once. Looking into it...

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

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


From ihse at openjdk.org  Thu Nov  3 14:51:34 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 3 Nov 2022 14:51:34 GMT
Subject: RFR: 8295653: Add a graph of the sealed class hierarchy for marked
 classes [v4]
In-Reply-To: <9M3u9EF9V10MOj-paMFa1W1slB19nZZ8rU3ylHh2iVM=.353c3e30-736f-4ece-9464-f0d5b59dae09@github.com>
References: <MI63mojOUcDBQ2WzbHdYZ9yhfwSQHT4vS72BHQKP1ic=.4254b7e5-4e71-4415-925d-d9e429285284@github.com>
 <wewvGmw-sDeZIq9i1rKObXQAzjJ6P6yAb_Pd8dODTFY=.0add705a-48b3-4b43-b94e-8e4c74f756d7@github.com>
 <GNO4nsqmRbYS27vaalBtocBMn2zqkRv_XG3NEZ7o_lE=.a9fd2596-676b-4fbd-b74e-c1e049863a54@github.com>
 <9M3u9EF9V10MOj-paMFa1W1slB19nZZ8rU3ylHh2iVM=.353c3e30-736f-4ece-9464-f0d5b59dae09@github.com>
Message-ID: <U5HDwcsz0vHYZc09wY-xTCmhChGQa1TZwbFbrUZi7q4=.aa307c31-6b0a-457b-8f0b-c0ad6e6e9458@github.com>

On Thu, 3 Nov 2022 14:45:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> 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?
>
> This is Per's code; I didn't look in detail in it. It does seem to be the correct place, though; it's more like the name of the method is bad, since it overloads the `toString` from `Object`, and gives the wrong impressions of its meaning and usage.
> 
> However, it seems we need change some code to be guaranteed by called only once. Looking into it...

Actually, no, it's fine. According to `toString` documentation:


     * If this taglet supports {@link #isBlockTag block} tags, it will be called once
     * for each comment containing instances of block tags, with a list of all the instances
     * of the block tag in that comment.


and I just presume we can trust the JDK authors to only add the tag once per class.

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

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


From ihse at openjdk.org  Thu Nov  3 14:54:50 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 3 Nov 2022 14:54:50 GMT
Subject: Integrated: 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: <m9DeeCYNZFdCuDvZw5EbkIx4HDWrwhRVQ0pP99xLjvM=.d9509af5-1bb8-49e9-8566-6809a2297866@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.

This pull request has now been integrated.

Changeset: b7442d12
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b7442d12e26f9c61db968fbaf71136e4b76cb82f
Stats:     366 lines in 5 files changed: 316 ins; 0 del; 50 mod

8295653: Add a graph of the sealed class hierarchy for marked classes

Co-authored-by: Per Minborg <pminborg at openjdk.org>
Reviewed-by: erikj, jjg

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

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


From sspitsyn at openjdk.org  Fri Nov  4 06:49:30 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 4 Nov 2022 06:49:30 GMT
Subject: RFR: JDK-8296188: Update style and header in JDWP Protocol spec
 and JVMTI spec
In-Reply-To: <UPw_VNjmNYf4olvt-h9TVFxSHllUVmJG0ta4VfBaWZY=.c4fae5a3-15f8-43bd-958a-2c2a0b708413@github.com>
References: <UPw_VNjmNYf4olvt-h9TVFxSHllUVmJG0ta4VfBaWZY=.c4fae5a3-15f8-43bd-958a-2c2a0b708413@github.com>
Message-ID: <WCErgvnuwe-8dx58j-0GSZW5uLGYZDONF1uqdoxXkJ8=.b90efd87-0ab8-4a30-b2ac-59f3506a56fb@github.com>

On Wed, 2 Nov 2022 19:07:36 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple makefile-only update to inject the standard stylesheet and navigation header into the two JDK specifications that are generated as HTML files in the `gensrc` directory, to bring these docs in line with the rest of the specs documents.
> 
> Generated docs at: 
> * http://cr.openjdk.java.net/~jjg/8296188/docs.00/specs/jdwp/jdwp-protocol.html
> * http://cr.openjdk.java.net/~jjg/8296188/docs.00/specs/jvmti.html
> 
> The JVM TI spec has a list of links at the beginning, in bold. This is not a CSS issue ... it is in the HTML, generated by XSL scripts. Ideally, the list should be in a separate `<nav>` element and the `<b>` tags removed, and maybe the style revised using local CSS. But that is a separate issue.

Looks good to me.
Thank you for the spec improvements!
Serguei

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

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


From asotona at openjdk.org  Fri Nov  4 15:17:34 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 4 Nov 2022 15:17:34 GMT
Subject: RFR: 8294982: Implementation of Classfile API
Message-ID: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>

This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.

Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.

Classfile API development is tracked at:
https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch

Development branch of consolidated JDK class files parsing, generating, and transforming is at:
https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch

Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/jdk/classfile/package-summary.html) is also available.

Please take you time to review this non-trivial JDK addition.

Thank you,
Adam

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

Commit messages:
 - removed executable
 - removed executable
 - removed executable flags and fixed whitespaces
 - removed executable flag from test/micro/org/openjdk/bench/jdk/classfile/Write.java
 - Merge branch 'classfile-api-branch' into classfile-api-initial-branch
 - Merge branch 'master' into classfile-api-branch
 - fixed Classfile API Javadoc build
 - removed obsolete factory mthods LocalVariableInfo::of and LocalVariableTypeInfo::of
 - added Classfile.Option FILTER_DEAD_LABELS
 - fixed javadoc of ModuleOpenInfo and ModuleRequireInfo
 - ... and 85 more: https://git.openjdk.org/jdk/compare/8ee0f7d5...4b3e63d5

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

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


From jjg at openjdk.org  Fri Nov  4 21:56:17 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 4 Nov 2022 21:56:17 GMT
Subject: RFR: JDK-8296137: diags-examples.xml is broken
Message-ID: <Y8whD9OCjRQ-KFUFSYgD_bMRsnYoWnY_TQsLP0BNToU=.7c06b1ed-df55-4885-ac94-a4be10f4d19d@github.com>

Please review some minor updates to the `diags/examples` mechanism, repairing some bitrot after one of the not-so-recent repo reorgs.

For bonus, I've added a target for the German version of the output.

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

Commit messages:
 - JDK-8296137: diags-examples.xml is broken

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

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


From iris at openjdk.org  Fri Nov  4 22:21:29 2022
From: iris at openjdk.org (Iris Clark)
Date: Fri, 4 Nov 2022 22:21:29 GMT
Subject: RFR: JDK-8296137: diags-examples.xml is broken
In-Reply-To: <Y8whD9OCjRQ-KFUFSYgD_bMRsnYoWnY_TQsLP0BNToU=.7c06b1ed-df55-4885-ac94-a4be10f4d19d@github.com>
References: <Y8whD9OCjRQ-KFUFSYgD_bMRsnYoWnY_TQsLP0BNToU=.7c06b1ed-df55-4885-ac94-a4be10f4d19d@github.com>
Message-ID: <cV4D9NvxIkHuwzPIUjxQodjxt4B1HFtV8AuUBysqk5M=.5795376e-e949-4a95-9a50-84ae3975a0fe@github.com>

On Fri, 4 Nov 2022 21:50:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some minor updates to the `diags/examples` mechanism, repairing some bitrot after one of the not-so-recent repo reorgs.
> 
> For bonus, I've added a target for the German version of the output.

Marked as reviewed by iris (Reviewer).

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

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


From vromero at openjdk.org  Fri Nov  4 22:30:30 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 4 Nov 2022 22:30:30 GMT
Subject: RFR: JDK-8296137: diags-examples.xml is broken
In-Reply-To: <Y8whD9OCjRQ-KFUFSYgD_bMRsnYoWnY_TQsLP0BNToU=.7c06b1ed-df55-4885-ac94-a4be10f4d19d@github.com>
References: <Y8whD9OCjRQ-KFUFSYgD_bMRsnYoWnY_TQsLP0BNToU=.7c06b1ed-df55-4885-ac94-a4be10f4d19d@github.com>
Message-ID: <_xycNWnz6SYSwF3z46hlstyVJjV7jlytrBD_JajDtAQ=.60315a94-7c73-42f8-9a89-be6e3b653e76@github.com>

On Fri, 4 Nov 2022 21:50:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some minor updates to the `diags/examples` mechanism, repairing some bitrot after one of the not-so-recent repo reorgs.
> 
> For bonus, I've added a target for the German version of the output.

lgtm

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

Marked as reviewed by vromero (Reviewer).

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


From serb at openjdk.org  Sat Nov  5 04:56:42 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 5 Nov 2022 04:56:42 GMT
Subject: RFR: 8295812: Skip the "half float" support in LittleCMS during
 the build [v2]
In-Reply-To: <F9XVuZZYovezop61nzuHLN6OKXlzp4hv4cme84f2aRg=.7966ac12-b6a3-49d1-bbfc-0fefccb5ba90@github.com>
References: <F9XVuZZYovezop61nzuHLN6OKXlzp4hv4cme84f2aRg=.7966ac12-b6a3-49d1-bbfc-0fefccb5ba90@github.com>
Message-ID: <acNoOQH34egmiXjdpwc2LUKrSgcb6DW5FUd6G_bmvNg=.27bcfbfb-7c06-4f30-bee3-90e09fa4b9c6@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.

Sergey Bylokhov 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 remote-tracking branch 'upstream/master' into JDK-8295812
 - 8295812: Skip the "half float" support in LittleCMS during the build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10830/files
  - new: https://git.openjdk.org/jdk/pull/10830/files/2b66abd4..cb694af2

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

  Stats: 180880 lines in 1463 files changed: 88306 ins; 60595 del; 31979 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 alanb at openjdk.org  Sat Nov  5 09:56:33 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 5 Nov 2022 09:56:33 GMT
Subject: RFR: 8294982: Implementation of Classfile API
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <LqZMBFkJ-X53za3TzPn4eiImbeyxsPwRkn4Y8a1rHsU=.9f6215e9-7546-4ba3-b268-0d80c32c77c0@github.com>

On Fri, 4 Nov 2022 12:38:04 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/jdk/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

@asotona Would it be possible to provide a summary of what is being proposed here? The JEP for Classfile API (JDK-8280389) hasn't been submitted yet so it's not on the technical roadmap. If I read understand this PR correctly, the it looks like it will being the implementation into the java.base so it can be used in java.base in advance of the JEP, is that right?

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

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


From mduigou at openjdk.org  Mon Nov  7 00:28:13 2022
From: mduigou at openjdk.org (Mike Duigou)
Date: Mon, 7 Nov 2022 00:28:13 GMT
Subject: RFR: 8294549: configure script should detect unsupported path [v2]
In-Reply-To: <INSePlc55Rszv4HetLtZS6-BnsZ2irY5hSeNTiipxwE=.55a00ecc-3f61-4615-96fd-7198a7b4ac63@github.com>
References: <INSePlc55Rszv4HetLtZS6-BnsZ2irY5hSeNTiipxwE=.55a00ecc-3f61-4615-96fd-7198a7b4ac63@github.com>
Message-ID: <GIJYF9CqnRArKBLhSi5OwwxqTSpJ_dZemUNo9GfcL0g=.871a484b-2cb8-45b8-8740-a64834d80979@github.com>

> 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.

Mike Duigou 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 one additional commit since the last revision:

  8294549: configure script should detect unsupported path
  
  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.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10477/files
  - new: https://git.openjdk.org/jdk/pull/10477/files/6197cf42..85ae7cc0

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

  Stats: 238242 lines in 2971 files changed: 125727 ins; 73010 del; 39505 mod
  Patch: https://git.openjdk.org/jdk/pull/10477.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10477/head:pull/10477

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


From mduigou at openjdk.org  Mon Nov  7 00:40:43 2022
From: mduigou at openjdk.org (Mike Duigou)
Date: Mon, 7 Nov 2022 00:40:43 GMT
Subject: RFR: 8294549: configure script should detect unsupported path [v2]
In-Reply-To: <GIJYF9CqnRArKBLhSi5OwwxqTSpJ_dZemUNo9GfcL0g=.871a484b-2cb8-45b8-8740-a64834d80979@github.com>
References: <INSePlc55Rszv4HetLtZS6-BnsZ2irY5hSeNTiipxwE=.55a00ecc-3f61-4615-96fd-7198a7b4ac63@github.com>
 <GIJYF9CqnRArKBLhSi5OwwxqTSpJ_dZemUNo9GfcL0g=.871a484b-2cb8-45b8-8740-a64834d80979@github.com>
Message-ID: <lU2M6yP0GzyoMQEow_I9CE3VRSQ952DSB0EwDQrNibk=.6df96e10-dab9-4742-9f46-cf22ca710f28@github.com>

On Mon, 7 Nov 2022 00:28:13 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.
>
> Mike Duigou 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 one additional commit since the last revision:
> 
>   8294549: configure script should detect unsupported path
>   
>   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.

I have removed the path checking from the top level configure script but changes are still required in the `configure` wrapper to correctly pass a potentially bad path for the real configure script. I considered adding the path checking to `basic.m4` in `BASIC_SETUP_PATHS` but could not understand why `UTIL_FIXUP_PATH(TOPDIR)` doesn't already reject the bad path like it promises. (I was also reminded just how loathsome autoconf is as a language?all the worst parts of shell with even more cruft and weirdness).

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

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


From jwaters at openjdk.org  Mon Nov  7 06:14:18 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 7 Nov 2022 06:14:18 GMT
Subject: RFR: 8295884: Implement IDE support for Eclipse [v15]
In-Reply-To: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
Message-ID: <PebfaG_6ch3i_9wfX-xOwNkVyw4rGZCJPugletTFN_o=.e4cfcd47-c305-4c99-9227-508148f49d00@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 Java Virtual Machine's source code, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's unique 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:

  More Changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10853/files
  - new: https://git.openjdk.org/jdk/pull/10853/files/125601f8..14934d9e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=13-14

  Stats: 38 lines in 1 file changed: 23 ins; 2 del; 13 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 asotona at openjdk.org  Mon Nov  7 10:16:34 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 7 Nov 2022 10:16:34 GMT
Subject: RFR: 8294982: Implementation of Classfile API
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <hQbkBN4W3Fe2tAzS-FP6_3uhsjvMWYn1MuygiHYtfx0=.02803d33-b594-4ee8-8640-412d6cc7a6ab@github.com>

On Fri, 4 Nov 2022 12:38:04 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/jdk/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

This pull request (plus a set of planned "chained" pull requests) is an attempt to resolve chicken and egg situation in the Classfile API development.

According to the JEP summary will Classfile API initially serve as an internal replacement for ASM in the JDK, to be later opened as a public API. The JEP has been returned to draft due to permanent feeling of incompleteness of the Classfile API and for lack of real cases and real impact on the JDK.

On the other side it is vital for Classfile API to grow on real cases and very specific applications across the whole JDK. The places of impact are tracked under [JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957) **Consolidate JDK class files parsing, generating, and transforming  (umbrella)**, where 11 of the 18 umbrella sub-tasks (representing individual JDK integrations) have been experimentally implemented and 10 of them are tracked and manually re-based and synchronised  in the jdk-sandbox repository branch. 

It is a complex chicken and egg task to develop library designed to replace ASM (currently sitting in java.base), and at the same time to develop and test its integrations spread across the whole JDK (from java.base lambdas and method handlers generation to the last tier test). And at the same time to prove it is complete enough to have a right to sit in the java.base.

Classfile API is not classified as a standalone JDK project, as all the applications across JDK can be integrated independently. However it is critical for the Classfile API to evolve close to the JDK mainline, so it can became an integral part of other JDK projects (for example project Valhalla). 

In this situation raised an idea to use GitHub pull requests chaining as a technical solution.
The idea is that many of the future applications of the Classfile API (the "chickens") can be individually reviewed, discussed and synchronised on top of this pull request (the "egg"), without immediate integration.

BTW: Originally I though it will be enough to keep this pull request as draft, however technical limitations did not allow me to chain another pull request to a draft pull request.

Any suggestions or proposals are welcome.

Thanks,
Adam

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

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


From ihse at openjdk.org  Mon Nov  7 11:59:31 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 7 Nov 2022 11:59:31 GMT
Subject: RFR: 8294982: Implementation of Classfile API
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <aFBkuTW7rzoou3eDYpTXF6y7hKP_cpT8rKoldx0PGjM=.1a1b117b-b2ee-4c12-8b90-37ed633b3a5e@github.com>

On Fri, 4 Nov 2022 12:38:04 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/jdk/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

So this should be considered as a "draft" PR, even if you cannot specify it as a draft for technical reasons? May I suggest that you prefix the title by `[DRAFT]`? 

That will serve the dual purpose of signalling to reviewers that this is indeed a draft, and it will also make the Skara tooling disallow integration (since the title rules are not being followed).

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

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


From ihse at openjdk.org  Mon Nov  7 12:19:11 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 7 Nov 2022 12:19:11 GMT
Subject: RFR: 8294982: Implementation of Classfile API
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <l5TiO65JvoxaXsg8kYAs1ugfRWjNVd_6HstdFTb2nfg=.05b28b60-3c60-4d83-a3e9-cbba6b4567d0@github.com>

On Fri, 4 Nov 2022 12:38:04 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/jdk/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

make/CompileInterimLangtools.gmk line 78:

> 76: 	$(call LogInfo, Generating Preview.java for jdk.compiler.interim)
> 77: 	$(call MakeDir, $(@D))
> 78: 	$(GREP) -v 'case PATTERN_SWITCH ->' $< > $@

I understand that you have based this on the example above. There is a huge difference, though. The sed expression just updates the package name to include the new `interim` part. These new additions seems to be designed to filter out actual code. 

Since no reason for this is given in comments, I'm assuming there is some code that either does not compile when building this for the interim JDK, or that gives the incorrect result if included. But that means that now suddenly the makefiles has intricate knowledge about specific lines of code in the source code! That is not a good entanglement to have.

make/CompileInterimLangtools.gmk line 84:

> 82: 	$(call LogInfo, Generating TransPatterns.java for jdk.compiler.interim)
> 83: 	$(call MakeDir, $(@D))
> 84: 	$(GREP) -v 'Assert.check(preview.' $< > $@

(The same goes for this instance, of course)

make/modules/java.base/Java.gmk line 37:

> 35: 
> 36: EXCLUDES += java/lang/doc-files
> 37: EXCLUDES += jdk/classfile/snippets

I don't like hard-coded excludes like this. Is this the first real-world example of snippets in the JDK? If not, how has this been resolved in other instances? Maybe we need a more general method to exclude snippets from compiling.

make/test/BuildMicrobenchmark.gmk line 106:

> 104:         --add-exports java.base/jdk.classfile.components=ALL-UNNAMED \
> 105:         --add-exports java.base/jdk.classfile.impl=ALL-UNNAMED \
> 106:         --add-exports java.base/jdk.internal.org.objectweb.asm=ALL-UNNAMED \

Why do you need to export ASM now, when it was not needed before? I thought the purpose here was to replace ASM..?

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

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


From ihse at openjdk.org  Mon Nov  7 12:19:12 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 7 Nov 2022 12:19:12 GMT
Subject: RFR: 8294982: Implementation of Classfile API
In-Reply-To: <l5TiO65JvoxaXsg8kYAs1ugfRWjNVd_6HstdFTb2nfg=.05b28b60-3c60-4d83-a3e9-cbba6b4567d0@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <l5TiO65JvoxaXsg8kYAs1ugfRWjNVd_6HstdFTb2nfg=.05b28b60-3c60-4d83-a3e9-cbba6b4567d0@github.com>
Message-ID: <8KVAMrO7qchZ5Cyzq-QbL4bRfKklcSjXVBzsJP-l1x0=.83786c3d-be15-4376-9cff-f2e6f0df9917@github.com>

On Mon, 7 Nov 2022 12:10:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/jdk/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> make/CompileInterimLangtools.gmk line 78:
> 
>> 76: 	$(call LogInfo, Generating Preview.java for jdk.compiler.interim)
>> 77: 	$(call MakeDir, $(@D))
>> 78: 	$(GREP) -v 'case PATTERN_SWITCH ->' $< > $@
> 
> I understand that you have based this on the example above. There is a huge difference, though. The sed expression just updates the package name to include the new `interim` part. These new additions seems to be designed to filter out actual code. 
> 
> Since no reason for this is given in comments, I'm assuming there is some code that either does not compile when building this for the interim JDK, or that gives the incorrect result if included. But that means that now suddenly the makefiles has intricate knowledge about specific lines of code in the source code! That is not a good entanglement to have.

To be more specific: is there some way the code in Preview.java and TransPatterns.java can be modified so this transmogrification is not needed?

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

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


From ihse at openjdk.org  Mon Nov  7 12:25:18 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 7 Nov 2022 12:25:18 GMT
Subject: RFR: JDK-8296137: diags-examples.xml is broken
In-Reply-To: <Y8whD9OCjRQ-KFUFSYgD_bMRsnYoWnY_TQsLP0BNToU=.7c06b1ed-df55-4885-ac94-a4be10f4d19d@github.com>
References: <Y8whD9OCjRQ-KFUFSYgD_bMRsnYoWnY_TQsLP0BNToU=.7c06b1ed-df55-4885-ac94-a4be10f4d19d@github.com>
Message-ID: <9kacXthJ9DQm7GiGAgh3wvGLQTlGa6K82CYH2dGxfQw=.a5e0de72-dafb-4f18-a891-e439db88b41b@github.com>

On Fri, 4 Nov 2022 21:50:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some minor updates to the `diags/examples` mechanism, repairing some bitrot after one of the not-so-recent repo reorgs.
> 
> For bonus, I've added a target for the German version of the output.

Looks good. Thanks for fixing, and sorry for breaking. :-( At some point, we should go through the files in `make/langtools` and check if they all are still needed, and so that we document how to test them, in case of future refactorings.

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

Marked as reviewed by ihse (Reviewer).

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


From ihse at openjdk.org  Mon Nov  7 12:29:36 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 7 Nov 2022 12:29:36 GMT
Subject: RFR: 8294549: configure script should detect unsupported path [v2]
In-Reply-To: <GIJYF9CqnRArKBLhSi5OwwxqTSpJ_dZemUNo9GfcL0g=.871a484b-2cb8-45b8-8740-a64834d80979@github.com>
References: <INSePlc55Rszv4HetLtZS6-BnsZ2irY5hSeNTiipxwE=.55a00ecc-3f61-4615-96fd-7198a7b4ac63@github.com>
 <GIJYF9CqnRArKBLhSi5OwwxqTSpJ_dZemUNo9GfcL0g=.871a484b-2cb8-45b8-8740-a64834d80979@github.com>
Message-ID: <zNgekPL5nZ8t_DJ4_suwa26PH5TfLRZN6DHnwmEngqA=.ac81e233-ea28-4778-afc2-25266a22fca7@github.com>

On Mon, 7 Nov 2022 00:28:13 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.
>
> Mike Duigou 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 one additional commit since the last revision:
> 
>   8294549: configure script should detect unsupported path
>   
>   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.

configure line 34:

> 32: 
> 33: if [ -z "${this_script_dir}" ]; then
> 34: 	echo "# Could not determine location of configure script"

Why the initial `#`?

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

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


From asotona at openjdk.org  Mon Nov  7 12:48:01 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 7 Nov 2022 12:48:01 GMT
Subject: RFR: 8294982: Implementation of Classfile API
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <gwUG0WIAqKG21bib0YVIC8CkolliWKVy8qEUtEBtsoI=.181ff991-403b-40d4-9c78-41f38957b652@github.com>

On Fri, 4 Nov 2022 12:38:04 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/jdk/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

I apologise for inconveniences, this chain of PRs to introduce Classfile API is probably too premature.
It seems to be possible to turn it into draft now.

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

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


From asotona at openjdk.org  Mon Nov  7 12:48:03 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 7 Nov 2022 12:48:03 GMT
Subject: RFR: 8294982: Implementation of Classfile API
In-Reply-To: <l5TiO65JvoxaXsg8kYAs1ugfRWjNVd_6HstdFTb2nfg=.05b28b60-3c60-4d83-a3e9-cbba6b4567d0@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <l5TiO65JvoxaXsg8kYAs1ugfRWjNVd_6HstdFTb2nfg=.05b28b60-3c60-4d83-a3e9-cbba6b4567d0@github.com>
Message-ID: <UsGoq_-ahKHHyk_TlcRWZtIdyMNN7gx5AaweXsEdskk=.ed9ac47b-e4c3-47a2-95be-32683a45792d@github.com>

On Mon, 7 Nov 2022 12:16:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/jdk/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> make/test/BuildMicrobenchmark.gmk line 106:
> 
>> 104:         --add-exports java.base/jdk.classfile.components=ALL-UNNAMED \
>> 105:         --add-exports java.base/jdk.classfile.impl=ALL-UNNAMED \
>> 106:         --add-exports java.base/jdk.internal.org.objectweb.asm=ALL-UNNAMED \
> 
> Why do you need to export ASM now, when it was not needed before? I thought the purpose here was to replace ASM..?

There are new benchmarks added, comparing performance of Classfile API with ASM.

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

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


From asotona at openjdk.org  Mon Nov  7 12:56:30 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 7 Nov 2022 12:56:30 GMT
Subject: RFR: 8294982: Implementation of Classfile API
In-Reply-To: <8KVAMrO7qchZ5Cyzq-QbL4bRfKklcSjXVBzsJP-l1x0=.83786c3d-be15-4376-9cff-f2e6f0df9917@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <l5TiO65JvoxaXsg8kYAs1ugfRWjNVd_6HstdFTb2nfg=.05b28b60-3c60-4d83-a3e9-cbba6b4567d0@github.com>
 <8KVAMrO7qchZ5Cyzq-QbL4bRfKklcSjXVBzsJP-l1x0=.83786c3d-be15-4376-9cff-f2e6f0df9917@github.com>
Message-ID: <1D0PTNGSVOGfVS0JBTUNc05udOIxs0UToG_8_Ubb4EU=.f3d5b9af-a5b3-47af-96e0-42df82444edc@github.com>

On Mon, 7 Nov 2022 12:15:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/CompileInterimLangtools.gmk line 78:
>> 
>>> 76: 	$(call LogInfo, Generating Preview.java for jdk.compiler.interim)
>>> 77: 	$(call MakeDir, $(@D))
>>> 78: 	$(GREP) -v 'case PATTERN_SWITCH ->' $< > $@
>> 
>> I understand that you have based this on the example above. There is a huge difference, though. The sed expression just updates the package name to include the new `interim` part. These new additions seems to be designed to filter out actual code. 
>> 
>> Since no reason for this is given in comments, I'm assuming there is some code that either does not compile when building this for the interim JDK, or that gives the incorrect result if included. But that means that now suddenly the makefiles has intricate knowledge about specific lines of code in the source code! That is not a good entanglement to have.
>
> To be more specific: is there some way the code in Preview.java and TransPatterns.java can be modified so this transmogrification is not needed?

Patched interim Preview and TransPatterns is a temporary workaround to allow internal use of pattern switch in the JDK sources.

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

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


From ihse at openjdk.org  Mon Nov  7 12:56:30 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 7 Nov 2022 12:56:30 GMT
Subject: RFR: 8294982: Implementation of Classfile API
In-Reply-To: <UsGoq_-ahKHHyk_TlcRWZtIdyMNN7gx5AaweXsEdskk=.ed9ac47b-e4c3-47a2-95be-32683a45792d@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <l5TiO65JvoxaXsg8kYAs1ugfRWjNVd_6HstdFTb2nfg=.05b28b60-3c60-4d83-a3e9-cbba6b4567d0@github.com>
 <UsGoq_-ahKHHyk_TlcRWZtIdyMNN7gx5AaweXsEdskk=.ed9ac47b-e4c3-47a2-95be-32683a45792d@github.com>
Message-ID: <BiOpTl1mDs57o56qBYvTVEOj5uPXl2zqCFAloy8h9_0=.dc8c6a14-94f6-426c-bcc8-515d6577d0b6@github.com>

On Mon, 7 Nov 2022 12:45:00 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> make/test/BuildMicrobenchmark.gmk line 106:
>> 
>>> 104:         --add-exports java.base/jdk.classfile.components=ALL-UNNAMED \
>>> 105:         --add-exports java.base/jdk.classfile.impl=ALL-UNNAMED \
>>> 106:         --add-exports java.base/jdk.internal.org.objectweb.asm=ALL-UNNAMED \
>> 
>> Why do you need to export ASM now, when it was not needed before? I thought the purpose here was to replace ASM..?
>
> There are new benchmarks added, comparing performance of Classfile API with ASM.

I see.

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

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


From asotona at openjdk.org  Mon Nov  7 13:05:30 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 7 Nov 2022 13:05:30 GMT
Subject: RFR: 8294982: Implementation of Classfile API
In-Reply-To: <l5TiO65JvoxaXsg8kYAs1ugfRWjNVd_6HstdFTb2nfg=.05b28b60-3c60-4d83-a3e9-cbba6b4567d0@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <l5TiO65JvoxaXsg8kYAs1ugfRWjNVd_6HstdFTb2nfg=.05b28b60-3c60-4d83-a3e9-cbba6b4567d0@github.com>
Message-ID: <SgfHbOybBS2rH24eOQDSgoS_Uc0YWdT0YlO6oJ79aFs=.9c07a20b-f21e-4610-b48a-82d9cce5eb98@github.com>

On Mon, 7 Nov 2022 12:13:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/jdk/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> make/modules/java.base/Java.gmk line 37:
> 
>> 35: 
>> 36: EXCLUDES += java/lang/doc-files
>> 37: EXCLUDES += jdk/classfile/snippets
> 
> I don't like hard-coded excludes like this. Is this the first real-world example of snippets in the JDK? If not, how has this been resolved in other instances? Maybe we need a more general method to exclude snippets from compiling.

I'll fix it, thanks.

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

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


From ihse at openjdk.org  Mon Nov  7 13:34:36 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 7 Nov 2022 13:34:36 GMT
Subject: RFR: 8294549: configure script should detect unsupported path [v2]
In-Reply-To: <GIJYF9CqnRArKBLhSi5OwwxqTSpJ_dZemUNo9GfcL0g=.871a484b-2cb8-45b8-8740-a64834d80979@github.com>
References: <INSePlc55Rszv4HetLtZS6-BnsZ2irY5hSeNTiipxwE=.55a00ecc-3f61-4615-96fd-7198a7b4ac63@github.com>
 <GIJYF9CqnRArKBLhSi5OwwxqTSpJ_dZemUNo9GfcL0g=.871a484b-2cb8-45b8-8740-a64834d80979@github.com>
Message-ID: <TY5zCY28F1cGJjCFX0oDBnghxJihwIlm4h7eNRR8Qxw=.376808b1-aff1-4c88-bf54-569776f49a1f@github.com>

On Mon, 7 Nov 2022 00:28:13 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.
>
> Mike Duigou 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 one additional commit since the last revision:
> 
>   8294549: configure script should detect unsupported path
>   
>   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.

Does this patch work for you? I'm getting errors before even launching the autoconf script:


ihse at saturnus:~/testa mellanslag/jdk$ bash configure

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

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


From ihse at openjdk.org  Mon Nov  7 13:45:34 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 7 Nov 2022 13:45:34 GMT
Subject: RFR: 8294549: configure script should detect unsupported path [v2]
In-Reply-To: <GIJYF9CqnRArKBLhSi5OwwxqTSpJ_dZemUNo9GfcL0g=.871a484b-2cb8-45b8-8740-a64834d80979@github.com>
References: <INSePlc55Rszv4HetLtZS6-BnsZ2irY5hSeNTiipxwE=.55a00ecc-3f61-4615-96fd-7198a7b4ac63@github.com>
 <GIJYF9CqnRArKBLhSi5OwwxqTSpJ_dZemUNo9GfcL0g=.871a484b-2cb8-45b8-8740-a64834d80979@github.com>
Message-ID: <pGwqhHRgCyPeXctgGwjq7msDO9ItIilBwieVMDms0w0=.9eeada6b-938e-45da-be54-0116d8538e65@github.com>

On Mon, 7 Nov 2022 00:28:13 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.
>
> Mike Duigou 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 one additional commit since the last revision:
> 
>   8294549: configure script should detect unsupported path
>   
>   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.

I think you need to restore you original space-checking part, but put it in `make/autoconf/configure`. I tried to make this script pass on a path containing spaces to the autoconf configure script, but it was just too much work, for very little gain. Several places assumed space could be used to separate distinct pathes, and that would have forced a complete rewrite of that logic.

With the patch as currently in the PR, and this addition, this works fine for me:


diff --git a/make/autoconf/configure b/make/autoconf/configure
index 4b26e3d7061..e75dc3c7203 100644
--- a/make/autoconf/configure
+++ b/make/autoconf/configure
@@ -1,6 +1,6 @@
 #!/bin/bash
 #
-# Copyright (c) 2012, 2020, Oracle and/or its affiliates. All rights reserved.
+# Copyright (c) 2012, 2022, Oracle and/or its affiliates. All rights reserved.
 # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 #
 # This code is free software; you can redistribute it and/or modify it
@@ -39,6 +39,12 @@ if test "x$BASH" = x; then
   echo "Error: This script must be run using bash." 1>&2
   exit 1
 fi
+
+if [[ "$TOPDIR" =~ .*[[:space:]]+.* ]]; then
+  echo "Error: Build path containing space character is not supported" 1>&2
+  exit 1
+fi
+
 # Force autoconf to use bash. This also means we must disable autoconf re-exec.
 export CONFIG_SHELL=$BASH
 export _as_can_reexec=no

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

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


From ihse at openjdk.org  Mon Nov  7 14:18:33 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 7 Nov 2022 14:18:33 GMT
Subject: RFR: 8296115: Allow for compiling the JDK with strict standards
 conformance [v4]
In-Reply-To: <RSam1XvDYiyOwOj7I-UtO4SkN026rS-_znurjm5lrWA=.735e341e-7892-4c22-96e1-46c8f589f25b@github.com>
References: <yaKDZVxxdPLeOt-Z2Mw9Mjknb9q1tg3Pp2PRYfHihiQ=.d7c3320f-a9ae-4779-9bd5-00a9366a8bce@github.com>
 <RSam1XvDYiyOwOj7I-UtO4SkN026rS-_znurjm5lrWA=.735e341e-7892-4c22-96e1-46c8f589f25b@github.com>
Message-ID: <mB4sS3aReMcKXWc0hLtv_ZjBS5aFNJ2MDjAYXplrFYw=.624d2b87-e990-4e61-879f-beb267ff6e38@github.com>

On Wed, 2 Nov 2022 16:45:35 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.
>
> 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 seven additional commits since the last revision:
> 
>  - Export not required
>  - Merge remote-tracking branch 'upstream/master' into permissive
>  - Merge remote-tracking branch 'upstream/master' into permissive
>  - Merge remote-tracking branch 'upstream/master' into permissive
>  - Format
>  - Keep docs up to date
>  - New --enable-conforming-compilation option

I experimented with enabling this for GHA, and it turned out that there are huge efforts needed to even make the code base compile with this flag turned on. I'm starting to wonder if it was such a great idea to introduce this, after all. I realize I did a poor job when reviewing this to ask if this did compile. Well, I can tell now, it does not. For gcc, it seems practically impossible to ever get it to work, since all hotspot constructs such as

DEBUG_ONLY(if (checkResult) log_trace("Checked"));

which are very common, will result in a warning about a superfluous semicolon in non-debug builds. (And similar for `AARCH64_ONLY(...);` etc).

For clang, this warning of semi-colon could be turned off separately, which -- combined with some other disabled warnings -- made it possible to compile. However, the code it complained about was in most cases fine, it was just using non-standard gcc or clang extensions to the C++ standard. We really need to raise this to a discussion if this should be considered a problem. 

Here is a commit showing most (but not all) of the changes needed to make clang compile on macOS with the new conformance option turned on: https://github.com/openjdk/jdk/commit/793c57a8986c7875b4913b6eabbaef8baab23e3e

I think some of these warnings are definitely legit, like `import-preprocessor-directive-pedantic` (where the code uses `#import` instead of `#include`) or `c++17-extensions` (we should not include code that is beyond C++14, at least not in this point in time). But most are complaints about benign use of gcc/clang extensions.

And the pedantic modes of gcc is really, really cranky. And it can't be piecewise turned off like clang, so as I said, I doubt this can ever get to work.

(Taggning @kimbarrett since I know you are interested in such questions)

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

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


From ihse at openjdk.org  Mon Nov  7 14:23:11 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 7 Nov 2022 14:23:11 GMT
Subject: RFR: 8296115: Allow for compiling the JDK with strict standards
 conformance [v4]
In-Reply-To: <RSam1XvDYiyOwOj7I-UtO4SkN026rS-_znurjm5lrWA=.735e341e-7892-4c22-96e1-46c8f589f25b@github.com>
References: <yaKDZVxxdPLeOt-Z2Mw9Mjknb9q1tg3Pp2PRYfHihiQ=.d7c3320f-a9ae-4779-9bd5-00a9366a8bce@github.com>
 <RSam1XvDYiyOwOj7I-UtO4SkN026rS-_znurjm5lrWA=.735e341e-7892-4c22-96e1-46c8f589f25b@github.com>
Message-ID: <gbONcaTt_YzfQdY8a5-MJ0lJX5hxHb6M7LNj09w5UPs=.2a3b24a6-a825-4ec5-be05-aa9106d11dd6@github.com>

On Wed, 2 Nov 2022 16:45:35 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.
>
> 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 seven additional commits since the last revision:
> 
>  - Export not required
>  - Merge remote-tracking branch 'upstream/master' into permissive
>  - Merge remote-tracking branch 'upstream/master' into permissive
>  - Merge remote-tracking branch 'upstream/master' into permissive
>  - Format
>  - Keep docs up to date
>  - New --enable-conforming-compilation option

Furthermore, I'm starting to wonder if it was such a great idea to combine this with the visual studio `/permissive-`. While the gcc/clang switches are about strict standards compliance, the visual studio switch is more of a "get the VS compiler more in line with other modern compilers", and Microsoft has explicitly warned that this will be enabled, then default, then the only choice, going forward. So this is really something we would want to see enabled all the time.

So, I am more or less proposing that we back this out, and that instead:

1) we try to enable `/permissive-` by default for Windows (this will require some code changes first)

2) we consider if we should raise the bar of "pedantictness" for clang, but with warnings we do not care about being turned off. (An alternative is that we explicitly turn on some selected additional warnings that we think are useful)

3) we entirely drops the idea that we could ever achieve anything like this for gcc, unless they up their game in having more finely grained warnings

4) and if you want to experiment with more strict compilation, to reach your goal of compiler/os-independence, you just use the standard method of `--with-extra-c-flags` to pass `-Wpedantict` etc.

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

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


From ihse at openjdk.org  Mon Nov  7 15:03:30 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 7 Nov 2022 15:03:30 GMT
Subject: RFR: 8296479: Remove stray comment about POST_STRIP_CMD
Message-ID: <_u0lir0oh7GLRB3Vc7OADvQxuU1iFB_RzPJIqFObVeQ=.66c5cb61-2c61-4a47-bef1-2e9d3d825c1a@github.com>

The variable POST_STRIP_CMD has been removed, but not all comments about it

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

Commit messages:
 - 8296479: Remove stray comment about POST_STRIP_CMD

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

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


From jjg at openjdk.org  Mon Nov  7 15:59:36 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 7 Nov 2022 15:59:36 GMT
Subject: RFR: JDK-8296137: diags-examples.xml is broken
In-Reply-To: <9kacXthJ9DQm7GiGAgh3wvGLQTlGa6K82CYH2dGxfQw=.a5e0de72-dafb-4f18-a891-e439db88b41b@github.com>
References: <Y8whD9OCjRQ-KFUFSYgD_bMRsnYoWnY_TQsLP0BNToU=.7c06b1ed-df55-4885-ac94-a4be10f4d19d@github.com>
 <9kacXthJ9DQm7GiGAgh3wvGLQTlGa6K82CYH2dGxfQw=.a5e0de72-dafb-4f18-a891-e439db88b41b@github.com>
Message-ID: <kOoey77Nqyn6-T6Imf_6UsgrOCFcWvm69alGsY1EvpM=.b1106100-4143-47f8-9d2a-227c2b7d0073@github.com>

On Mon, 7 Nov 2022 12:23:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Looks good. Thanks for fixing, and sorry for breaking. :-( At some point, we should go through the files in `make/langtools` and check if they all are still needed, and so that we document how to test them, in case of future refactorings.

Yeah, ideally we should execute code like this more of the time, perhaps figuring out how to run it in some sort of test.

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

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


From jjg at openjdk.org  Mon Nov  7 16:01:41 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 7 Nov 2022 16:01:41 GMT
Subject: Integrated: JDK-8296137: diags-examples.xml is broken
In-Reply-To: <Y8whD9OCjRQ-KFUFSYgD_bMRsnYoWnY_TQsLP0BNToU=.7c06b1ed-df55-4885-ac94-a4be10f4d19d@github.com>
References: <Y8whD9OCjRQ-KFUFSYgD_bMRsnYoWnY_TQsLP0BNToU=.7c06b1ed-df55-4885-ac94-a4be10f4d19d@github.com>
Message-ID: <SFcQbOVrWsCVkbcTwg8smLy9vSNZyUAHzeY2MFm1Enc=.e4546db7-e929-46a0-96c3-ca9ecdcfc3bd@github.com>

On Fri, 4 Nov 2022 21:50:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some minor updates to the `diags/examples` mechanism, repairing some bitrot after one of the not-so-recent repo reorgs.
> 
> For bonus, I've added a target for the German version of the output.

This pull request has now been integrated.

Changeset: f8b2574e
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f8b2574ebc32fa0e62dbaa0f2447757ff83c320f
Stats:     12 lines in 2 files changed: 6 ins; 0 del; 6 mod

8296137: diags-examples.xml is broken

Reviewed-by: iris, vromero, ihse

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

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


From ihse at openjdk.org  Mon Nov  7 16:25:39 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 7 Nov 2022 16:25:39 GMT
Subject: RFR: 8294982: Implementation of Classfile API
In-Reply-To: <1D0PTNGSVOGfVS0JBTUNc05udOIxs0UToG_8_Ubb4EU=.f3d5b9af-a5b3-47af-96e0-42df82444edc@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <l5TiO65JvoxaXsg8kYAs1ugfRWjNVd_6HstdFTb2nfg=.05b28b60-3c60-4d83-a3e9-cbba6b4567d0@github.com>
 <8KVAMrO7qchZ5Cyzq-QbL4bRfKklcSjXVBzsJP-l1x0=.83786c3d-be15-4376-9cff-f2e6f0df9917@github.com>
 <1D0PTNGSVOGfVS0JBTUNc05udOIxs0UToG_8_Ubb4EU=.f3d5b9af-a5b3-47af-96e0-42df82444edc@github.com>
Message-ID: <5OGC5Uv2U2YuWEueIlag1J1-sIisWbuwQnJdEGwFrRE=.098668c9-1e3a-4e79-9a3a-30d55fe7e440@github.com>

On Mon, 7 Nov 2022 12:52:38 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> To be more specific: is there some way the code in Preview.java and TransPatterns.java can be modified so this transmogrification is not needed?
>
> Patched interim Preview and TransPatterns is a temporary workaround to allow internal use of pattern switch in the JDK sources.

So this will be removed later on in one of the follow up "chicken" PRs?

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

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


From asotona at openjdk.org  Mon Nov  7 16:30:32 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 7 Nov 2022 16:30:32 GMT
Subject: RFR: 8294982: Implementation of Classfile API
In-Reply-To: <5OGC5Uv2U2YuWEueIlag1J1-sIisWbuwQnJdEGwFrRE=.098668c9-1e3a-4e79-9a3a-30d55fe7e440@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <l5TiO65JvoxaXsg8kYAs1ugfRWjNVd_6HstdFTb2nfg=.05b28b60-3c60-4d83-a3e9-cbba6b4567d0@github.com>
 <8KVAMrO7qchZ5Cyzq-QbL4bRfKklcSjXVBzsJP-l1x0=.83786c3d-be15-4376-9cff-f2e6f0df9917@github.com>
 <1D0PTNGSVOGfVS0JBTUNc05udOIxs0UToG_8_Ubb4EU=.f3d5b9af-a5b3-47af-96e0-42df82444edc@github.com>
 <5OGC5Uv2U2YuWEueIlag1J1-sIisWbuwQnJdEGwFrRE=.098668c9-1e3a-4e79-9a3a-30d55fe7e440@github.com>
Message-ID: <A9kiGx0-AfBCC6IrmmwUGIxOY0EbGKu6wHCpDXQNiQE=.4b6ee2f8-affa-4f46-8713-bb1d0a125fbf@github.com>

On Mon, 7 Nov 2022 16:21:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Patched interim Preview and TransPatterns is a temporary workaround to allow internal use of pattern switch in the JDK sources.
>
> So this will be removed later on in one of the follow up "chicken" PRs?

It will be removed in this PR later, this specific workaround is not intended to fall into JDK.
The CompileInterimLangtools patch represents a way how to make the whole Classfile API and following "chickens" compilable in the current JDK.

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

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


From iris at openjdk.org  Mon Nov  7 17:06:20 2022
From: iris at openjdk.org (Iris Clark)
Date: Mon, 7 Nov 2022 17:06:20 GMT
Subject: RFR: 8296479: Remove stray comment about POST_STRIP_CMD
In-Reply-To: <_u0lir0oh7GLRB3Vc7OADvQxuU1iFB_RzPJIqFObVeQ=.66c5cb61-2c61-4a47-bef1-2e9d3d825c1a@github.com>
References: <_u0lir0oh7GLRB3Vc7OADvQxuU1iFB_RzPJIqFObVeQ=.66c5cb61-2c61-4a47-bef1-2e9d3d825c1a@github.com>
Message-ID: <zjrb5pIyR84yXRfw2IWQ8tK02qzlYJT8TqVROvTl-nU=.7d2d9b26-fde9-41ce-98ea-2993d7b9c9c8@github.com>

On Mon, 7 Nov 2022 14:56:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The variable POST_STRIP_CMD has been removed, but not all comments about it

Marked as reviewed by iris (Reviewer).

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

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


From ihse at openjdk.org  Mon Nov  7 19:06:20 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 7 Nov 2022 19:06:20 GMT
Subject: Integrated: 8296479: Remove stray comment about POST_STRIP_CMD
In-Reply-To: <_u0lir0oh7GLRB3Vc7OADvQxuU1iFB_RzPJIqFObVeQ=.66c5cb61-2c61-4a47-bef1-2e9d3d825c1a@github.com>
References: <_u0lir0oh7GLRB3Vc7OADvQxuU1iFB_RzPJIqFObVeQ=.66c5cb61-2c61-4a47-bef1-2e9d3d825c1a@github.com>
Message-ID: <59a2RfHrPi9AhFJtVoH51ODFG09GZtgovDJv44R033Y=.16da06a3-d654-4118-be8a-4d4c8a9919fa@github.com>

On Mon, 7 Nov 2022 14:56:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The variable POST_STRIP_CMD has been removed, but not all comments about it

This pull request has now been integrated.

Changeset: b29817a6
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b29817a626ce58fb06a104720317ea62ea6697d7
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8296479: Remove stray comment about POST_STRIP_CMD

Reviewed-by: iris

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

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


From lujaniuk at openjdk.org  Mon Nov  7 23:16:44 2022
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Mon, 7 Nov 2022 23:16:44 GMT
Subject: Integrated: 8295663 Rephrase introduction to testing.md
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: <mW29bT1-0XWbf7dH40Ymd8Agym3h9V5j5OQpMrqE66A=.2eb721bc-a154-4c05-8619-a331726996be@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

This pull request has now been integrated.

Changeset: b6738c18
Author:    Ludvig Janiuk <lujaniuk at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b6738c1831a75d493982730c5f39a7704e746ba7
Stats:     87 lines in 2 files changed: 31 ins; 3 del; 53 mod

8295663: Rephrase introduction to testing.md

Reviewed-by: ihse, erikj

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

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


From shade at openjdk.org  Tue Nov  8 10:37:06 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 8 Nov 2022 10:37:06 GMT
Subject: RFR: 8294591: Fix cast-function-type warning in TemplateTable [v5]
In-Reply-To: <F9kScSH8YZ9kK8XAcl5pPPE6sPrHCBUc_zNriSaP8EU=.d5c7452c-72ed-4f41-9dea-5bd8a7fccbc0@github.com>
References: <F9kScSH8YZ9kK8XAcl5pPPE6sPrHCBUc_zNriSaP8EU=.d5c7452c-72ed-4f41-9dea-5bd8a7fccbc0@github.com>
Message-ID: <KbvGzI0aAbjwHV9ps_M_Wvkmcf5bgIF0etAUFYXkNTw=.0c55b7ce-b985-4abf-b4de-4d35381a9bfd@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 five commits:

 - Merge branch 'master' into JDK-8294591-warning-cast-function-type-templatetable
 - Fix build failures
 - 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=04
  Stats: 46 lines in 9 files changed: 6 ins; 1 del; 39 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 jwaters at openjdk.org  Wed Nov  9 08:23:27 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 9 Nov 2022 08:23:27 GMT
Subject: RFR: 8296115: Allow for compiling the JDK with strict standards
 conformance [v4]
In-Reply-To: <RSam1XvDYiyOwOj7I-UtO4SkN026rS-_znurjm5lrWA=.735e341e-7892-4c22-96e1-46c8f589f25b@github.com>
References: <yaKDZVxxdPLeOt-Z2Mw9Mjknb9q1tg3Pp2PRYfHihiQ=.d7c3320f-a9ae-4779-9bd5-00a9366a8bce@github.com>
 <RSam1XvDYiyOwOj7I-UtO4SkN026rS-_znurjm5lrWA=.735e341e-7892-4c22-96e1-46c8f589f25b@github.com>
Message-ID: <r6rCJSMzjBRylCbxbQO5cZD3GuKSBNY6sh22dsXcse4=.df073432-b968-4a49-8bf5-84d32addf331@github.com>

On Wed, 2 Nov 2022 16:45:35 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.
>
> 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 seven additional commits since the last revision:
> 
>  - Export not required
>  - Merge remote-tracking branch 'upstream/master' into permissive
>  - Merge remote-tracking branch 'upstream/master' into permissive
>  - Merge remote-tracking branch 'upstream/master' into permissive
>  - Format
>  - Keep docs up to date
>  - New --enable-conforming-compilation option

> I experimented with enabling this for GHA, and it turned out that there are huge efforts needed to even make the code base compile with this flag turned on. I'm starting to wonder if it was such a great idea to introduce this, after all. I realize I did a poor job when reviewing this to ask if this did compile. Well, I can tell now, it does not. For gcc, it seems practically impossible to ever get it to work, since all hotspot constructs such as
> 
> ```
> DEBUG_ONLY(if (checkResult) log_trace("Checked"));
> ```
> 
> which are very common, will result in a warning about a superfluous semicolon in non-debug builds. (And similar for `AARCH64_ONLY(...);` etc).
> 
> For clang, this warning of semi-colon could be turned off separately, which -- combined with some other disabled warnings -- made it possible to compile. However, the code it complained about was in most cases fine, it was just using non-standard gcc or clang extensions to the C++ standard. We really need to raise this to a discussion if this should be considered a problem.
> 
> Here is a commit showing most (but not all) of the changes needed to make clang compile on macOS with the new conformance option turned on: [793c57a](https://github.com/openjdk/jdk/commit/793c57a8986c7875b4913b6eabbaef8baab23e3e)
> 
> I think some of these warnings are definitely legit, like `import-preprocessor-directive-pedantic` (where the code uses `#import` instead of `#include`) or `c++17-extensions` (we should not include code that is beyond C++14, at least not in this point in time). But most are complaints about benign use of gcc/clang extensions.
> 
> And the pedantic modes of gcc is really, really cranky. And it can't be piecewise turned off like clang, so as I said, I doubt this can ever get to work.
> 
> (Taggning @kimbarrett since I know you are interested in such questions)

Oh dear, I was expecting several issues with gcc but it seems like I _grossly_ underestimated just how strict it would be. I'll back this out and reopen [8241499](https://bugs.openjdk.org/browse/JDK-8241499) if there aren't any objections to that, since this is my mess to clean up. From what I've tested -permissive- didn't really break anything, so it should be trivial to change that to just be on by default instead of through a flag (Testing not considered, at least)

> c++17-extensions (we should not include code that is beyond C++14, at least not in this point in time).

There are plans for having code compatibility past C++14? Unlike the permissive switch, from what I've tested a large chunk of java.desktop code is really not happy with anything C++17 or above, so that would be a really big problem if so

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

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


From ihse at openjdk.org  Wed Nov  9 10:13:36 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Nov 2022 10:13:36 GMT
Subject: RFR: 8296115: Allow for compiling the JDK with strict standards
 conformance [v4]
In-Reply-To: <r6rCJSMzjBRylCbxbQO5cZD3GuKSBNY6sh22dsXcse4=.df073432-b968-4a49-8bf5-84d32addf331@github.com>
References: <yaKDZVxxdPLeOt-Z2Mw9Mjknb9q1tg3Pp2PRYfHihiQ=.d7c3320f-a9ae-4779-9bd5-00a9366a8bce@github.com>
 <RSam1XvDYiyOwOj7I-UtO4SkN026rS-_znurjm5lrWA=.735e341e-7892-4c22-96e1-46c8f589f25b@github.com>
 <r6rCJSMzjBRylCbxbQO5cZD3GuKSBNY6sh22dsXcse4=.df073432-b968-4a49-8bf5-84d32addf331@github.com>
Message-ID: <ODEzj70zqX0TZhBKVlKA_602CM3bufkBCihInkZQdB8=.170d427b-270e-4d45-b95f-9b45cf420269@github.com>

On Wed, 9 Nov 2022 08:19:45 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> 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 seven additional commits since the last revision:
>> 
>>  - Export not required
>>  - Merge remote-tracking branch 'upstream/master' into permissive
>>  - Merge remote-tracking branch 'upstream/master' into permissive
>>  - Merge remote-tracking branch 'upstream/master' into permissive
>>  - Format
>>  - Keep docs up to date
>>  - New --enable-conforming-compilation option
>
>> I experimented with enabling this for GHA, and it turned out that there are huge efforts needed to even make the code base compile with this flag turned on. I'm starting to wonder if it was such a great idea to introduce this, after all. I realize I did a poor job when reviewing this to ask if this did compile. Well, I can tell now, it does not. For gcc, it seems practically impossible to ever get it to work, since all hotspot constructs such as
>> 
>> ```
>> DEBUG_ONLY(if (checkResult) log_trace("Checked"));
>> ```
>> 
>> which are very common, will result in a warning about a superfluous semicolon in non-debug builds. (And similar for `AARCH64_ONLY(...);` etc).
>> 
>> For clang, this warning of semi-colon could be turned off separately, which -- combined with some other disabled warnings -- made it possible to compile. However, the code it complained about was in most cases fine, it was just using non-standard gcc or clang extensions to the C++ standard. We really need to raise this to a discussion if this should be considered a problem.
>> 
>> Here is a commit showing most (but not all) of the changes needed to make clang compile on macOS with the new conformance option turned on: [793c57a](https://github.com/openjdk/jdk/commit/793c57a8986c7875b4913b6eabbaef8baab23e3e)
>> 
>> I think some of these warnings are definitely legit, like `import-preprocessor-directive-pedantic` (where the code uses `#import` instead of `#include`) or `c++17-extensions` (we should not include code that is beyond C++14, at least not in this point in time). But most are complaints about benign use of gcc/clang extensions.
>> 
>> And the pedantic modes of gcc is really, really cranky. And it can't be piecewise turned off like clang, so as I said, I doubt this can ever get to work.
>> 
>> (Taggning @kimbarrett since I know you are interested in such questions)
> 
> Oh dear, I was expecting several issues with gcc but it seems like I _grossly_ underestimated just how strict it would be. I'll back this out and reopen [8241499](https://bugs.openjdk.org/browse/JDK-8241499) if there aren't any objections to that, since this is my mess to clean up. From what I've tested -permissive- didn't really break anything, so it should be trivial to change that to just be on by default instead of through a flag (Testing not considered, at least)
> 
>> c++17-extensions (we should not include code that is beyond C++14, at least not in this point in time).
> 
> There are plans for having code compatibility past C++14? Unlike the permissive switch, from what I've tested a large chunk of java.desktop code is really not happy with anything C++17 or above, so that would be a really big problem if so

@TheShermanTanker Yes, I think that would be the best way forward. Thank you for taking care of it!

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

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


From djelinski at openjdk.org  Wed Nov  9 10:30:39 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 9 Nov 2022 10:30:39 GMT
Subject: RFR: 8296115: Allow for compiling the JDK with strict standards
 conformance [v4]
In-Reply-To: <RSam1XvDYiyOwOj7I-UtO4SkN026rS-_znurjm5lrWA=.735e341e-7892-4c22-96e1-46c8f589f25b@github.com>
References: <yaKDZVxxdPLeOt-Z2Mw9Mjknb9q1tg3Pp2PRYfHihiQ=.d7c3320f-a9ae-4779-9bd5-00a9366a8bce@github.com>
 <RSam1XvDYiyOwOj7I-UtO4SkN026rS-_znurjm5lrWA=.735e341e-7892-4c22-96e1-46c8f589f25b@github.com>
Message-ID: <Wr1ms01L-YRhMg1hNepQHE4CGfjgkr2XssygEhdXDfY=.9550157a-e32f-497a-9bfe-8550356ce95d@github.com>

On Wed, 2 Nov 2022 16:45:35 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.
>
> 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 seven additional commits since the last revision:
> 
>  - Export not required
>  - Merge remote-tracking branch 'upstream/master' into permissive
>  - Merge remote-tracking branch 'upstream/master' into permissive
>  - Merge remote-tracking branch 'upstream/master' into permissive
>  - Format
>  - Keep docs up to date
>  - New --enable-conforming-compilation option

FWIW, `-permissive-` is getting less permissive with every compiler iteration; with MSVC2022 (` C Compiler:     Version 19.33.31629`) even hotspot doesn't build.

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

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


From ihse at openjdk.org  Wed Nov  9 12:17:32 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Nov 2022 12:17:32 GMT
Subject: RFR: 8296115: Allow for compiling the JDK with strict standards
 conformance [v4]
In-Reply-To: <Wr1ms01L-YRhMg1hNepQHE4CGfjgkr2XssygEhdXDfY=.9550157a-e32f-497a-9bfe-8550356ce95d@github.com>
References: <yaKDZVxxdPLeOt-Z2Mw9Mjknb9q1tg3Pp2PRYfHihiQ=.d7c3320f-a9ae-4779-9bd5-00a9366a8bce@github.com>
 <RSam1XvDYiyOwOj7I-UtO4SkN026rS-_znurjm5lrWA=.735e341e-7892-4c22-96e1-46c8f589f25b@github.com>
 <Wr1ms01L-YRhMg1hNepQHE4CGfjgkr2XssygEhdXDfY=.9550157a-e32f-497a-9bfe-8550356ce95d@github.com>
Message-ID: <IcumtyDaWt_1UWxpAFTg6yKqIYox9_BQzNICyeK6dIQ=.691b492f-a1b9-4d2a-adfa-06157a747356@github.com>

On Wed, 9 Nov 2022 10:26:36 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> 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 seven additional commits since the last revision:
>> 
>>  - Export not required
>>  - Merge remote-tracking branch 'upstream/master' into permissive
>>  - Merge remote-tracking branch 'upstream/master' into permissive
>>  - Merge remote-tracking branch 'upstream/master' into permissive
>>  - Format
>>  - Keep docs up to date
>>  - New --enable-conforming-compilation option
>
> FWIW, `-permissive-` is getting less permissive with every compiler iteration; with MSVC2022 (` C Compiler:     Version 19.33.31629`) even hotspot doesn't build.

@djelinski That's a bit alarming. :-/ Do you have any idea if it complains "correctly" on Hotspot by detecting fishy code that should be fixed, or if it is overly cranky and is complaining about reasonable but non-standard extensions?

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

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


From djelinski at openjdk.org  Wed Nov  9 13:21:43 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 9 Nov 2022 13:21:43 GMT
Subject: RFR: 8296115: Allow for compiling the JDK with strict standards
 conformance [v4]
In-Reply-To: <IcumtyDaWt_1UWxpAFTg6yKqIYox9_BQzNICyeK6dIQ=.691b492f-a1b9-4d2a-adfa-06157a747356@github.com>
References: <yaKDZVxxdPLeOt-Z2Mw9Mjknb9q1tg3Pp2PRYfHihiQ=.d7c3320f-a9ae-4779-9bd5-00a9366a8bce@github.com>
 <RSam1XvDYiyOwOj7I-UtO4SkN026rS-_znurjm5lrWA=.735e341e-7892-4c22-96e1-46c8f589f25b@github.com>
 <Wr1ms01L-YRhMg1hNepQHE4CGfjgkr2XssygEhdXDfY=.9550157a-e32f-497a-9bfe-8550356ce95d@github.com>
 <IcumtyDaWt_1UWxpAFTg6yKqIYox9_BQzNICyeK6dIQ=.691b492f-a1b9-4d2a-adfa-06157a747356@github.com>
Message-ID: <vfzjsWSPUD34sMnBaBpEYqsM3QXYlKHQ9ytQRpShMDA=.f7dc1978-08ab-4c8f-ab1e-25dd13bbf502@github.com>

On Wed, 9 Nov 2022 12:15:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> FWIW, `-permissive-` is getting less permissive with every compiler iteration; with MSVC2022 (` C Compiler:     Version 19.33.31629`) even hotspot doesn't build.
>
> @djelinski That's a bit alarming. :-/ Do you have any idea if it complains "correctly" on Hotspot by detecting fishy code that should be fixed, or if it is overly cranky and is complaining about reasonable but non-standard extensions?

@magicus that depends on how you define "cranky"; in default mode, `long` and `int` are fully interchangeable. In `permissive-`, they are [distinct types](https://learn.microsoft.com/en-us/cpp/overview/cpp-conformance-improvements-2019?view=msvc-170#overload-resolution-involving-integral-overloads-and-long-arguments). As a result, compilation of code that assumes that `jint` is equal to `int` breaks (on Windows, `jint` is typedef'd to `long`).

Example failure:

C:...\src\hotspot\share\opto\mulnode.cpp(248): error C2668: 'uabs': ambiguous call to overloaded function
C:...\src\hotspot\share\utilities/globalDefinitions.hpp(1146): note: could be 'unsigned int uabs(int)'
C:...\src\hotspot\share\utilities/globalDefinitions.hpp(1145): note: or       'julong uabs(jlong)'
C:...\src\hotspot\share\utilities/globalDefinitions.hpp(1136): note: or       'julong uabs(julong)'
C:...\src\hotspot\share\utilities/globalDefinitions.hpp(1127): note: or       'unsigned int uabs(unsigned int)'
C:...\src\hotspot\share\opto\mulnode.cpp(248): note: while trying to match the argument list '(const jint)'

FWIW, clang-cl also fails on this.

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

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


From jwaters at openjdk.org  Wed Nov  9 13:32:32 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 9 Nov 2022 13:32:32 GMT
Subject: RFR: 8296115: Allow for compiling the JDK with strict standards
 conformance [v4]
In-Reply-To: <IcumtyDaWt_1UWxpAFTg6yKqIYox9_BQzNICyeK6dIQ=.691b492f-a1b9-4d2a-adfa-06157a747356@github.com>
References: <yaKDZVxxdPLeOt-Z2Mw9Mjknb9q1tg3Pp2PRYfHihiQ=.d7c3320f-a9ae-4779-9bd5-00a9366a8bce@github.com>
 <RSam1XvDYiyOwOj7I-UtO4SkN026rS-_znurjm5lrWA=.735e341e-7892-4c22-96e1-46c8f589f25b@github.com>
 <Wr1ms01L-YRhMg1hNepQHE4CGfjgkr2XssygEhdXDfY=.9550157a-e32f-497a-9bfe-8550356ce95d@github.com>
 <IcumtyDaWt_1UWxpAFTg6yKqIYox9_BQzNICyeK6dIQ=.691b492f-a1b9-4d2a-adfa-06157a747356@github.com>
Message-ID: <Omy5TirC_kPKxQXWjZJEigQDMwpG-GLSG0B0LtKc1QQ=.74c67092-6d05-4e22-8d36-03a80fa84c25@github.com>

On Wed, 9 Nov 2022 12:15:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> FWIW, `-permissive-` is getting less permissive with every compiler iteration; with MSVC2022 (` C Compiler:     Version 19.33.31629`) even hotspot doesn't build.
>
> @djelinski That's a bit alarming. :-/ Do you have any idea if it complains "correctly" on Hotspot by detecting fishy code that should be fixed, or if it is overly cranky and is complaining about reasonable but non-standard extensions?

> @magicus that depends on how you define "cranky"; in default mode, `long` and `int` are fully interchangeable. In `permissive-`, they are [distinct types](https://learn.microsoft.com/en-us/cpp/overview/cpp-conformance-improvements-2019?view=msvc-170#overload-resolution-involving-integral-overloads-and-long-arguments). As a result, compilation of code that assumes that `jint` is equal to `int` breaks (on Windows, `jint` is typedef'd to `long`).
> 
> Example failure:
> 
> ```
> C:...\src\hotspot\share\opto\mulnode.cpp(248): error C2668: 'uabs': ambiguous call to overloaded function
> C:...\src\hotspot\share\utilities/globalDefinitions.hpp(1146): note: could be 'unsigned int uabs(int)'
> C:...\src\hotspot\share\utilities/globalDefinitions.hpp(1145): note: or       'julong uabs(jlong)'
> C:...\src\hotspot\share\utilities/globalDefinitions.hpp(1136): note: or       'julong uabs(julong)'
> C:...\src\hotspot\share\utilities/globalDefinitions.hpp(1127): note: or       'unsigned int uabs(unsigned int)'
> C:...\src\hotspot\share\opto\mulnode.cpp(248): note: while trying to match the argument list '(const jint)'
> ```
> 
> FWIW, clang-cl also fails on this.

I recall having had to deal with this while trying to wrestle the Windows JDK into being accepted by gcc, the solution was to simply define jint to int instead as it is with the Unix JDK (there were also sizeof checks to typedef jlong to either long or long long, but that's another story). From what I recall back when this was an issue for me this actually worked very well, the only time it choked up was when a jint was compared with a long, which is surprisingly only in rather few sections of native code. The inverse however, trying to make the JDK go with jint being typedef'd as long, is significantly harder

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

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


From jwaters at openjdk.org  Thu Nov 10 03:33:42 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 10 Nov 2022 03:33:42 GMT
Subject: RFR: 8296758: [BACKOUT] Revert 8296115
Message-ID: <YViKh_ufMbgGyvPCLNg4Yc2OWnH0vRGzLBANbYWSbvU=.ebdb2575-ff9a-4b9b-9225-38fc5cd8720c@github.com>

8296115 unfortunately did not prove to be as useful as expected, revert it and reopen 8241499 for a future change.

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

Commit messages:
 - flags-cflags.m4

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

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


From jwaters at openjdk.org  Thu Nov 10 03:38:44 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 10 Nov 2022 03:38:44 GMT
Subject: RFR: 8296758: [BACKOUT] Revert 8296115 [v2]
In-Reply-To: <YViKh_ufMbgGyvPCLNg4Yc2OWnH0vRGzLBANbYWSbvU=.ebdb2575-ff9a-4b9b-9225-38fc5cd8720c@github.com>
References: <YViKh_ufMbgGyvPCLNg4Yc2OWnH0vRGzLBANbYWSbvU=.ebdb2575-ff9a-4b9b-9225-38fc5cd8720c@github.com>
Message-ID: <puE85vhk6M95iRQ44Rm9MXq6IY5Sra3etNHKiZUlus4=.d3a6925e-b79a-4ad2-bc77-778773732f20@github.com>

> 8296115 unfortunately did not prove to be as useful as expected, revert it and reopen 8241499 for a future change.

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

  jdk-options.m4

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11077/files
  - new: https://git.openjdk.org/jdk/pull/11077/files/4519a8bb..46ebb6f4

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

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

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


From serb at openjdk.org  Thu Nov 10 06:11:06 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 10 Nov 2022 06:11:06 GMT
Subject: Integrated: 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: <xQox9x_wwfjIshct9MIo1wRtMlfzJrYt1CixvJCSCpg=.ca4461d0-0e18-40fb-9401-1f0cf4e63069@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.

This pull request has now been integrated.

Changeset: f0a6e71e
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f0a6e71e4d63c9820659f6ff29f94d0476d48b09
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8295812: Skip the "half float" support in LittleCMS during the build

Reviewed-by: erikj, prr, ihse

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

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


From ihse at openjdk.org  Thu Nov 10 09:17:30 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Nov 2022 09:17:30 GMT
Subject: RFR: 8296758: [BACKOUT] Revert 8296115 [v2]
In-Reply-To: <puE85vhk6M95iRQ44Rm9MXq6IY5Sra3etNHKiZUlus4=.d3a6925e-b79a-4ad2-bc77-778773732f20@github.com>
References: <YViKh_ufMbgGyvPCLNg4Yc2OWnH0vRGzLBANbYWSbvU=.ebdb2575-ff9a-4b9b-9225-38fc5cd8720c@github.com>
 <puE85vhk6M95iRQ44Rm9MXq6IY5Sra3etNHKiZUlus4=.d3a6925e-b79a-4ad2-bc77-778773732f20@github.com>
Message-ID: <eG0p1HD5y6l42aqSnAvb9HrtyJuYufIIh6bN3bVQftk=.821187a7-c0e9-4b6d-9379-ed35afacfa67@github.com>

On Thu, 10 Nov 2022 03:38:44 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> 8296115 unfortunately did not prove to be as useful as expected, revert it and reopen 8241499 for a future change (which I'll likely address soon).
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   jdk-options.m4

Can you remove the `Support for checking standards conforming code` addition to the build documentation as well?

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

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


From jwaters at openjdk.org  Thu Nov 10 13:05:32 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 10 Nov 2022 13:05:32 GMT
Subject: RFR: 8296758: [BACKOUT] Revert 8296115 [v2]
In-Reply-To: <eG0p1HD5y6l42aqSnAvb9HrtyJuYufIIh6bN3bVQftk=.821187a7-c0e9-4b6d-9379-ed35afacfa67@github.com>
References: <YViKh_ufMbgGyvPCLNg4Yc2OWnH0vRGzLBANbYWSbvU=.ebdb2575-ff9a-4b9b-9225-38fc5cd8720c@github.com>
 <puE85vhk6M95iRQ44Rm9MXq6IY5Sra3etNHKiZUlus4=.d3a6925e-b79a-4ad2-bc77-778773732f20@github.com>
 <eG0p1HD5y6l42aqSnAvb9HrtyJuYufIIh6bN3bVQftk=.821187a7-c0e9-4b6d-9379-ed35afacfa67@github.com>
Message-ID: <AQu2gK2l_V_iGBIXY6H0OpCORos5RMQwaoeUMKgk9lw=.807c39d5-620d-4964-b458-1770c7845e6c@github.com>

On Thu, 10 Nov 2022 09:13:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Can you remove the `Support for checking standards conforming code` addition to the build documentation as well?

Oops - forgot about that, will do in a moment

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

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


From jwaters at openjdk.org  Thu Nov 10 13:10:45 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 10 Nov 2022 13:10:45 GMT
Subject: RFR: 8296758: [BACKOUT] Revert 8296115 [v3]
In-Reply-To: <YViKh_ufMbgGyvPCLNg4Yc2OWnH0vRGzLBANbYWSbvU=.ebdb2575-ff9a-4b9b-9225-38fc5cd8720c@github.com>
References: <YViKh_ufMbgGyvPCLNg4Yc2OWnH0vRGzLBANbYWSbvU=.ebdb2575-ff9a-4b9b-9225-38fc5cd8720c@github.com>
Message-ID: <xNq0O1reQHFA6sCRwJ2IZTFL1zrlvc7KBY8Xv0Llw-k=.ba6c9e54-5f53-4827-bc62-89c25ada6bbe@github.com>

> 8296115 unfortunately did not prove to be as useful as expected, revert it and reopen 8241499 for a future change (which I'll likely address soon).

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

  building.md

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11077/files
  - new: https://git.openjdk.org/jdk/pull/11077/files/46ebb6f4..d0d123a0

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

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

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


From jwaters at openjdk.org  Thu Nov 10 13:16:38 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 10 Nov 2022 13:16:38 GMT
Subject: RFR: 8296758: [BACKOUT] Revert 8296115 [v4]
In-Reply-To: <YViKh_ufMbgGyvPCLNg4Yc2OWnH0vRGzLBANbYWSbvU=.ebdb2575-ff9a-4b9b-9225-38fc5cd8720c@github.com>
References: <YViKh_ufMbgGyvPCLNg4Yc2OWnH0vRGzLBANbYWSbvU=.ebdb2575-ff9a-4b9b-9225-38fc5cd8720c@github.com>
Message-ID: <V3Dd86X0G6AgRqmurQEP4-wywpsVTaaBElVbFNVt5Fo=.2b904fd6-5324-40bf-be15-773e742671a9@github.com>

> 8296115 unfortunately did not prove to be as useful as expected, revert it and reopen 8241499 for a future change (which I'll likely address soon).

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

  building.html

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11077/files
  - new: https://git.openjdk.org/jdk/pull/11077/files/d0d123a0..675b6d7d

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

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

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


From ihse at openjdk.org  Thu Nov 10 14:03:31 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Nov 2022 14:03:31 GMT
Subject: RFR: 8296758: [BACKOUT] Revert 8296115 [v4]
In-Reply-To: <V3Dd86X0G6AgRqmurQEP4-wywpsVTaaBElVbFNVt5Fo=.2b904fd6-5324-40bf-be15-773e742671a9@github.com>
References: <YViKh_ufMbgGyvPCLNg4Yc2OWnH0vRGzLBANbYWSbvU=.ebdb2575-ff9a-4b9b-9225-38fc5cd8720c@github.com>
 <V3Dd86X0G6AgRqmurQEP4-wywpsVTaaBElVbFNVt5Fo=.2b904fd6-5324-40bf-be15-773e742671a9@github.com>
Message-ID: <BdBTXMsSGHhVtCA-CfRFcCJBkvAS4aWKy5h5lCCmjY0=.4f06c895-1f13-4ebe-8d6c-e811b32f02d2@github.com>

On Thu, 10 Nov 2022 13:16:38 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> 8296115 unfortunately did not prove to be as useful as expected, revert it and reopen 8241499 for a future change (which I'll likely address soon).
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   building.html

Marked as reviewed by ihse (Reviewer).

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

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


From ihse at openjdk.org  Fri Nov 11 11:13:29 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 11 Nov 2022 11:13:29 GMT
Subject: RFR: 8296872: gtest is built with the build-jdk
Message-ID: <vr3irJp7tM0AlK5fmmgJHBAPwiQoSqZyzLpayR3Z5EQ=.1d035335-1134-4187-8ff5-a80faad63dc1@github.com>

The build-jdk is a JDK built on the current sources that can execute on the build platform. This is needed when cross-compiling, in addition to the boot-jdk (which runs on the build platform, but is an older version of the JDK), and is different from the JDK resulting from the build (which can only execute on the target platform).

If we do not supply a pre-built build-jdk, the build system creates a new, on the fly, before starting the compilation proper. 

This build-jdk includes gtest for hotspot, if available. This is just a waste of resources (and actually triggered a bug; which is how it was discovered).

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

Commit messages:
 - 8296872: gtest is built with the build-jdk

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

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


From dholmes at openjdk.org  Fri Nov 11 11:49:33 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 11 Nov 2022 11:49:33 GMT
Subject: RFR: 8296872: gtest is built with the build-jdk
In-Reply-To: <vr3irJp7tM0AlK5fmmgJHBAPwiQoSqZyzLpayR3Z5EQ=.1d035335-1134-4187-8ff5-a80faad63dc1@github.com>
References: <vr3irJp7tM0AlK5fmmgJHBAPwiQoSqZyzLpayR3Z5EQ=.1d035335-1134-4187-8ff5-a80faad63dc1@github.com>
Message-ID: <meZD5DQ5WqlQ70T60tYa6FJf25eSqhU6IxtXWSd5sU8=.ad92a055-700a-458a-a5f8-7e41eadae6b6@github.com>

On Fri, 11 Nov 2022 11:07:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The build-jdk is a JDK built on the current sources that can execute on the build platform. This is needed when cross-compiling, in addition to the boot-jdk (which runs on the build platform, but is an older version of the JDK), and is different from the JDK resulting from the build (which can only execute on the target platform).
> 
> If we do not supply a pre-built build-jdk, the build system creates a new, on the fly, before starting the compilation proper. 
> 
> This build-jdk includes gtest for hotspot, if available. This is just a waste of resources (and actually triggered a bug; which is how it was discovered).

Looks good to me. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

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


From stefank at openjdk.org  Fri Nov 11 14:33:52 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 11 Nov 2022 14:33:52 GMT
Subject: RFR: 8296886: Fix various include sort order issues
Message-ID: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>

The sorted blocks of includes have deteriorated to the point that I felt compelled to clean up some of the issues.

One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory, so I don't think that's a good enough argument, again IMHO. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share, j
 ust like the other platform-independent headers in HotSpot.

While going over the include headers I've also cleaned up surrounding whitespaces and incorrect include guards.

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

Commit messages:
 - Various include order fixes

Changes: https://git.openjdk.org/jdk/pull/11108/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11108&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296886
  Stats: 839 lines in 323 files changed: 433 ins; 299 del; 107 mod
  Patch: https://git.openjdk.org/jdk/pull/11108.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11108/head:pull/11108

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


From eosterlund at openjdk.org  Fri Nov 11 14:49:42 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 11 Nov 2022 14:49:42 GMT
Subject: RFR: 8296886: Fix various include sort order issues
In-Reply-To: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
References: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
Message-ID: <ofs1xv7I47Zf48RVFGfNZWiCh5p6qk4xCpPXFjFxlL0=.98bda3b8-6600-4f70-a332-28424e55f082@github.com>

On Fri, 11 Nov 2022 14:26:20 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The sorted blocks of includes have deteriorated to the point that I felt compelled to clean up some of the issues.
> 
> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory, so I don't think that's a good enough argument, again IMHO. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share,
  just like the other platform-independent headers in HotSpot.
> 
> While going over the include headers I've also cleaned up surrounding whitespaces and incorrect include guards.

Hmm. Now that "jvm.hpp" becomes "include/jvm.hpp" it seems like it would make sense if the include guard for jvm.hpp reflected the relative file path, like most other files. I noticed that its current include guard is `#ifndef _JAVASOFT_JVM_H_`. When I search for "javasoft" I get no hits. I guess it isn't obvious if we can change it without introducing build issues for users out there? So maybe it should remain the way it is anyway.

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

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


From jwaters at openjdk.org  Fri Nov 11 14:59:12 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 11 Nov 2022 14:59:12 GMT
Subject: RFR: 8296478: Rework 8282948 and 8282700 to use the new autoconf
 UTIL_ARG_WITH
Message-ID: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>

8285093 introduced the new UTIL_ARG_WITH definition, which was not available when both 8282948 and 8282700 were written. They can now be moved to using the cleaner logic that UTIL_ARG_WITH grants.

There are many more options that still use AC_ARG_WITH in jdk-version.m4. They are out of the scope of this commit, which aims only to rework the previous integrated commits mentioned above.

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

Commit messages:
 - Squash

Changes: https://git.openjdk.org/jdk/pull/11020/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11020&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296478
  Stats: 199 lines in 1 file changed: 48 ins; 43 del; 108 mod
  Patch: https://git.openjdk.org/jdk/pull/11020.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11020/head:pull/11020

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


From jwaters at openjdk.org  Fri Nov 11 14:59:12 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 11 Nov 2022 14:59:12 GMT
Subject: RFR: 8296478: Rework 8282948 and 8282700 to use the new autoconf
 UTIL_ARG_WITH
In-Reply-To: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
References: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
Message-ID: <eYuT5uT-g4oRVyDYTyI-nX9peUMs_NibOWH_qMWcCZM=.ce9d1206-4efa-4085-a95c-12a06e8681b1@github.com>

On Mon, 7 Nov 2022 14:39:02 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> 8285093 introduced the new UTIL_ARG_WITH definition, which was not available when both 8282948 and 8282700 were written. They can now be moved to using the cleaner logic that UTIL_ARG_WITH grants.
> 
> There are many more options that still use AC_ARG_WITH in jdk-version.m4. They are out of the scope of this commit, which aims only to rework the previous integrated commits mentioned above.

All the options from 8282948 and 8282700 have now been refitted to use UTIL_ARG_WITH, but with one exception: --with-vendor-name and the corresponding COMPANY_NAME. For one reason or another this particular flag simply refuses to work properly with UTIL_ARG_WITH, and after numerous attempts I'm completely lost as to how to make it function without crashing autoconf halfway through before the configure script is even generated

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

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


From mikael at openjdk.org  Fri Nov 11 17:45:30 2022
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Fri, 11 Nov 2022 17:45:30 GMT
Subject: RFR: 8296872: gtest is built with the build-jdk
In-Reply-To: <vr3irJp7tM0AlK5fmmgJHBAPwiQoSqZyzLpayR3Z5EQ=.1d035335-1134-4187-8ff5-a80faad63dc1@github.com>
References: <vr3irJp7tM0AlK5fmmgJHBAPwiQoSqZyzLpayR3Z5EQ=.1d035335-1134-4187-8ff5-a80faad63dc1@github.com>
Message-ID: <FB1NgA41ZScQcHITXQrcTOuToC2b2vYLl-ZMzPzh-VE=.c9a7f90e-2e82-401b-b210-a4230280fa75@github.com>

On Fri, 11 Nov 2022 11:07:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The build-jdk is a JDK built on the current sources that can execute on the build platform. This is needed when cross-compiling, in addition to the boot-jdk (which runs on the build platform, but is an older version of the JDK), and is different from the JDK resulting from the build (which can only execute on the target platform).
> 
> If we do not supply a pre-built build-jdk, the build system creates a new, on the fly, before starting the compilation proper. 
> 
> This build-jdk includes gtest for hotspot, if available. This is just a waste of resources (and actually triggered a bug; which is how it was discovered).

Marked as reviewed by mikael (Reviewer).

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

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


From ihse at openjdk.org  Fri Nov 11 21:49:47 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 11 Nov 2022 21:49:47 GMT
Subject: Integrated: 8296872: gtest is built with the build-jdk
In-Reply-To: <vr3irJp7tM0AlK5fmmgJHBAPwiQoSqZyzLpayR3Z5EQ=.1d035335-1134-4187-8ff5-a80faad63dc1@github.com>
References: <vr3irJp7tM0AlK5fmmgJHBAPwiQoSqZyzLpayR3Z5EQ=.1d035335-1134-4187-8ff5-a80faad63dc1@github.com>
Message-ID: <hwI8JFdRy3JhaoyVb3CI419dneAXyr4gVA3E5gCBuAI=.e55e2ae2-4e64-444b-8a3f-921678b6cb9c@github.com>

On Fri, 11 Nov 2022 11:07:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The build-jdk is a JDK built on the current sources that can execute on the build platform. This is needed when cross-compiling, in addition to the boot-jdk (which runs on the build platform, but is an older version of the JDK), and is different from the JDK resulting from the build (which can only execute on the target platform).
> 
> If we do not supply a pre-built build-jdk, the build system creates a new, on the fly, before starting the compilation proper. 
> 
> This build-jdk includes gtest for hotspot, if available. This is just a waste of resources (and actually triggered a bug; which is how it was discovered).

This pull request has now been integrated.

Changeset: 7f587e5a
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7f587e5a5cc1b71ced1cd27f748201c6662040bd
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8296872: gtest is built with the build-jdk

Co-authored-by: Mikael Vidstedt <mikael at openjdk.org>
Reviewed-by: dholmes, mikael

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

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


From jwaters at openjdk.org  Fri Nov 11 21:52:07 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 11 Nov 2022 21:52:07 GMT
Subject: Integrated: 8296758: [BACKOUT] Revert 8296115
In-Reply-To: <YViKh_ufMbgGyvPCLNg4Yc2OWnH0vRGzLBANbYWSbvU=.ebdb2575-ff9a-4b9b-9225-38fc5cd8720c@github.com>
References: <YViKh_ufMbgGyvPCLNg4Yc2OWnH0vRGzLBANbYWSbvU=.ebdb2575-ff9a-4b9b-9225-38fc5cd8720c@github.com>
Message-ID: <FZrn6sPAgDCpnnuJwVpbEAsx3ZSOKO2evDVz1lz4qxE=.48631dcf-c5c1-4a5f-b90c-7355c0510251@github.com>

On Thu, 10 Nov 2022 03:25:33 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> 8296115 unfortunately did not prove to be as useful as expected, revert it and reopen 8241499 for a future change (which I'll likely address soon).

This pull request has now been integrated.

Changeset: f0b648bc
Author:    Julian Waters <jwaters at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f0b648bc5cea0014e85e16b14c285618c4b94661
Stats:     36 lines in 4 files changed: 0 ins; 36 del; 0 mod

8296758: [BACKOUT] Revert 8296115

Reviewed-by: ihse

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

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


From kbarrett at openjdk.org  Sat Nov 12 00:48:34 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 12 Nov 2022 00:48:34 GMT
Subject: RFR: 8296886: Fix various include sort order issues
In-Reply-To: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
References: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
Message-ID: <2lOleILw53UHm1WCmH4QPBsjbisb1h6H7Gz9jJRtJ8A=.139da306-4220-438c-be4c-64be6dc14c5d@github.com>

On Fri, 11 Nov 2022 14:26:20 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The sorted blocks of includes have deteriorated to the point that I felt compelled to clean up some of the issues.
> 
> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory, so I don't think that's a good enough argument, again IMHO. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share,
  just like the other platform-independent headers in HotSpot.
> 
> While going over the include headers I've also cleaned up surrounding whitespaces and incorrect include guards.

I don't think platform-specific files that are included without providing a
directory should be sorted with the shared files on just the filename.  That
just scatters the platform-specific files, in a way that I think isn't
helpful.  Such files ought to be at the end, using the appropriate macros.
But there are some filenames that don't have the appropriate stem for use with
those macros.  I think those files should be renamed.  So I disagree with
moving the includes of these files.  I'd prefer they were left as-is by this
change, with a followup to rename files and use the appropriate macros.

There are some files external to hotspot that are being included without any
directory component, such as jni.h and jimage.hpp. Moving them into the middle
of the "shared" includes, sorted by just filename name without a directory,
seems like it is hiding external dependencies. I don't have a well-formed
suggestion for what to do about them, but I think the proposed moves aren't
helpful.

I wonder if standard library includes should also be sorted.  I think you
might have done that in some places, but not sure about that.  Certainly there
are some that aren't.

There are a number of gtest where a standard library include was moved to
after the include of unittest.hpp. I think unittest.hpp is supposed to always
be the last included header, and added a comment to those places. But now I
can't find anything that says that. (BTW, I agree with moving things like
threadHelper.inline.hpp into a block after normal includes, with
unittest.hpp.)

Related, there are 62 .cpp files missing "precompiled.hpp"
`find . -name "*.cpp" -exec grep -L "precompiled.hpp" {} ;`
At least some (os_linux.cpp, os_posix.cpp) have a comment claiming
intentionality, though that seems suspect (os_linux.cpp has been that way
since before mercurial). I think this should be another followup.

I wish this change had been split up a bit. One change (or a separate commit
within this change) that dealt with files in share/include could have been
mechanically checked or pretty easily verfied by eye. That would have left a
much smaller residue that needed going through more carefully.

Touching a whole mess of gtests to put a blank line between other includes and
the final include of unittest.hpp could also have been separate (PR or commit).

Should there be any additions to the style guide to codify some of these
changes?  I can't find anything about where unittest.hpp and other
gtest-specific headers should go.  Nor can I find anything about where
standard library headers should go.

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 30:

> 28: #include "compiler/compiler_globals.hpp"
> 29: #include "compiler/disassembler.hpp"
> 30: #include "crc32c.h"

This ought to remain at the end, included using `CPU_HEADER_H("crc32c")`, but the file doesn't have the appropriate suffix.  I think the file name should be changed so that can be done.  This seems to be the only C++ file under cpu/ that doesn't have the appropriate suffix.  There are similarly "misnamed" files under various os/ subdirs; I didn't look for any in os_cpu/.

src/hotspot/os/windows/jvm_windows.cpp line 27:

> 25: #include "precompiled.hpp"
> 26: #include "include/jvm.h"
> 27: #include "os_windows.hpp"

os_windows should be at the end, included using `OS_HEADER("os")`.

src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp line 57:

> 55: #if !defined(__APPLE__) && !defined(__NetBSD__)
> 56: #include <pthread.h>
> 57: # include <pthread_np.h> /* For pthread_attr_get_np */

Remove unneeded space.

src/hotspot/share/cds/classListParser.cpp line 42:

> 40: #include "interpreter/bytecodeStream.hpp"
> 41: #include "interpreter/linkResolver.hpp"
> 42: #include "jimage.hpp"

Sorting jimage.hpp with hotspot/share stuff seems weird, and is kind of hiding this external dependency.  (It's coming from java.base.)

src/hotspot/share/prims/scopedMemoryAccess.cpp line 34:

> 32: #include "runtime/interfaceSupport.inline.hpp"
> 33: #include "runtime/jniHandles.inline.hpp"
> 34: #include "runtime/deoptimization.hpp"

runtime/deoptimization.hpp should be at the front of the runtime/ list.

src/hotspot/share/prims/whitebox.cpp line 26:

> 24: 
> 25: #include "precompiled.hpp"
> 26: #include <new>

Why was `<new>` removed?

test/hotspot/gtest/jfr/test_adaptiveSampler.cpp line 48:

> 46: #include "unittest.hpp"
> 47: 
> 48: #include <cmath>

Why is this after unittest.hpp?

test/hotspot/gtest/metaprogramming/test_enableIf.cpp line 32:

> 30: #include "unittest.hpp"
> 31: 
> 32: #include <type_traits>

Why is this following unittest.hpp.

test/hotspot/gtest/runtime/test_os_linux.cpp line 28:

> 26: #ifdef LINUX
> 27: 
> 28: #include "os_linux.hpp"

Why do we even need this - we have runtime/os.hpp and we're on Linux.

test/hotspot/gtest/utilities/test_align.cpp line 31:

> 29: #include "unittest.hpp"
> 30: 
> 31: #include <limits>

Why after unittest.hpp?

test/hotspot/gtest/utilities/test_bitMap_setops.cpp line 34:

> 32: #include "unittest.hpp"
> 33: 
> 34: #include <stdlib.h>

Why after unittest.hpp.

test/hotspot/gtest/utilities/test_count_leading_zeros.cpp line 32:

> 30: #include "unittest.hpp"
> 31: 
> 32: #include <limits>

[pre-existing] Why after unittest.hpp?

test/hotspot/gtest/utilities/test_enumIterator.cpp line 29:

> 27: #include "unittest.hpp"
> 28: 
> 29: #include <type_traits>

Why after unittest.hpp?

test/hotspot/gtest/utilities/test_globalDefinitions.cpp line 33:

> 31: #include "unittest.hpp"
> 32: 
> 33: #include <type_traits>

Why after unittest.hpp.

test/hotspot/gtest/utilities/test_nonblockingQueue.cpp line 32:

> 30: #include "threadHelper.inline.hpp"
> 31: #include "unittest.hpp"
> 32: #include <new>

Why removing `<new>`?  (and pre-existing, why after unittest.hpp?)

test/hotspot/gtest/utilities/test_population_count.cpp line 33:

> 31: #include "unittest.hpp"
> 32: 
> 33: #include <limits>

Why after unittest.hpp?

test/hotspot/gtest/utilities/test_powerOfTwo.cpp line 31:

> 29: #include "unittest.hpp"
> 30: 
> 31: #include <limits>

Why after unittest.hpp?

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

Changes requested by kbarrett (Reviewer).

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


From clanger at openjdk.org  Sat Nov 12 15:23:41 2022
From: clanger at openjdk.org (Christoph Langer)
Date: Sat, 12 Nov 2022 15:23:41 GMT
Subject: RFR: 8296904: Improve handling of macos xcode toolchain [v2]
In-Reply-To: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
References: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
Message-ID: <tIAra5jBQrKyPBbOBCRon-1FPIYM8csax1FKpi48OSk=.ce063463-01b6-4a8e-96a7-ee4d2fc3682e@github.com>

> With this PR I'd like to make it easier to use dedicated installations of Xcode on Mac OS for OpenJDK builds without having to switch the active Xcode globally via `xcode-select`.
> 
> I propose adding a new configure flag `--with-xcode-path` that takes the path to an Xcode installation. If the option is set, this path is expanded to a valid `TOOLCHAIN_PATH`.
> 
> Furthermore, I fix detection of xcodebuild and correctly setting the sysroot from the toolchain by moving `AC_SUBST(TOOLCHAIN_PATH)` before calling `BASIC_SETUP_XCODE_SYSROOT` and honoring `TOOLCHAIN_PATH` in BASIC_SETUP_XCODE_SYSROOT in the case when no devkit is specified. As I see it, this is a viable fix, even if not introducing `--with-xcode-path`.

Christoph Langer has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Improve options for xcode toolchain

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11113/files
  - new: https://git.openjdk.org/jdk/pull/11113/files/d9dcf5b2..dd808218

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

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

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


From jwaters at openjdk.org  Sat Nov 12 16:18:04 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 12 Nov 2022 16:18:04 GMT
Subject: RFR: 8295884: Implement IDE support for Eclipse [v16]
In-Reply-To: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
Message-ID: <1iiGymPVIbiGtytzR_H-CysyK1QOk0e1m-AyOMb010s=.2a41cfbc-6f3c-4da4-849f-e5a02b9af6a6@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 Java Virtual Machine's source code, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's unique 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 21 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into eclipse
 - More Changes
 - Rename RAnDOM to WORKSPACE_ID
 - Merge remote-tracking branch 'upstream/master' into eclipse
 - Merge remote-tracking branch 'upstream/master' into eclipse
 - Merge remote-tracking branch 'upstream/master' into eclipse
 - 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
 - ... and 11 more: https://git.openjdk.org/jdk/compare/c88faff1...6734b840

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10853/files
  - new: https://git.openjdk.org/jdk/pull/10853/files/14934d9e..6734b840

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=14-15

  Stats: 18065 lines in 703 files changed: 8929 ins; 6463 del; 2673 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  Sat Nov 12 16:18:54 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 12 Nov 2022 16:18:54 GMT
Subject: RFR: 8296478: Rework 8282948 and 8282700 to use the new autoconf
 UTIL_ARG_WITH [v2]
In-Reply-To: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
References: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
Message-ID: <WXiInV6g7gltKihp6pg6kd3kVtX9EIB-yX7YQI34LYk=.162eb88a-c4cb-464c-8a26-dd1db571ed99@github.com>

> 8285093 introduced the new UTIL_ARG_WITH definition, which was not available when both 8282948 and 8282700 were written. They can now be moved to using the cleaner logic that UTIL_ARG_WITH grants.
> 
> There are many more options that still use AC_ARG_WITH in jdk-version.m4. They are out of the scope of this commit, which aims only to rework the previous integrated commits mentioned above.

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

 - Merge remote-tracking branch 'upstream/master' into util
 - Squash

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11020/files
  - new: https://git.openjdk.org/jdk/pull/11020/files/4dd895ab..42e625f5

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

  Stats: 462 lines in 34 files changed: 299 ins; 94 del; 69 mod
  Patch: https://git.openjdk.org/jdk/pull/11020.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11020/head:pull/11020

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


From jwaters at openjdk.org  Sat Nov 12 16:45:19 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 12 Nov 2022 16:45:19 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language features
Message-ID: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>

After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cases were caught by the very briefly integrated 8296115

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

Commit messages:
 - More Style Changes
 - Minor Style Changes
 - Merge remote-tracking branch 'upstream/master' into conformance
 - Missed an attribute
 - Oops v2
 - Resolve Conflict
 - This will likely fail, but that's not important
 - Further formatting
 - Merge jdkMerge remote-tracking branch 'upstream/master' into warnings
 - Code style
 - ... and 53 more: https://git.openjdk.org/jdk/compare/657a0b2f...6d85c432

Changes: https://git.openjdk.org/jdk/pull/11081/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11081&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295146
  Stats: 254 lines in 48 files changed: 100 ins; 23 del; 131 mod
  Patch: https://git.openjdk.org/jdk/pull/11081.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11081/head:pull/11081

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


From jwaters at openjdk.org  Sun Nov 13 14:49:39 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 13 Nov 2022 14:49:39 GMT
Subject: RFR: 8295884: Implement IDE support for Eclipse [v17]
In-Reply-To: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
Message-ID: <CUp8yiWiOah_6kdyh5nltIPNB1mDkBmA27ewcxbERxs=.22dd3d8d-885b-4eb3-b55f-a5cc0d8992f1@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 Java Virtual Machine's source code, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's unique 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 miscellaneous directories in any Workspace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10853/files
  - new: https://git.openjdk.org/jdk/pull/10853/files/6734b840..564ceced

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=15-16

  Stats: 7 lines in 1 file changed: 7 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  Sun Nov 13 14:52:49 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 13 Nov 2022 14:52:49 GMT
Subject: RFR: 8295884: Implement IDE support for Eclipse [v18]
In-Reply-To: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
Message-ID: <SrBwfZmNkUMBwUVMRRYGR-jQKn8WUIKU4h7b3uSLEs4=.a77b8555-62c2-4c9a-85ad-13521957d895@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 Java Virtual Machine's source code, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's unique 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:

  Oversight

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10853/files
  - new: https://git.openjdk.org/jdk/pull/10853/files/564ceced..4c030fe6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=16-17

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 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 dholmes at openjdk.org  Sun Nov 13 23:29:06 2022
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 13 Nov 2022 23:29:06 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features
In-Reply-To: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
Message-ID: <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>

On Thu, 10 Nov 2022 06:20:41 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115
> 
> No changes to the behaviour of the JDK has resulted in any way from this commit

This looks good in general. It is a pity there is so much simple moving of where "attributes" are listed, as it makes it look like the changes are more extensive than they really are - that said I prefer to see the attributes appear before a function/method signature rather than after, or somewhere in-between.

A few other comments below.

Thanks.

make/autoconf/flags-cflags.m4 line 632:

> 630:   if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then
> 631:     STATIC_LIBS_CFLAGS="$STATIC_LIBS_CFLAGS -ffunction-sections -fdata-sections \
> 632:       -DJNIEXPORT='[[gnu::visibility(\"hidden\")]]'"

So IIUC we now use attributes via the C++11 syntax rather than compiler-specific syntax - even where the C++11 syntax is referring to a compiler specific attribute. Is that right?

src/hotspot/os/linux/os_perf_linux.cpp line 233:

> 231:  *  Ensure that 'fmt' does _NOT_ contain the first two "%d %s"
> 232:  */
> 233: SCANF_ARGS(2, 0) static int vread_statdata(const char* procfile, _SCANFMT_ const char* fmt, va_list args) {

If `SCANF_ARGS` can/must come first then I suggest adding a newline after it so the method signature is easier to spot. Applied everywhere of course.

src/hotspot/os/windows/os_windows.hpp line 35:

> 33: class Thread;
> 34: 
> 35: static unsigned __stdcall thread_native_entry(Thread*);

Why was this removed? This is needed to correctly specify the call sequence for the thread entry routine when used with `_beginThreadex`:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-170

src/hotspot/share/cds/filemap.hpp line 482:

> 480: 
> 481:   // Errors.
> 482:   ATTRIBUTE_PRINTF(1, 2) static void fail_stop(const char *msg, ...);

Again I suggest a newline after `ATTRIBUTE_PRINTF`

src/hotspot/share/utilities/compilerWarnings.hpp line 47:

> 45: #endif
> 46: 
> 47: #ifndef PRAGMA_DISABLE_VISCPP_WARNING

Why rename this from `MSVC` to `VISCPP`? IIRC the full name is Microsft Visual Studio C++, so you new name is not obviously better and the change just adds noise to the PR. Further `MSVC` matches what MS themselves use and even the attribute namespace in C++11 is `MSVC`.
Update: I see the inconsistency with `compilerWarnings_visCPP.hpp`

src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 37:

> 35: #endif
> 36: 
> 37: #if defined(__clang_major__) && \

Not clear why this was moved ??

src/hotspot/share/utilities/debug.hpp line 172:

> 170: void report_fatal(VMErrorType error_type, const char* file, int line, const char* detail_fmt, ...) ATTRIBUTE_PRINTF(4, 5);
> 171: void report_vm_out_of_memory(const char* file, int line, size_t size, VMErrorType vm_err_type,
> 172:                              const char* detail_fmt, ...) ATTRIBUTE_PRINTF(5, 6);

Why were the ATTRIBUTE_PRINTFs removed?

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

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


From jwaters at openjdk.org  Mon Nov 14 01:22:47 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 14 Nov 2022 01:22:47 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features
In-Reply-To: <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
Message-ID: <0fVP40VVRuOoZCEJ1M3BLubshBHbD4m_lj-j1qaGTTk=.391ade50-b3fe-4d4e-ae71-ba8a975a31cd@github.com>

On Sun, 13 Nov 2022 22:59:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115
>> 
>> No changes to the behaviour of the JDK has resulted in any way from this commit
>
> src/hotspot/os/windows/os_windows.hpp line 35:
> 
>> 33: class Thread;
>> 34: 
>> 35: static unsigned __stdcall thread_native_entry(Thread*);
> 
> Why was this removed? This is needed to correctly specify the call sequence for the thread entry routine when used with `_beginThreadex`:
> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-170

I'm not sure I follow, I didn't remove anything here?

> src/hotspot/share/utilities/compilerWarnings.hpp line 47:
> 
>> 45: #endif
>> 46: 
>> 47: #ifndef PRAGMA_DISABLE_VISCPP_WARNING
> 
> Why rename this from `MSVC` to `VISCPP`? IIRC the full name is Microsft Visual Studio C++, so you new name is not obviously better and the change just adds noise to the PR. Further `MSVC` matches what MS themselves use and even the attribute namespace in C++11 is `MSVC`.
> Update: I see the inconsistency with `compilerWarnings_visCPP.hpp`

Yep, it was renamed since the file is also named VISCPP, and I felt that matching the names was a good style change

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

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


From jwaters at openjdk.org  Mon Nov 14 01:38:18 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 14 Nov 2022 01:38:18 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features
In-Reply-To: <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
Message-ID: <jxCazhUqSAhkx-jLo3Y1rBwdhQmzGYKEzUzIKRDbZms=.117eb027-ed31-422a-af60-2b40f3ae1cce@github.com>

On Sun, 13 Nov 2022 23:07:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115
>> 
>> No changes to the behaviour of the JDK has resulted in any way from this commit
>
> src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 37:
> 
>> 35: #endif
>> 36: 
>> 37: #if defined(__clang_major__) && \
> 
> Not clear why this was moved ??

I'm not sure which one you're referring to, but the PRAGMA_DIAG_PUSH/POP was moved up to the top of the header to match compilerWarnings_visCPP.hpp, and PRAGMA_DISABLE_GCC_WARNING_AUX was moved to macros.hpp as the more general PRAGMA macro, since it's useful for all compilers and not just gcc

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

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


From jwaters at openjdk.org  Mon Nov 14 01:41:24 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 14 Nov 2022 01:41:24 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features
In-Reply-To: <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
Message-ID: <JifpzUjotcu252D3-usFaP6YYOm26UkGxNigCl8TyS4=.ad93c4a9-b88d-40f5-adc4-461e78311a5b@github.com>

On Sun, 13 Nov 2022 23:08:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115
>> 
>> No changes to the behaviour of the JDK has resulted in any way from this commit
>
> src/hotspot/share/utilities/debug.hpp line 172:
> 
>> 170: void report_fatal(VMErrorType error_type, const char* file, int line, const char* detail_fmt, ...) ATTRIBUTE_PRINTF(4, 5);
>> 171: void report_vm_out_of_memory(const char* file, int line, size_t size, VMErrorType vm_err_type,
>> 172:                              const char* detail_fmt, ...) ATTRIBUTE_PRINTF(5, 6);
> 
> Why were the ATTRIBUTE_PRINTFs removed?

The ATTRIBUTE_PRINTF macros are still there, just moved in front of the methods

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

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


From jwaters at openjdk.org  Mon Nov 14 01:46:16 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 14 Nov 2022 01:46:16 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features
In-Reply-To: <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
Message-ID: <cvaF0K8j70TF2vlmgBHzQYAOiYSeP7uZ_Y4yavC0J2w=.e69dd78a-7b52-4a00-969e-e4a195623c2b@github.com>

On Sun, 13 Nov 2022 23:16:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115
>> 
>> No changes to the behaviour of the JDK has resulted in any way from this commit
>
> make/autoconf/flags-cflags.m4 line 632:
> 
>> 630:   if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then
>> 631:     STATIC_LIBS_CFLAGS="$STATIC_LIBS_CFLAGS -ffunction-sections -fdata-sections \
>> 632:       -DJNIEXPORT='[[gnu::visibility(\"hidden\")]]'"
> 
> So IIUC we now use attributes via the C++11 syntax rather than compiler-specific syntax - even where the C++11 syntax is referring to a compiler specific attribute. Is that right?

Yep, just something that C++ does a little neater, at least in my view

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

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


From dholmes at openjdk.org  Mon Nov 14 02:13:24 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 14 Nov 2022 02:13:24 GMT
Subject: RFR: 8296886: Fix various include sort order issues
In-Reply-To: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
References: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
Message-ID: <nIA9wC-xmdZZ-ifksYR9KLG85-H-GeSR3Nc73Kg9a4U=.75c6e156-d9ea-4e9f-abb1-d99833c04f1a@github.com>

On Fri, 11 Nov 2022 14:26:20 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The sorted blocks of includes have deteriorated to the point that I felt compelled to clean up some of the issues.
> 
> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory, so I don't think that's a good enough argument, again IMHO. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share,
  just like the other platform-independent headers in HotSpot.
> 
> While going over the include headers I've also cleaned up surrounding whitespaces and incorrect include guards.

This seems very disruptive and I'm not sure there is any real gain. From a practical view how does this potentially impact the ability to do clean backports?

I don't agree with the changed treatment of `share/include` and I think it looks very strange to see `#include "include/xxx.h"`

I agree with Kim it would be better to break this up into different issues so that we don't roadblock on "all or nothing".

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

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


From jwaters at openjdk.org  Mon Nov 14 04:14:24 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 14 Nov 2022 04:14:24 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v2]
In-Reply-To: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
Message-ID: <x8nDS5oBvPgUmNTQie92RqlCGQpIvXY2Ribuu-YIeg0=.541a91ec-7dda-49b5-a274-6c127d6b1039@github.com>

> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115
> 
> No changes to the behaviour of the JDK has resulted in any way from this commit

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

  ATTRIBUTE_SCANF

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11081/files
  - new: https://git.openjdk.org/jdk/pull/11081/files/6d85c432..bb3ef0dd

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

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

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


From jwaters at openjdk.org  Mon Nov 14 04:14:26 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 14 Nov 2022 04:14:26 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v2]
In-Reply-To: <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
Message-ID: <xa0OxJAKuXs1pITkUZKcljgKl00lHRp9XUdMrknO9J4=.6aa6f913-0739-4bf8-a05a-bd77a7e8bfdd@github.com>

On Sun, 13 Nov 2022 22:58:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ATTRIBUTE_SCANF
>
> src/hotspot/os/linux/os_perf_linux.cpp line 233:
> 
>> 231:  *  Ensure that 'fmt' does _NOT_ contain the first two "%d %s"
>> 232:  */
>> 233: SCANF_ARGS(2, 0) static int vread_statdata(const char* procfile, _SCANFMT_ const char* fmt, va_list args) {
> 
> If `SCANF_ARGS` can/must come first then I suggest adding a newline after it so the method signature is easier to spot. Applied everywhere of course.

Resolved, thanks

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

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


From stefank at openjdk.org  Mon Nov 14 08:01:32 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 14 Nov 2022 08:01:32 GMT
Subject: RFR: 8296886: Fix various include sort order issues
In-Reply-To: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
References: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
Message-ID: <79P1w9DIxbQlPsfei2SPI11TOqry6l8JzT4gd8EKtuI=.5d1e8298-0f0d-4153-9558-890bbf9c46e3@github.com>

On Fri, 11 Nov 2022 14:26:20 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The sorted blocks of includes have deteriorated to the point that I felt compelled to clean up some of the issues.
> 
> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory, so I don't think that's a good enough argument, again IMHO. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share,
  just like the other platform-independent headers in HotSpot.
> 
> While going over the include headers I've also cleaned up surrounding whitespaces and incorrect include guards.

I'll split this out into separate changes.

* Regarding in `#include "include/xxx.h"`: This used to be `#include "prims/xxx.h"` and sorted the rest of the header file. Then they got moved to include/ and the directory was dropped for some reason. @dholmes-ora maybe you have a better name than `include/`, that is less eye jarring?

* Remember, a lot of the order we used was generated by a script. Some of the complaints above are against the style that was used ever since we added these includes to the files.

* System files comes after the HotSpot includes, with a blank line before.

* Platform files don't necessarily use the macro stems and then don't sort after the shared includes. I'm fine with changing this, but that would have to be tackled as a separate proposal.

* Sounds like a good proposal to move the external, shared headers like jimage.h and jni.h to a separate section *after* the HotSpot includes.

* I also remember that unittest.h needs to go at the end of the list, and have seen many violations of that. I added a blank line as a suggestion that this might give a visual aid of what's going on.

* <new> is typically provided via allocation.hpp, but I can leave the few odd <new> includes.

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

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


From dholmes at openjdk.org  Mon Nov 14 08:07:34 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 14 Nov 2022 08:07:34 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v2]
In-Reply-To: <0fVP40VVRuOoZCEJ1M3BLubshBHbD4m_lj-j1qaGTTk=.391ade50-b3fe-4d4e-ae71-ba8a975a31cd@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
 <0fVP40VVRuOoZCEJ1M3BLubshBHbD4m_lj-j1qaGTTk=.391ade50-b3fe-4d4e-ae71-ba8a975a31cd@github.com>
Message-ID: <mowWW-lO9a5Zo4iT-sbh1YTZFXO4UjKuJK7OpfrhFFo=.c7e5430a-de42-4465-ba85-10dfb8c71184@github.com>

On Mon, 14 Nov 2022 01:17:38 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/hotspot/os/windows/os_windows.hpp line 35:
>> 
>>> 33: class Thread;
>>> 34: 
>>> 35: static unsigned __stdcall thread_native_entry(Thread*);
>> 
>> Why was this removed? This is needed to correctly specify the call sequence for the thread entry routine when used with `_beginThreadex`:
>> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-170
>
> I'm not sure I follow, I didn't remove anything here?

Sorry my eyes must be playing tricks on me. ??

Why did you need to add this here?

>> src/hotspot/share/utilities/compilerWarnings.hpp line 47:
>> 
>>> 45: #endif
>>> 46: 
>>> 47: #ifndef PRAGMA_DISABLE_VISCPP_WARNING
>> 
>> Why rename this from `MSVC` to `VISCPP`? IIRC the full name is Microsft Visual Studio C++, so you new name is not obviously better and the change just adds noise to the PR. Further `MSVC` matches what MS themselves use and even the attribute namespace in C++11 is `MSVC`.
>> Update: I see the inconsistency with `compilerWarnings_visCPP.hpp`
>
> Yep, it was renamed since the file is also named VISCPP, and I felt that matching the names was a good style change

I think it is the file that has the "bad" name in this case. :( But okay.

>> src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 37:
>> 
>>> 35: #endif
>>> 36: 
>>> 37: #if defined(__clang_major__) && \
>> 
>> Not clear why this was moved ??
>
> I'm not sure which one you're referring to, but the PRAGMA_DIAG_PUSH/POP was moved up to the top of the header to match compilerWarnings_visCPP.hpp, and PRAGMA_DISABLE_GCC_WARNING_AUX was moved to macros.hpp as the more general PRAGMA macro, since it's useful for all compilers and not just gcc

Okay

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

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


From dholmes at openjdk.org  Mon Nov 14 08:10:45 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 14 Nov 2022 08:10:45 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v2]
In-Reply-To: <JifpzUjotcu252D3-usFaP6YYOm26UkGxNigCl8TyS4=.ad93c4a9-b88d-40f5-adc4-461e78311a5b@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
 <JifpzUjotcu252D3-usFaP6YYOm26UkGxNigCl8TyS4=.ad93c4a9-b88d-40f5-adc4-461e78311a5b@github.com>
Message-ID: <_hwdz6oHBktC95v1xdiK-szAPmho2bxrDMCWBUAPGo0=.2ff0735d-5fda-4322-ac1f-1b4bec31dc56@github.com>

On Mon, 14 Nov 2022 01:39:17 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/hotspot/share/utilities/debug.hpp line 172:
>> 
>>> 170:                             int status, const char* detail);
>>> 171: ATTRIBUTE_PRINTF(4, 5)
>>> 172: void report_fatal(VMErrorType error_type, const char* file, int line, const char* detail_fmt, ...);
>> 
>> Why were the ATTRIBUTE_PRINTFs removed?
>
> The ATTRIBUTE_PRINTF macros are still there, just moved in front of the methods

Wow I'm really having eyesight problems today! Sorry about that.

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

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


From stuefe at openjdk.org  Mon Nov 14 08:30:35 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 14 Nov 2022 08:30:35 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v2]
In-Reply-To: <x8nDS5oBvPgUmNTQie92RqlCGQpIvXY2Ribuu-YIeg0=.541a91ec-7dda-49b5-a274-6c127d6b1039@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <x8nDS5oBvPgUmNTQie92RqlCGQpIvXY2Ribuu-YIeg0=.541a91ec-7dda-49b5-a274-6c127d6b1039@github.com>
Message-ID: <vIdqGyQkQAXZauPAFCN2CkP_sG-N2nN90_HYrOHisYA=.e704c782-83d0-4464-b646-75f2cda0b686@github.com>

On Mon, 14 Nov 2022 04:14:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115
>> 
>> No changes to the behaviour of the JDK has resulted in any way from this commit
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ATTRIBUTE_SCANF

Hi Julian,

unfortunately, your patch will make backporting more difficult. We cannot downport it to older releases compiled with older compilers. But since it touches a lot of files it will sit smack in the middle of patch sequences, requiring manual merges for patches after it.

Is there any benefit to using the new syntax compared to the old one? It does seem similar verbose, so I don't see any benefit there.

Cheers, Thomas

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

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


From stefank at openjdk.org  Mon Nov 14 09:28:38 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 14 Nov 2022 09:28:38 GMT
Subject: RFR: 8296886: Fix various include sort order issues
In-Reply-To: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
References: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
Message-ID: <h5ph1Zz-NXkaf65cn9rW33rps6qW6RPOaJYrj7RrO04=.12781fcc-3669-456f-829c-3b2416c83c0c@github.com>

On Fri, 11 Nov 2022 14:26:20 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The sorted blocks of includes have deteriorated to the point that I felt compelled to clean up some of the issues.
> 
> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory, so I don't think that's a good enough argument, again IMHO. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share,
  just like the other platform-independent headers in HotSpot.
> 
> While going over the include headers I've also cleaned up surrounding whitespaces and incorrect include guards.

Closing this down and restarting this discussion with limited patch, which only adds the missing include/ dir: #11133.

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

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


From stefank at openjdk.org  Mon Nov 14 09:34:05 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 14 Nov 2022 09:34:05 GMT
Subject: RFR: 8296926: Use proper include lines for files in include/
Message-ID: <tl8LtRfG6_BUCdNMucC4JCSbjv_-yFP46CXbqYnvNxs=.cba35dd6-f1ee-41bf-aa87-9381cc064bf6@github.com>

One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share, just like the other platform-independent headers in HotSpot.

This RFE splits out the 'include/' changes from #11108 / JDK-8296886, so that those changes can be discussed separately.

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

Commit messages:
 - 8296926: Use proper include lines for files in include/

Changes: https://git.openjdk.org/jdk/pull/11133/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11133&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296926
  Stats: 270 lines in 154 files changed: 109 ins; 116 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/11133.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11133/head:pull/11133

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


From aph at openjdk.org  Mon Nov 14 11:11:27 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 14 Nov 2022 11:11:27 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v2]
In-Reply-To: <vIdqGyQkQAXZauPAFCN2CkP_sG-N2nN90_HYrOHisYA=.e704c782-83d0-4464-b646-75f2cda0b686@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <x8nDS5oBvPgUmNTQie92RqlCGQpIvXY2Ribuu-YIeg0=.541a91ec-7dda-49b5-a274-6c127d6b1039@github.com>
 <vIdqGyQkQAXZauPAFCN2CkP_sG-N2nN90_HYrOHisYA=.e704c782-83d0-4464-b646-75f2cda0b686@github.com>
Message-ID: <SRjjAqG5gAsvlkrnUTYFXBwO_Urv7DC1Z3yse50RPb4=.c7a1f821-af0b-4383-a69a-612585ebc17c@github.com>

On Mon, 14 Nov 2022 08:28:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> unfortunately, your patch will make backporting more difficult. We cannot downport it to older releases compiled with older compilers. But since it touches a lot of files it will sit smack in the middle of patch sequences, requiring manual merges for patches after it.
> 
> Is there any benefit to using the new syntax compared to the old one? It does seem similar verbose, so I don't see any benefit there.

I have to agree with Thomas here. Newer is not always better.

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

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


From kbarrett at openjdk.org  Mon Nov 14 11:41:17 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 14 Nov 2022 11:41:17 GMT
Subject: RFR: 8296886: Fix various include sort order issues
In-Reply-To: <2lOleILw53UHm1WCmH4QPBsjbisb1h6H7Gz9jJRtJ8A=.139da306-4220-438c-be4c-64be6dc14c5d@github.com>
References: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
 <2lOleILw53UHm1WCmH4QPBsjbisb1h6H7Gz9jJRtJ8A=.139da306-4220-438c-be4c-64be6dc14c5d@github.com>
Message-ID: <MfGGgkYsvTjqm5ClboYxOSRR5ar9iNUGAzINXl3gkOQ=.67e650a1-31b5-4cb4-a5bb-e62389c8c4ba@github.com>

On Fri, 11 Nov 2022 21:21:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> The sorted blocks of includes have deteriorated to the point that I felt compelled to clean up some of the issues.
>> 
>> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory, so I don't think that's a good enough argument, again IMHO. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share
 , just like the other platform-independent headers in HotSpot.
>> 
>> While going over the include headers I've also cleaned up surrounding whitespaces and incorrect include guards.
>
> src/hotspot/os/windows/jvm_windows.cpp line 27:
> 
>> 25: #include "precompiled.hpp"
>> 26: #include "include/jvm.h"
>> 27: #include "os_windows.hpp"
> 
> os_windows should be at the end, included using `OS_HEADER("os")`.

But should we be directly including os_windows.hpp, rather than including os.hpp?

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

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


From jwaters at openjdk.org  Mon Nov 14 12:00:28 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 14 Nov 2022 12:00:28 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v2]
In-Reply-To: <_hwdz6oHBktC95v1xdiK-szAPmho2bxrDMCWBUAPGo0=.2ff0735d-5fda-4322-ac1f-1b4bec31dc56@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
 <JifpzUjotcu252D3-usFaP6YYOm26UkGxNigCl8TyS4=.ad93c4a9-b88d-40f5-adc4-461e78311a5b@github.com>
 <_hwdz6oHBktC95v1xdiK-szAPmho2bxrDMCWBUAPGo0=.2ff0735d-5fda-4322-ac1f-1b4bec31dc56@github.com>
Message-ID: <aRZ0z2fQtE_oqBULtBDXoWOjZTczhBd77qXOuxkA1a0=.a485227d-efdf-42d6-9a79-a01959ddce42@github.com>

On Mon, 14 Nov 2022 08:08:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The ATTRIBUTE_PRINTF macros are still there, just moved in front of the methods
>
> Wow I'm really having eyesight problems today! Sorry about that.

Haha, no worries

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

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


From kbarrett at openjdk.org  Mon Nov 14 12:14:29 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 14 Nov 2022 12:14:29 GMT
Subject: RFR: 8296926: Use proper include lines for files in include/
In-Reply-To: <tl8LtRfG6_BUCdNMucC4JCSbjv_-yFP46CXbqYnvNxs=.cba35dd6-f1ee-41bf-aa87-9381cc064bf6@github.com>
References: <tl8LtRfG6_BUCdNMucC4JCSbjv_-yFP46CXbqYnvNxs=.cba35dd6-f1ee-41bf-aa87-9381cc064bf6@github.com>
Message-ID: <ie1izA5PqtodXGxKwtgp4mHWgJvIVQm5p8txTQMOCuQ=.1759b455-df96-442a-8575-f525a21e2169@github.com>

On Mon, 14 Nov 2022 09:25:11 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share, just like the other platform-independent headers in HotSpot
 .
> 
> This RFE splits out the 'include/' changes from #11108 / JDK-8296886, so that those changes can be discussed separately.

This looks fine to me.

Since the headers in the include/ directory are the interface exposed by HotSpot to the rest of the JDK, perhaps a better name might have been "hotspot" or "hotspot_api" or something like that.  OTOH, the clients in the rest of the JDK include them without a directory, so the directory name doesn't matter to them.  I'm fine with the existing name.

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

Marked as reviewed by kbarrett (Reviewer).

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


From jwaters at openjdk.org  Mon Nov 14 12:24:31 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 14 Nov 2022 12:24:31 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v2]
In-Reply-To: <mowWW-lO9a5Zo4iT-sbh1YTZFXO4UjKuJK7OpfrhFFo=.c7e5430a-de42-4465-ba85-10dfb8c71184@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
 <0fVP40VVRuOoZCEJ1M3BLubshBHbD4m_lj-j1qaGTTk=.391ade50-b3fe-4d4e-ae71-ba8a975a31cd@github.com>
 <mowWW-lO9a5Zo4iT-sbh1YTZFXO4UjKuJK7OpfrhFFo=.c7e5430a-de42-4465-ba85-10dfb8c71184@github.com>
Message-ID: <UwMOA0K5cYSIeTkRgIl6QlPe2iTTA5z0vCH3jzUmx4E=.2b35fc6c-e96a-4807-863f-583631128a4e@github.com>

On Mon, 14 Nov 2022 08:01:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I'm not sure I follow, I didn't remove anything here?
>
> Sorry my eyes must be playing tricks on me. ??
> 
> Why did you need to add this here?

It's to avoid redefining the linkage as static in os_windows.cpp (where it's implemented) after an extern declaration (inside the class), which is forbidden by C++11:

> The linkages implied by successive declarations for a given entity shall agree. That is, within a given scope, each declaration declaring the same variable name or the same overloading of a function name shall imply the same linkage.

While 2019 by default seems to ignore this rule and accepts the conflicting linkage as a language extension, this can cause issues with newer and stricter versions of the Visual C++ compiler (especially with -permissive- passed during compilation, which Magnus and Daniel have pointed out in another discussion will become the default mode of compilation in the future). It's not possible to declare a static friend inside a class, so the addition above takes advantage of another C++ feature instead:

> ?11.3/4 [class.friend]
A function first declared in a friend declaration has external linkage (3.5). Otherwise, the function retains its previous linkage (7.1.1).

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

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


From dholmes at openjdk.org  Mon Nov 14 12:53:29 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 14 Nov 2022 12:53:29 GMT
Subject: RFR: 8296926: Use proper include lines for files in include/
In-Reply-To: <tl8LtRfG6_BUCdNMucC4JCSbjv_-yFP46CXbqYnvNxs=.cba35dd6-f1ee-41bf-aa87-9381cc064bf6@github.com>
References: <tl8LtRfG6_BUCdNMucC4JCSbjv_-yFP46CXbqYnvNxs=.cba35dd6-f1ee-41bf-aa87-9381cc064bf6@github.com>
Message-ID: <9VDQOwxKWG4ynIq6Kq0_g9l4Mu9Q-GJCwI6dnFh-hyc=.8434a7c1-096c-49e5-bc0e-b8a8911462a8@github.com>

On Mon, 14 Nov 2022 09:25:11 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share, just like the other platform-independent headers in HotSpot
 .
> 
> This RFE splits out the 'include/' changes from #11108 / JDK-8296886, so that those changes can be discussed separately.

Please rename `share/include` to something more meaningful e.g. `share/export` or `share/hotspot` (as Kim suggested). Software that contains an `include` directory typically also specifies `-Iinclude/` so that you see `#include "foo.h"` not  `#include "include/foo.h"`. Thanks.

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

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


From kbarrett at openjdk.org  Mon Nov 14 13:42:02 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 14 Nov 2022 13:42:02 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v2]
In-Reply-To: <x8nDS5oBvPgUmNTQie92RqlCGQpIvXY2Ribuu-YIeg0=.541a91ec-7dda-49b5-a274-6c127d6b1039@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <x8nDS5oBvPgUmNTQie92RqlCGQpIvXY2Ribuu-YIeg0=.541a91ec-7dda-49b5-a274-6c127d6b1039@github.com>
Message-ID: <ZFIm743da2bNDg0P_C6hPwK8ld2QAZSiR1vt3rQJFC0=.1d280d20-15a1-42fb-970b-07e565a320c5@github.com>

On Mon, 14 Nov 2022 04:14:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115
>> 
>> No changes to the behaviour of the JDK has resulted in any way from this commit
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ATTRIBUTE_SCANF

Changes requested by kbarrett (Reviewer).

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

> 65:   # Hotspot cannot handle an empty build number
> 66:   VERSION_BUILD := 0
> 67: endif

I think the proposed "solution" is *much* worse than this.

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

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


From kbarrett at openjdk.org  Mon Nov 14 13:42:04 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 14 Nov 2022 13:42:04 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v2]
In-Reply-To: <cvaF0K8j70TF2vlmgBHzQYAOiYSeP7uZ_Y4yavC0J2w=.e69dd78a-7b52-4a00-969e-e4a195623c2b@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
 <cvaF0K8j70TF2vlmgBHzQYAOiYSeP7uZ_Y4yavC0J2w=.e69dd78a-7b52-4a00-969e-e4a195623c2b@github.com>
Message-ID: <PqiJunKhY85BbqgIB5X96kg16Dm-mTszPAFzYOjsfWs=.ebb72cc2-e4e0-4e8f-823e-1f5f97881a6a@github.com>

On Mon, 14 Nov 2022 01:42:40 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> make/autoconf/flags-cflags.m4 line 632:
>> 
>>> 630:   if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then
>>> 631:     STATIC_LIBS_CFLAGS="$STATIC_LIBS_CFLAGS -ffunction-sections -fdata-sections \
>>> 632:       -DJNIEXPORT='[[gnu::visibility(\"hidden\")]]'"
>> 
>> So IIUC we now use attributes via the C++11 syntax rather than compiler-specific syntax - even where the C++11 syntax is referring to a compiler specific attribute. Is that right?
>
> Yep, just something that C++ does a little neater, at least in my view

We (the HotSpot Group) have not discussed or approved the use of the new C++ attribute syntax, whether for standard attributes or compiler-specific ones.  That involves an update to the Style Guide.  I'm not convinced switching existing uses from compiler-specific `__attribute__` syntax to compiler-specific `[[attribute]]` syntax is worth the substantial code churn.

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

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


From jwaters at openjdk.org  Mon Nov 14 15:49:30 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 14 Nov 2022 15:49:30 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: <1YCK8xNkyZsASrKu6alUGEF7gyG3xicTxkpbIEjTkpE=.9ce5fbb2-28de-42e7-9789-4ff5e14b7857@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 know Skara, I'm deliberately holding off from integrating this for now...

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

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


From stefank at openjdk.org  Mon Nov 14 16:04:30 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 14 Nov 2022 16:04:30 GMT
Subject: RFR: 8296926: Use proper include lines for files in include/
In-Reply-To: <tl8LtRfG6_BUCdNMucC4JCSbjv_-yFP46CXbqYnvNxs=.cba35dd6-f1ee-41bf-aa87-9381cc064bf6@github.com>
References: <tl8LtRfG6_BUCdNMucC4JCSbjv_-yFP46CXbqYnvNxs=.cba35dd6-f1ee-41bf-aa87-9381cc064bf6@github.com>
Message-ID: <ORKl1lE7IuVrWBwe5TGaklZkumTw1ePMjNnrAhqD5ks=.b66bcb0b-536d-4b73-bc5d-0de0cc424232@github.com>

On Mon, 14 Nov 2022 09:25:11 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share, just like the other platform-independent headers in HotSpot
 .
> 
> This RFE splits out the 'include/' changes from #11108 / JDK-8296886, so that those changes can be discussed separately.

An alternative is to just that include/ is special, and shouldn't be specified, but then properly sort jvm.h and friends alphabetically, as specified in the Style Guide.

I'm fine with either solution, but I really want to remove this half measure that only some of the directory-less include lines are put at the top of the include block. If we are going to have such a special-case rule, then I'd argue that we should come up with a structure that is easy to explain and maintain, and write it down in our Style Guide.

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

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


From jwaters at openjdk.org  Mon Nov 14 16:12:48 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 14 Nov 2022 16:12:48 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
Message-ID: <gay-N6xDnfKHcngB9ddJIZD6Jfg2m_ZCzZn1gWPFN-o=.785036e8-1d1d-41d3-bac3-211b9d03cd71@github.com>

> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115
> 
> No changes to the behaviour of the JDK has resulted in any way from this commit

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

  Revert to using simpler solution similar to the original 8274980

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11081/files
  - new: https://git.openjdk.org/jdk/pull/11081/files/bb3ef0dd..fe5371c9

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

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

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


From dholmes at openjdk.org  Mon Nov 14 21:54:59 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 14 Nov 2022 21:54:59 GMT
Subject: RFR: 8296926: Use proper include lines for files in include/
In-Reply-To: <tl8LtRfG6_BUCdNMucC4JCSbjv_-yFP46CXbqYnvNxs=.cba35dd6-f1ee-41bf-aa87-9381cc064bf6@github.com>
References: <tl8LtRfG6_BUCdNMucC4JCSbjv_-yFP46CXbqYnvNxs=.cba35dd6-f1ee-41bf-aa87-9381cc064bf6@github.com>
Message-ID: <NnikEO-HpI3xhdlNu8Ibtk-e9VADlVBPJMwl04PPLwk=.6bf1d7af-1b9a-4bca-ac62-2670949159b9@github.com>

On Mon, 14 Nov 2022 09:25:11 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share, just like the other platform-independent headers in HotSpot
 .
> 
> This RFE splits out the 'include/' changes from #11108 / JDK-8296886, so that those changes can be discussed separately.

Okay I'm fine with `jvm.h` being placed in sort order rather than adding the `include/` part. Thanks.

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

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


From jwaters at openjdk.org  Tue Nov 15 00:52:07 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 15 Nov 2022 00:52:07 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <ZFIm743da2bNDg0P_C6hPwK8ld2QAZSiR1vt3rQJFC0=.1d280d20-15a1-42fb-970b-07e565a320c5@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <x8nDS5oBvPgUmNTQie92RqlCGQpIvXY2Ribuu-YIeg0=.541a91ec-7dda-49b5-a274-6c127d6b1039@github.com>
 <ZFIm743da2bNDg0P_C6hPwK8ld2QAZSiR1vt3rQJFC0=.1d280d20-15a1-42fb-970b-07e565a320c5@github.com>
Message-ID: <7OFGmmeTJLL_dl8LZC0y11-crea_x6bM5Sto5_c366k=.8fda2c5a-b7b7-4c98-9a6e-b6c6cf14db3a@github.com>

On Mon, 14 Nov 2022 13:08:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert to using simpler solution similar to the original 8274980
>
> make/hotspot/lib/CompileJvm.gmk line 67:
> 
>> 65:   # Hotspot cannot handle an empty build number
>> 66:   VERSION_BUILD := 0
>> 67: endif
> 
> I think the proposed "solution" is *much* worse than this.

Reverted to use the original, less intrusive solution from [8274980](https://github.com/openjdk/jdk/pull/11081/commits/83ed3deb29d7344bbc95a3831f2388d077bc59e9) that initially could not work with the older Visual C++ compiler (With a minor improvement to handle #define 0)

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

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


From manc at openjdk.org  Tue Nov 15 05:35:53 2022
From: manc at openjdk.org (Man Cao)
Date: Tue, 15 Nov 2022 05:35:53 GMT
Subject: RFR: 8296970: Remove sysThreadAvailableStackWithSlack from
 hotspot-symbols
Message-ID: <yi2Yx_J2hxrMTkdZk2j6L5ADa406T7FO0vyudT2z208=.a1c2e878-96c8-41da-a12b-1d2c8ab54fd4@github.com>

Hi all,

Could anyone review this cleanup to remove dead symbol "sysThreadAvailableStackWithSlack"? See https://bugs.openjdk.org/browse/JDK-8296970 for more details.

-Man

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

Commit messages:
 - 8296970: Remove sysThreadAvailableStackWithSlack from hotspot-symbols

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

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


From kbarrett at openjdk.org  Tue Nov 15 06:42:58 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 15 Nov 2022 06:42:58 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <gay-N6xDnfKHcngB9ddJIZD6Jfg2m_ZCzZn1gWPFN-o=.785036e8-1d1d-41d3-bac3-211b9d03cd71@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <gay-N6xDnfKHcngB9ddJIZD6Jfg2m_ZCzZn1gWPFN-o=.785036e8-1d1d-41d3-bac3-211b9d03cd71@github.com>
Message-ID: <XXVqN4ByCrB34JRZSgiNYWsdrwEOTKjo5u81sTFG5bE=.7748c17a-4a13-42aa-b10d-219fe6775da2@github.com>

On Mon, 14 Nov 2022 16:12:48 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115
>> 
>> No changes to the behaviour of the JDK has resulted in any way from this commit
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert to using simpler solution similar to the original 8274980

A few more issues as I slog my way through this commingled PR.  Probably more to come.

src/hotspot/share/utilities/globalDefinitions.hpp line 50:

> 48: 
> 49: #ifndef ATTRIBUTE_ALIGNED
> 50: #define ATTRIBUTE_ALIGNED(x) alignas(x)

HotSpot Group has not discussed or approved use of `alignas` - see https://bugs.openjdk.org/browse/JDK-8250269.  This is another change that is independent of most of the rest of this PR, and should be dealt with separately.  The various MSVC-conditional direct uses of `_declspec(align(N))` should probably currently be using `ATTRIBUTE_ALIGNED`.

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

Changes requested by kbarrett (Reviewer).

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


From kbarrett at openjdk.org  Tue Nov 15 06:42:59 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 15 Nov 2022 06:42:59 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <7OFGmmeTJLL_dl8LZC0y11-crea_x6bM5Sto5_c366k=.8fda2c5a-b7b7-4c98-9a6e-b6c6cf14db3a@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <x8nDS5oBvPgUmNTQie92RqlCGQpIvXY2Ribuu-YIeg0=.541a91ec-7dda-49b5-a274-6c127d6b1039@github.com>
 <ZFIm743da2bNDg0P_C6hPwK8ld2QAZSiR1vt3rQJFC0=.1d280d20-15a1-42fb-970b-07e565a320c5@github.com>
 <7OFGmmeTJLL_dl8LZC0y11-crea_x6bM5Sto5_c366k=.8fda2c5a-b7b7-4c98-9a6e-b6c6cf14db3a@github.com>
Message-ID: <S1wp3kCTkaV5pa7NNeFP57Zrf2JFGs9BNzMC1dYkfXU=.262781f6-e561-42e2-893d-918cf6fc189b@github.com>

On Tue, 15 Nov 2022 00:49:59 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> make/hotspot/lib/CompileJvm.gmk line 67:
>> 
>>> 65:   # Hotspot cannot handle an empty build number
>>> 66:   VERSION_BUILD := 0
>>> 67: endif
>> 
>> I think the proposed "solution" is *much* worse than this.
>
> Reverted to use the original, less intrusive solution from [8274980](https://github.com/openjdk/jdk/pull/11081/commits/83ed3deb29d7344bbc95a3831f2388d077bc59e9) that initially could not work with the older Visual C++ compiler (With a minor improvement to handle #define 0)

Sorry, but I don't think that's much better than the prior version, and still doesn't seem better than the current code.  What problem is this change supposed to be solving?  I didn't find any open bugs that seemed relevant (could be I just didn't recognize such).  Whatever it is seems likely to be unrelated to any of the other changes in this PR; it would have been / would be better to deal with it separately.

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

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


From kbarrett at openjdk.org  Tue Nov 15 06:42:59 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 15 Nov 2022 06:42:59 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <mowWW-lO9a5Zo4iT-sbh1YTZFXO4UjKuJK7OpfrhFFo=.c7e5430a-de42-4465-ba85-10dfb8c71184@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
 <0fVP40VVRuOoZCEJ1M3BLubshBHbD4m_lj-j1qaGTTk=.391ade50-b3fe-4d4e-ae71-ba8a975a31cd@github.com>
 <mowWW-lO9a5Zo4iT-sbh1YTZFXO4UjKuJK7OpfrhFFo=.c7e5430a-de42-4465-ba85-10dfb8c71184@github.com>
Message-ID: <V_tHKXIx0k0HzvHk3hnP9vVP4F0Vx4uD9a1oz5DTi54=.d8437f88-81fc-4412-a2ee-074fd4c6e9c1@github.com>

On Mon, 14 Nov 2022 08:02:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Yep, it was renamed since the file is also named VISCPP, and I felt that matching the names was a good style change
>
> I think it is the file that has the "bad" name in this case. :( But okay.

I also think the macro name should be left alone.  It's the file suffix that is "bad", though I'm not convinced it's so bad as to be worth changing.  (There's also `TARGET_COMPILER_visCPP`.)

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

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


From ihse at openjdk.org  Tue Nov 15 07:08:06 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Nov 2022 07:08:06 GMT
Subject: RFR: 8295070: Introduce more target combinations for compiler
 flags [v3]
In-Reply-To: <1YCK8xNkyZsASrKu6alUGEF7gyG3xicTxkpbIEjTkpE=.9ce5fbb2-28de-42e7-9789-4ff5e14b7857@github.com>
References: <alUrMJ4fQy9z3dKu3BideMeVLc7DhlUbd_IWx79mZVU=.74eb4654-00b0-497f-9450-e87d9b435e37@github.com>
 <dEz1C15HnujCTsRaRZ_0G9DV_Z0fyun60AzAfq04hNw=.92012cfb-2a75-4d7f-b062-b5b40b102b4e@github.com>
 <1YCK8xNkyZsASrKu6alUGEF7gyG3xicTxkpbIEjTkpE=.9ce5fbb2-28de-42e7-9789-4ff5e14b7857@github.com>
Message-ID: <hW0r4C-03_FDGNZB0DDwq-r-9yoGDS_yrq4Z15JDK5I=.5169431b-e529-4244-973b-3c77eee4cdaf@github.com>

On Mon, 14 Nov 2022 15:45:50 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> I know Skara, I'm deliberately holding off from integrating this for now...

Why is that?

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

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


From jwaters at openjdk.org  Tue Nov 15 08:23:06 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 15 Nov 2022 08:23:06 GMT
Subject: RFR: 8295070: Introduce more target combinations for compiler
 flags [v3]
In-Reply-To: <hW0r4C-03_FDGNZB0DDwq-r-9yoGDS_yrq4Z15JDK5I=.5169431b-e529-4244-973b-3c77eee4cdaf@github.com>
References: <alUrMJ4fQy9z3dKu3BideMeVLc7DhlUbd_IWx79mZVU=.74eb4654-00b0-497f-9450-e87d9b435e37@github.com>
 <dEz1C15HnujCTsRaRZ_0G9DV_Z0fyun60AzAfq04hNw=.92012cfb-2a75-4d7f-b062-b5b40b102b4e@github.com>
 <1YCK8xNkyZsASrKu6alUGEF7gyG3xicTxkpbIEjTkpE=.9ce5fbb2-28de-42e7-9789-4ff5e14b7857@github.com>
 <hW0r4C-03_FDGNZB0DDwq-r-9yoGDS_yrq4Z15JDK5I=.5169431b-e529-4244-973b-3c77eee4cdaf@github.com>
Message-ID: <WG8EOYxFWjE8ipYgLJzj2qDubbFA5EJQOb_eIkBRMmE=.8fe9f433-2156-424c-82b8-73be19871936@github.com>

On Tue, 15 Nov 2022 07:05:33 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > I know Skara, I'm deliberately holding off from integrating this for now...
> 
> Why is that?

I was trying to see if I could find and rework every site that could use touching up with this change in one fell swoop, but on second thought never mind, it's taking a bit too long to do that all at once

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

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


From jwaters at openjdk.org  Tue Nov 15 09:52:04 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 15 Nov 2022 09:52:04 GMT
Subject: Integrated: 8295070: Introduce more target combinations for compiler
 flags
In-Reply-To: <alUrMJ4fQy9z3dKu3BideMeVLc7DhlUbd_IWx79mZVU=.74eb4654-00b0-497f-9450-e87d9b435e37@github.com>
References: <alUrMJ4fQy9z3dKu3BideMeVLc7DhlUbd_IWx79mZVU=.74eb4654-00b0-497f-9450-e87d9b435e37@github.com>
Message-ID: <dOpfZXFAlDK9EDATjzQOk3Z99WrqxJ6JJXq7_wyu0yc=.b5c9001b-ff14-4aa0-a8d6-d9e518a03bb4@github.com>

On Mon, 10 Oct 2022 15:08:43 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

This pull request has now been integrated.

Changeset: 9adb7283
Author:    Julian Waters <jwaters at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9adb72837836c5cd67cd41af36aac3c07274f01b
Stats:     48 lines in 1 file changed: 37 ins; 0 del; 11 mod

8295070: Introduce more target combinations for compiler flags

Reviewed-by: erikj, ihse

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

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


From lujaniuk at openjdk.org  Tue Nov 15 10:02:08 2022
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Tue, 15 Nov 2022 10:02:08 GMT
Subject: RFR: JDK-8297000 [jib] Add more friendly warning for proxy issues
Message-ID: <kFnWkvqxdHvbqf4hajjA2n9rBELOGWPTk_vLxPfU4P8=.dc3062c3-fcde-44b9-8433-2f04ccd9074b@github.com>

When jib tries to download itself behind a proxy, sometimes it can get a different file than it expected. This can result in cryptic errors that are hard to troubleshoot. Let's handle this a little more gracefully by detecting it in the bootstrapper and printing an error.

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

Commit messages:
 - JDK-8297000 [jib] Add more friendly warning for proxy issues

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

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


From stefank at openjdk.org  Tue Nov 15 10:42:58 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 15 Nov 2022 10:42:58 GMT
Subject: RFR: 8296926: Use proper include lines for files in include/ [v2]
In-Reply-To: <tl8LtRfG6_BUCdNMucC4JCSbjv_-yFP46CXbqYnvNxs=.cba35dd6-f1ee-41bf-aa87-9381cc064bf6@github.com>
References: <tl8LtRfG6_BUCdNMucC4JCSbjv_-yFP46CXbqYnvNxs=.cba35dd6-f1ee-41bf-aa87-9381cc064bf6@github.com>
Message-ID: <advo_9N-gWLIYj0pvZdBMKdX99rRMRKTIHUCybir2tI=.09dbeb3c-a27d-4195-98bb-9923d25dda1d@github.com>

> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share, just like the other platform-independent headers in HotSpot
 .
> 
> This RFE splits out the 'include/' changes from #11108 / JDK-8296886, so that those changes can be discussed separately.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Remove include/ from includes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11133/files
  - new: https://git.openjdk.org/jdk/pull/11133/files/38707dff..a4a479ed

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

  Stats: 207 lines in 137 files changed: 69 ins; 69 del; 69 mod
  Patch: https://git.openjdk.org/jdk/pull/11133.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11133/head:pull/11133

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


From jwaters at openjdk.org  Tue Nov 15 12:25:06 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 15 Nov 2022 12:25:06 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <S1wp3kCTkaV5pa7NNeFP57Zrf2JFGs9BNzMC1dYkfXU=.262781f6-e561-42e2-893d-918cf6fc189b@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <x8nDS5oBvPgUmNTQie92RqlCGQpIvXY2Ribuu-YIeg0=.541a91ec-7dda-49b5-a274-6c127d6b1039@github.com>
 <ZFIm743da2bNDg0P_C6hPwK8ld2QAZSiR1vt3rQJFC0=.1d280d20-15a1-42fb-970b-07e565a320c5@github.com>
 <7OFGmmeTJLL_dl8LZC0y11-crea_x6bM5Sto5_c366k=.8fda2c5a-b7b7-4c98-9a6e-b6c6cf14db3a@github.com>
 <S1wp3kCTkaV5pa7NNeFP57Zrf2JFGs9BNzMC1dYkfXU=.262781f6-e561-42e2-893d-918cf6fc189b@github.com>
Message-ID: <iSTDY2tJsH0cZdGm-b43DfFGTQN8vKa_hBBHMgjKu_k=.3c3d967c-1bd7-43f1-85a5-aa5a3ece6171@github.com>

On Tue, 15 Nov 2022 06:12:52 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Reverted to use the original, less intrusive solution from [8274980](https://github.com/openjdk/jdk/pull/11081/commits/83ed3deb29d7344bbc95a3831f2388d077bc59e9) that initially could not work with the older Visual C++ compiler (With a minor improvement to handle #define 0)
>
> Sorry, but I don't think that's much better than the prior version, and still doesn't seem better than the current code.  What problem is this change supposed to be solving?  I didn't find any open bugs that seemed relevant (could be I just didn't recognize such).  Whatever it is seems likely to be unrelated to any of the other changes in this PR; it would have been / would be better to deal with it separately.

It's related to the JEP-223 version build numbers, which the original commit couldn't get to work due to a preprocessor trick not working with the now unsupported 2017. I just felt it could be included here out of convenience, but I guess I can split it off into another change if required

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

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


From jwaters at openjdk.org  Tue Nov 15 12:34:04 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 15 Nov 2022 12:34:04 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <PqiJunKhY85BbqgIB5X96kg16Dm-mTszPAFzYOjsfWs=.ebb72cc2-e4e0-4e8f-823e-1f5f97881a6a@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
 <cvaF0K8j70TF2vlmgBHzQYAOiYSeP7uZ_Y4yavC0J2w=.e69dd78a-7b52-4a00-969e-e4a195623c2b@github.com>
 <PqiJunKhY85BbqgIB5X96kg16Dm-mTszPAFzYOjsfWs=.ebb72cc2-e4e0-4e8f-823e-1f5f97881a6a@github.com>
Message-ID: <cRXeR6mdu1s4Vy4P-1TDPTCdnso0soubbR2tSeVvYiY=.3d543774-2096-4b96-89e7-50aec40fa96b@github.com>

On Mon, 14 Nov 2022 13:06:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Yep, just something that C++ does a little neater, at least in my view
>
> We (the HotSpot Group) have not discussed or approved the use of the new C++ attribute syntax, whether for standard attributes or compiler-specific ones.  That involves an update to the Style Guide.  I'm not convinced switching existing uses from compiler-specific `__attribute__` syntax to compiler-specific `[[attribute]]` syntax is worth the substantial code churn.

I was under the assumption that anything not listed under "Not discussed" or "Forbidden" was free game in HotSpot, I apologise for my goof since that isn't the case. That said, I am curious if there are any isolated conversations about the attribute syntax anywhere

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

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


From erikj at openjdk.org  Tue Nov 15 13:56:11 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 15 Nov 2022 13:56:11 GMT
Subject: RFR: 8296904: Improve handling of macos xcode toolchain [v2]
In-Reply-To: <tIAra5jBQrKyPBbOBCRon-1FPIYM8csax1FKpi48OSk=.ce063463-01b6-4a8e-96a7-ee4d2fc3682e@github.com>
References: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
 <tIAra5jBQrKyPBbOBCRon-1FPIYM8csax1FKpi48OSk=.ce063463-01b6-4a8e-96a7-ee4d2fc3682e@github.com>
Message-ID: <K0ZDYMNhSBy_WBVh_mqoGZVwVZP1_AvJpHj6CgFeneM=.4b4def46-17ee-4cb2-9663-72c37a680082@github.com>

On Sat, 12 Nov 2022 15:23:41 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> With this PR I'd like to make it easier to use dedicated installations of Xcode on Mac OS for OpenJDK builds without having to switch the active Xcode globally via `xcode-select`.
>> 
>> I propose adding a new configure flag `--with-xcode-path` that takes the path to an Xcode installation. If the option is set, this path is expanded to a valid `TOOLCHAIN_PATH`.
>> 
>> Furthermore, I fix detection of xcodebuild and correctly setting the sysroot from the toolchain by moving `AC_SUBST(TOOLCHAIN_PATH)` before calling `BASIC_SETUP_XCODE_SYSROOT` and honoring `TOOLCHAIN_PATH` in BASIC_SETUP_XCODE_SYSROOT in the case when no devkit is specified. As I see it, this is a viable fix, even if not introducing `--with-xcode-path`.
>
> Christoph Langer has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Improve options for xcode toolchain

I think this looks good. It's technically possible to achieve what you need using the existing `--with-toolchain-path`, but in the case of Xcode, that is rather cumbersome as you need to point to the internal `bin` directories in the Xcode installation instead of just the top level Xcode application dir.

make/autoconf/basic.m4 line 306:

> 304: 
> 305:   AC_ARG_WITH([xcode-path], [AS_HELP_STRING([--with-xcode-path],
> 306:       [set up toolchain on Mac OS using a path to an xcode installation])])

Suggestion:

      [set up toolchain on Mac OS using a path to an Xcode installation])])

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

Marked as reviewed by erikj (Reviewer).

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


From erikj at openjdk.org  Tue Nov 15 14:09:01 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 15 Nov 2022 14:09:01 GMT
Subject: RFR: 8296478: Rework 8282948 and 8282700 to use the new autoconf
 UTIL_ARG_WITH [v2]
In-Reply-To: <WXiInV6g7gltKihp6pg6kd3kVtX9EIB-yX7YQI34LYk=.162eb88a-c4cb-464c-8a26-dd1db571ed99@github.com>
References: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
 <WXiInV6g7gltKihp6pg6kd3kVtX9EIB-yX7YQI34LYk=.162eb88a-c4cb-464c-8a26-dd1db571ed99@github.com>
Message-ID: <4oGi5GyFXqXEXT2o0WoB9oIiOmguuEiHnkPshproLnw=.5e0fd8ba-dfc0-4682-967e-ed93dca04a7f@github.com>

On Sat, 12 Nov 2022 16:18:54 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> 8285093 introduced the new UTIL_ARG_WITH definition, which was not available when both 8282948 and 8282700 were written. They can now be moved to using the cleaner logic that UTIL_ARG_WITH grants.
>> 
>> There are many more options that still use AC_ARG_WITH in jdk-version.m4. They are out of the scope of this commit, which aims only to rework the previous integrated commits mentioned above.
>
> 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 two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into util
>  - Squash

I think this looks good. I'm assuming you have manually tried the options and inspected the resulting spec.gmk thoroughly.

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

Marked as reviewed by erikj (Reviewer).

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


From coleenp at openjdk.org  Tue Nov 15 14:15:02 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 15 Nov 2022 14:15:02 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <gay-N6xDnfKHcngB9ddJIZD6Jfg2m_ZCzZn1gWPFN-o=.785036e8-1d1d-41d3-bac3-211b9d03cd71@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <gay-N6xDnfKHcngB9ddJIZD6Jfg2m_ZCzZn1gWPFN-o=.785036e8-1d1d-41d3-bac3-211b9d03cd71@github.com>
Message-ID: <iF4tdByM8y7NzhFfm2dbJ38l39Ld8CZIPdt3zC7w_d4=.eda73685-fe4a-41cf-b39f-d8134c6c1f9c@github.com>

On Mon, 14 Nov 2022 16:12:48 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115
>> 
>> No changes to the behaviour of the JDK has resulted in any way from this commit
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert to using simpler solution similar to the original 8274980

Can you have separate PRs for each type of thing you're changing?

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

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


From aph at openjdk.org  Tue Nov 15 14:20:43 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Nov 2022 14:20:43 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator)
Message-ID: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>

JEP 429 implementation.

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

Commit messages:
 - Update StressStackOverflow
 - Release _scopedValueCache after use
 - Merge branch 'JDK-8286666' of https://github.com/theRealAph/jdk into JDK-8286666
 - Update src/java.base/share/classes/jdk/internal/vm/ScopedValueContainer.java
 - Rename test
 - Update
 - Whitespace
 - Rewrite ScopedValue stress test
 - Reviewer feedback
 - Reviewer feedback
 - ... and 10 more: https://git.openjdk.org/jdk/compare/d4d183ed...0d72ca2f

Changes: https://git.openjdk.org/jdk/pull/10952/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8286666
  Stats: 3272 lines in 52 files changed: 2868 ins; 246 del; 158 mod
  Patch: https://git.openjdk.org/jdk/pull/10952.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952

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


From dlong at openjdk.org  Tue Nov 15 14:20:47 2022
From: dlong at openjdk.org (Dean Long)
Date: Tue, 15 Nov 2022 14:20:47 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator)
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <ZZdAKZ9bIbjt0_jcpXkqAsHbFAjmp6cK8pPC8Y9bks4=.6f1b1a45-8434-4275-97e9-8d02bfb828bf@github.com>

On Wed, 2 Nov 2022 16:23:34 GMT, Andrew Haley <aph at openjdk.org> wrote:

> JEP 429 implementation.

src/hotspot/share/prims/jvm.cpp line 1410:

> 1408:       loc = 3;
> 1409:     } else if (method == resolver.thread_run_method) {
> 1410:       loc = 2;

This depends on how javac numbers locals, right?  It seems a bit fragile.  This is one of the reasons why doPrivileged uses the helper method executePrivileged, so the locals are arguments, giving them predictable offsets.

src/java.base/share/classes/jdk/internal/vm/ScopedValueContainer.java line 53:

> 51:     /**
> 52:      * Returns the "latest" ScopedValueContainer for the current Thread. This may be on
> 53:      * the current thread's scope task or ma require walking up the tree to find it.

Suggestion:

     * the current thread's scope task or may require walking up the tree to find it.

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

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


From aph at openjdk.org  Tue Nov 15 14:20:48 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Nov 2022 14:20:48 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator)
In-Reply-To: <dkd9EyTzZJXTs_6-x0NF6VpAhP9CXyi2o9fla7WcOJM=.3cc41e07-6f17-4d9d-ad98-e372a0c421bb@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <ZZdAKZ9bIbjt0_jcpXkqAsHbFAjmp6cK8pPC8Y9bks4=.6f1b1a45-8434-4275-97e9-8d02bfb828bf@github.com>
 <dkd9EyTzZJXTs_6-x0NF6VpAhP9CXyi2o9fla7WcOJM=.3cc41e07-6f17-4d9d-ad98-e372a0c421bb@github.com>
Message-ID: <buDIXmfTPJUOV6ITOJzStRgl2rTMugKZov6HCrNSHgY=.e8cdf866-d68e-4edd-922e-a7c776019ff0@github.com>

On Thu, 10 Nov 2022 17:42:38 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/share/prims/jvm.cpp line 1410:
>> 
>>> 1408:       loc = 3;
>>> 1409:     } else if (method == resolver.thread_run_method) {
>>> 1410:       loc = 2;
>> 
>> This depends on how javac numbers locals, right?  It seems a bit fragile.  This is one of the reasons why doPrivileged uses the helper method executePrivileged, so the locals are arguments, giving them predictable offsets.
>
> Ah, good point. I'll have a look at doing that.

Done.

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

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


From aph at openjdk.org  Tue Nov 15 14:20:48 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Nov 2022 14:20:48 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator)
In-Reply-To: <ZZdAKZ9bIbjt0_jcpXkqAsHbFAjmp6cK8pPC8Y9bks4=.6f1b1a45-8434-4275-97e9-8d02bfb828bf@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <ZZdAKZ9bIbjt0_jcpXkqAsHbFAjmp6cK8pPC8Y9bks4=.6f1b1a45-8434-4275-97e9-8d02bfb828bf@github.com>
Message-ID: <dkd9EyTzZJXTs_6-x0NF6VpAhP9CXyi2o9fla7WcOJM=.3cc41e07-6f17-4d9d-ad98-e372a0c421bb@github.com>

On Fri, 4 Nov 2022 23:17:32 GMT, Dean Long <dlong at openjdk.org> wrote:

>> JEP 429 implementation.
>
> src/hotspot/share/prims/jvm.cpp line 1410:
> 
>> 1408:       loc = 3;
>> 1409:     } else if (method == resolver.thread_run_method) {
>> 1410:       loc = 2;
> 
> This depends on how javac numbers locals, right?  It seems a bit fragile.  This is one of the reasons why doPrivileged uses the helper method executePrivileged, so the locals are arguments, giving them predictable offsets.

Ah, good point. I'll have a look at doing that.

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

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


From alanb at openjdk.org  Tue Nov 15 14:20:50 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Nov 2022 14:20:50 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator)
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <2qiwIUFK4kh7KzfhV8rlx9lXY79B_LkUvFo3E9hKDyM=.682039e2-78be-4864-a90a-3bd6e5372547@github.com>

On Wed, 2 Nov 2022 16:23:34 GMT, Andrew Haley <aph at openjdk.org> wrote:

> JEP 429 implementation.

src/hotspot/share/prims/jvm.cpp line 4072:

> 4070:  */
> 4071: JVM_ENTRY(void, JVM_EnsureMaterializedForStackWalk_func(JNIEnv* env, jobject vthread, jobject value))
> 4072:   //asm("nop");

The asm("nop") was commented out to get the build working. Its inserted by the compiler now so I assume the commented now asm can be removed.

src/java.base/share/classes/java/lang/VirtualThread.java line 318:

> 316:         }
> 317:     }
> 318:     @Hidden

Can we rename this to runWith(Runnable, Object) in both Thread and VirtualThread to keep the naming consistent if we can?

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

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


From duke at openjdk.org  Tue Nov 15 14:20:53 2022
From: duke at openjdk.org (ExE Boss)
Date: Tue, 15 Nov 2022 14:20:53 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator)
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <FclwJZRKpjSGCNnl3yRZRRzmvJuQlXNHFmdcQ742p18=.f9ed06dd-4602-400d-aa91-2091b9f26982@github.com>

On Wed, 2 Nov 2022 16:23:34 GMT, Andrew Haley <aph at openjdk.org> wrote:

> JEP 429 implementation.

src/java.base/share/classes/java/lang/Thread.java line 1610:

> 1608:             ensureMaterializedForStackWalk(bindings);
> 1609:             task.run();
> 1610:             Reference.reachabilityFence(bindings);

This?should probably?be?in a?`try`?`finally`?block:
Suggestion:

            try {
                task.run();
            } finally {
                Reference.reachabilityFence(bindings);
            }

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 481:

> 479:         }
> 480:  */
> 481:         return findBinding() != Snapshot.NIL;

This?should probably?call `Cache.put(this,?value)` when?`findBinding()` isn?t?`Snapshot.NIL`, since?it?s?likely that?`isBound()` will?most?commonly be?used in?the?form?of:

if (SCOPED_VALUE.isBound()) {
	final var value = SCOPED_VALUE.get();
	// do something with `value`
}


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

Suggestion:

        var value = findBinding();
        if (value == Snapshot.NIL) {
            return false;
        }
        Cache.put(this, value);
        return true;

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

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


From aph at openjdk.org  Tue Nov 15 14:20:53 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Nov 2022 14:20:53 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator)
In-Reply-To: <FclwJZRKpjSGCNnl3yRZRRzmvJuQlXNHFmdcQ742p18=.f9ed06dd-4602-400d-aa91-2091b9f26982@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <FclwJZRKpjSGCNnl3yRZRRzmvJuQlXNHFmdcQ742p18=.f9ed06dd-4602-400d-aa91-2091b9f26982@github.com>
Message-ID: <40rwB5m6Mskkevkwkj8B34o540txfesN7P-pOGWPfqA=.4cf0adb3-1e3d-4a87-b2bf-505c7f15d487@github.com>

On Thu, 3 Nov 2022 11:50:17 GMT, ExE Boss <duke at openjdk.org> wrote:

>> JEP 429 implementation.
>
> src/java.base/share/classes/java/lang/Thread.java line 1610:
> 
>> 1608:             ensureMaterializedForStackWalk(bindings);
>> 1609:             task.run();
>> 1610:             Reference.reachabilityFence(bindings);
> 
> This?should probably?be?in a?`try`?`finally`?block:
> Suggestion:
> 
>             try {
>                 task.run();
>             } finally {
>                 Reference.reachabilityFence(bindings);
>             }

I wonder. The pattern I'm using here is based on `AccessController.executePrivileged`, which doesn't have the `finally` clause. Perhaps I should add one here anyway.

> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 481:
> 
>> 479:         }
>> 480:  */
>> 481:         return findBinding() != Snapshot.NIL;
> 
> This?should probably?call `Cache.put(this,?value)` when?`findBinding()` isn?t?`Snapshot.NIL`, since?it?s?likely that?`isBound()` will?most?commonly be?used in?the?form?of:
> 
> if (SCOPED_VALUE.isBound()) {
> 	final var value = SCOPED_VALUE.get();
> 	// do something with `value`
> }
> 
> 
> --------------------------------------------------------------------------------
> 
> Suggestion:
> 
>         var value = findBinding();
>         if (value == Snapshot.NIL) {
>             return false;
>         }
>         Cache.put(this, value);
>         return true;

Probably so, yes. I'll have a look at that along with caching failure.

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

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


From aph at openjdk.org  Tue Nov 15 14:20:56 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Nov 2022 14:20:56 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator)
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <3lVtaG-K0g_3M_-8_lszieivuJ4a88CKmyWj0MH8cgU=.fc28bd92-72ec-4eff-962f-06c7404954fd@github.com>

On Wed, 2 Nov 2022 16:23:34 GMT, Andrew Haley <aph at openjdk.org> wrote:

> JEP 429 implementation.

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 475:

> 473:         // ??? Do we want to search cache for this? In most cases we don't expect
> 474:         // this {@link ScopedValue} to be bound, so it's not worth it. But I may
> 475:         // be wrong about that.

We should make it switchable by a runtime parameter. We should optionally cache failures.
Add a microbenchmark for that.

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

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


From dlong at openjdk.org  Tue Nov 15 14:20:54 2022
From: dlong at openjdk.org (Dean Long)
Date: Tue, 15 Nov 2022 14:20:54 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator)
In-Reply-To: <40rwB5m6Mskkevkwkj8B34o540txfesN7P-pOGWPfqA=.4cf0adb3-1e3d-4a87-b2bf-505c7f15d487@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <FclwJZRKpjSGCNnl3yRZRRzmvJuQlXNHFmdcQ742p18=.f9ed06dd-4602-400d-aa91-2091b9f26982@github.com>
 <40rwB5m6Mskkevkwkj8B34o540txfesN7P-pOGWPfqA=.4cf0adb3-1e3d-4a87-b2bf-505c7f15d487@github.com>
Message-ID: <kXgHNrHUMWBv50mRCkzuOOT9wNCoNzpSHGmaCmP5gGE=.27f2e129-b410-4a74-a14b-c41ea260f72e@github.com>

On Fri, 4 Nov 2022 09:53:39 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Thread.java line 1610:
>> 
>>> 1608:             ensureMaterializedForStackWalk(bindings);
>>> 1609:             task.run();
>>> 1610:             Reference.reachabilityFence(bindings);
>> 
>> This?should probably?be?in a?`try`?`finally`?block:
>> Suggestion:
>> 
>>             try {
>>                 task.run();
>>             } finally {
>>                 Reference.reachabilityFence(bindings);
>>             }
>
> I wonder. The pattern I'm using here is based on `AccessController.executePrivileged`, which doesn't have the `finally` clause. Perhaps I should add one here anyway.

I hope it doesn't matter.  There is an example in the reachabilityFence javadocs where it does not use finally.  For it to matter, I think the compiler would need to inline through run() and prove that it can throw an exception, but I don't think that's how the JIT compilers currently implement reachabilityFence.  I suppose a finally shouldn't hurt, however.

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

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


From aph at openjdk.org  Tue Nov 15 14:20:55 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Nov 2022 14:20:55 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator)
In-Reply-To: <2qiwIUFK4kh7KzfhV8rlx9lXY79B_LkUvFo3E9hKDyM=.682039e2-78be-4864-a90a-3bd6e5372547@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <2qiwIUFK4kh7KzfhV8rlx9lXY79B_LkUvFo3E9hKDyM=.682039e2-78be-4864-a90a-3bd6e5372547@github.com>
Message-ID: <Yj81L0TMKWcS5VBcJfGyzQQVfAr0mtM10YMyfQJp2WY=.a37e4cff-c9cc-47f2-ad49-661151cc27e0@github.com>

On Mon, 14 Nov 2022 17:34:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JEP 429 implementation.
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 318:
> 
>> 316:         }
>> 317:     }
>> 318:     @Hidden
> 
> Can we rename this to runWith(Runnable, Object) in both Thread and VirtualThread to keep the naming consistent if we can?

OK. I do want to keep the name of this method consistent throughout. There are version for `Runnable` and `Callable` and it makes the runtime code cleaner if they have the same name.

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

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


From erikj at openjdk.org  Tue Nov 15 14:24:59 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 15 Nov 2022 14:24:59 GMT
Subject: RFR: JDK-8297000 [jib] Add more friendly warning for proxy issues
In-Reply-To: <kFnWkvqxdHvbqf4hajjA2n9rBELOGWPTk_vLxPfU4P8=.dc3062c3-fcde-44b9-8433-2f04ccd9074b@github.com>
References: <kFnWkvqxdHvbqf4hajjA2n9rBELOGWPTk_vLxPfU4P8=.dc3062c3-fcde-44b9-8433-2f04ccd9074b@github.com>
Message-ID: <9c6H-ur3Win5l25hGc52FbbK55NW5VlmX16xPg-AccM=.a9441b73-0a49-478c-b977-3ee8f17f14b5@github.com>

On Tue, 15 Nov 2022 09:55:38 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> When jib tries to download itself behind a proxy, sometimes it can get a different file than it expected. This can result in cryptic errors that are hard to troubleshoot. Let's handle this a little more gracefully by detecting it in the bootstrapper and printing an error.

Marked as reviewed by erikj (Reviewer).

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

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


From shade at openjdk.org  Tue Nov 15 14:26:43 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Nov 2022 14:26:43 GMT
Subject: RFR: 8294591: Fix cast-function-type warning in TemplateTable [v6]
In-Reply-To: <F9kScSH8YZ9kK8XAcl5pPPE6sPrHCBUc_zNriSaP8EU=.d5c7452c-72ed-4f41-9dea-5bd8a7fccbc0@github.com>
References: <F9kScSH8YZ9kK8XAcl5pPPE6sPrHCBUc_zNriSaP8EU=.d5c7452c-72ed-4f41-9dea-5bd8a7fccbc0@github.com>
Message-ID: <YFUqNAFHWeIeZjced_rpvGUTPuEr0vnWkSgcyyB7kL4=.c89e3fb4-5122-4ed3-88c2-7215ce3a6620@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 six commits:

 - Merge branch 'master' into JDK-8294591-warning-cast-function-type-templatetable
 - Merge branch 'master' into JDK-8294591-warning-cast-function-type-templatetable
 - Fix build failures
 - 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=05
  Stats: 46 lines in 9 files changed: 6 ins; 1 del; 39 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 erikj at openjdk.org  Tue Nov 15 14:29:21 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 15 Nov 2022 14:29:21 GMT
Subject: RFR: 8296926: Use proper include lines for files in include/ [v2]
In-Reply-To: <advo_9N-gWLIYj0pvZdBMKdX99rRMRKTIHUCybir2tI=.09dbeb3c-a27d-4195-98bb-9923d25dda1d@github.com>
References: <tl8LtRfG6_BUCdNMucC4JCSbjv_-yFP46CXbqYnvNxs=.cba35dd6-f1ee-41bf-aa87-9381cc064bf6@github.com>
 <advo_9N-gWLIYj0pvZdBMKdX99rRMRKTIHUCybir2tI=.09dbeb3c-a27d-4195-98bb-9923d25dda1d@github.com>
Message-ID: <TNg63dXWqSlUgpHB5xDsocZHPUOBF4SMYXte1BNR70g=.340a38f8-f45a-4e02-9ea2-954c0fb8434f@github.com>

On Tue, 15 Nov 2022 10:42:58 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share, just like the other platform-independent headers in HotSpo
 t.
>> 
>> This RFE splits out the 'include/' changes from #11108 / JDK-8296886, so that those changes can be discussed separately.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove include/ from includes

Build change looks good.

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

Marked as reviewed by erikj (Reviewer).

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


From jwaters at openjdk.org  Tue Nov 15 14:53:59 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 15 Nov 2022 14:53:59 GMT
Subject: RFR: 8296478: Rework 8282948 and 8282700 to use the new autoconf
 UTIL_ARG_WITH [v2]
In-Reply-To: <4oGi5GyFXqXEXT2o0WoB9oIiOmguuEiHnkPshproLnw=.5e0fd8ba-dfc0-4682-967e-ed93dca04a7f@github.com>
References: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
 <WXiInV6g7gltKihp6pg6kd3kVtX9EIB-yX7YQI34LYk=.162eb88a-c4cb-464c-8a26-dd1db571ed99@github.com>
 <4oGi5GyFXqXEXT2o0WoB9oIiOmguuEiHnkPshproLnw=.5e0fd8ba-dfc0-4682-967e-ed93dca04a7f@github.com>
Message-ID: <ltDPOieSd9Abdzmzw2-fAl6IouPqHIgFGNdkIvUFWiw=.c261bae1-0318-42d7-805d-00eb67d27442@github.com>

On Tue, 15 Nov 2022 14:06:35 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I think this looks good. I'm assuming you have manually tried the options and inspected the resulting spec.gmk thoroughly.

Yep, but for completion's sake I re-ran configure again for a fresh spec.gmk:


COPYRIGHT_YEAR:=2022
HOTSPOT_BUILD_TIME:=2022-11-10T08:57:48Z

# Platform naming variables
LAUNCHER_NAME:=openjdk
PRODUCT_NAME:=OpenJDK
PRODUCT_SUFFIX:=Runtime Environment
JDK_RC_PLATFORM_NAME:=Platform
JDK_RC_NAME:=OpenJDK Platform
COMPANY_NAME:=N/A
HOTSPOT_VM_DISTRO:=OpenJDK
MACOSX_BUNDLE_NAME_BASE=OpenJDK
MACOSX_BUNDLE_ID_BASE=net.java.openjdk-internal
MACOSX_BUNDLE_BUILD_VERSION=0
USERNAME:=vertig0
VENDOR_URL:=https://openjdk.org/
VENDOR_URL_BUG:=https://bugreport.java.com/bugreport/
VENDOR_URL_VM_BUG:=https://bugreport.java.com/bugreport/crash.jsp


The offending COMPANY_NAME option is still getting on my nerves though :/

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

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


From aph at openjdk.org  Tue Nov 15 14:57:35 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Nov 2022 14:57:35 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v2]
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <8Yik6EmjgjWQSz-lAL99OFhis_ZpNTP3IGYyebnggyM=.67de9502-136c-4a17-b6fe-9cb89b72c37a@github.com>

> JEP 429 implementation.

Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:

 - Update test
 - Reviewer feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10952/files
  - new: https://git.openjdk.org/jdk/pull/10952/files/0d72ca2f..4bd44d66

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

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

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


From alanb at openjdk.org  Tue Nov 15 15:06:05 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Nov 2022 15:06:05 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v2]
In-Reply-To: <Yj81L0TMKWcS5VBcJfGyzQQVfAr0mtM10YMyfQJp2WY=.a37e4cff-c9cc-47f2-ad49-661151cc27e0@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <2qiwIUFK4kh7KzfhV8rlx9lXY79B_LkUvFo3E9hKDyM=.682039e2-78be-4864-a90a-3bd6e5372547@github.com>
 <Yj81L0TMKWcS5VBcJfGyzQQVfAr0mtM10YMyfQJp2WY=.a37e4cff-c9cc-47f2-ad49-661151cc27e0@github.com>
Message-ID: <p0meBnMWhQHcgk4Zxz9jbZThPkQNBFNC9mBA54mEqCc=.9f60a7d8-149d-4372-83a7-8166c4b2e3f1@github.com>

On Tue, 15 Nov 2022 14:15:26 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/VirtualThread.java line 318:
>> 
>>> 316:         }
>>> 317:     }
>>> 318:     @Hidden
>> 
>> Can we rename this to runWith(Runnable, Object) in both Thread and VirtualThread to keep the naming consistent if we can?
>
> OK. I do want to keep the name of this method consistent throughout. There are version for `Runnable` and `Callable` and it makes the runtime code cleaner if they have the same name.

The other thing here is that there two calls to reachabilityFence, it shouldn't need both.

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

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


From stefank at openjdk.org  Tue Nov 15 15:21:03 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 15 Nov 2022 15:21:03 GMT
Subject: RFR: 8296926: Use proper include lines for files in include/ [v3]
In-Reply-To: <tl8LtRfG6_BUCdNMucC4JCSbjv_-yFP46CXbqYnvNxs=.cba35dd6-f1ee-41bf-aa87-9381cc064bf6@github.com>
References: <tl8LtRfG6_BUCdNMucC4JCSbjv_-yFP46CXbqYnvNxs=.cba35dd6-f1ee-41bf-aa87-9381cc064bf6@github.com>
Message-ID: <9gZ-d-amnILbr_KlmSakclFAuAwxwYxXi9Mg8AlefI0=.9d8c75b1-212d-40ce-a689-8352ceb802c8@github.com>

> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share, just like the other platform-independent headers in HotSpot
 .
> 
> This RFE splits out the 'include/' changes from #11108 / JDK-8296886, so that those changes can be discussed separately.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Revert make file changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11133/files
  - new: https://git.openjdk.org/jdk/pull/11133/files/a4a479ed..92cba2ea

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

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

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


From stefank at openjdk.org  Tue Nov 15 15:18:02 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 15 Nov 2022 15:18:02 GMT
Subject: RFR: 8296926: Use proper include lines for files in include/ [v2]
In-Reply-To: <TNg63dXWqSlUgpHB5xDsocZHPUOBF4SMYXte1BNR70g=.340a38f8-f45a-4e02-9ea2-954c0fb8434f@github.com>
References: <tl8LtRfG6_BUCdNMucC4JCSbjv_-yFP46CXbqYnvNxs=.cba35dd6-f1ee-41bf-aa87-9381cc064bf6@github.com>
 <advo_9N-gWLIYj0pvZdBMKdX99rRMRKTIHUCybir2tI=.09dbeb3c-a27d-4195-98bb-9923d25dda1d@github.com>
 <TNg63dXWqSlUgpHB5xDsocZHPUOBF4SMYXte1BNR70g=.340a38f8-f45a-4e02-9ea2-954c0fb8434f@github.com>
Message-ID: <-ok_diV5QiOvTWi2l0uOgCNcev-kAwdqllyekkQWbFg=.faec8a60-67be-4c10-8759-5e1ffe9af0bc@github.com>

On Tue, 15 Nov 2022 14:25:15 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Build change looks good.

Thanks, Erik. Actually, that change should have been reverted with the last change. I'll revert that.

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

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


From jwaters at openjdk.org  Tue Nov 15 16:04:10 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 15 Nov 2022 16:04:10 GMT
Subject: RFR: 8296478: Rework 8282948 and 8282700 to use the new autoconf
 UTIL_ARG_WITH [v2]
In-Reply-To: <WXiInV6g7gltKihp6pg6kd3kVtX9EIB-yX7YQI34LYk=.162eb88a-c4cb-464c-8a26-dd1db571ed99@github.com>
References: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
 <WXiInV6g7gltKihp6pg6kd3kVtX9EIB-yX7YQI34LYk=.162eb88a-c4cb-464c-8a26-dd1db571ed99@github.com>
Message-ID: <TL04FQDlJAOOMbHHdWVV90md6SHU67sY-KE0h1RS6Wk=.15982f3b-5f17-4efd-a0f7-b701adcbadb6@github.com>

On Sat, 12 Nov 2022 16:18:54 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> 8285093 introduced the new UTIL_ARG_WITH definition, which was not available when both 8282948 and 8282700 were written. They can now be moved to using the cleaner logic that UTIL_ARG_WITH grants.
>> 
>> There are many more options that still use AC_ARG_WITH in jdk-version.m4. They are out of the scope of this commit, which aims only to rework the previous integrated commits mentioned above.
>
> 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 two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into util
>  - Squash

Oh, silly me, you mean with the options passed

(Arbitrary values passed because I can't think of unique names)

bash configure --with-toolchain-type=gcc --build=x86_64-pc-msys --openjdk-target=x86_64-pc-msys --without-version-opt --with-jtreg=/d/Eclipse/jtreg --with-build-user=UCRT64 --with-macosx-bundle-name-base=Java --enable-linktime-gc --enable-jvm-feature-link-time-opt


`MACOSX_BUNDLE_NAME_BASE=Java`

I'm not confident enough to integrate yet though, since I'm fairly certain COMPANY_NAME isn't working due to a deeper and potentially more serious underlying problem

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

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


From aph at openjdk.org  Tue Nov 15 15:52:22 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Nov 2022 15:52:22 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v3]
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <upL_LOJRbB9XCJtuvA7rHX3CzZe34ZgbK50GeS_dFhs=.d5490421-c718-4e53-9b7d-cbb24f3a7b0f@github.com>

> JEP 429 implementation.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Reviewer feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10952/files
  - new: https://git.openjdk.org/jdk/pull/10952/files/4bd44d66..442a04ef

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

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

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


From jaroslav.bachorik at datadoghq.com  Tue Nov 15 16:28:35 2022
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Tue, 15 Nov 2022 17:28:35 +0100
Subject: How to use `--with-jib`?
Message-ID: <CAPb8aJ4g-RHi14pqbt2J=WwwLOg36_EJn5A1b=qqzNYLVVkERA@mail.gmail.com>

Hello,

I apologize for possibly stupid question - but how can I use the
'--with-jib' option?
In particular, where can I get the binaries I can point `--with-jib` to?

Thanks a bunch!

-JB-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20221115/9f42ed6b/attachment.htm>

From aph at openjdk.org  Tue Nov 15 16:37:15 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Nov 2022 16:37:15 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v4]
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <fJ7c8YV5FyFoWr_aN3FvOPtHKVQaP357dHygu1t38jY=.6964383d-bc17-4706-9abe-85a60b6817ae@github.com>

> JEP 429 implementation.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Reviewer feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10952/files
  - new: https://git.openjdk.org/jdk/pull/10952/files/442a04ef..c70945bf

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

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

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


From aph at openjdk.org  Tue Nov 15 17:18:19 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Nov 2022 17:18:19 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v5]
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <N2dCDLPJeA2u7BzUSEmSGED-0qx7wBr7VLiIgJyBeng=.7d01959f-70c4-4a77-b3be-25609ee8c797@github.com>

> JEP 429 implementation.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Fix failing serviceability tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10952/files
  - new: https://git.openjdk.org/jdk/pull/10952/files/c70945bf..4e650314

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

  Stats: 17 lines in 7 files changed: 14 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10952.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952

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


From aph at openjdk.org  Tue Nov 15 17:36:16 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Nov 2022 17:36:16 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v6]
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <rFpWIyEO_DC9u3gyaxwlC3nK0gdo_2gGlX9bgNZvtZE=.2eec08c4-0a50-4f81-b4c9-45eba639f941@github.com>

> JEP 429 implementation.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Fix failing serviceability tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10952/files
  - new: https://git.openjdk.org/jdk/pull/10952/files/4e650314..e1063d7b

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

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

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


From erik.joelsson at oracle.com  Tue Nov 15 18:03:35 2022
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 15 Nov 2022 10:03:35 -0800
Subject: How to use `--with-jib`?
In-Reply-To: <CAPb8aJ4g-RHi14pqbt2J=WwwLOg36_EJn5A1b=qqzNYLVVkERA@mail.gmail.com>
References: <CAPb8aJ4g-RHi14pqbt2J=WwwLOg36_EJn5A1b=qqzNYLVVkERA@mail.gmail.com>
Message-ID: <52485dc2-0036-5e84-f54b-ed45cd4699fb@oracle.com>

Hello Jaroslav,

Jib is an Oracle internal tool used to manage builds and tests of 
OpenJDK at Oracle. There is no way for us to share that with external 
people unfortunately.

/Erik

On 11/15/22 08:28, Jaroslav Bachor?k wrote:
> Hello,
>
> I apologize for possibly stupid question - but how can I use the 
> '--with-jib' option?
> In particular, where can I get the binaries I can point `--with-jib` to?
>
> Thanks a bunch!
>
> -JB-


From erikj at openjdk.org  Tue Nov 15 18:09:07 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 15 Nov 2022 18:09:07 GMT
Subject: RFR: 8296478: Rework 8282948 and 8282700 to use the new autoconf
 UTIL_ARG_WITH [v2]
In-Reply-To: <WXiInV6g7gltKihp6pg6kd3kVtX9EIB-yX7YQI34LYk=.162eb88a-c4cb-464c-8a26-dd1db571ed99@github.com>
References: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
 <WXiInV6g7gltKihp6pg6kd3kVtX9EIB-yX7YQI34LYk=.162eb88a-c4cb-464c-8a26-dd1db571ed99@github.com>
Message-ID: <lB2klW_hd-DONie-kR1uoTz3PoJRUFlJwmAAEBdNrWc=.44399ff2-54ef-4eba-a3d5-6c748c1fb119@github.com>

On Sat, 12 Nov 2022 16:18:54 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> 8285093 introduced the new UTIL_ARG_WITH definition, which was not available when both 8282948 and 8282700 were written. They can now be moved to using the cleaner logic that UTIL_ARG_WITH grants.
>> 
>> There are many more options that still use AC_ARG_WITH in jdk-version.m4. They are out of the scope of this commit, which aims only to rework the previous integrated commits mentioned above.
>
> 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 two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into util
>  - Squash

I mean with both options passed and without, with empty options when applicable etc. Verified that spec.gmk is the same before and after the patch with the same options set.

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

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


From alanb at openjdk.org  Tue Nov 15 18:19:11 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Nov 2022 18:19:11 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v6]
In-Reply-To: <rFpWIyEO_DC9u3gyaxwlC3nK0gdo_2gGlX9bgNZvtZE=.2eec08c4-0a50-4f81-b4c9-45eba639f941@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <rFpWIyEO_DC9u3gyaxwlC3nK0gdo_2gGlX9bgNZvtZE=.2eec08c4-0a50-4f81-b4c9-45eba639f941@github.com>
Message-ID: <C-v7qjsby2H_3Unxk5z109bqWYTG5swuqp5MJEhgptc=.78a1caa9-0c6d-4f0e-bd8c-3757b16cb453@github.com>

On Tue, 15 Nov 2022 17:36:16 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> JEP 429 implementation.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix failing serviceability tests

test/jdk/ProblemList.txt line 804:

> 802: 
> 803: # Loom, fibers branch
> 804: 

This is left over from when Stress.java was excluded so we can remove it from the PR.

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

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


From mcimadamore at openjdk.org  Tue Nov 15 19:27:08 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 15 Nov 2022 19:27:08 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v6]
In-Reply-To: <rFpWIyEO_DC9u3gyaxwlC3nK0gdo_2gGlX9bgNZvtZE=.2eec08c4-0a50-4f81-b4c9-45eba639f941@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <rFpWIyEO_DC9u3gyaxwlC3nK0gdo_2gGlX9bgNZvtZE=.2eec08c4-0a50-4f81-b4c9-45eba639f941@github.com>
Message-ID: <nK7KFzzYywjKGp2TTJF1ALF4yQdkN0HC1ja2wtZTSRc=.ef43617b-9781-44cf-b3d1-7ad951ec598a@github.com>

On Tue, 15 Nov 2022 17:36:16 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> JEP 429 implementation.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix failing serviceability tests

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 43:

> 41: /**
> 42:  * A value that is set once and is then available for reading for a bounded period of
> 43:  * execution by a thread. A {@code ScopedValue} allows for safely and efficiently sharing

by a thread, or by one or more threads? (when inherited)

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 160:

> 158:  * record.
> 159:  *
> 160:  * <p>For this incubator release, we have provided some system properties

Maybe it would be better to frame this as "The reference implementation provides some system properties". The term "reference implementation" is used elsewhere to define JDK specific mechanisms that might, or might not carry across to other JVM/Java SE API implementations.

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 172:

> 170:  * must be an integer power of 2.
> 171:  *
> 172:  * <p>For example, you could use {@code -Djdk.incubator.concurrent.ScopedValue.cacheSize=8}.

I would also avoid "you" and "we" in the javadoc. While javadoc is not formal, we often use locutions such as "clients can use/do XYZ".

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 180:

> 178:  * thread preserves its scoped-value cache when blocked. Like {@code
> 179:  * ScopedValue.cacheSize}, this is a space versus speed trade-off: if
> 180:  * you have a great many virtual threads that are blocked most of the

"in situations where many virtual threads are blocked most of the time, ..."

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 185:

> 183:  * would have to be regenerated after a blocking operation.
> 184:  *
> 185:  * @param <T> the type of the value

Suggestion:

 * @param <T> the type of the scoped value

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 354:

> 352: 
> 353:         /**
> 354:          * Calls a value returning operation with each scoped value in this mapping bound

Suggestion:

         * Calls a value-returning operation with each scoped value in this mapping bound

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 460:

> 458:      * }
> 459:      *
> 460:      * @param key the ScopedValue key

should use `@code` or `@link`

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 463:

> 461:      * @param value the value, can be {@code null}
> 462:      * @param <T> the type of the value
> 463:      * @return a new Carrier with a single mapping

same here

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 470:

> 468: 
> 469:     /**
> 470:      * Calls a value returning operation with a {@code ScopedValue} bound to a value

Suggestion:

     * Calls a value returning-operation with a {@code ScopedValue} bound to a value

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 490:

> 488:      * }
> 489:      *
> 490:      * @param key the ScopedValue

Again, missing `@code` - please check all methods

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 613:

> 611:      * @return the value of the scoped value if bound, otherwise {@code other}
> 612:      */
> 613:     public T orElse(T other) {

>From an API perspective, wouldn't return `Optional` a more consistent choice? `Optional` has all methods we need to deal with this kind of stuff...

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 229:

> 227:  *   <li> Inheritance of {@linkplain ScopedValue scoped values} across threads.
> 228:  *   <li> Confinement checks. The phrase "threads contained in the task scope" in method
> 229:  *   descriptions means threads started in the task scope or descendant scopes.

sadly, the term "descendant scopes" is not defined elsewhere in this javadoc

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 233:

> 231:  *
> 232:  * <p> The following example demonstrates the inheritance of a scoped value. A scoped
> 233:  * value {@code USERNAME} is bound to the value "duke". A StructuredTaskScope is created

Missing `@code` or `@link` for `StructuredTaskScope`

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 237:

> 235:  * The thread inherits the scoped value <em>bindings</em> captured when creating the
> 236:  * task scope. The code in {@code childTask} uses the value of the scoped value and so
> 237:  * reads the value "duke".

Suggestion:

 * reads the value {@code "duke"}.

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

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


From alanb at openjdk.org  Tue Nov 15 20:14:02 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Nov 2022 20:14:02 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v6]
In-Reply-To: <nK7KFzzYywjKGp2TTJF1ALF4yQdkN0HC1ja2wtZTSRc=.ef43617b-9781-44cf-b3d1-7ad951ec598a@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <rFpWIyEO_DC9u3gyaxwlC3nK0gdo_2gGlX9bgNZvtZE=.2eec08c4-0a50-4f81-b4c9-45eba639f941@github.com>
 <nK7KFzzYywjKGp2TTJF1ALF4yQdkN0HC1ja2wtZTSRc=.ef43617b-9781-44cf-b3d1-7ad951ec598a@github.com>
Message-ID: <5hAVImQZUFPiE99N8uZ5KC7YUGHEkYglmftttBxZln4=.d469624e-5ddc-4c13-bc64-ed0c73ceb5a2@github.com>

On Tue, 15 Nov 2022 18:28:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix failing serviceability tests
>
> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 43:
> 
>> 41: /**
>> 42:  * A value that is set once and is then available for reading for a bounded period of
>> 43:  * execution by a thread. A {@code ScopedValue} allows for safely and efficiently sharing
> 
> by a thread, or by one or more threads? (when inherited)

I'd prefer to keep this as is because it's too much to use "threads" or mention inheritance in the first paragraph.

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

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


From alanb at openjdk.org  Tue Nov 15 20:29:10 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Nov 2022 20:29:10 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v6]
In-Reply-To: <nK7KFzzYywjKGp2TTJF1ALF4yQdkN0HC1ja2wtZTSRc=.ef43617b-9781-44cf-b3d1-7ad951ec598a@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <rFpWIyEO_DC9u3gyaxwlC3nK0gdo_2gGlX9bgNZvtZE=.2eec08c4-0a50-4f81-b4c9-45eba639f941@github.com>
 <nK7KFzzYywjKGp2TTJF1ALF4yQdkN0HC1ja2wtZTSRc=.ef43617b-9781-44cf-b3d1-7ad951ec598a@github.com>
Message-ID: <XEqyhW1QAJKrizAC-gOblrN7Pa1F_f2C8I5XO9RJqBM=.bc08c201-9382-43a6-a68b-b809028524a8@github.com>

On Tue, 15 Nov 2022 19:19:57 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix failing serviceability tests
>
> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 613:
> 
>> 611:      * @return the value of the scoped value if bound, otherwise {@code other}
>> 612:      */
>> 613:     public T orElse(T other) {
> 
> From an API perspective, wouldn't return `Optional` a more consistent choice? `Optional` has all methods we need to deal with this kind of stuff...

This comment is on orElse but I suspect you are suggesting that get() be changed to return Optional. I think we'll need to get more feedback/usage of this API before re-visiting that.

> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 229:
> 
>> 227:  *   <li> Inheritance of {@linkplain ScopedValue scoped values} across threads.
>> 228:  *   <li> Confinement checks. The phrase "threads contained in the task scope" in method
>> 229:  *   descriptions means threads started in the task scope or descendant scopes.
> 
> sadly, the term "descendant scopes" is not defined elsewhere in this javadoc

Good poin,t, we had more setup in previous iterations.
@theRealAph I'll adjust this in the loom repo as I can't do it here.

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

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


From mcimadamore at openjdk.org  Tue Nov 15 21:31:37 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 15 Nov 2022 21:31:37 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v6]
In-Reply-To: <XEqyhW1QAJKrizAC-gOblrN7Pa1F_f2C8I5XO9RJqBM=.bc08c201-9382-43a6-a68b-b809028524a8@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <rFpWIyEO_DC9u3gyaxwlC3nK0gdo_2gGlX9bgNZvtZE=.2eec08c4-0a50-4f81-b4c9-45eba639f941@github.com>
 <nK7KFzzYywjKGp2TTJF1ALF4yQdkN0HC1ja2wtZTSRc=.ef43617b-9781-44cf-b3d1-7ad951ec598a@github.com>
 <XEqyhW1QAJKrizAC-gOblrN7Pa1F_f2C8I5XO9RJqBM=.bc08c201-9382-43a6-a68b-b809028524a8@github.com>
Message-ID: <CRejKgLiOJHhFPCEfxGBnnNGZiFhES4Ac9Dqtgq2VWY=.12932aae-9015-4452-9a7c-4c59b1981495@github.com>

On Tue, 15 Nov 2022 20:26:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 613:
>> 
>>> 611:      * @return the value of the scoped value if bound, otherwise {@code other}
>>> 612:      */
>>> 613:     public T orElse(T other) {
>> 
>> From an API perspective, wouldn't return `Optional` a more consistent choice? `Optional` has all methods we need to deal with this kind of stuff...
>
> This comment is on orElse but I suspect you are suggesting that get() be changed to return Optional. I think we'll need to get more feedback/usage of this API before re-visiting that.

Yes, my comment was really on `get` - that said, I note that saying get().get() would look odd (but maybe finding some other name for `ScopedValue::get`, such as `find` might work)

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

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


From clanger at openjdk.org  Tue Nov 15 21:45:25 2022
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 15 Nov 2022 21:45:25 GMT
Subject: RFR: 8296904: Improve handling of macos xcode toolchain [v3]
In-Reply-To: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
References: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
Message-ID: <qOWYOLTicFL1YEmGaFrRWhhQnXe7g-4KEjVsCox8RAM=.7e644243-089f-4300-8000-6a6b57be1c56@github.com>

> With this PR I'd like to make it easier to use dedicated installations of Xcode on Mac OS for OpenJDK builds without having to switch the active Xcode globally via `xcode-select`.
> 
> I propose adding a new configure flag `--with-xcode-path` that takes the path to an Xcode installation. If the option is set, this path is expanded to a valid `TOOLCHAIN_PATH`.
> 
> Furthermore, I fix detection of xcodebuild and correctly setting the sysroot from the toolchain by moving `AC_SUBST(TOOLCHAIN_PATH)` before calling `BASIC_SETUP_XCODE_SYSROOT` and honoring `TOOLCHAIN_PATH` in BASIC_SETUP_XCODE_SYSROOT in the case when no devkit is specified. As I see it, this is a viable fix, even if not introducing `--with-xcode-path`.

Christoph Langer 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:

 - Review suggestion
 - Merge branch 'master' into xcode-toolchain
 - Improve options for xcode toolchain

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11113/files
  - new: https://git.openjdk.org/jdk/pull/11113/files/dd808218..312c5b06

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

  Stats: 3535 lines in 97 files changed: 2253 ins; 741 del; 541 mod
  Patch: https://git.openjdk.org/jdk/pull/11113.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11113/head:pull/11113

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


From clanger at openjdk.org  Tue Nov 15 21:45:28 2022
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 15 Nov 2022 21:45:28 GMT
Subject: RFR: 8296904: Improve handling of macos xcode toolchain [v2]
In-Reply-To: <tIAra5jBQrKyPBbOBCRon-1FPIYM8csax1FKpi48OSk=.ce063463-01b6-4a8e-96a7-ee4d2fc3682e@github.com>
References: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
 <tIAra5jBQrKyPBbOBCRon-1FPIYM8csax1FKpi48OSk=.ce063463-01b6-4a8e-96a7-ee4d2fc3682e@github.com>
Message-ID: <62dB2wmWPuL46o2eT55Ay7eWHZHBbvTTaSjqycCNgz8=.4598413e-ac11-4775-b332-4c662b9e3637@github.com>

On Sat, 12 Nov 2022 15:23:41 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> With this PR I'd like to make it easier to use dedicated installations of Xcode on Mac OS for OpenJDK builds without having to switch the active Xcode globally via `xcode-select`.
>> 
>> I propose adding a new configure flag `--with-xcode-path` that takes the path to an Xcode installation. If the option is set, this path is expanded to a valid `TOOLCHAIN_PATH`.
>> 
>> Furthermore, I fix detection of xcodebuild and correctly setting the sysroot from the toolchain by moving `AC_SUBST(TOOLCHAIN_PATH)` before calling `BASIC_SETUP_XCODE_SYSROOT` and honoring `TOOLCHAIN_PATH` in BASIC_SETUP_XCODE_SYSROOT in the case when no devkit is specified. As I see it, this is a viable fix, even if not introducing `--with-xcode-path`.
>
> Christoph Langer has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Improve options for xcode toolchain

Thanks for the review, I took over your suggestion. Will integrate shortly.

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

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


From jaroslav.bachorik at datadoghq.com  Wed Nov 16 06:38:42 2022
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Wed, 16 Nov 2022 07:38:42 +0100
Subject: How to use `--with-jib`?
In-Reply-To: <52485dc2-0036-5e84-f54b-ed45cd4699fb@oracle.com>
References: <CAPb8aJ4g-RHi14pqbt2J=WwwLOg36_EJn5A1b=qqzNYLVVkERA@mail.gmail.com>
 <52485dc2-0036-5e84-f54b-ed45cd4699fb@oracle.com>
Message-ID: <CAPb8aJ5kqpkW5uH-7uHxB0jV2y61t7ATH8ZY5_q_e1B3aKOY7A@mail.gmail.com>

Hi Erik,

On Tue 15. 11. 2022 at 19:03, <erik.joelsson at oracle.com> wrote:

> Hello Jaroslav,
>
> Jib is an Oracle internal tool used to manage builds and tests of
> OpenJDK at Oracle. There is no way for us to share that with external
> people unfortunately.


Ah, so it has nothing to do with the Google Jib ?
A bit of unfortunate that Oracle internal implementation detail is a part
of the generic OpenJDK build config :(

-JB-


>
> /Erik
>
> On 11/15/22 08:28, Jaroslav Bachor?k wrote:
> > Hello,
> >
> > I apologize for possibly stupid question - but how can I use the
> > '--with-jib' option?
> > In particular, where can I get the binaries I can point `--with-jib` to?
> >
> > Thanks a bunch!
> >
> > -JB-
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20221116/c2e592d1/attachment.htm>

From jwaters at openjdk.org  Wed Nov 16 07:07:55 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 16 Nov 2022 07:07:55 GMT
Subject: RFR: 8296478: Rework 8282948 and 8282700 to use the new autoconf
 UTIL_ARG_WITH [v2]
In-Reply-To: <WXiInV6g7gltKihp6pg6kd3kVtX9EIB-yX7YQI34LYk=.162eb88a-c4cb-464c-8a26-dd1db571ed99@github.com>
References: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
 <WXiInV6g7gltKihp6pg6kd3kVtX9EIB-yX7YQI34LYk=.162eb88a-c4cb-464c-8a26-dd1db571ed99@github.com>
Message-ID: <DOnS2unjHTadEAkE6nwJPq3tte8hVLIGg-t0ufGTaPc=.02bcefbd-ea0d-4b4e-a8a7-f24794114198@github.com>

On Sat, 12 Nov 2022 16:18:54 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> 8285093 introduced the new UTIL_ARG_WITH definition, which was not available when both 8282948 and 8282700 were written. They can now be moved to using the cleaner logic that UTIL_ARG_WITH grants.
>> 
>> There are many more options that still use AC_ARG_WITH in jdk-version.m4. They are out of the scope of this commit, which aims only to rework the previous integrated commits mentioned above.
>
> 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 two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into util
>  - Squash

Yep, that I've done too. Nothing really interesting I can show for the opposite case, since virtually all of them are errors when passed a --without flag. I'm still going to hold off from integrating until I can figure out what the issue with the --with-vendor-name option is though

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

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


From ihse at openjdk.org  Wed Nov 16 08:31:56 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Nov 2022 08:31:56 GMT
Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed [v4]
In-Reply-To: <OG6PBKDNftaAF-ybH8jebIjEs5qcomgL90FAcuxg5AU=.640a50d1-3617-4c86-8959-491226b5346a@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>
 <OG6PBKDNftaAF-ybH8jebIjEs5qcomgL90FAcuxg5AU=.640a50d1-3617-4c86-8959-491226b5346a@github.com>
Message-ID: <EBoNLji14NTOMbkxq2Ur7yHtoz1JcGDcHi7eKrCjgmY=.7df07f07-63c3-42b0-9cff-d4b509d49109@github.com>

On Tue, 18 Oct 2022 15:21:58 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> 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

@chhagedorn Are you waiting for an additional Hotspot review?

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

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


From shade at openjdk.org  Wed Nov 16 08:32:02 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 16 Nov 2022 08:32:02 GMT
Subject: RFR: 8294591: Fix cast-function-type warning in TemplateTable [v6]
In-Reply-To: <YFUqNAFHWeIeZjced_rpvGUTPuEr0vnWkSgcyyB7kL4=.c89e3fb4-5122-4ed3-88c2-7215ce3a6620@github.com>
References: <F9kScSH8YZ9kK8XAcl5pPPE6sPrHCBUc_zNriSaP8EU=.d5c7452c-72ed-4f41-9dea-5bd8a7fccbc0@github.com>
 <YFUqNAFHWeIeZjced_rpvGUTPuEr0vnWkSgcyyB7kL4=.c89e3fb4-5122-4ed3-88c2-7215ce3a6620@github.com>
Message-ID: <4zL45U4twO112SLW6jqQJyRWlhAmYI7HUB1EhIKl7UQ=.1da3aac9-6118-4a23-a47f-550cdc20b530@github.com>

On Tue, 15 Nov 2022 14:26:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> 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 six commits:
> 
>  - Merge branch 'master' into JDK-8294591-warning-cast-function-type-templatetable
>  - Merge branch 'master' into JDK-8294591-warning-cast-function-type-templatetable
>  - Fix build failures
>  - Merge branch 'master' into JDK-8294591-warning-cast-function-type-templatetable
>  - Also disable warnings in gtests
>  - Fix

Remerged, retested. Unless there are other comments, I'll integrate this.

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

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


From chagedorn at openjdk.org  Wed Nov 16 08:51:04 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 16 Nov 2022 08:51: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: <ZOj-Cb86tjWGXWJK8AQx4EB81bcerOGONb4P6vkPZkw=.0fb827e5-8c50-4174-a0fd-4f1142b8d4f2@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

Yes, I think it would be good to get a second review of the DWARF parser changes. Maybe @tstuefe?

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

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


From stuefe at openjdk.org  Wed Nov 16 08:51:04 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 16 Nov 2022 08:51:04 GMT
Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed [v4]
In-Reply-To: <ZOj-Cb86tjWGXWJK8AQx4EB81bcerOGONb4P6vkPZkw=.0fb827e5-8c50-4174-a0fd-4f1142b8d4f2@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>
 <ZOj-Cb86tjWGXWJK8AQx4EB81bcerOGONb4P6vkPZkw=.0fb827e5-8c50-4174-a0fd-4f1142b8d4f2@github.com>
Message-ID: <ofIMTnRPIIqTzVGjaaaBedoelHOGrD3aKbEi79M7RT8=.655c1544-0c68-4c21-90e1-38c276bb731e@github.com>

On Wed, 16 Nov 2022 08:46:15 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> Yes, I think it would be good to get a second review of the DWARF parser changes. Maybe @tstuefe?

I'm a bit swamped, but try to take a look later today.

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

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


From chagedorn at openjdk.org  Wed Nov 16 09:07:07 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 16 Nov 2022 09:07: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: <KsZ_zoL91I2XpA4CGT5-wtuPi4CYfFn3LlAPWOpAOrM=.8a304e68-1e28-4f3c-b0b8-4a24377a1bab@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

Thank you Thomas! Take your time, there is no hurry.

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

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


From stefank at openjdk.org  Wed Nov 16 11:05:59 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 16 Nov 2022 11:05:59 GMT
Subject: RFR: 8296926: Sort include lines of files in the include/
 directory [v4]
In-Reply-To: <tl8LtRfG6_BUCdNMucC4JCSbjv_-yFP46CXbqYnvNxs=.cba35dd6-f1ee-41bf-aa87-9381cc064bf6@github.com>
References: <tl8LtRfG6_BUCdNMucC4JCSbjv_-yFP46CXbqYnvNxs=.cba35dd6-f1ee-41bf-aa87-9381cc064bf6@github.com>
Message-ID: <Ui-S20RkgTtaXg8YyowdihZ7MAxV8yTEidms18YpKUQ=.adc86da6-1326-448d-ad8e-73be100a6d14@github.com>

> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share, just like the other platform-independent headers in HotSpot
 .
> 
> This RFE splits out the 'include/' changes from #11108 / JDK-8296886, so that those changes can be discussed separately.

Stefan Karlsson 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 five additional commits since the last revision:

 - Remove include/ from test/hotspot files
 - Merge remote-tracking branch 'upstream/master' into 8296926_proper_include_lines_for_include_dir_files
 - Revert make file changes
 - Remove include/ from includes
 - 8296926: Use proper include lines for files in include/

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11133/files
  - new: https://git.openjdk.org/jdk/pull/11133/files/92cba2ea..e9b7a5c4

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

  Stats: 4236 lines in 147 files changed: 2626 ins; 894 del; 716 mod
  Patch: https://git.openjdk.org/jdk/pull/11133.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11133/head:pull/11133

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


From lkorinth at openjdk.org  Wed Nov 16 11:06:00 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 16 Nov 2022 11:06:00 GMT
Subject: RFR: 8296926: Sort include lines of files in the include/
 directory [v4]
In-Reply-To: <Ui-S20RkgTtaXg8YyowdihZ7MAxV8yTEidms18YpKUQ=.adc86da6-1326-448d-ad8e-73be100a6d14@github.com>
References: <tl8LtRfG6_BUCdNMucC4JCSbjv_-yFP46CXbqYnvNxs=.cba35dd6-f1ee-41bf-aa87-9381cc064bf6@github.com>
 <Ui-S20RkgTtaXg8YyowdihZ7MAxV8yTEidms18YpKUQ=.adc86da6-1326-448d-ad8e-73be100a6d14@github.com>
Message-ID: <kXbjbISue3PCTpnD1eAs31EE4M8JGm7DhMRZkY5IOvA=.38a460fa-ac33-473f-89f9-e8dab2382b64@github.com>

On Wed, 16 Nov 2022 11:02:19 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share, just like the other platform-independent headers in HotSpo
 t.
>> 
>> This RFE splits out the 'include/' changes from #11108 / JDK-8296886, so that those changes can be discussed separately.
>
> Stefan Karlsson 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 five additional commits since the last revision:
> 
>  - Remove include/ from test/hotspot files
>  - Merge remote-tracking branch 'upstream/master' into 8296926_proper_include_lines_for_include_dir_files
>  - Revert make file changes
>  - Remove include/ from includes
>  - 8296926: Use proper include lines for files in include/

Although I prefer the original solution with path, I think the current version is also a good improvement. Approved. Thanks for fixing this!

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

Marked as reviewed by lkorinth (Reviewer).

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


From aph at openjdk.org  Wed Nov 16 11:06:46 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 16 Nov 2022 11:06:46 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v7]
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <y8PbnEuueI86HzraVE8471Mk_n6fqi5oAjJ7p-Oa8nc=.ae1c3ebd-8721-40a7-b31e-87746e267e4e@github.com>

> JEP 429 implementation.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Update src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java
  
  Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10952/files
  - new: https://git.openjdk.org/jdk/pull/10952/files/e1063d7b..1bd9d47a

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

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

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


From aph at openjdk.org  Wed Nov 16 11:06:47 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 16 Nov 2022 11:06:47 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v6]
In-Reply-To: <5hAVImQZUFPiE99N8uZ5KC7YUGHEkYglmftttBxZln4=.d469624e-5ddc-4c13-bc64-ed0c73ceb5a2@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <rFpWIyEO_DC9u3gyaxwlC3nK0gdo_2gGlX9bgNZvtZE=.2eec08c4-0a50-4f81-b4c9-45eba639f941@github.com>
 <nK7KFzzYywjKGp2TTJF1ALF4yQdkN0HC1ja2wtZTSRc=.ef43617b-9781-44cf-b3d1-7ad951ec598a@github.com>
 <5hAVImQZUFPiE99N8uZ5KC7YUGHEkYglmftttBxZln4=.d469624e-5ddc-4c13-bc64-ed0c73ceb5a2@github.com>
Message-ID: <KZP5SV2QP7DmleReNRTHuXGWnXOI8ui-keo8bE5HevA=.76c59d85-6f9d-42ee-9f87-a6f21bb6fee8@github.com>

On Tue, 15 Nov 2022 20:11:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I'd prefer to keep this as is because it's too much to use "threads" or mention inheritance in the first paragraph.

I agree.

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

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


From aph at openjdk.org  Wed Nov 16 11:06:51 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 16 Nov 2022 11:06:51 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v6]
In-Reply-To: <nK7KFzzYywjKGp2TTJF1ALF4yQdkN0HC1ja2wtZTSRc=.ef43617b-9781-44cf-b3d1-7ad951ec598a@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <rFpWIyEO_DC9u3gyaxwlC3nK0gdo_2gGlX9bgNZvtZE=.2eec08c4-0a50-4f81-b4c9-45eba639f941@github.com>
 <nK7KFzzYywjKGp2TTJF1ALF4yQdkN0HC1ja2wtZTSRc=.ef43617b-9781-44cf-b3d1-7ad951ec598a@github.com>
Message-ID: <gvyVzC0NPYwWrx_xHSNugz9DDryV-XAbMwFuzQgpIJE=.b1d10622-d1c9-4e21-8d05-4ada5cf605ec@github.com>

On Tue, 15 Nov 2022 18:35:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix failing serviceability tests
>
> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 172:
> 
>> 170:  * must be an integer power of 2.
>> 171:  *
>> 172:  * <p>For example, you could use {@code -Djdk.incubator.concurrent.ScopedValue.cacheSize=8}.
> 
> I would also avoid "you" and "we" in the javadoc. While javadoc is not formal, we often use locutions such as "clients can use/do XYZ".

OK, it's a style thing. Wilco.

> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 185:
> 
>> 183:  * would have to be regenerated after a blocking operation.
>> 184:  *
>> 185:  * @param <T> the type of the value
> 
> Suggestion:
> 
>  * @param <T> the type of the scoped value

Mm, but this is the type of the value of the `ScopedValue` instance.
So, the type of the scoped value is `ScopedValue<T>`, the type of the value is `T`, is it not?

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

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


From aph at openjdk.org  Wed Nov 16 11:06:51 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 16 Nov 2022 11:06:51 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v6]
In-Reply-To: <CRejKgLiOJHhFPCEfxGBnnNGZiFhES4Ac9Dqtgq2VWY=.12932aae-9015-4452-9a7c-4c59b1981495@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <rFpWIyEO_DC9u3gyaxwlC3nK0gdo_2gGlX9bgNZvtZE=.2eec08c4-0a50-4f81-b4c9-45eba639f941@github.com>
 <nK7KFzzYywjKGp2TTJF1ALF4yQdkN0HC1ja2wtZTSRc=.ef43617b-9781-44cf-b3d1-7ad951ec598a@github.com>
 <XEqyhW1QAJKrizAC-gOblrN7Pa1F_f2C8I5XO9RJqBM=.bc08c201-9382-43a6-a68b-b809028524a8@github.com>
 <CRejKgLiOJHhFPCEfxGBnnNGZiFhES4Ac9Dqtgq2VWY=.12932aae-9015-4452-9a7c-4c59b1981495@github.com>
Message-ID: <b96D_PGxmI4uKC9L9GBappJWwfZS_ken4e7ho3HCoA4=.5b5db3c9-316d-46a9-9e7f-3f85ff46d73b@github.com>

On Tue, 15 Nov 2022 21:28:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This comment is on orElse but I suspect you are suggesting that get() be changed to return Optional. I think we'll need to get more feedback/usage of this API before re-visiting that.
>
> Yes, my comment was really on `get` - that said, I note that saying get().get() would look odd (but maybe finding some other name for `ScopedValue::get`, such as `find` might work)

It certainly would look odd. This API is, by design, as lightweight as it possibly can be, both from an implementation and a user's point of view. It's also intended to be as close as possible to an "invisible" parameter passed to all callees. From that point of view, `get()` is a wart. `get().get()` is just...

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

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


From mcimadamore at openjdk.org  Wed Nov 16 11:45:41 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 16 Nov 2022 11:45:41 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v6]
In-Reply-To: <gvyVzC0NPYwWrx_xHSNugz9DDryV-XAbMwFuzQgpIJE=.b1d10622-d1c9-4e21-8d05-4ada5cf605ec@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <rFpWIyEO_DC9u3gyaxwlC3nK0gdo_2gGlX9bgNZvtZE=.2eec08c4-0a50-4f81-b4c9-45eba639f941@github.com>
 <nK7KFzzYywjKGp2TTJF1ALF4yQdkN0HC1ja2wtZTSRc=.ef43617b-9781-44cf-b3d1-7ad951ec598a@github.com>
 <gvyVzC0NPYwWrx_xHSNugz9DDryV-XAbMwFuzQgpIJE=.b1d10622-d1c9-4e21-8d05-4ada5cf605ec@github.com>
Message-ID: <rbjUHcMTBVqqmi0KImuzs0jVOp94PBFVxvsRsv1_0Iw=.89564d70-23c9-4c6a-9cfd-38f2af702b88@github.com>

On Wed, 16 Nov 2022 10:57:49 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 185:
>> 
>>> 183:  * would have to be regenerated after a blocking operation.
>>> 184:  *
>>> 185:  * @param <T> the type of the value
>> 
>> Suggestion:
>> 
>>  * @param <T> the type of the scoped value
>
> Mm, but this is the type of the value of the `ScopedValue` instance.
> So, the type of the scoped value is `ScopedValue<T>`, the type of the value is `T`, is it not?

Right - there's "scoped value" which is the holder, and "value of the scoped value" which is what has the type T. You are correct that just dropping "scoped" in there doesn't make things better. Conversely, just leaving "value" and nothing else (as per PR) is ambiguous. It feels like we need some way (uniform throughout the javadoc) to speak about "the value associated to a scoped value instance".

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

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


From mcimadamore at openjdk.org  Wed Nov 16 11:45:43 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 16 Nov 2022 11:45:43 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v6]
In-Reply-To: <b96D_PGxmI4uKC9L9GBappJWwfZS_ken4e7ho3HCoA4=.5b5db3c9-316d-46a9-9e7f-3f85ff46d73b@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <rFpWIyEO_DC9u3gyaxwlC3nK0gdo_2gGlX9bgNZvtZE=.2eec08c4-0a50-4f81-b4c9-45eba639f941@github.com>
 <nK7KFzzYywjKGp2TTJF1ALF4yQdkN0HC1ja2wtZTSRc=.ef43617b-9781-44cf-b3d1-7ad951ec598a@github.com>
 <XEqyhW1QAJKrizAC-gOblrN7Pa1F_f2C8I5XO9RJqBM=.bc08c201-9382-43a6-a68b-b809028524a8@github.com>
 <CRejKgLiOJHhFPCEfxGBnnNGZiFhES4Ac9Dqtgq2VWY=.12932aae-9015-4452-9a7c-4c59b1981495@github.com>
 <b96D_PGxmI4uKC9L9GBappJWwfZS_ken4e7ho3HCoA4=.5b5db3c9-316d-46a9-9e7f-3f85ff46d73b@github.com>
Message-ID: <8Gol6phltQIqgGpXbVDn_iUDtqyRm8NKy_U63w2oQ8g=.ba7a834d-bb03-4a20-ae69-4371068f1439@github.com>

On Wed, 16 Nov 2022 11:03:07 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Yes, my comment was really on `get` - that said, I note that saying get().get() would look odd (but maybe finding some other name for `ScopedValue::get`, such as `find` might work)
>
> It certainly would look odd. This API is, by design, as lightweight as it possibly can be, both from an implementation and a user's point of view. It's also intended to be as close as possible to an "invisible" parameter passed to all callees. From that point of view, `get()` is a wart. `get().get()` is just...

IMHO there are ways to have the cake and eat it too. That is, we could have a couple of overloads:


T get() { ... } // throws NSME if not found
Optional<T> find() // returns empty optional if not found


Then, for simple use cases, code will stay the same as today. But, if users want to deal with optionality explicitly, they can call `find` and then call `orElse`, `map` or whatever they like.

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

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


From alanb at openjdk.org  Wed Nov 16 12:04:00 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Nov 2022 12:04:00 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v6]
In-Reply-To: <8Gol6phltQIqgGpXbVDn_iUDtqyRm8NKy_U63w2oQ8g=.ba7a834d-bb03-4a20-ae69-4371068f1439@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <rFpWIyEO_DC9u3gyaxwlC3nK0gdo_2gGlX9bgNZvtZE=.2eec08c4-0a50-4f81-b4c9-45eba639f941@github.com>
 <nK7KFzzYywjKGp2TTJF1ALF4yQdkN0HC1ja2wtZTSRc=.ef43617b-9781-44cf-b3d1-7ad951ec598a@github.com>
 <XEqyhW1QAJKrizAC-gOblrN7Pa1F_f2C8I5XO9RJqBM=.bc08c201-9382-43a6-a68b-b809028524a8@github.com>
 <CRejKgLiOJHhFPCEfxGBnnNGZiFhES4Ac9Dqtgq2VWY=.12932aae-9015-4452-9a7c-4c59b1981495@github.com>
 <b96D_PGxmI4uKC9L9GBappJWwfZS_ken4e7ho3HCoA4=.5b5db3c9-316d-46a9-9e7f-3f85ff46d73b@github.com>
 <8Gol6phltQIqgGpXbVDn_iUDtqyRm8NKy_U63w2oQ8g=.ba7a834d-bb03-4a20-ae69-4371068f1439@github.com>
Message-ID: <xviMqszPHdP7wFjNGMk5u5o81rC-KK8GWRQQwAA642E=.306213e0-8b8b-4f96-9ee3-f7eac92015b4@github.com>

On Wed, 16 Nov 2022 11:41:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> It certainly would look odd. This API is, by design, as lightweight as it possibly can be, both from an implementation and a user's point of view. It's also intended to be as close as possible to an "invisible" parameter passed to all callees. From that point of view, `get()` is a wart. `get().get()` is just...
>
> IMHO there are ways to have the cake and eat it too. That is, we could have a couple of overloads:
> 
> 
> T get() { ... } // throws NSME if not found
> Optional<T> find() // returns empty optional if not found
> 
> 
> Then, for simple use cases, code will stay the same as today. But, if users want to deal with optionality explicitly, they can call `find` and then call `orElse`, `map` or whatever they like.

We expect isBound() will be used a lot and I think that is clearer (and cheaper) than find().isEmpty(). 

Time will tell on orElse/orElseThrow and whether they should be replaced with an Optional view. That is, I think your comments mostly apply to those two methods rather than get/isBound.

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

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


From mcimadamore at openjdk.org  Wed Nov 16 12:14:14 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 16 Nov 2022 12:14:14 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v6]
In-Reply-To: <xviMqszPHdP7wFjNGMk5u5o81rC-KK8GWRQQwAA642E=.306213e0-8b8b-4f96-9ee3-f7eac92015b4@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <rFpWIyEO_DC9u3gyaxwlC3nK0gdo_2gGlX9bgNZvtZE=.2eec08c4-0a50-4f81-b4c9-45eba639f941@github.com>
 <nK7KFzzYywjKGp2TTJF1ALF4yQdkN0HC1ja2wtZTSRc=.ef43617b-9781-44cf-b3d1-7ad951ec598a@github.com>
 <XEqyhW1QAJKrizAC-gOblrN7Pa1F_f2C8I5XO9RJqBM=.bc08c201-9382-43a6-a68b-b809028524a8@github.com>
 <CRejKgLiOJHhFPCEfxGBnnNGZiFhES4Ac9Dqtgq2VWY=.12932aae-9015-4452-9a7c-4c59b1981495@github.com>
 <b96D_PGxmI4uKC9L9GBappJWwfZS_ken4e7ho3HCoA4=.5b5db3c9-316d-46a9-9e7f-3f85ff46d73b@github.com>
 <8Gol6phltQIqgGpXbVDn_iUDtqyRm8NKy_U63w2oQ8g=.ba7a834d-bb03-4a20-ae69-4371068f1439@github.com>
 <xviMqszPHdP7wFjNGMk5u5o81rC-KK8GWRQQwAA642E=.306213e0-8b8b-4f96-9ee3-f7eac92015b4@github.com>
Message-ID: <A9xOoYTgicpAXaATLn1jLW1X0pP7ZlDRh0ISp9E1H3M=.7ee59a3e-5e66-43a0-89b2-fcfa4674b449@github.com>

On Wed, 16 Nov 2022 12:01:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> IMHO there are ways to have the cake and eat it too. That is, we could have a couple of overloads:
>> 
>> 
>> T get() { ... } // throws NSME if not found
>> Optional<T> find() // returns empty optional if not found
>> 
>> 
>> Then, for simple use cases, code will stay the same as today. But, if users want to deal with optionality explicitly, they can call `find` and then call `orElse`, `map` or whatever they like.
>
> We expect isBound() will be used a lot and I think that is clearer (and cheaper) than find().isEmpty(). 
> 
> Time will tell on orElse/orElseThrow and whether they should be replaced with an Optional view. That is, I think your comments mostly apply to those two methods rather than get/isBound.

Note that `isBound` can also be explained as just a shorcut for `find().isEmpty()`. That is, I'm not really suggesting to drop sugary methods from the API. But by exposing the optional nature of the result, the API might end up being more composable.

But, as you said, we don't have to decide now.

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

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


From stuefe at openjdk.org  Wed Nov 16 12:29:17 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 16 Nov 2022 12:29:17 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: <3CD6ryhzVPUpiJTkeepDevEr96HfvCkLdCR2AzmxqoA=.db139ad6-cbb6-4791-a6d1-4d28e54fdcd1@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

Changes requested by stuefe (Reviewer).

src/hotspot/share/utilities/elfFile.cpp line 1605:

> 1603:   uint32_t current_index = 1; // file_names start at index 1
> 1604:   const size_t dwarf_filename_len = 1024;
> 1605:   char dwarf_filename[dwarf_filename_len]; // Store the filename read from DWARF which is then copied to 'filename'.

Putting such a large array on the stack is a bit borderline. Especially in error reporting, where you may build up stack repeatedly via secondary crash handling. I realize though that no good alternatives exist. C-heap may be corrupted, ResourceArea is also out of the question. Could we get away with using filename directly?

src/hotspot/share/utilities/elfFile.cpp line 1636:

> 1634:   char* last_slash = strrchr(filename, *os::file_separator());
> 1635:   if (last_slash != nullptr) {
> 1636:     uint16_t index_after_slash = (uint16_t)(last_slash + 1 - filename);

Why uint16_t? 

We have `pointer_delta()` for that btw if you want to be super correct. See globalDefinitions.hpp

src/hotspot/share/utilities/elfFile.cpp line 1638:

> 1636:     uint16_t index_after_slash = (uint16_t)(last_slash + 1 - filename);
> 1637:     // Copy filename to beginning of buffer.
> 1638:     int bytes_written = jio_snprintf(filename, filename_len - index_after_slash, "%s", filename + index_after_slash);

I don't think this is guaranteed to work since the memory areas you move may interleave. You should copy char-wise, or use `memmove(3)`.

src/hotspot/share/utilities/elfFile.cpp line 1651:

> 1649:   int bytes_written = jio_snprintf(dst, count, "%s", src);
> 1650:   // Add null terminator.
> 1651:   dst[count - 1] = '\0';

Does it make sense to return a truncated file name up to the caller of `DwarfFile::LineNumberProgram::get_filename_from_header()`? Will this not just confuse him? I think it makes more sense to cleanly handle truncation, and e.g. skip file parsing for dwarf files with too long names.

src/hotspot/share/utilities/elfFile.hpp line 865:

> 863:     bool get_filename_from_header(uint32_t file_index, char* filename, size_t filename_len);
> 864:     static void strip_path_prefix(char* filename, const size_t filename_len);
> 865:     static void copy_dwarf_filename_to_filename(char* src, size_t src_len, char* dst, size_t dst_len);

Stupid question, do these have to be exposed? Or could they be just static helpers in elfFile.cpp?

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

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


From duke at openjdk.org  Wed Nov 16 12:52:10 2022
From: duke at openjdk.org (ExE Boss)
Date: Wed, 16 Nov 2022 12:52:10 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v6]
In-Reply-To: <A9xOoYTgicpAXaATLn1jLW1X0pP7ZlDRh0ISp9E1H3M=.7ee59a3e-5e66-43a0-89b2-fcfa4674b449@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <rFpWIyEO_DC9u3gyaxwlC3nK0gdo_2gGlX9bgNZvtZE=.2eec08c4-0a50-4f81-b4c9-45eba639f941@github.com>
 <nK7KFzzYywjKGp2TTJF1ALF4yQdkN0HC1ja2wtZTSRc=.ef43617b-9781-44cf-b3d1-7ad951ec598a@github.com>
 <XEqyhW1QAJKrizAC-gOblrN7Pa1F_f2C8I5XO9RJqBM=.bc08c201-9382-43a6-a68b-b809028524a8@github.com>
 <CRejKgLiOJHhFPCEfxGBnnNGZiFhES4Ac9Dqtgq2VWY=.12932aae-9015-4452-9a7c-4c59b1981495@github.com>
 <b96D_PGxmI4uKC9L9GBappJWwfZS_ken4e7ho3HCoA4=.5b5db3c9-316d-46a9-9e7f-3f85ff46d73b@github.com>
 <8Gol6phltQIqgGpXbVDn_iUDtqyRm8NKy_U63w2oQ8g=.ba7a834d-bb03-4a20-ae69-4371068f1439@github.com>
 <xviMqszPHdP7wFjNGMk5u5o81rC-KK8GWRQQwAA642E=.306213e0-8b8b-4f96-9ee3-f7eac92015b4@github.com>
 <A9xOoYTgicpAXaATLn1jLW1X0pP7ZlDRh0ISp9E1H3M=.7ee59a3e-5e66-43a0-89b2-fcfa4674b449@github.com>
Message-ID: <okStohonRqnvGd9Sx3M4vIfuwrDfZW-9bHUQn-BrtKk=.8c8f166d-025a-43b9-88d7-6e7882ac1394@github.com>

On Wed, 16 Nov 2022 12:11:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> We expect isBound() will be used a lot and I think that is clearer (and cheaper) than find().isEmpty(). 
>> 
>> Time will tell on orElse/orElseThrow and whether they should be replaced with an Optional view. That is, I think your comments mostly apply to those two methods rather than get/isBound.
>
> Note that `isBound` can also be explained as just a shorcut for `find().isEmpty()`. That is, I'm not really suggesting to drop sugary methods from the API. But by exposing the optional nature of the result, the API might end up being more composable.
> 
> But, as you said, we don't have to decide now.

Note?that `ScopedValue` can?currently be?bound to?`null`, but?by?using `Optional`, there?would be?no?way to?differentiate an?unbound `ScopedValue` from?one bound?to?`null`.

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

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


From stefank at openjdk.org  Wed Nov 16 12:52:55 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 16 Nov 2022 12:52:55 GMT
Subject: RFR: 8296926: Sort include lines of files in the include/
 directory [v4]
In-Reply-To: <Ui-S20RkgTtaXg8YyowdihZ7MAxV8yTEidms18YpKUQ=.adc86da6-1326-448d-ad8e-73be100a6d14@github.com>
References: <tl8LtRfG6_BUCdNMucC4JCSbjv_-yFP46CXbqYnvNxs=.cba35dd6-f1ee-41bf-aa87-9381cc064bf6@github.com>
 <Ui-S20RkgTtaXg8YyowdihZ7MAxV8yTEidms18YpKUQ=.adc86da6-1326-448d-ad8e-73be100a6d14@github.com>
Message-ID: <0QivfI9yo0RhJYISYtMy3GXN9KY_YlX0GKyLaMalT3E=.d92f4faf-0c02-416d-9840-73d6826d5ad4@github.com>

On Wed, 16 Nov 2022 11:05:59 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share, just like the other platform-independent headers in HotSpo
 t.
>> 
>> This RFE splits out the 'include/' changes from #11108 / JDK-8296886, so that those changes can be discussed separately.
>
> Stefan Karlsson 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 five additional commits since the last revision:
> 
>  - Remove include/ from test/hotspot files
>  - Merge remote-tracking branch 'upstream/master' into 8296926_proper_include_lines_for_include_dir_files
>  - Revert make file changes
>  - Remove include/ from includes
>  - 8296926: Use proper include lines for files in include/

Thanks for the reviews and discussions.

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

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


From stefank at openjdk.org  Wed Nov 16 12:54:40 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 16 Nov 2022 12:54:40 GMT
Subject: Integrated: 8296926: Sort include lines of files in the include/
 directory
In-Reply-To: <tl8LtRfG6_BUCdNMucC4JCSbjv_-yFP46CXbqYnvNxs=.cba35dd6-f1ee-41bf-aa87-9381cc064bf6@github.com>
References: <tl8LtRfG6_BUCdNMucC4JCSbjv_-yFP46CXbqYnvNxs=.cba35dd6-f1ee-41bf-aa87-9381cc064bf6@github.com>
Message-ID: <WaXoihwHebbvEEytUbV4-E6YWt5vZ0XOQZKBZl-B49Y=.d7181ee2-8a1d-4498-a081-9fe35a57459b@github.com>

On Mon, 14 Nov 2022 09:25:11 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share, just like the other platform-independent headers in HotSpot
 .
> 
> This RFE splits out the 'include/' changes from #11108 / JDK-8296886, so that those changes can be discussed separately.

This pull request has now been integrated.

Changeset: 813b223a
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/813b223a6bcd9f6290ee9c8840a8c69061ade48c
Stats:     231 lines in 113 files changed: 111 ins; 117 del; 3 mod

8296926: Sort include lines of files in the include/ directory

Reviewed-by: kbarrett, erikj, lkorinth

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

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


From alanb at openjdk.org  Wed Nov 16 13:16:09 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Nov 2022 13:16:09 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v6]
In-Reply-To: <okStohonRqnvGd9Sx3M4vIfuwrDfZW-9bHUQn-BrtKk=.8c8f166d-025a-43b9-88d7-6e7882ac1394@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <rFpWIyEO_DC9u3gyaxwlC3nK0gdo_2gGlX9bgNZvtZE=.2eec08c4-0a50-4f81-b4c9-45eba639f941@github.com>
 <nK7KFzzYywjKGp2TTJF1ALF4yQdkN0HC1ja2wtZTSRc=.ef43617b-9781-44cf-b3d1-7ad951ec598a@github.com>
 <XEqyhW1QAJKrizAC-gOblrN7Pa1F_f2C8I5XO9RJqBM=.bc08c201-9382-43a6-a68b-b809028524a8@github.com>
 <CRejKgLiOJHhFPCEfxGBnnNGZiFhES4Ac9Dqtgq2VWY=.12932aae-9015-4452-9a7c-4c59b1981495@github.com>
 <b96D_PGxmI4uKC9L9GBappJWwfZS_ken4e7ho3HCoA4=.5b5db3c9-316d-46a9-9e7f-3f85ff46d73b@github.com>
 <8Gol6phltQIqgGpXbVDn_iUDtqyRm8NKy_U63w2oQ8g=.ba7a834d-bb03-4a20-ae69-4371068f1439@github.com>
 <xviMqszPHdP7wFjNGMk5u5o81rC-KK8GWRQQwAA642E=.306213e0-8b8b-4f96-9ee3-f7eac92015b4@github.com>
 <A9xOoYTgicpAXaATLn1jLW1X0pP7ZlDRh0ISp9E1H3M=.7ee59a3e-5e66-43a0-89b2-fcfa4674b449@github.com>
 <okStohonRqnvGd9Sx3M4vIfuwrDfZW-9bHUQn-BrtKk=.8c8f166d-025a-43b9-88d7-6e7882ac1394@github.com>
Message-ID: <VQfLGLzs4-yMjO1eZMm-rku-Ti63OETdzNtRnaberMs=.8e95e70e-114d-4920-bb31-d3e8f72c502d@github.com>

On Wed, 16 Nov 2022 12:50:04 GMT, ExE Boss <duke at openjdk.org> wrote:

> Note?that `ScopedValue` can?currently be?bound to?`null`, but?by?using `Optional`, there?would be?no?way to?differentiate an?unbound `ScopedValue` from?one bound?to?`null`.

That's right, an Optional view would have to deal with that.

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

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


From ihse at openjdk.org  Wed Nov 16 13:31:09 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Nov 2022 13:31:09 GMT
Subject: RFR: 8297041: Remove the last remnants of sjavac
Message-ID: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>

The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc.

Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code.

This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place.

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

Commit messages:
 - Update copyright year for javac server files
 - One more sjavac reference in test
 - Remove last references to sjavac
 - Move compilation of javac server to interim langtools
 - Update package in compilation as well
 - Remove or rename remaining references to sjavac
 - Change package name to javacserver
 - Clean up Options
 - Move javac server to buildtools
 - Cut last ties to javac internals...
 - ... and 4 more: https://git.openjdk.org/jdk/compare/d0fae43e...2124c86b

Changes: https://git.openjdk.org/jdk/pull/11185/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11185&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297041
  Stats: 12695 lines in 118 files changed: 1058 ins; 11574 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/11185.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11185/head:pull/11185

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


From ihse at openjdk.org  Wed Nov 16 13:35:04 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Nov 2022 13:35:04 GMT
Subject: RFR: 8297041: Remove the last remnants of sjavac
In-Reply-To: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
Message-ID: <JUaz8z0HCWb7nesWL6TwnlvTHjgxjoTTAvkbf-HxF6A=.181317f5-8b0b-4f6e-9fd9-e31da5d4b7c8@github.com>

On Wed, 16 Nov 2022 13:22:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc.
> 
> Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code.
> 
> This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place.

Some more detailed explanations of the changes I've made in this patch.

* I have stripped down the original sjavac code to retain only the "javac server" part, and associated machinery. In some cases it can probably be possible to cut out even more baggage, but I had to draw the line somewhere.
* The remaining sjavac code has moved to `make/langtools/tools`, together with the other langtools buildtools.
* All sjavac jtreg tests in langtools has been removed.
* A few non-sjavac-related tests (for AppCDS) references sjavac. My interpretation is that these classes were just picked arbitrarily as a good representation, so I have modified these tests to pick other, arbitrary classes. (I'd like to have some input from AppCDS folks that I did this correctly)
* I have verified that it is still possible to build with, and without, the javac server, and that there has been no build performance regressions.
* The original implementation used a class internal to the `jdk.compiler` module to actually kick off the javac compilation. This was no longer an option when moving out of the module, but fortunately there is actually an exported class that does the same, `com.sun.tools.javac.Main`. This is however deprecated, and I realize it is not ideal to introduce a dependency to a deprecated class (but see below).

On a longer term, the current javac server tool is under scrutiny, and it will probably be rewritten into a more general "portal" to run other langtools binaries such as javadoc. It will also be transformed into using the ToolProvider API, which will solve the problem of calling the deprecated method. @sormuras is working on this.

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

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


From cstein at openjdk.org  Wed Nov 16 13:52:59 2022
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 16 Nov 2022 13:52:59 GMT
Subject: RFR: 8297041: Remove the last remnants of sjavac
In-Reply-To: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
Message-ID: <8lxHo8-YXCouOHXWzh4_dzhNRsXXCztN1QETwKe7hlQ=.83d75077-4b11-4d0e-acdc-f2784fd2d634@github.com>

On Wed, 16 Nov 2022 13:22:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc.
> 
> Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code.
> 
> This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place.

LGTM

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

Marked as reviewed by cstein (Committer).

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


From erikj at openjdk.org  Wed Nov 16 14:10:04 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 16 Nov 2022 14:10:04 GMT
Subject: RFR: 8297041: Remove the last remnants of sjavac
In-Reply-To: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
Message-ID: <ObrdH4mmNt3fqgNS9EKPSAfECovk9LWLnClLzhk9YyA=.25420186-ae1f-4339-92b9-ba268a78d36a@github.com>

On Wed, 16 Nov 2022 13:22:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc.
> 
> Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code.
> 
> This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place.

Would it be worth keeping the relevant tests around in a separate test root for buildtools, given that this buildtool is rather big and complex? Or is the replacement so imminent that it's not worth the effort?

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

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


From aph at openjdk.org  Wed Nov 16 14:13:29 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 16 Nov 2022 14:13:29 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v8]
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <16r2j-OSTNYGEK74xtcCK4RxnFxJ1fztEjSy5uYZ8EY=.9aab72c6-3aa9-4621-bcfc-b1298c83e69d@github.com>

> JEP 429 implementation.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Update src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java
  
  Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10952/files
  - new: https://git.openjdk.org/jdk/pull/10952/files/1bd9d47a..222ddcbc

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

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

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


From cstein at openjdk.org  Wed Nov 16 14:14:59 2022
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 16 Nov 2022 14:14:59 GMT
Subject: RFR: 8297041: Remove the last remnants of sjavac
In-Reply-To: <ObrdH4mmNt3fqgNS9EKPSAfECovk9LWLnClLzhk9YyA=.25420186-ae1f-4339-92b9-ba268a78d36a@github.com>
References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
 <ObrdH4mmNt3fqgNS9EKPSAfECovk9LWLnClLzhk9YyA=.25420186-ae1f-4339-92b9-ba268a78d36a@github.com>
Message-ID: <SAaDNvVSjC3bQD5vvTnY68j93lCkvUZjKJ6dNYyGTrg=.b12dcc25-ca84-4ea1-b7ca-7a26edb6f8a0@github.com>

On Wed, 16 Nov 2022 14:06:16 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Or is the replacement so imminent that it's not worth the effort?

This. I aim to replace `javacserver` with a well-tested `javatoolportal` buildtool in the coming months. An almost working POC is already available - but forcing it to go live with the JDK 20 train would not be good and replacing a minimal `javacserver` buildtool is an easier/lighter task.

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

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


From aph at openjdk.org  Wed Nov 16 14:18:01 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 16 Nov 2022 14:18:01 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v9]
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <mHmKVPWC_R7fBUpYFSeJXVrYqS29db3Lx6x4j6-gvW8=.503976ec-428b-4351-9428-9664c17a96e6@github.com>

> JEP 429 implementation.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Oops

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10952/files
  - new: https://git.openjdk.org/jdk/pull/10952/files/222ddcbc..2a2b0cca

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

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

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


From erikj at openjdk.org  Wed Nov 16 14:31:19 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 16 Nov 2022 14:31:19 GMT
Subject: RFR: 8297041: Remove the last remnants of sjavac
In-Reply-To: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
Message-ID: <aCNu8qcj9_G8Zkmrezs-CaLlGP5gdZIsHJ52wXm17Kk=.98e3dc97-bf03-41a6-a832-4cb85ae27f74@github.com>

On Wed, 16 Nov 2022 13:22:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc.
> 
> Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code.
> 
> This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place.

Marked as reviewed by erikj (Reviewer).

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

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


From aph at openjdk.org  Wed Nov 16 15:47:05 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 16 Nov 2022 15:47:05 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v6]
In-Reply-To: <rbjUHcMTBVqqmi0KImuzs0jVOp94PBFVxvsRsv1_0Iw=.89564d70-23c9-4c6a-9cfd-38f2af702b88@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <rFpWIyEO_DC9u3gyaxwlC3nK0gdo_2gGlX9bgNZvtZE=.2eec08c4-0a50-4f81-b4c9-45eba639f941@github.com>
 <nK7KFzzYywjKGp2TTJF1ALF4yQdkN0HC1ja2wtZTSRc=.ef43617b-9781-44cf-b3d1-7ad951ec598a@github.com>
 <gvyVzC0NPYwWrx_xHSNugz9DDryV-XAbMwFuzQgpIJE=.b1d10622-d1c9-4e21-8d05-4ada5cf605ec@github.com>
 <rbjUHcMTBVqqmi0KImuzs0jVOp94PBFVxvsRsv1_0Iw=.89564d70-23c9-4c6a-9cfd-38f2af702b88@github.com>
Message-ID: <F3FOR0XhsuCAvOB5jfKOz3qDcSPZqEIPVJIXT6ZXpYQ=.1f2a45a3-d7ac-4201-a90e-6a88b42c0a8f@github.com>

On Wed, 16 Nov 2022 11:38:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Mm, but this is the type of the value of the `ScopedValue` instance.
>> So, the type of the scoped value is `ScopedValue<T>`, the type of the value is `T`, is it not?
>
> Right - there's "scoped value" which is the holder, and "value of the scoped value" which is what has the type T. You are correct that just dropping "scoped" in there doesn't make things better. Conversely, just leaving "value" and nothing else (as per PR) is ambiguous. It feels like we need some way (uniform throughout the javadoc) to speak about "the value associated to a scoped value instance".

I think that's the "bound value" of the instance or the "value bound to" the `ScopedValue<T>` instance.

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

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


From chagedorn at openjdk.org  Wed Nov 16 15:53:12 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 16 Nov 2022 15:53:12 GMT
Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed [v4]
In-Reply-To: <3CD6ryhzVPUpiJTkeepDevEr96HfvCkLdCR2AzmxqoA=.db139ad6-cbb6-4791-a6d1-4d28e54fdcd1@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>
 <3CD6ryhzVPUpiJTkeepDevEr96HfvCkLdCR2AzmxqoA=.db139ad6-cbb6-4791-a6d1-4d28e54fdcd1@github.com>
Message-ID: <-LPuNwZylHWH7M8ifGeNw27j7T7-kQzbKa4y0H6cHvM=.8ea671b0-980d-4a81-94b6-1ddab48c1fea@github.com>

On Wed, 16 Nov 2022 12:23:50 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> 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
>
> src/hotspot/share/utilities/elfFile.cpp line 1651:
> 
>> 1649:   int bytes_written = jio_snprintf(dst, count, "%s", src);
>> 1650:   // Add null terminator.
>> 1651:   dst[count - 1] = '\0';
> 
> Does it make sense to return a truncated file name up to the caller of `DwarfFile::LineNumberProgram::get_filename_from_header()`? Will this not just confuse him? I think it makes more sense to cleanly handle truncation, and e.g. skip file parsing for dwarf files with too long names.

I think you're right that it's rather unexpected to get an incomplete filename back. But just silently skipping the filename might be confusing as well. We could either print an error (I guess that's useful either way but should only be printed with `TraceDwarfLevel`) or just return a generic "buffer overflow" string as filename instead if it fits into the provided filename buffer. And only if that's not possible we could silently skip the filename. Would that be an option?

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

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


From aph at openjdk.org  Wed Nov 16 16:01:10 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 16 Nov 2022 16:01:10 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v6]
In-Reply-To: <nK7KFzzYywjKGp2TTJF1ALF4yQdkN0HC1ja2wtZTSRc=.ef43617b-9781-44cf-b3d1-7ad951ec598a@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <rFpWIyEO_DC9u3gyaxwlC3nK0gdo_2gGlX9bgNZvtZE=.2eec08c4-0a50-4f81-b4c9-45eba639f941@github.com>
 <nK7KFzzYywjKGp2TTJF1ALF4yQdkN0HC1ja2wtZTSRc=.ef43617b-9781-44cf-b3d1-7ad951ec598a@github.com>
Message-ID: <FHV54avkRj2f7vf-_chBEqAAVP3r-CZpU9PfJlldWmU=.87413912-0826-4d80-8f71-0134ddd2994a@github.com>

On Tue, 15 Nov 2022 19:15:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix failing serviceability tests
>
> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 460:
> 
>> 458:      * }
>> 459:      *
>> 460:      * @param key the ScopedValue key
> 
> should use `@code` or `@link`

Sorry, I don't understand what you want.

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

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


From chagedorn at openjdk.org  Wed Nov 16 16:04:46 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 16 Nov 2022 16:04:46 GMT
Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed [v4]
In-Reply-To: <3CD6ryhzVPUpiJTkeepDevEr96HfvCkLdCR2AzmxqoA=.db139ad6-cbb6-4791-a6d1-4d28e54fdcd1@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>
 <3CD6ryhzVPUpiJTkeepDevEr96HfvCkLdCR2AzmxqoA=.db139ad6-cbb6-4791-a6d1-4d28e54fdcd1@github.com>
Message-ID: <huGJVrBNvoINQMJiajYJhBLeD6LpYFKUreKCmpEaf48=.693210ab-4185-48f8-91ad-ed68b399b416@github.com>

On Wed, 16 Nov 2022 11:59:19 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> 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
>
> src/hotspot/share/utilities/elfFile.cpp line 1605:
> 
>> 1603:   uint32_t current_index = 1; // file_names start at index 1
>> 1604:   const size_t dwarf_filename_len = 1024;
>> 1605:   char dwarf_filename[dwarf_filename_len]; // Store the filename read from DWARF which is then copied to 'filename'.
> 
> Putting such a large array on the stack is a bit borderline. Especially in error reporting, where you may build up stack repeatedly via secondary crash handling. I realize though that no good alternatives exist. C-heap may be corrupted, ResourceArea is also out of the question. Could we get away with using filename directly?

That's true. Maybe I can change the algorithm to read single characters instead and reset the buffer once I'm encountering a file separator. I'll try that out.

> Why uint16_t?

There is no specific reason. I'll change it to `uint32_t`. 
 
> We have `pointer_delta()` for that btw if you want to be super correct. See globalDefinitions.hpp

Ah that's great! Will use that one instead.

> src/hotspot/share/utilities/elfFile.hpp line 865:
> 
>> 863:     bool get_filename_from_header(uint32_t file_index, char* filename, size_t filename_len);
>> 864:     static void strip_path_prefix(char* filename, const size_t filename_len);
>> 865:     static void copy_dwarf_filename_to_filename(char* src, size_t src_len, char* dst, size_t dst_len);
> 
> Stupid question, do these have to be exposed? Or could they be just static helpers in elfFile.cpp?

In theory, they don't need to be exposed in the sense of being declared in the header. But in terms of readability, I've decided to put them in the private block of class `LineNumberProgram` which is the only user of these methods. What would be the advantages of moving them completely to `elfFile.cpp` as static helper functions?

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

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


From stuefe at openjdk.org  Wed Nov 16 16:11:51 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 16 Nov 2022 16:11:51 GMT
Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed [v4]
In-Reply-To: <-LPuNwZylHWH7M8ifGeNw27j7T7-kQzbKa4y0H6cHvM=.8ea671b0-980d-4a81-94b6-1ddab48c1fea@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>
 <3CD6ryhzVPUpiJTkeepDevEr96HfvCkLdCR2AzmxqoA=.db139ad6-cbb6-4791-a6d1-4d28e54fdcd1@github.com>
 <-LPuNwZylHWH7M8ifGeNw27j7T7-kQzbKa4y0H6cHvM=.8ea671b0-980d-4a81-94b6-1ddab48c1fea@github.com>
Message-ID: <S4pT9MhCorn5XvwppyTIKDMWmutvDzcZShwzGbvwGAA=.45cbb5d3-3ef0-4b9b-ba7c-0ad8ab7152b9@github.com>

On Wed, 16 Nov 2022 15:50:31 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> src/hotspot/share/utilities/elfFile.cpp line 1651:
>> 
>>> 1649:   int bytes_written = jio_snprintf(dst, count, "%s", src);
>>> 1650:   // Add null terminator.
>>> 1651:   dst[count - 1] = '\0';
>> 
>> Does it make sense to return a truncated file name up to the caller of `DwarfFile::LineNumberProgram::get_filename_from_header()`? Will this not just confuse him? I think it makes more sense to cleanly handle truncation, and e.g. skip file parsing for dwarf files with too long names.
>
> I think you're right that it's rather unexpected to get an incomplete filename back. But just silently skipping the filename might be confusing as well. We could either print an error (I guess that's useful either way but should only be printed with `TraceDwarfLevel`) or just return a generic "buffer overflow" string as filename instead if it fits into the provided filename buffer. And only if that's not possible we could silently skip the filename. Would that be an option?

Optional tracing and returning a generic string sounds fine.

>> src/hotspot/share/utilities/elfFile.hpp line 865:
>> 
>>> 863:     bool get_filename_from_header(uint32_t file_index, char* filename, size_t filename_len);
>>> 864:     static void strip_path_prefix(char* filename, const size_t filename_len);
>>> 865:     static void copy_dwarf_filename_to_filename(char* src, size_t src_len, char* dst, size_t dst_len);
>> 
>> Stupid question, do these have to be exposed? Or could they be just static helpers in elfFile.cpp?
>
> In theory, they don't need to be exposed in the sense of being declared in the header. But in terms of readability, I've decided to put them in the private block of class `LineNumberProgram` which is the only user of these methods. What would be the advantages of moving them completely to `elfFile.cpp` as static helper functions?

Oh, I generally just prefer to keep things locally if possible. Slim interfaces, less polluted global namespace, possibly (though not here) less include deps. Don't worry, if you prefer it this way, keep it in.

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

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


From stefank at openjdk.org  Wed Nov 16 16:17:48 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 16 Nov 2022 16:17:48 GMT
Subject: RFR: 8296886: Fix various include sort order issues [v2]
In-Reply-To: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
References: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
Message-ID: <JjDvqbScU0zoekDaaXbN4IUU0bv9tdm2Pvev5sqVggw=.e17fde8e-4462-4803-88e8-d1af700812e7@github.com>

> The sorted blocks of includes have deteriorated to the point that I felt compelled to clean up some of the issues.
> 
> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory, so I don't think that's a good enough argument, again IMHO. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share,
  just like the other platform-independent headers in HotSpot.
> 
> While going over the include headers I've also cleaned up surrounding whitespaces and incorrect include guards.

Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Cleanups
 - Merge remote-tracking branch 'upstream/master' into various_include_order_fixes
 - Various include order fixes

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

Changes: https://git.openjdk.org/jdk/pull/11108/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11108&range=01
  Stats: 323 lines in 116 files changed: 143 ins; 163 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/11108.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11108/head:pull/11108

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


From ihse at openjdk.org  Wed Nov 16 16:44:16 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Nov 2022 16:44:16 GMT
Subject: RFR: 8297041: Remove the last remnants of sjavac
In-Reply-To: <ObrdH4mmNt3fqgNS9EKPSAfECovk9LWLnClLzhk9YyA=.25420186-ae1f-4339-92b9-ba268a78d36a@github.com>
References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
 <ObrdH4mmNt3fqgNS9EKPSAfECovk9LWLnClLzhk9YyA=.25420186-ae1f-4339-92b9-ba268a78d36a@github.com>
Message-ID: <jSIXSNB5jlpKJ0OxG2lIf_G3O1Q0jJWbWCEVpXDWEK0=.f56d3507-e50a-47f3-aa45-138e60583284@github.com>

On Wed, 16 Nov 2022 14:06:16 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc.
>> 
>> Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code.
>> 
>> This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place.
>
> Would it be worth keeping the relevant tests around in a separate test root for buildtools, given that this buildtool is rather big and complex? Or is the replacement so imminent that it's not worth the effort?

@erikj79 I'd also like to add that, at this point, the buildtool is not very complex. Right now it just listens to a port, and kicks off a javac compilation for each incoming call. It looks more complex since we've come here the long way around from a more complicated tool, and I did not spend too much time simplifying the code.

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

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


From aph at openjdk.org  Wed Nov 16 16:55:24 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 16 Nov 2022 16:55:24 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v10]
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <E7HwXXjC4P7B2RXor6pCyw9g8ZaW63bkvF_vZBw7Obs=.bf6400de-54cc-429f-a898-d27328e542f6@github.com>

> JEP 429 implementation.

Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:

 - Javadoc changes.
 - ProblemList.txt cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10952/files
  - new: https://git.openjdk.org/jdk/pull/10952/files/2a2b0cca..280cd6c5

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

  Stats: 46 lines in 3 files changed: 8 ins; 6 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/10952.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952

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


From jjg at openjdk.org  Wed Nov 16 17:56:13 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 16 Nov 2022 17:56:13 GMT
Subject: RFR: 8297041: Remove the last remnants of sjavac
In-Reply-To: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
Message-ID: <l1ScWjGMeDMWfHzGC9AmHkiRtYBMbQEbz_oKFdk9vAQ=.e63fa7c0-4a12-4e01-ae30-51304fcfa465@github.com>

On Wed, 16 Nov 2022 13:22:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc.
> 
> Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code.
> 
> This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place.

make/langtools/tools/javacserver/comp/SjavacImpl.java line 36:

> 34: import java.io.PrintWriter;
> 35: import java.io.StringWriter;
> 36: import java.util.stream.Stream;

This is a build tool, so you get to set the guidelines, but generally, this is an unusual order for imports

make/langtools/tools/javacserver/comp/SjavacImpl.java line 47:

> 45:  *  deletion without notice.</b>
> 46:  */
> 47: public class SjavacImpl implements Sjavac {

... so it looks like there are still some vestiges of `Sjavac` ...

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

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


From jjg at openjdk.org  Wed Nov 16 18:02:18 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 16 Nov 2022 18:02:18 GMT
Subject: RFR: 8297041: Remove the last remnants of sjavac
In-Reply-To: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
Message-ID: <wF99SFlLAleWm5XZgGEtGGZ1Pkq0AV3EcZjeqTX4V1w=.e9a198a8-ce53-4eb2-ae24-03f9f0a3e46a@github.com>

On Wed, 16 Nov 2022 13:22:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc.
> 
> Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code.
> 
> This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place.

Nice cleanup.

test/langtools/ProblemList.txt line 69:

> 67: tools/sjavac/IgnoreSymbolFile.java                                              8158002    generic-all    Requires investigation
> 68: tools/sjavac/ClasspathDependencies.java                                         8158002    generic-all    Requires investigation
> 69: 

I presume these issues, 8152055, 8158002, are still open?    They should either be closed or assigned to the build team.

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

Marked as reviewed by jjg (Reviewer).

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


From mcimadamore at openjdk.org  Wed Nov 16 18:28:23 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 16 Nov 2022 18:28:23 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v6]
In-Reply-To: <FHV54avkRj2f7vf-_chBEqAAVP3r-CZpU9PfJlldWmU=.87413912-0826-4d80-8f71-0134ddd2994a@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <rFpWIyEO_DC9u3gyaxwlC3nK0gdo_2gGlX9bgNZvtZE=.2eec08c4-0a50-4f81-b4c9-45eba639f941@github.com>
 <nK7KFzzYywjKGp2TTJF1ALF4yQdkN0HC1ja2wtZTSRc=.ef43617b-9781-44cf-b3d1-7ad951ec598a@github.com>
 <FHV54avkRj2f7vf-_chBEqAAVP3r-CZpU9PfJlldWmU=.87413912-0826-4d80-8f71-0134ddd2994a@github.com>
Message-ID: <NFdU7AI9d-0to8S9U8ejxndmN5goTf7szK2kVuMzMcU=.cd22a103-7e3a-4049-9c2b-15b34e8d0ab5@github.com>

On Wed, 16 Nov 2022 15:58:49 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 460:
>> 
>>> 458:      * }
>>> 459:      *
>>> 460:      * @param key the ScopedValue key
>> 
>> should use `@code` or `@link`
>
> Sorry, I don't understand what you want.

There is a "bare" reference to `ScopedValue`. Should it be `{@code ScopedValue}` or `{@link ScopedValue}` ?

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

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


From ccheung at openjdk.org  Wed Nov 16 18:39:59 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 16 Nov 2022 18:39:59 GMT
Subject: RFR: 8283238: make/scripts/compare.sh should show the diff when
 classlist does not match
Message-ID: <z6LknSn-yU6wJPSOrpTK4Lz0PTGZIhCC7mk86XETi2s=.704b0aef-4f0b-4da3-837e-13aec459a4d1@github.com>

Please review this change for enabling verbose (-vv) when running the compare.sh script so that the diff between files will be available in the build stdout file. This is for troubleshooting the two bugs ([JDK-8283220](https://bugs.openjdk.org/browse/JDK-8283220), [JDK-8295951](https://bugs.openjdk.org/browse/JDK-8295951)) which happened intermittently.

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

Commit messages:
 - 8283238: make/scripts/compare.sh should show the diff when classlist does not match

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

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


From ihse at openjdk.org  Wed Nov 16 18:47:05 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Nov 2022 18:47:05 GMT
Subject: RFR: 8297041: Remove the last remnants of sjavac
In-Reply-To: <l1ScWjGMeDMWfHzGC9AmHkiRtYBMbQEbz_oKFdk9vAQ=.e63fa7c0-4a12-4e01-ae30-51304fcfa465@github.com>
References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
 <l1ScWjGMeDMWfHzGC9AmHkiRtYBMbQEbz_oKFdk9vAQ=.e63fa7c0-4a12-4e01-ae30-51304fcfa465@github.com>
Message-ID: <4079KkZ1LlxwoUYO_FbAPc7wMAzkme3WUWBIXGRZvu4=.1ecec3ee-c8aa-459f-9700-80dd8f6983a9@github.com>

On Wed, 16 Nov 2022 17:51:20 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc.
>> 
>> Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code.
>> 
>> This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place.
>
> make/langtools/tools/javacserver/comp/SjavacImpl.java line 36:
> 
>> 34: import java.io.PrintWriter;
>> 35: import java.io.StringWriter;
>> 36: import java.util.stream.Stream;
> 
> This is a build tool, so you get to set the guidelines, but generally, this is an unusual order for imports

Haha! Calling this "unusual" is the most diplomatic expression I've heard today. :-) This is just bonkers. I used a combination of "organize imports" on IntelliJ (without setting up specific rules for the project) and a brute search-and-replace. I'll fix.

> make/langtools/tools/javacserver/comp/SjavacImpl.java line 47:
> 
>> 45:  *  deletion without notice.</b>
>> 46:  */
>> 47: public class SjavacImpl implements Sjavac {
> 
> ... so it looks like there are still some vestiges of `Sjavac` ...

Yes, I did not bother renaming the files and classes in the actual javacserver implementation. I'm hoping Christian will clean this up later on anyway. I just tried to prune out the lion's share of what's not needed anymore.

> test/langtools/ProblemList.txt line 69:
> 
>> 67: tools/sjavac/IgnoreSymbolFile.java                                              8158002    generic-all    Requires investigation
>> 68: tools/sjavac/ClasspathDependencies.java                                         8158002    generic-all    Requires investigation
>> 69: 
> 
> I presume these issues, 8152055, 8158002, are still open?    They should either be closed or assigned to the build team.

No, I've closed them already, with a reference to this issue.

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

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


From ihse at openjdk.org  Wed Nov 16 18:47:06 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Nov 2022 18:47:06 GMT
Subject: RFR: 8297041: Remove the last remnants of sjavac
In-Reply-To: <4079KkZ1LlxwoUYO_FbAPc7wMAzkme3WUWBIXGRZvu4=.1ecec3ee-c8aa-459f-9700-80dd8f6983a9@github.com>
References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
 <l1ScWjGMeDMWfHzGC9AmHkiRtYBMbQEbz_oKFdk9vAQ=.e63fa7c0-4a12-4e01-ae30-51304fcfa465@github.com>
 <4079KkZ1LlxwoUYO_FbAPc7wMAzkme3WUWBIXGRZvu4=.1ecec3ee-c8aa-459f-9700-80dd8f6983a9@github.com>
Message-ID: <481wI-t55703G09LJRP45YUrPga7pe8M_diFquKb_c4=.31d3ceda-d828-42ee-a8d2-1bd3f160dc65@github.com>

On Wed, 16 Nov 2022 18:42:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> test/langtools/ProblemList.txt line 69:
>> 
>>> 67: tools/sjavac/IgnoreSymbolFile.java                                              8158002    generic-all    Requires investigation
>>> 68: tools/sjavac/ClasspathDependencies.java                                         8158002    generic-all    Requires investigation
>>> 69: 
>> 
>> I presume these issues, 8152055, 8158002, are still open?    They should either be closed or assigned to the build team.
>
> No, I've closed them already, with a reference to this issue.

To be clear: they referred to the test code that is removed as part of this PR, so closing them is the only reasonable thing to do.

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

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


From aph at openjdk.org  Wed Nov 16 19:06:59 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 16 Nov 2022 19:06:59 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v10]
In-Reply-To: <40rwB5m6Mskkevkwkj8B34o540txfesN7P-pOGWPfqA=.4cf0adb3-1e3d-4a87-b2bf-505c7f15d487@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <FclwJZRKpjSGCNnl3yRZRRzmvJuQlXNHFmdcQ742p18=.f9ed06dd-4602-400d-aa91-2091b9f26982@github.com>
 <40rwB5m6Mskkevkwkj8B34o540txfesN7P-pOGWPfqA=.4cf0adb3-1e3d-4a87-b2bf-505c7f15d487@github.com>
Message-ID: <6PNLRgFIjkvIRL_tIW0btKxdEapZI6_JC8roNRFBSws=.a6292551-ac7b-4f45-a851-3c4c614edc3b@github.com>

On Fri, 4 Nov 2022 09:50:10 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 481:
>> 
>>> 479:         }
>>> 480:  */
>>> 481:         return findBinding() != Snapshot.NIL;
>> 
>> This?should probably?call `Cache.put(this,?value)` when?`findBinding()` isn?t?`Snapshot.NIL`, since?it?s?likely that?`isBound()` will?most?commonly be?used in?the?form?of:
>> 
>> if (SCOPED_VALUE.isBound()) {
>> 	final var value = SCOPED_VALUE.get();
>> 	// do something with `value`
>> }
>> 
>> 
>> --------------------------------------------------------------------------------
>> 
>> Suggestion:
>> 
>>         var value = findBinding();
>>         if (value == Snapshot.NIL) {
>>             return false;
>>         }
>>         Cache.put(this, value);
>>         return true;
>
> Probably so, yes. I'll have a look at that along with caching failure.

So I just did the experiment of caching failures and the result of `isBound()`.

This test:


    @Benchmark
    @OutputTimeUnit(TimeUnit.NANOSECONDS)
    public int thousandMaybeGets(Blackhole bh) throws Exception {
        int result = 0;
        for (int i = 0; i < 1_000; i++) {
            if (ScopedValuesData.sl1.isBound()) {
                result += ScopedValuesData.sl1.get();
            }
        }
        return result;
    }



Before and after:


ScopedValues.thousandMaybeGets       avgt   10  13436.112 ? 20.885  ns/op
ScopedValues.thousandMaybeGets       avgt   10     56.315 ? 0.583  ns/op


You may have a point. The experiment is on a branch  called `JDK-8286666-cache-queries` in [My personal repo](https://github.com/theRealAph/jdk).

I'd push it now but it's getting a bit late to make such changes now. WDYT?

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

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


From aph at openjdk.org  Wed Nov 16 19:11:15 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 16 Nov 2022 19:11:15 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v6]
In-Reply-To: <NFdU7AI9d-0to8S9U8ejxndmN5goTf7szK2kVuMzMcU=.cd22a103-7e3a-4049-9c2b-15b34e8d0ab5@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <rFpWIyEO_DC9u3gyaxwlC3nK0gdo_2gGlX9bgNZvtZE=.2eec08c4-0a50-4f81-b4c9-45eba639f941@github.com>
 <nK7KFzzYywjKGp2TTJF1ALF4yQdkN0HC1ja2wtZTSRc=.ef43617b-9781-44cf-b3d1-7ad951ec598a@github.com>
 <FHV54avkRj2f7vf-_chBEqAAVP3r-CZpU9PfJlldWmU=.87413912-0826-4d80-8f71-0134ddd2994a@github.com>
 <NFdU7AI9d-0to8S9U8ejxndmN5goTf7szK2kVuMzMcU=.cd22a103-7e3a-4049-9c2b-15b34e8d0ab5@github.com>
Message-ID: <b14aZ4u72bwzdV7d_XpSwz4ztTSkmRUn4UhQlVhzZPo=.28665341-dd5c-4040-9275-70194d931287@github.com>

On Wed, 16 Nov 2022 18:26:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Sorry, I don't understand what you want.
>
> There is a "bare" reference to `ScopedValue`. Should it be `{@code ScopedValue}` or `{@link ScopedValue}` ?

Ahh, OK.

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

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


From alanb at openjdk.org  Wed Nov 16 19:17:04 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Nov 2022 19:17:04 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v6]
In-Reply-To: <b14aZ4u72bwzdV7d_XpSwz4ztTSkmRUn4UhQlVhzZPo=.28665341-dd5c-4040-9275-70194d931287@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <rFpWIyEO_DC9u3gyaxwlC3nK0gdo_2gGlX9bgNZvtZE=.2eec08c4-0a50-4f81-b4c9-45eba639f941@github.com>
 <nK7KFzzYywjKGp2TTJF1ALF4yQdkN0HC1ja2wtZTSRc=.ef43617b-9781-44cf-b3d1-7ad951ec598a@github.com>
 <FHV54avkRj2f7vf-_chBEqAAVP3r-CZpU9PfJlldWmU=.87413912-0826-4d80-8f71-0134ddd2994a@github.com>
 <NFdU7AI9d-0to8S9U8ejxndmN5goTf7szK2kVuMzMcU=.cd22a103-7e3a-4049-9c2b-15b34e8d0ab5@github.com>
 <b14aZ4u72bwzdV7d_XpSwz4ztTSkmRUn4UhQlVhzZPo=.28665341-dd5c-4040-9275-70194d931287@github.com>
Message-ID: <B1UmptxQ5alAKr-9Nofkzo04KEdU4iOF47sJSI-dczc=.af326156-a6d3-4022-9db6-dd06d990ea80@github.com>

On Wed, 16 Nov 2022 19:08:48 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> There is a "bare" reference to `ScopedValue`. Should it be `{@code ScopedValue}` or `{@link ScopedValue}` ?
>
> Ahh, OK.

We fixed those in the recent update.

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

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


From erikj at openjdk.org  Wed Nov 16 19:18:05 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 16 Nov 2022 19:18:05 GMT
Subject: RFR: 8283238: make/scripts/compare.sh should show the diff when
 classlist does not match
In-Reply-To: <z6LknSn-yU6wJPSOrpTK4Lz0PTGZIhCC7mk86XETi2s=.704b0aef-4f0b-4da3-837e-13aec459a4d1@github.com>
References: <z6LknSn-yU6wJPSOrpTK4Lz0PTGZIhCC7mk86XETi2s=.704b0aef-4f0b-4da3-837e-13aec459a4d1@github.com>
Message-ID: <aUlGOecAQl2kFvvCrXjz007mvyn1ZVN94OyK3-a1ns0=.66aa4731-909a-4dd2-aa09-7b293884e960@github.com>

On Wed, 16 Nov 2022 18:32:47 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this change for enabling verbose (-vv) when running the compare.sh script so that the diff between files will be available in the build stdout file. This is for troubleshooting the two bugs ([JDK-8283220](https://bugs.openjdk.org/browse/JDK-8283220), [JDK-8295951](https://bugs.openjdk.org/browse/JDK-8295951)) which happened intermittently.

Marked as reviewed by erikj (Reviewer).

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

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


From ihse at openjdk.org  Wed Nov 16 19:25:02 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Nov 2022 19:25:02 GMT
Subject: RFR: 8283238: make/scripts/compare.sh should show the diff when
 classlist does not match
In-Reply-To: <z6LknSn-yU6wJPSOrpTK4Lz0PTGZIhCC7mk86XETi2s=.704b0aef-4f0b-4da3-837e-13aec459a4d1@github.com>
References: <z6LknSn-yU6wJPSOrpTK4Lz0PTGZIhCC7mk86XETi2s=.704b0aef-4f0b-4da3-837e-13aec459a4d1@github.com>
Message-ID: <GL1RbjBdUrzk5RxtaAuTY0KpdxnCOJVuUXlcNvhGSis=.9b21169a-2ec0-46ce-a114-f95577ba9488@github.com>

On Wed, 16 Nov 2022 18:32:47 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this change for enabling verbose (-vv) when running the compare.sh script so that the diff between files will be available in the build stdout file. This is for troubleshooting the two bugs ([JDK-8283220](https://bugs.openjdk.org/browse/JDK-8283220), [JDK-8295951](https://bugs.openjdk.org/browse/JDK-8295951)) which happened intermittently.

Have you tested that -vv gives you the diff for classlist files?

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

Marked as reviewed by ihse (Reviewer).

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


From ihse at openjdk.org  Wed Nov 16 19:35:51 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Nov 2022 19:35:51 GMT
Subject: RFR: 8296478: Rework 8282948 and 8282700 to use the new autoconf
 UTIL_ARG_WITH [v2]
In-Reply-To: <WXiInV6g7gltKihp6pg6kd3kVtX9EIB-yX7YQI34LYk=.162eb88a-c4cb-464c-8a26-dd1db571ed99@github.com>
References: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
 <WXiInV6g7gltKihp6pg6kd3kVtX9EIB-yX7YQI34LYk=.162eb88a-c4cb-464c-8a26-dd1db571ed99@github.com>
Message-ID: <xsA_zEozmr44E_zlgOxijO5q1ngsV52nCzvXr1nn9UQ=.c5ed07a4-5a33-430c-af5c-f562eab482dd@github.com>

On Sat, 12 Nov 2022 16:18:54 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> 8285093 introduced the new UTIL_ARG_WITH definition, which was not available when both 8282948 and 8282700 were written. They can now be moved to using the cleaner logic that UTIL_ARG_WITH grants.
>> 
>> There are many more options that still use AC_ARG_WITH in jdk-version.m4. They are out of the scope of this commit, which aims only to rework the previous integrated commits mentioned above.
>
> 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 two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into util
>  - Squash

make/autoconf/jdk-version.m4 line 82:

> 80:   UTIL_ARG_WITH(NAME: build-user, TYPE: string,
> 81:     RESULT: USERNAME,
> 82:     DEFAULT: $USERNAME,

This looks like the same values flow in and out of the function. Maybe call the fallback value `DEFAULT_USERNAME`?

make/autoconf/jdk-version.m4 line 84:

> 82:     DEFAULT: $USERNAME,
> 83:     DESC: [build username to use in version strings],
> 84:     IF_GIVEN: [

In general, I think these tests would be better expressed using the `CHECK_VALUE` construct, rather than `IF_GIVEN`. (A more specific reason is better than a vaguer and more general)

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

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


From ihse at openjdk.org  Wed Nov 16 19:39:04 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Nov 2022 19:39:04 GMT
Subject: RFR: 8296478: Rework 8282948 and 8282700 to use the new autoconf
 UTIL_ARG_WITH [v2]
In-Reply-To: <WXiInV6g7gltKihp6pg6kd3kVtX9EIB-yX7YQI34LYk=.162eb88a-c4cb-464c-8a26-dd1db571ed99@github.com>
References: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
 <WXiInV6g7gltKihp6pg6kd3kVtX9EIB-yX7YQI34LYk=.162eb88a-c4cb-464c-8a26-dd1db571ed99@github.com>
Message-ID: <rGEF2wnu76IrXoYP6jDhnbxDMubW8xtZ8qUgL_h46B4=.2874c951-c89f-4932-9776-b2687268e29b@github.com>

On Sat, 12 Nov 2022 16:18:54 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> 8285093 introduced the new UTIL_ARG_WITH definition, which was not available when both 8282948 and 8282700 were written. They can now be moved to using the cleaner logic that UTIL_ARG_WITH grants.
>> 
>> There are many more options that still use AC_ARG_WITH in jdk-version.m4. They are out of the scope of this commit, which aims only to rework the previous integrated commits mentioned above.
>
> 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 two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into util
>  - Squash

make/autoconf/jdk-version.m4 line 123:

> 121:   # The vendor URL, if any
> 122:   # Only set VENDOR_URL if '--with-vendor-url' was used and is not empty.
> 123:   # Otherwise we will use the value from "branding.conf" included above.

I think this is actually a bit confusing, especially when put in focus like this by your rewrite. Perhaps the values in branding.conf should be renamed like `DEFAULT_VENDOR_URL`? That is what it is, after all -- even if you modify branding.conf in a fork, it can still be overridden by configure arguments.

(This comment is also driven by the fact that I don't really like a construction where the same value both goes into the UTIL_ARG_WITH as comes out of it. If at all possible, I really like to avoid re-assigning values to variables).

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

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


From ccheung at openjdk.org  Wed Nov 16 19:40:04 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 16 Nov 2022 19:40:04 GMT
Subject: RFR: 8283238: make/scripts/compare.sh should show the diff when
 classlist does not match
In-Reply-To: <GL1RbjBdUrzk5RxtaAuTY0KpdxnCOJVuUXlcNvhGSis=.9b21169a-2ec0-46ce-a114-f95577ba9488@github.com>
References: <z6LknSn-yU6wJPSOrpTK4Lz0PTGZIhCC7mk86XETi2s=.704b0aef-4f0b-4da3-837e-13aec459a4d1@github.com>
 <GL1RbjBdUrzk5RxtaAuTY0KpdxnCOJVuUXlcNvhGSis=.9b21169a-2ec0-46ce-a114-f95577ba9488@github.com>
Message-ID: <v49KwEuVQfLXSgTZvy7aSRGoFtTbPHBiQWBb0AmoknA=.4438929f-ed02-44d9-b7e8-837bd593c932@github.com>

On Wed, 16 Nov 2022 19:21:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Have you tested that -vv gives you the diff for classlist files?

I did tested it but not seeing the diff for classlist files since the bugs in question only happened intermittently.

For a normal run, the build stdout file would include listings of JDK Libraries, Test Libraries, JDK Executables, Test Executables as follows: 

`[2022-11-16T05:44:54,471Z] JDK Libraries... 
[2022-11-16T05:44:54,471Z] Binary : Size : Symbols : Deps : Fulldump : Disass : 
[2022-11-16T05:44:54,496Z] : : : : : : ./lib/libattach.dylib 
[2022-11-16T05:44:54,521Z] : : : : : : ./lib/libawt.dylib 
[2022-11-16T05:44:54,548Z] : : : : : : ./lib/libawt_lwawt.dylib 
[2022-11-16T05:44:54,571Z] : : : : : : ./lib/libdt_socket.dylib 
<snip>`

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

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


From ihse at openjdk.org  Wed Nov 16 19:42:49 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Nov 2022 19:42:49 GMT
Subject: RFR: 8296478: Rework 8282948 and 8282700 to use the new autoconf
 UTIL_ARG_WITH [v2]
In-Reply-To: <WXiInV6g7gltKihp6pg6kd3kVtX9EIB-yX7YQI34LYk=.162eb88a-c4cb-464c-8a26-dd1db571ed99@github.com>
References: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
 <WXiInV6g7gltKihp6pg6kd3kVtX9EIB-yX7YQI34LYk=.162eb88a-c4cb-464c-8a26-dd1db571ed99@github.com>
Message-ID: <bqoIBM304dAl0GgVtQbZ-SCroIvq1C6v3O0oR4u_HtQ=.3c60b04c-f176-4f45-bba1-f67f80536a9a@github.com>

On Sat, 12 Nov 2022 16:18:54 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> 8285093 introduced the new UTIL_ARG_WITH definition, which was not available when both 8282948 and 8282700 were written. They can now be moved to using the cleaner logic that UTIL_ARG_WITH grants.
>> 
>> There are many more options that still use AC_ARG_WITH in jdk-version.m4. They are out of the scope of this commit, which aims only to rework the previous integrated commits mentioned above.
>
> 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 two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into util
>  - Squash

make/autoconf/jdk-version.m4 line 95:

> 93:   UTIL_ARG_WITH(NAME: jdk-rc-name, TYPE: string,
> 94:     DEFAULT: [$PRODUCT_NAME $JDK_RC_PLATFORM_NAME],
> 95:     DESC: [Set JDK RC name. This is used for FileDescription and ProductName

Please use `DEFAULT_DESC` instead of the old `@<:@...@:>@` construct. (This too goes for all the instances)

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

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


From ihse at openjdk.org  Wed Nov 16 19:48:16 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Nov 2022 19:48:16 GMT
Subject: RFR: 8296478: Rework 8282948 and 8282700 to use the new autoconf
 UTIL_ARG_WITH
In-Reply-To: <eYuT5uT-g4oRVyDYTyI-nX9peUMs_NibOWH_qMWcCZM=.ce9d1206-4efa-4085-a95c-12a06e8681b1@github.com>
References: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
 <eYuT5uT-g4oRVyDYTyI-nX9peUMs_NibOWH_qMWcCZM=.ce9d1206-4efa-4085-a95c-12a06e8681b1@github.com>
Message-ID: <4y0I-QpW7qUSZHuAH1_huwqoGJU4aSVeMaNNkfpJq6s=.1362b9d2-882f-482d-98e8-2dd59a0a7d53@github.com>

On Fri, 11 Nov 2022 14:56:29 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> For one reason or another this particular flag simply refuses to work properly with UTIL_ARG_WITH, and after numerous attempts I'm completely lost as to how to make it function without crashing autoconf halfway through before the configure script is even generated

This sounds like the typical case that happens if you inadvertently write the name of a macro ("function") that gets expanded. Like this:

AC_DEFUN([TEST_FOO],
[
   echo Debug: we are running in TEST_FOO
])


will fail to compile with a stack overflow, since the `TEST_FOO` in the debug output will be recursively expanded with the function we're trying to expand. (Been there, done that, has produced profanities over autoconf enough to guarantee me a very hot place in the afterlife, before I figured that one out...)

So check if you are trying to write a "keyword" where a substring matches some other defined macro.

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

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


From ihse at openjdk.org  Wed Nov 16 19:55:04 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Nov 2022 19:55:04 GMT
Subject: RFR: 8296904: Improve handling of macos xcode toolchain [v3]
In-Reply-To: <qOWYOLTicFL1YEmGaFrRWhhQnXe7g-4KEjVsCox8RAM=.7e644243-089f-4300-8000-6a6b57be1c56@github.com>
References: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
 <qOWYOLTicFL1YEmGaFrRWhhQnXe7g-4KEjVsCox8RAM=.7e644243-089f-4300-8000-6a6b57be1c56@github.com>
Message-ID: <7diU14c5he7ck398JBB9xOORGw-5ky3Tek-6Wi8yjE0=.cb65f54f-cdf2-4418-af8e-022cabd6eb53@github.com>

On Tue, 15 Nov 2022 21:45:25 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> With this PR I'd like to make it easier to use dedicated installations of Xcode on Mac OS for OpenJDK builds without having to switch the active Xcode globally via `xcode-select`.
>> 
>> I propose adding a new configure flag `--with-xcode-path` that takes the path to an Xcode installation. If the option is set, this path is expanded to a valid `TOOLCHAIN_PATH`.
>> 
>> Furthermore, I fix detection of xcodebuild and correctly setting the sysroot from the toolchain by moving `AC_SUBST(TOOLCHAIN_PATH)` before calling `BASIC_SETUP_XCODE_SYSROOT` and honoring `TOOLCHAIN_PATH` in BASIC_SETUP_XCODE_SYSROOT in the case when no devkit is specified. As I see it, this is a viable fix, even if not introducing `--with-xcode-path`.
>
> Christoph Langer 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:
> 
>  - Review suggestion
>  - Merge branch 'master' into xcode-toolchain
>  - Improve options for xcode toolchain

Looks good, thanks for fixing this!

Is there perhaps some documentation in doc/building.md that needs updating? I know there is a bit written about Xcode, I can imagine some pointers to this new argument would fit in there.

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

Marked as reviewed by ihse (Reviewer).

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


From ihse at openjdk.org  Wed Nov 16 20:02:57 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Nov 2022 20:02:57 GMT
Subject: RFR: JDK-8297000 [jib] Add more friendly warning for proxy issues
In-Reply-To: <kFnWkvqxdHvbqf4hajjA2n9rBELOGWPTk_vLxPfU4P8=.dc3062c3-fcde-44b9-8433-2f04ccd9074b@github.com>
References: <kFnWkvqxdHvbqf4hajjA2n9rBELOGWPTk_vLxPfU4P8=.dc3062c3-fcde-44b9-8433-2f04ccd9074b@github.com>
Message-ID: <7KaGiYrIV_4cG9u5iGG9pf_WwZHs3lZezgqu6517Ph0=.621935dd-90bf-46e5-845f-5b2931ea2252@github.com>

On Tue, 15 Nov 2022 09:55:38 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> When jib tries to download itself behind a proxy, sometimes it can get a different file than it expected. This can result in cryptic errors that are hard to troubleshoot. Let's handle this a little more gracefully by detecting it in the bootstrapper and printing an error.

bin/jib.sh line 137:

> 135:     FILEOUTPUT=`file ${installed_jib_script}.gz`
> 136:     # ${X:${#Y}} gives X without the first ${#Y} characters, and ${#Y} is length of Y.
> 137:     FILEOUTPUT=${FILEOUTPUT:${#PREFIX}}

I think this is a bashism. While we do have /bin/bash in the shebang, this does not really matter since we have no executable bit on the script, so users will have to explicitly call it with a shell. So many users are likely to do `sh bin/jib.sh`, and then this will break.

My recommendation would be to use standard tools like cut or grep instead, something like:

file $installedscript.gz | grep "gzip compressed data" -q
if test $? -neq 0; then 
...

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

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


From ihse at openjdk.org  Wed Nov 16 20:02:57 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Nov 2022 20:02:57 GMT
Subject: RFR: JDK-8297000 [jib] Add more friendly warning for proxy issues
In-Reply-To: <7KaGiYrIV_4cG9u5iGG9pf_WwZHs3lZezgqu6517Ph0=.621935dd-90bf-46e5-845f-5b2931ea2252@github.com>
References: <kFnWkvqxdHvbqf4hajjA2n9rBELOGWPTk_vLxPfU4P8=.dc3062c3-fcde-44b9-8433-2f04ccd9074b@github.com>
 <7KaGiYrIV_4cG9u5iGG9pf_WwZHs3lZezgqu6517Ph0=.621935dd-90bf-46e5-845f-5b2931ea2252@github.com>
Message-ID: <g7h5TV7ODyfO-vgxt-DIEpE082Y8ms5l6ZVpbglSNFg=.72d7b643-9f11-42bb-b06d-6d54f1996163@github.com>

On Wed, 16 Nov 2022 19:57:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> When jib tries to download itself behind a proxy, sometimes it can get a different file than it expected. This can result in cryptic errors that are hard to troubleshoot. Let's handle this a little more gracefully by detecting it in the bootstrapper and printing an error.
>
> bin/jib.sh line 137:
> 
>> 135:     FILEOUTPUT=`file ${installed_jib_script}.gz`
>> 136:     # ${X:${#Y}} gives X without the first ${#Y} characters, and ${#Y} is length of Y.
>> 137:     FILEOUTPUT=${FILEOUTPUT:${#PREFIX}}
> 
> I think this is a bashism. While we do have /bin/bash in the shebang, this does not really matter since we have no executable bit on the script, so users will have to explicitly call it with a shell. So many users are likely to do `sh bin/jib.sh`, and then this will break.
> 
> My recommendation would be to use standard tools like cut or grep instead, something like:
> 
> file $installedscript.gz | grep "gzip compressed data" -q
> if test $? -neq 0; then 
> ...

(Warning: untested code)

I also would like to clarify the use of bash. For configure script, and scripts started by the makefiles, we rely on and enforce bash, so in those cases bashisms are accepted (and almost encouraged, at least good ones). But in "user facing" scripts like this, or the top level `configure` script, we want to make minimal assumptions about the shell used, since the shebang path means nothing in our case.

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

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


From ccheung at openjdk.org  Wed Nov 16 20:11:56 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 16 Nov 2022 20:11:56 GMT
Subject: RFR: 8283238: make/scripts/compare.sh should show the diff when
 classlist does not match
In-Reply-To: <z6LknSn-yU6wJPSOrpTK4Lz0PTGZIhCC7mk86XETi2s=.704b0aef-4f0b-4da3-837e-13aec459a4d1@github.com>
References: <z6LknSn-yU6wJPSOrpTK4Lz0PTGZIhCC7mk86XETi2s=.704b0aef-4f0b-4da3-837e-13aec459a4d1@github.com>
Message-ID: <o19Wwe9D1qFqjY7tLwyUhRl8GmpYeQdp9WEaFl6cyGE=.ac8df647-c036-4ae7-9d9b-6b560facfee7@github.com>

On Wed, 16 Nov 2022 18:32:47 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this change for enabling verbose (-vv) when running the compare.sh script so that the diff between files will be available in the build stdout file. This is for troubleshooting the two bugs ([JDK-8283220](https://bugs.openjdk.org/browse/JDK-8283220), [JDK-8295951](https://bugs.openjdk.org/browse/JDK-8295951)) which happened intermittently.

Thanks Erik and Magnus.

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

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


From ccheung at openjdk.org  Wed Nov 16 20:14:11 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 16 Nov 2022 20:14:11 GMT
Subject: Integrated: 8283238: make/scripts/compare.sh should show the diff when
 classlist does not match
In-Reply-To: <z6LknSn-yU6wJPSOrpTK4Lz0PTGZIhCC7mk86XETi2s=.704b0aef-4f0b-4da3-837e-13aec459a4d1@github.com>
References: <z6LknSn-yU6wJPSOrpTK4Lz0PTGZIhCC7mk86XETi2s=.704b0aef-4f0b-4da3-837e-13aec459a4d1@github.com>
Message-ID: <4rh1TMIoTsS725-3XsfhTdEF42GObw4iXeCpgbOOKWg=.f6cdd71d-3d96-491f-be39-f1d2d79bf4fb@github.com>

On Wed, 16 Nov 2022 18:32:47 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this change for enabling verbose (-vv) when running the compare.sh script so that the diff between files will be available in the build stdout file. This is for troubleshooting the two bugs ([JDK-8283220](https://bugs.openjdk.org/browse/JDK-8283220), [JDK-8295951](https://bugs.openjdk.org/browse/JDK-8295951)) which happened intermittently.

This pull request has now been integrated.

Changeset: f0474b82
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f0474b826d76c91d7746213b14c4c1166e2a0a4a
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8283238: make/scripts/compare.sh should show the diff when classlist does not match

Reviewed-by: erikj, ihse

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

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


From mikael at openjdk.org  Wed Nov 16 22:51:52 2022
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 16 Nov 2022 22:51:52 GMT
Subject: RFR: 8297165: Update Pandoc to version 2.19.2 for Oracle builds
Message-ID: <XH7qOax47e6K3-D5B-zNwHkYI25VhrdbRz_6Urqve1c=.26346100-fa53-443c-ac23-19e10b18b3ca@github.com>

Update to Pandoc 2.19.2 for all Oracle platforms/builds. This updates the createPandocBundle.sh script to reflect the bundle layout of the latest upstream pandoc bundles, and adds support for an optional platform argument to the script.

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

Commit messages:
 - Update copyright year
 - Move platform specific logic
 - 8297165: Update Pandoc to version 2.19.2 for Oracle builds

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

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


From erikj at openjdk.org  Wed Nov 16 23:06:24 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 16 Nov 2022 23:06:24 GMT
Subject: RFR: 8297165: Update Pandoc to version 2.19.2 for Oracle builds
In-Reply-To: <XH7qOax47e6K3-D5B-zNwHkYI25VhrdbRz_6Urqve1c=.26346100-fa53-443c-ac23-19e10b18b3ca@github.com>
References: <XH7qOax47e6K3-D5B-zNwHkYI25VhrdbRz_6Urqve1c=.26346100-fa53-443c-ac23-19e10b18b3ca@github.com>
Message-ID: <uT_r4cO-_gTbWsxvCkKFoUtGUpPZR1UdI7SVJvgTF0s=.30675327-1145-4fd8-b621-0d7a4906f566@github.com>

On Wed, 16 Nov 2022 22:02:43 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Update to Pandoc 2.19.2 for all Oracle platforms/builds. This updates the createPandocBundle.sh script to reflect the bundle layout of the latest upstream pandoc bundles, and adds support for an optional platform argument to the script.

Marked as reviewed by erikj (Reviewer).

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

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


From jjg at openjdk.org  Wed Nov 16 23:06:24 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 16 Nov 2022 23:06:24 GMT
Subject: RFR: 8297165: Update Pandoc to version 2.19.2 for Oracle builds
In-Reply-To: <XH7qOax47e6K3-D5B-zNwHkYI25VhrdbRz_6Urqve1c=.26346100-fa53-443c-ac23-19e10b18b3ca@github.com>
References: <XH7qOax47e6K3-D5B-zNwHkYI25VhrdbRz_6Urqve1c=.26346100-fa53-443c-ac23-19e10b18b3ca@github.com>
Message-ID: <rA9cXMfjdrops6vzI9y6LKKIEvsw8mprBlW3F-dRsHM=.98a07939-23f1-49ba-9028-7b9ec674e9b9@github.com>

On Wed, 16 Nov 2022 22:02:43 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Update to Pandoc 2.19.2 for all Oracle platforms/builds. This updates the createPandocBundle.sh script to reflect the bundle layout of the latest upstream pandoc bundles, and adds support for an optional platform argument to the script.

The changes in `jib-profiles.js` look good to me.

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

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


From mikael at openjdk.org  Wed Nov 16 23:11:58 2022
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 16 Nov 2022 23:11:58 GMT
Subject: RFR: 8297165: Update Pandoc to version 2.19.2 for Oracle builds
 [v2]
In-Reply-To: <XH7qOax47e6K3-D5B-zNwHkYI25VhrdbRz_6Urqve1c=.26346100-fa53-443c-ac23-19e10b18b3ca@github.com>
References: <XH7qOax47e6K3-D5B-zNwHkYI25VhrdbRz_6Urqve1c=.26346100-fa53-443c-ac23-19e10b18b3ca@github.com>
Message-ID: <D7kuoIsCfr1vEqV0a0lyLz9UEFOCK_uY_A_Yz7ZHGFA=.06308e1b-404b-47aa-9800-cee7a650a73b@github.com>

> Update to Pandoc 2.19.2 for all Oracle platforms/builds. This updates the createPandocBundle.sh script to reflect the bundle layout of the latest upstream pandoc bundles, and adds support for an optional platform argument to the script.

Mikael Vidstedt 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:

 - Merge branch 'master' into 8297165-pandoc-2.19.2
 - Update copyright year
 - Move platform specific logic
 - 8297165: Update Pandoc to version 2.19.2 for Oracle builds

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11197/files
  - new: https://git.openjdk.org/jdk/pull/11197/files/38682650..b5fd9fbf

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

  Stats: 4397 lines in 212 files changed: 2722 ins; 841 del; 834 mod
  Patch: https://git.openjdk.org/jdk/pull/11197.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11197/head:pull/11197

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


From dholmes at openjdk.org  Thu Nov 17 02:32:52 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 17 Nov 2022 02:32:52 GMT
Subject: RFR: 8296926: Sort include lines of files in the include/
 directory [v4]
In-Reply-To: <Ui-S20RkgTtaXg8YyowdihZ7MAxV8yTEidms18YpKUQ=.adc86da6-1326-448d-ad8e-73be100a6d14@github.com>
References: <tl8LtRfG6_BUCdNMucC4JCSbjv_-yFP46CXbqYnvNxs=.cba35dd6-f1ee-41bf-aa87-9381cc064bf6@github.com>
 <Ui-S20RkgTtaXg8YyowdihZ7MAxV8yTEidms18YpKUQ=.adc86da6-1326-448d-ad8e-73be100a6d14@github.com>
Message-ID: <JkY5Uxb3Mwok0Dtm_J9T4ULcVGj8MkaAWzbkDhvf3aE=.aeac2778-fe5c-497e-95bf-b8ef90549154@github.com>

On Wed, 16 Nov 2022 11:05:59 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share, just like the other platform-independent headers in HotSpo
 t.
>> 
>> This RFE splits out the 'include/' changes from #11108 / JDK-8296886, so that those changes can be discussed separately.
>
> Stefan Karlsson 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 five additional commits since the last revision:
> 
>  - Remove include/ from test/hotspot files
>  - Merge remote-tracking branch 'upstream/master' into 8296926_proper_include_lines_for_include_dir_files
>  - Revert make file changes
>  - Remove include/ from includes
>  - 8296926: Use proper include lines for files in include/

Sorry I didn't get a chance to look at this yesterday. A belated "thumbs up".

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

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


From jwaters at openjdk.org  Thu Nov 17 04:01:28 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 17 Nov 2022 04:01:28 GMT
Subject: RFR: 8296478: Rework 8282948 and 8282700 to use the new autoconf
 UTIL_ARG_WITH [v2]
In-Reply-To: <bqoIBM304dAl0GgVtQbZ-SCroIvq1C6v3O0oR4u_HtQ=.3c60b04c-f176-4f45-bba1-f67f80536a9a@github.com>
References: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
 <WXiInV6g7gltKihp6pg6kd3kVtX9EIB-yX7YQI34LYk=.162eb88a-c4cb-464c-8a26-dd1db571ed99@github.com>
 <bqoIBM304dAl0GgVtQbZ-SCroIvq1C6v3O0oR4u_HtQ=.3c60b04c-f176-4f45-bba1-f67f80536a9a@github.com>
Message-ID: <hOMshjA_GIlU1qUS2-CGkNbjl1BZ4jrwroECmaTIo1U=.6586a2fa-b382-4bd6-9a0c-4df6cd6e95c8@github.com>

On Wed, 16 Nov 2022 19:39:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> 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 two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into util
>>  - Squash
>
> make/autoconf/jdk-version.m4 line 95:
> 
>> 93:   UTIL_ARG_WITH(NAME: jdk-rc-name, TYPE: string,
>> 94:     DEFAULT: [$PRODUCT_NAME $JDK_RC_PLATFORM_NAME],
>> 95:     DESC: [Set JDK RC name. This is used for FileDescription and ProductName
> 
> Please use `DEFAULT_DESC` instead of the old `@<:@...@:>@` construct. (This too goes for all the instances)

Embarrassingly I left it that way since I didn't know what `@<:@...@:>@` actually did. So the following replacement should work?

DEFAULT_DESC: [Set JDK RC name. This is used for FileDescription and ProductName properties of MS Windows binaries.]

> make/autoconf/jdk-version.m4 line 123:
> 
>> 121:   # The vendor URL, if any
>> 122:   # Only set VENDOR_URL if '--with-vendor-url' was used and is not empty.
>> 123:   # Otherwise we will use the value from "branding.conf" included above.
> 
> I think this is actually a bit confusing, especially when put in focus like this by your rewrite. Perhaps the values in branding.conf should be renamed like `DEFAULT_VENDOR_URL`? That is what it is, after all -- even if you modify branding.conf in a fork, it can still be overridden by configure arguments.
> 
> (This comment is also driven by the fact that I don't really like a construction where the same value both goes into the UTIL_ARG_WITH as comes out of it. If at all possible, I really like to avoid re-assigning values to variables).

Alright, I avoided changing those to keep the commit as small as possible, but I guess it's free game now that I have the green light

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

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


From jwaters at openjdk.org  Thu Nov 17 04:39:12 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 17 Nov 2022 04:39:12 GMT
Subject: RFR: 8296478: Rework 8282948 and 8282700 to use the new autoconf
 UTIL_ARG_WITH [v3]
In-Reply-To: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
References: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
Message-ID: <7SZhHXCxeJOm-DcwkHW7PvEiiGV8SUsnRF_PqSC2Guw=.950e0f98-1fcf-4e94-b6b3-bbfbed9929db@github.com>

> 8285093 introduced the new UTIL_ARG_WITH definition, which was not available when both 8282948 and 8282700 were written. They can now be moved to using the cleaner logic that UTIL_ARG_WITH grants.
> 
> There are many more options that still use AC_ARG_WITH in jdk-version.m4. They are out of the scope of this commit, which aims only to rework the previous integrated commits mentioned above.

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

  Use DEFAULT_DESC

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11020/files
  - new: https://git.openjdk.org/jdk/pull/11020/files/42e625f5..0c347b38

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

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

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


From jwaters at openjdk.org  Thu Nov 17 04:39:14 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 17 Nov 2022 04:39:14 GMT
Subject: RFR: 8296478: Rework 8282948 and 8282700 to use the new autoconf
 UTIL_ARG_WITH [v2]
In-Reply-To: <hOMshjA_GIlU1qUS2-CGkNbjl1BZ4jrwroECmaTIo1U=.6586a2fa-b382-4bd6-9a0c-4df6cd6e95c8@github.com>
References: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
 <WXiInV6g7gltKihp6pg6kd3kVtX9EIB-yX7YQI34LYk=.162eb88a-c4cb-464c-8a26-dd1db571ed99@github.com>
 <bqoIBM304dAl0GgVtQbZ-SCroIvq1C6v3O0oR4u_HtQ=.3c60b04c-f176-4f45-bba1-f67f80536a9a@github.com>
 <hOMshjA_GIlU1qUS2-CGkNbjl1BZ4jrwroECmaTIo1U=.6586a2fa-b382-4bd6-9a0c-4df6cd6e95c8@github.com>
Message-ID: <3BOn2Yia-qskCskJ7pkmTDOdmHvhPC8C1CQwTUbsfQU=.26281a3f-8826-436a-9245-ed9f114127c8@github.com>

On Thu, 17 Nov 2022 03:56:44 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> make/autoconf/jdk-version.m4 line 95:
>> 
>>> 93:   UTIL_ARG_WITH(NAME: jdk-rc-name, TYPE: string,
>>> 94:     DEFAULT: [$PRODUCT_NAME $JDK_RC_PLATFORM_NAME],
>>> 95:     DESC: [Set JDK RC name. This is used for FileDescription and ProductName
>> 
>> Please use `DEFAULT_DESC` instead of the old `@<:@...@:>@` construct. (This too goes for all the instances)
>
> Embarrassingly I left it that way since I didn't know what `@<:@...@:>@` actually did. So the following replacement should work?
> 
> DEFAULT_DESC: [Set JDK RC name. This is used for FileDescription and ProductName properties of MS Windows binaries.]

I've changed them accordingly to what should be right, do let me know if I've made any mistakes in my usage of `DEFAULT_DESC`

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

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


From jwaters at openjdk.org  Thu Nov 17 04:46:23 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 17 Nov 2022 04:46:23 GMT
Subject: RFR: 8296478: Rework 8282948 and 8282700 to use the new autoconf
 UTIL_ARG_WITH [v2]
In-Reply-To: <xsA_zEozmr44E_zlgOxijO5q1ngsV52nCzvXr1nn9UQ=.c5ed07a4-5a33-430c-af5c-f562eab482dd@github.com>
References: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
 <WXiInV6g7gltKihp6pg6kd3kVtX9EIB-yX7YQI34LYk=.162eb88a-c4cb-464c-8a26-dd1db571ed99@github.com>
 <xsA_zEozmr44E_zlgOxijO5q1ngsV52nCzvXr1nn9UQ=.c5ed07a4-5a33-430c-af5c-f562eab482dd@github.com>
Message-ID: <hqz_Mg38SdHSYPfbxIXDDCBIXNyqlkeoW_YPVlKwUBI=.0f9f49bd-654e-44b5-857a-0131ceed85d7@github.com>

On Wed, 16 Nov 2022 19:32:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> 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 two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into util
>>  - Squash
>
> make/autoconf/jdk-version.m4 line 84:
> 
>> 82:     DEFAULT: $USERNAME,
>> 83:     DESC: [build username to use in version strings],
>> 84:     IF_GIVEN: [
> 
> In general, I think these tests would be better expressed using the `CHECK_VALUE` construct, rather than `IF_GIVEN`. (A more specific reason is better than a vaguer and more general)

Something concerning is happening when I do that: The code in the CHECK_VALUE block from the resulting configure script has all of the square brackets completely nuked, which is causing the logic in it to always fail. Switching back to IF_GIVEN on my end doesn't help either, it now always destroys all the brackets as well when it was working fine before. Something might be going wrong in the actual utility itself, but I can't tell what exactly :/

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

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


From jwaters at openjdk.org  Thu Nov 17 06:32:24 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 17 Nov 2022 06:32:24 GMT
Subject: RFR: 8296478: Rework 8282948 and 8282700 to use the new autoconf
 UTIL_ARG_WITH [v4]
In-Reply-To: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
References: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
Message-ID: <MwrkLAm89Y6v4-WaqMp3_b1mhZeis8fx4UMEbFHK8g0=.bc453ed5-0641-45df-97b2-7386217bdf4d@github.com>

> 8285093 introduced the new UTIL_ARG_WITH definition, which was not available when both 8282948 and 8282700 were written. They can now be moved to using the cleaner logic that UTIL_ARG_WITH grants.
> 
> There are many more options that still use AC_ARG_WITH in jdk-version.m4. They are out of the scope of this commit, which aims only to rework the previous integrated commits mentioned above.

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

  branding.conf should use the DEFAULT_ prefix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11020/files
  - new: https://git.openjdk.org/jdk/pull/11020/files/0c347b38..239c88af

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

  Stats: 26 lines in 2 files changed: 1 ins; 3 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/11020.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11020/head:pull/11020

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


From jwaters at openjdk.org  Thu Nov 17 06:36:50 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 17 Nov 2022 06:36:50 GMT
Subject: RFR: 8296478: Rework 8282948 and 8282700 to use the new autoconf
 UTIL_ARG_WITH [v5]
In-Reply-To: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
References: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
Message-ID: <8S8N1iXr8G3iTrIlHh4BzaLxgNw6yFBNBKVS0uChsJI=.514e8478-3a44-4a6f-a38d-7304588c8213@github.com>

> 8285093 introduced the new UTIL_ARG_WITH definition, which was not available when both 8282948 and 8282700 were written. They can now be moved to using the cleaner logic that UTIL_ARG_WITH grants.
> 
> There are many more options that still use AC_ARG_WITH in jdk-version.m4. They are out of the scope of this commit, which aims only to rework the previous integrated commits mentioned above.

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

  Uh oh

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11020/files
  - new: https://git.openjdk.org/jdk/pull/11020/files/239c88af..4cbd7207

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

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

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


From jwaters at openjdk.org  Thu Nov 17 06:36:53 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 17 Nov 2022 06:36:53 GMT
Subject: RFR: 8296478: Rework 8282948 and 8282700 to use the new autoconf
 UTIL_ARG_WITH [v2]
In-Reply-To: <xsA_zEozmr44E_zlgOxijO5q1ngsV52nCzvXr1nn9UQ=.c5ed07a4-5a33-430c-af5c-f562eab482dd@github.com>
References: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
 <WXiInV6g7gltKihp6pg6kd3kVtX9EIB-yX7YQI34LYk=.162eb88a-c4cb-464c-8a26-dd1db571ed99@github.com>
 <xsA_zEozmr44E_zlgOxijO5q1ngsV52nCzvXr1nn9UQ=.c5ed07a4-5a33-430c-af5c-f562eab482dd@github.com>
Message-ID: <PmdVZbLXmx5sUAfa7rUZY3xKPQgs3kzSG2UHNyiHpw0=.98edc892-f3e4-4fd2-b086-31fff6ebf24d@github.com>

On Wed, 16 Nov 2022 19:33:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> 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 two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into util
>>  - Squash
>
> make/autoconf/jdk-version.m4 line 82:
> 
>> 80:   UTIL_ARG_WITH(NAME: build-user, TYPE: string,
>> 81:     RESULT: USERNAME,
>> 82:     DEFAULT: $USERNAME,
> 
> This looks like the same values flow in and out of the function. Maybe call the fallback value `DEFAULT_USERNAME`?

Resolved, thanks

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

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


From jwaters at openjdk.org  Thu Nov 17 07:16:39 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 17 Nov 2022 07:16:39 GMT
Subject: RFR: 8296478: Rework 8282948 and 8282700 to use the new autoconf
 UTIL_ARG_WITH
In-Reply-To: <4y0I-QpW7qUSZHuAH1_huwqoGJU4aSVeMaNNkfpJq6s=.1362b9d2-882f-482d-98e8-2dd59a0a7d53@github.com>
References: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
 <eYuT5uT-g4oRVyDYTyI-nX9peUMs_NibOWH_qMWcCZM=.ce9d1206-4efa-4085-a95c-12a06e8681b1@github.com>
 <4y0I-QpW7qUSZHuAH1_huwqoGJU4aSVeMaNNkfpJq6s=.1362b9d2-882f-482d-98e8-2dd59a0a7d53@github.com>
Message-ID: <qhmjKQLtgmj5ae4SOnf_0-3L0OJoa_l1Ayfw8wUQJz0=.0f9fa665-4859-44d4-80d3-b0d7c36ef319@github.com>

On Wed, 16 Nov 2022 19:44:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > For one reason or another this particular flag simply refuses to work properly with UTIL_ARG_WITH, and after numerous attempts I'm completely lost as to how to make it function without crashing autoconf halfway through before the configure script is even generated
> 
> This sounds like the typical case that happens if you inadvertently write the name of a macro ("function") that gets expanded. Like this:
> 
> ```
> AC_DEFUN([TEST_FOO],
> [
>    echo Debug: we are running in TEST_FOO
> ])
> ```
> 
> will fail to compile with a stack overflow, since the `TEST_FOO` in the debug output will be recursively expanded with the function we're trying to expand. (Been there, done that, has produced profanities over autoconf enough to guarantee me a very hot place in the afterlife, before I figured that one out...)
> 
> So check if you are trying to write a "keyword" where a substring matches some other defined macro.

Scoured the following for any of the related issues you pointed out, can't seem to figure out what I'm overwriting or doing wrong though :(
(I'm only using the IF_GIVEN block for demonstration purposes, I'll change it to CHECK_VALUE later on, but see above for a problem I picked up while doing so)

UTIL_ARG_WITH(NAME: vendor-name, TYPE: string,
  RESULT: COMPANY_NAME,
  DEFAULT: $DEFAULT_COMPANY_NAME,
  DESC: [Set vendor name. Among others, used to set the 'java.vendor'
     and 'java.vm.vendor' system properties.],
  DEFAULT_DESC: [not specified],
  IF_GIVEN: [
    if test "x$COMPANY_NAME" = x; then
      AC_MSG_ERROR([--with-vendor-name must have a value])
    elif [ ! [[ $COMPANY_NAME =~ ^[[:print:]]*$ ]] ]; then
      AC_MSG_ERROR([--with-vendor-name contains non-printing characters: $COMPANY_NAME])
    fi
  ])   
  AC_SUBST(COMPANY_NAME)


Runnable configure script is not up to date
Generating runnable configure script at /d/Eclipse/Workspace/jdk/build/.configure-support/generated-configure.sh
Using autoconf at /usr/bin/autoconf [autoconf (GNU Autoconf) 2.71]

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

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


From stefank at openjdk.org  Thu Nov 17 08:16:28 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 17 Nov 2022 08:16:28 GMT
Subject: RFR: 8296886: Fix various include sort order issues [v2]
In-Reply-To: <JjDvqbScU0zoekDaaXbN4IUU0bv9tdm2Pvev5sqVggw=.e17fde8e-4462-4803-88e8-d1af700812e7@github.com>
References: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
 <JjDvqbScU0zoekDaaXbN4IUU0bv9tdm2Pvev5sqVggw=.e17fde8e-4462-4803-88e8-d1af700812e7@github.com>
Message-ID: <HAQlrE-kNn9bi_clIGTIEp059Ub1t_BUMzBg3dy6NuY=.91ee39cc-62d8-4fea-8f89-e953be9f2c99@github.com>

On Wed, 16 Nov 2022 16:17:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The sorted blocks of includes have deteriorated to the point that I felt compelled to clean up some of the issues.
>> 
>> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory, so I don't think that's a good enough argument, again IMHO. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share
 , just like the other platform-independent headers in HotSpot.
>> 
>> While going over the include headers I've also cleaned up surrounding whitespaces and incorrect include guards.
>
> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Cleanups
>  - Merge remote-tracking branch 'upstream/master' into various_include_order_fixes
>  - Various include order fixes

I've updated the patch for this RFR with just sort-order changes and a blank line fixes around the include blocks. Everything else has been moved out of this PR. I hope this limited version of this cleanup isn't too controversial.

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

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


From stefank at openjdk.org  Thu Nov 17 08:16:30 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 17 Nov 2022 08:16:30 GMT
Subject: RFR: 8296886: Fix various include sort order issues [v2]
In-Reply-To: <2lOleILw53UHm1WCmH4QPBsjbisb1h6H7Gz9jJRtJ8A=.139da306-4220-438c-be4c-64be6dc14c5d@github.com>
References: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
 <2lOleILw53UHm1WCmH4QPBsjbisb1h6H7Gz9jJRtJ8A=.139da306-4220-438c-be4c-64be6dc14c5d@github.com>
Message-ID: <g1eRfN33PRGjljH1Hog1tXax1eVZp5kqbrl1nOiOiWc=.67c1484a-a92d-44f0-924d-7daf2c2a80db@github.com>

On Fri, 11 Nov 2022 21:01:31 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Cleanups
>>  - Merge remote-tracking branch 'upstream/master' into various_include_order_fixes
>>  - Various include order fixes
>
> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 30:
> 
>> 28: #include "compiler/compiler_globals.hpp"
>> 29: #include "compiler/disassembler.hpp"
>> 30: #include "crc32c.h"
> 
> This ought to remain at the end, included using `CPU_HEADER_H("crc32c")`, but the file doesn't have the appropriate suffix.  I think the file name should be changed so that can be done.  This seems to be the only C++ file under cpu/ that doesn't have the appropriate suffix.  There are similarly "misnamed" files under various os/ subdirs; I didn't look for any in os_cpu/.

I'd like to defer that discussion to a separate RFE.

> src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp line 57:
> 
>> 55: #if !defined(__APPLE__) && !defined(__NetBSD__)
>> 56: #include <pthread.h>
>> 57: # include <pthread_np.h> /* For pthread_attr_get_np */
> 
> Remove unneeded space.

I reverted all such space cleanups, in the interest of getting the limited cleanup fixed. If we want to fix these spaces I'd like that to happen as a separate RFE.

> src/hotspot/share/cds/classListParser.cpp line 42:
> 
>> 40: #include "interpreter/bytecodeStream.hpp"
>> 41: #include "interpreter/linkResolver.hpp"
>> 42: #include "jimage.hpp"
> 
> Sorting jimage.hpp with hotspot/share stuff seems weird, and is kind of hiding this external dependency.  (It's coming from java.base.)

We can hopefully discuss this as a separate RFE.

> src/hotspot/share/prims/whitebox.cpp line 26:
> 
>> 24: 
>> 25: #include "precompiled.hpp"
>> 26: #include <new>
> 
> Why was `<new>` removed?

We tend to pull it in via memory/allocation.hpp. I can revert this, but I'm not sure it is important. There's no consistency in when we include `<new>` or not.

> test/hotspot/gtest/jfr/test_adaptiveSampler.cpp line 48:
> 
>> 46: #include "unittest.hpp"
>> 47: 
>> 48: #include <cmath>
> 
> Why is this after unittest.hpp?

System includes go after HotSpot includes.

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

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


From stefank at openjdk.org  Thu Nov 17 08:16:30 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 17 Nov 2022 08:16:30 GMT
Subject: RFR: 8296886: Fix various include sort order issues [v2]
In-Reply-To: <MfGGgkYsvTjqm5ClboYxOSRR5ar9iNUGAzINXl3gkOQ=.67e650a1-31b5-4cb4-a5bb-e62389c8c4ba@github.com>
References: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
 <2lOleILw53UHm1WCmH4QPBsjbisb1h6H7Gz9jJRtJ8A=.139da306-4220-438c-be4c-64be6dc14c5d@github.com>
 <MfGGgkYsvTjqm5ClboYxOSRR5ar9iNUGAzINXl3gkOQ=.67e650a1-31b5-4cb4-a5bb-e62389c8c4ba@github.com>
Message-ID: <i33cy0VH1KgvNnU7xyk41MZyVweNzlYzOh5fDplaESI=.6fcf06b6-a459-49a9-901d-f88f907c2f4a@github.com>

On Mon, 14 Nov 2022 11:39:10 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/os/windows/jvm_windows.cpp line 27:
>> 
>>> 25: #include "precompiled.hpp"
>>> 26: #include "include/jvm.h"
>>> 27: #include "os_windows.hpp"
>> 
>> os_windows should be at the end, included using `OS_HEADER("os")`.
>
> But should we be directly including os_windows.hpp, rather than including os.hpp?

Deferring those discussions to a potential separate RFE.

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

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


From ihse at openjdk.org  Thu Nov 17 09:21:53 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 17 Nov 2022 09:21:53 GMT
Subject: RFR: 8297041: Remove the last remnants of sjavac [v2]
In-Reply-To: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
Message-ID: <S69lflCZsor47KYO4-j5W7L1bC8wxHCqSsgV9oUxIiI=.921650ac-a4fa-46be-846d-483323511ad2@github.com>

> The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc.
> 
> Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code.
> 
> This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Fix weird imports
 - Update comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11185/files
  - new: https://git.openjdk.org/jdk/pull/11185/files/2124c86b..8ff38b78

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

  Stats: 77 lines in 15 files changed: 45 ins; 30 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11185.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11185/head:pull/11185

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


From ihse at openjdk.org  Thu Nov 17 09:23:35 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 17 Nov 2022 09:23:35 GMT
Subject: Integrated: 8297041: Remove the last remnants of sjavac
In-Reply-To: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
References: <71JasPR4nmrPa3xwWpxYt6rjkC1Kpm0wBHFauGfiQ7w=.3d7e200a-a732-4dfe-84a1-2953b7d6b30d@github.com>
Message-ID: <QWQArKF8QOhyEqhqmMxOp4Wu6BAldOHpEffOPzqYYuo=.cc2559f2-87f2-4aa4-99a8-6313aad6c66a@github.com>

On Wed, 16 Nov 2022 13:22:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc.
> 
> Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code.
> 
> This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place.

This pull request has now been integrated.

Changeset: 4527dc67
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4527dc67be6d238dcecd98c2aa05cbf0b8077e59
Stats:     12695 lines in 118 files changed: 1060 ins; 11561 del; 74 mod

8297041: Remove the last remnants of sjavac

Reviewed-by: cstein, erikj, jjg

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

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


From erikj at openjdk.org  Thu Nov 17 13:53:20 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 17 Nov 2022 13:53:20 GMT
Subject: RFR: 8296754: AutoCreateSharedArchive in JDK 20 is not compatible
 with JDK 19 [v3]
In-Reply-To: <LoXt--qKOhm1M40uk4SF8qpJakRuaTXU5Pr2eYwn_xk=.455ddfb0-c668-473c-b303-ffed70926257@github.com>
References: <bStp4S1ZwR75Ej89W2VAUL4Py7DfDgG03yggGWsZl8w=.200561aa-a37e-4a24-a70c-30be21601377@github.com>
 <LoXt--qKOhm1M40uk4SF8qpJakRuaTXU5Pr2eYwn_xk=.455ddfb0-c668-473c-b303-ffed70926257@github.com>
Message-ID: <uye-gXkSQ8CVkZ-xZ1VJLb7TiGY_uO7earXPL9ma5ms=.ffb4df65-f450-45d8-aed1-5b869ee314a4@github.com>

On Wed, 16 Nov 2022 22:30:56 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The -XX:+AutoCreateSharedArchive flag was implemented in JDK 19, however, this flag doesn't work across JDK 19 and 20.
>> 
>> Expected: JDK 20 should recreate the specified CDS archive
>> Actual: JDK 20 cannot recognize the archive file and gives up
>> 
>> The new field from GenericCDSFileMapHeader is now in FileMapHeader. Verified with tier 1-4 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test now passes

Makefile change looks good.

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

Marked as reviewed by erikj (Reviewer).

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


From matsaave at openjdk.org  Thu Nov 17 16:56:09 2022
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 17 Nov 2022 16:56:09 GMT
Subject: RFR: 8296754: AutoCreateSharedArchive in JDK 20 is not compatible
 with JDK 19 [v4]
In-Reply-To: <bStp4S1ZwR75Ej89W2VAUL4Py7DfDgG03yggGWsZl8w=.200561aa-a37e-4a24-a70c-30be21601377@github.com>
References: <bStp4S1ZwR75Ej89W2VAUL4Py7DfDgG03yggGWsZl8w=.200561aa-a37e-4a24-a70c-30be21601377@github.com>
Message-ID: <zJx_hZOYlr2NKwP734vJYEB3P--0VF1KEp7pB5OEYo0=.837e3857-9c8c-48ed-8100-2b2f04f6a1e7@github.com>

> The -XX:+AutoCreateSharedArchive flag was implemented in JDK 19, however, this flag doesn't work across JDK 19 and 20.
> 
> Expected: JDK 20 should recreate the specified CDS archive
> Actual: JDK 20 cannot recognize the archive file and gives up
> 
> The new field from GenericCDSFileMapHeader is now in FileMapHeader. Verified with tier 1-4 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Removed unused import

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11148/files
  - new: https://git.openjdk.org/jdk/pull/11148/files/4d168999..25e5ff72

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

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

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


From mikael at openjdk.org  Thu Nov 17 17:03:30 2022
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 17 Nov 2022 17:03:30 GMT
Subject: RFR: 8297165: Update Pandoc to version 2.19.2 for Oracle builds
 [v2]
In-Reply-To: <D7kuoIsCfr1vEqV0a0lyLz9UEFOCK_uY_A_Yz7ZHGFA=.06308e1b-404b-47aa-9800-cee7a650a73b@github.com>
References: <XH7qOax47e6K3-D5B-zNwHkYI25VhrdbRz_6Urqve1c=.26346100-fa53-443c-ac23-19e10b18b3ca@github.com>
 <D7kuoIsCfr1vEqV0a0lyLz9UEFOCK_uY_A_Yz7ZHGFA=.06308e1b-404b-47aa-9800-cee7a650a73b@github.com>
Message-ID: <q_JRNlXBjQHDPVoQzeFPj0ob5fDd-WwmnxOA97tc2wc=.728b50f9-6167-4cba-a8ce-6a954b2cb36f@github.com>

On Wed, 16 Nov 2022 23:11:58 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> Update to Pandoc 2.19.2 for all Oracle platforms/builds. This updates the createPandocBundle.sh script to reflect the bundle layout of the latest upstream pandoc bundles, and adds support for an optional platform argument to the script.
>
> Mikael Vidstedt 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:
> 
>  - Merge branch 'master' into 8297165-pandoc-2.19.2
>  - Update copyright year
>  - Move platform specific logic
>  - 8297165: Update Pandoc to version 2.19.2 for Oracle builds

Thank you!

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

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


From mikael at openjdk.org  Thu Nov 17 17:07:17 2022
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 17 Nov 2022 17:07:17 GMT
Subject: Integrated: 8297165: Update Pandoc to version 2.19.2 for Oracle builds
In-Reply-To: <XH7qOax47e6K3-D5B-zNwHkYI25VhrdbRz_6Urqve1c=.26346100-fa53-443c-ac23-19e10b18b3ca@github.com>
References: <XH7qOax47e6K3-D5B-zNwHkYI25VhrdbRz_6Urqve1c=.26346100-fa53-443c-ac23-19e10b18b3ca@github.com>
Message-ID: <4nGaylNLHgrZ1TQnYpCNanHMUqDSq249-DQ2Nw6YqNo=.cd103fc6-1949-4149-b028-cb8c61460f22@github.com>

On Wed, 16 Nov 2022 22:02:43 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Update to Pandoc 2.19.2 for all Oracle platforms/builds. This updates the createPandocBundle.sh script to reflect the bundle layout of the latest upstream pandoc bundles, and adds support for an optional platform argument to the script.

This pull request has now been integrated.

Changeset: 9c432a09
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9c432a09dbf1824d793cc1a49b533e57f2316b62
Stats:     31 lines in 2 files changed: 10 ins; 15 del; 6 mod

8297165: Update Pandoc to version 2.19.2 for Oracle builds

Reviewed-by: erikj

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

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


From achung at openjdk.org  Thu Nov 17 19:16:31 2022
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 17 Nov 2022 19:16:31 GMT
Subject: RFR: 8297088: Update LCMS to 2.14
Message-ID: <dNSastNjApaqQREyv3DDYY-uEfyXn9Mfjp_4hXgcpOk=.24e9897d-a556-4b34-b315-b1be2ba46735@github.com>

Redo of 8295369: Update LCMS to 2.14
Update LCMS to newest release.
Updated DISABLED_WARNINGS_gcc for LCMS to include type limits to prevent a build error in linux.
Automatic tests and J2D demo tests were run.

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

Commit messages:
 - disabled warning for type-limits for lcms
 - 8295369: Update LCMS to 2.14

Changes: https://git.openjdk.org/jdk/pull/11217/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11217&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297088
  Stats: 2138 lines in 32 files changed: 1546 ins; 134 del; 458 mod
  Patch: https://git.openjdk.org/jdk/pull/11217.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11217/head:pull/11217

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


From erikj at openjdk.org  Thu Nov 17 20:38:44 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 17 Nov 2022 20:38:44 GMT
Subject: RFR: 8297088: Update LCMS to 2.14
In-Reply-To: <dNSastNjApaqQREyv3DDYY-uEfyXn9Mfjp_4hXgcpOk=.24e9897d-a556-4b34-b315-b1be2ba46735@github.com>
References: <dNSastNjApaqQREyv3DDYY-uEfyXn9Mfjp_4hXgcpOk=.24e9897d-a556-4b34-b315-b1be2ba46735@github.com>
Message-ID: <04uBn0FTAqiDocPk9RgbcjcuP5pXhJmiASyZqKb4S7o=.714e7a70-008e-4b86-97da-7015cccda764@github.com>

On Thu, 17 Nov 2022 19:05:36 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Redo of 8295369: Update LCMS to 2.14
> Update LCMS to newest release.
> Updated DISABLED_WARNINGS_gcc for LCMS to include type limits to prevent a build error in linux.
> Automatic tests and J2D demo tests were run.

Build change looks good.

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

Marked as reviewed by erikj (Reviewer).

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


From matsaave at openjdk.org  Thu Nov 17 21:46:45 2022
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 17 Nov 2022 21:46:45 GMT
Subject: RFR: 8296754: AutoCreateSharedArchive in JDK 20 is not compatible
 with JDK 19 [v5]
In-Reply-To: <bStp4S1ZwR75Ej89W2VAUL4Py7DfDgG03yggGWsZl8w=.200561aa-a37e-4a24-a70c-30be21601377@github.com>
References: <bStp4S1ZwR75Ej89W2VAUL4Py7DfDgG03yggGWsZl8w=.200561aa-a37e-4a24-a70c-30be21601377@github.com>
Message-ID: <aR-wSfDP2l1zX1Lxl19eHmoNtWn6bi7_iq_CADf_VJo=.3dbb5544-8142-4017-a403-432f557fc72c@github.com>

> The -XX:+AutoCreateSharedArchive flag was implemented in JDK 19, however, this flag doesn't work across JDK 19 and 20.
> 
> Expected: JDK 20 should recreate the specified CDS archive
> Actual: JDK 20 cannot recognize the archive file and gives up
> 
> The new field from GenericCDSFileMapHeader is now in FileMapHeader. Verified with tier 1-4 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Added newline to end of test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11148/files
  - new: https://git.openjdk.org/jdk/pull/11148/files/25e5ff72..718b4f64

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

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

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


From clanger at openjdk.org  Thu Nov 17 21:47:22 2022
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 17 Nov 2022 21:47:22 GMT
Subject: RFR: 8296904: Improve handling of macos xcode toolchain [v4]
In-Reply-To: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
References: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
Message-ID: <ol7aMwcrVu33PVUBWrFUB-IW_KK-yFHUziUSQ6Pgzu8=.854ae7da-d943-4b1b-883f-7693617bbcd1@github.com>

> With this PR I'd like to make it easier to use dedicated installations of Xcode on Mac OS for OpenJDK builds without having to switch the active Xcode globally via `xcode-select`.
> 
> I propose adding a new configure flag `--with-xcode-path` that takes the path to an Xcode installation. If the option is set, this path is expanded to a valid `TOOLCHAIN_PATH`.
> 
> Furthermore, I fix detection of xcodebuild and correctly setting the sysroot from the toolchain by moving `AC_SUBST(TOOLCHAIN_PATH)` before calling `BASIC_SETUP_XCODE_SYSROOT` and honoring `TOOLCHAIN_PATH` in `BASIC_SETUP_XCODE_SYSROOT` in the case when no devkit is specified. As I see it, this is a viable fix, even if not introducing `--with-xcode-path`.

Christoph Langer 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 five additional commits since the last revision:

 - Updating building.md doc
 - Merge branch 'master' into xcode-toolchain
 - Review suggestion
 - Merge branch 'master' into xcode-toolchain
 - Improve options for xcode toolchain

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11113/files
  - new: https://git.openjdk.org/jdk/pull/11113/files/312c5b06..e6daa708

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

  Stats: 19242 lines in 434 files changed: 5192 ins; 12747 del; 1303 mod
  Patch: https://git.openjdk.org/jdk/pull/11113.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11113/head:pull/11113

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


From clanger at openjdk.org  Thu Nov 17 21:50:18 2022
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 17 Nov 2022 21:50:18 GMT
Subject: RFR: 8296904: Improve handling of macos xcode toolchain [v5]
In-Reply-To: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
References: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
Message-ID: <uaU60OO3v2WDdUrzp3HHXoJgEUzw4vaE3Dv4QQeteY8=.d5d46dc2-3570-4f42-a1b2-0a7b617fb244@github.com>

> With this PR I'd like to make it easier to use dedicated installations of Xcode on Mac OS for OpenJDK builds without having to switch the active Xcode globally via `xcode-select`.
> 
> I propose adding a new configure flag `--with-xcode-path` that takes the path to an Xcode installation. If the option is set, this path is expanded to a valid `TOOLCHAIN_PATH`.
> 
> Furthermore, I fix detection of xcodebuild and correctly setting the sysroot from the toolchain by moving `AC_SUBST(TOOLCHAIN_PATH)` before calling `BASIC_SETUP_XCODE_SYSROOT` and honoring `TOOLCHAIN_PATH` in `BASIC_SETUP_XCODE_SYSROOT` in the case when no devkit is specified. As I see it, this is a viable fix, even if not introducing `--with-xcode-path`.

Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:

  Minor polishing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11113/files
  - new: https://git.openjdk.org/jdk/pull/11113/files/e6daa708..8190d598

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

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

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


From clanger at openjdk.org  Thu Nov 17 21:54:53 2022
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 17 Nov 2022 21:54:53 GMT
Subject: RFR: 8296904: Improve handling of macos xcode toolchain [v6]
In-Reply-To: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
References: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
Message-ID: <3wayRxjHwIyBEXzD5roxgtqPlpGwA1I64MxIH4zFVpk=.d334295c-6e34-4311-8edc-80033ff00686@github.com>

> With this PR I'd like to make it easier to use dedicated installations of Xcode on Mac OS for OpenJDK builds without having to switch the active Xcode globally via `xcode-select`.
> 
> I propose adding a new configure flag `--with-xcode-path` that takes the path to an Xcode installation. If the option is set, this path is expanded to a valid `TOOLCHAIN_PATH`.
> 
> Furthermore, I fix detection of xcodebuild and correctly setting the sysroot from the toolchain by moving `AC_SUBST(TOOLCHAIN_PATH)` before calling `BASIC_SETUP_XCODE_SYSROOT` and honoring `TOOLCHAIN_PATH` in `BASIC_SETUP_XCODE_SYSROOT` in the case when no devkit is specified. As I see it, this is a viable fix, even if not introducing `--with-xcode-path`.

Christoph Langer has updated the pull request incrementally with two additional commits since the last revision:

 - Add dots
 - Whitespace stuff

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11113/files
  - new: https://git.openjdk.org/jdk/pull/11113/files/8190d598..f066f764

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

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

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


From clanger at openjdk.org  Thu Nov 17 21:54:54 2022
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 17 Nov 2022 21:54:54 GMT
Subject: RFR: 8296904: Improve handling of macos xcode toolchain [v3]
In-Reply-To: <7diU14c5he7ck398JBB9xOORGw-5ky3Tek-6Wi8yjE0=.cb65f54f-cdf2-4418-af8e-022cabd6eb53@github.com>
References: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
 <qOWYOLTicFL1YEmGaFrRWhhQnXe7g-4KEjVsCox8RAM=.7e644243-089f-4300-8000-6a6b57be1c56@github.com>
 <7diU14c5he7ck398JBB9xOORGw-5ky3Tek-6Wi8yjE0=.cb65f54f-cdf2-4418-af8e-022cabd6eb53@github.com>
Message-ID: <Sm_BJupfRuNXXjE_ocJDsoYDFveqv0xZYAY6EO4ErsU=.47bed3a4-48ff-4513-a82a-58b27d9454e7@github.com>

On Wed, 16 Nov 2022 19:52:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Is there perhaps some documentation in doc/building.md that needs updating? I know there is a bit written about Xcode, I can imagine some pointers to this new argument would fit in there.

Good suggestion. I made some edits in building.md. Please have a look. Also, what about building.html? Is this generated and if so, how can I regenerate it?

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

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


From serb at openjdk.org  Fri Nov 18 08:44:24 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 18 Nov 2022 08:44:24 GMT
Subject: RFR: 8297088: Update LCMS to 2.14
In-Reply-To: <dNSastNjApaqQREyv3DDYY-uEfyXn9Mfjp_4hXgcpOk=.24e9897d-a556-4b34-b315-b1be2ba46735@github.com>
References: <dNSastNjApaqQREyv3DDYY-uEfyXn9Mfjp_4hXgcpOk=.24e9897d-a556-4b34-b315-b1be2ba46735@github.com>
Message-ID: <ipiXX_herQFr9T35SL10vIC3cIbIp_w1E-Xy_8mb_oU=.5b9f5d94-7ac8-4ab1-ae36-63d3b735de56@github.com>

On Thu, 17 Nov 2022 19:05:36 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Redo of 8295369: Update LCMS to 2.14
> Update LCMS to newest release.
> Updated DISABLED_WARNINGS_gcc for LCMS to include type limits to prevent a build error in linux.
> Automatic tests and J2D demo tests were run.

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

> 306:         libawt/java2d, \
> 307:     HEADERS_FROM_SRC := $(LIBLCMS_HEADERS_FROM_SRC), \
> 308:     DISABLED_WARNINGS_gcc := format-nonliteral type-limits stringop-truncation, \

it would be good to report this upstream.

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

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


From serb at openjdk.org  Fri Nov 18 09:12:20 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 18 Nov 2022 09:12:20 GMT
Subject: RFR: 8297088: Update LCMS to 2.14
In-Reply-To: <dNSastNjApaqQREyv3DDYY-uEfyXn9Mfjp_4hXgcpOk=.24e9897d-a556-4b34-b315-b1be2ba46735@github.com>
References: <dNSastNjApaqQREyv3DDYY-uEfyXn9Mfjp_4hXgcpOk=.24e9897d-a556-4b34-b315-b1be2ba46735@github.com>
Message-ID: <8KhAMgOEU6RSj_jo8w0HUrWfwI-sNvrfQVmkdr_OGgo=.9b1f6754-9c1f-4b81-bfdb-67d16dc8005c@github.com>

On Thu, 17 Nov 2022 19:05:36 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Redo of 8295369: Update LCMS to 2.14
> Update LCMS to newest release.
> Updated DISABLED_WARNINGS_gcc for LCMS to include type limits to prevent a build error in linux.
> Automatic tests and J2D demo tests were run.

Marked as reviewed by serb (Reviewer).

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

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


From jwaters at openjdk.org  Fri Nov 18 09:21:42 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 18 Nov 2022 09:21:42 GMT
Subject: RFR: 8296478: Rework 8282948 and 8282700 to use the new autoconf
 UTIL_ARG_WITH [v5]
In-Reply-To: <8S8N1iXr8G3iTrIlHh4BzaLxgNw6yFBNBKVS0uChsJI=.514e8478-3a44-4a6f-a38d-7304588c8213@github.com>
References: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
 <8S8N1iXr8G3iTrIlHh4BzaLxgNw6yFBNBKVS0uChsJI=.514e8478-3a44-4a6f-a38d-7304588c8213@github.com>
Message-ID: <LYIifAMPJQTyKYBCREQJ829-o_pqL4W_2V3-gvJccgY=.d57dc64a-991b-4295-a43b-96b21191cccb@github.com>

On Thu, 17 Nov 2022 06:36:50 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> 8285093 introduced the new UTIL_ARG_WITH definition, which was not available when both 8282948 and 8282700 were written. They can now be moved to using the cleaner logic that UTIL_ARG_WITH grants.
>> 
>> There are many more options that still use AC_ARG_WITH in jdk-version.m4. They are out of the scope of this commit, which aims only to rework the previous integrated commits mentioned above.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Uh oh

I've found the reason after headbanging for quite a while:
`DESC: [Set vendor name. Among others, used to set the 'java.vendor' and 'java.vm.vendor' system properties.]`

It's the comma in between "Among others, used to set...". This seems like a general flaw in UTIL_ARG_WITH and (I believe?) more fundamentally in UTIL_DEFUN_NAMED. I could rewrite the message itself to not have the comma and bypass this entirely, but I'll refrain from doing so since I doubt you'd want this bug to continue persisting silently where it might end up rearing its ugly head when it's used again in future commits

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

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


From ihse at openjdk.org  Fri Nov 18 11:11:25 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 18 Nov 2022 11:11:25 GMT
Subject: RFR: 8296904: Improve handling of macos xcode toolchain [v6]
In-Reply-To: <3wayRxjHwIyBEXzD5roxgtqPlpGwA1I64MxIH4zFVpk=.d334295c-6e34-4311-8edc-80033ff00686@github.com>
References: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
 <3wayRxjHwIyBEXzD5roxgtqPlpGwA1I64MxIH4zFVpk=.d334295c-6e34-4311-8edc-80033ff00686@github.com>
Message-ID: <dh0mAcyc5ehp9tg-e1ghFPALovcGqYGLyC0D2gzXYpM=.c019cb4b-889d-4da4-bf4b-d3cfcb21f0ca@github.com>

On Thu, 17 Nov 2022 21:54:53 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> With this PR I'd like to make it easier to use dedicated installations of Xcode on Mac OS for OpenJDK builds without having to switch the active Xcode globally via `xcode-select`.
>> 
>> I propose adding a new configure flag `--with-xcode-path` that takes the path to an Xcode installation. If the option is set, this path is expanded to a valid `TOOLCHAIN_PATH`.
>> 
>> Furthermore, I fix detection of xcodebuild and correctly setting the sysroot from the toolchain by moving `AC_SUBST(TOOLCHAIN_PATH)` before calling `BASIC_SETUP_XCODE_SYSROOT` and honoring `TOOLCHAIN_PATH` in `BASIC_SETUP_XCODE_SYSROOT` in the case when no devkit is specified. As I see it, this is a viable fix, even if not introducing `--with-xcode-path`.
>
> Christoph Langer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add dots
>  - Whitespace stuff

It is generated, and you can re-generate it using `make update-build-docs`. However, you need to have the same version of pandoc installed and configured, otherwise you'll get a lot of spurious changes. 

To help you out, I checked out your branch and regenerated it for you. You can find it at https://github.com/openjdk/jdk/commit/66ef4b730656daeb4108f7118b92dea3e8da6475 (from https://github.com/magicus/jdk/tree/xcode-toolchain). If you are not a git wrangling pro, you can download it as a diff and apply it locally by appending `.diff`: https://github.com/openjdk/jdk/commit/66ef4b730656daeb4108f7118b92dea3e8da6475.diff

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

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


From ihse at openjdk.org  Fri Nov 18 11:31:19 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 18 Nov 2022 11:31:19 GMT
Subject: RFR: 8296478: Rework 8282948 and 8282700 to use the new autoconf
 UTIL_ARG_WITH [v5]
In-Reply-To: <8S8N1iXr8G3iTrIlHh4BzaLxgNw6yFBNBKVS0uChsJI=.514e8478-3a44-4a6f-a38d-7304588c8213@github.com>
References: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
 <8S8N1iXr8G3iTrIlHh4BzaLxgNw6yFBNBKVS0uChsJI=.514e8478-3a44-4a6f-a38d-7304588c8213@github.com>
Message-ID: <DFOaxSVc2s3jfKITRsn10IKr45zBiuNuSrX7Mh7G-X8=.f9dec2d0-5956-4f7c-831d-876d49b9edf7@github.com>

On Thu, 17 Nov 2022 06:36:50 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> 8285093 introduced the new UTIL_ARG_WITH definition, which was not available when both 8282948 and 8282700 were written. They can now be moved to using the cleaner logic that UTIL_ARG_WITH grants.
>> 
>> There are many more options that still use AC_ARG_WITH in jdk-version.m4. They are out of the scope of this commit, which aims only to rework the previous integrated commits mentioned above.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Uh oh

Aaaahhh, **that** bug. I've run into that before. I did attempt to fix it but after wasting too many hours I gave up. :-( It seems to be a limitation in m4 that I cannot understand how to get around. At some point, the string literal, even though quoted inside the `[...]`, is expanded and parsed as m4 macro expansion arguments. In theory, I should have been able to add an additional layer of quoting and then un-quote it once it was past the problematic point, but that did not work.

I solved the problem by not solving it, and instead rephrased the message to not need the comma. (Imho, this limitation actually improved the quality of the descriptions, so it was not bad per se).

But I agree that it is annoying to have such a limitation in `UTIL_DEFUN_NAMED`. If you want to have a go at trying to solve it, please do! I'll fully admit my shortcomings and state that trying to solve this passes my knowledge and ability to manipulate m4. 

Or, maybe, you could add some documentation to `UTIL_DEFUN_NAMED` and `UTIL_ARG_WITH`, saying that comma is not allowed in the values.

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

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


From clanger at openjdk.org  Fri Nov 18 12:03:31 2022
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 18 Nov 2022 12:03:31 GMT
Subject: RFR: 8296904: Improve handling of macos xcode toolchain [v7]
In-Reply-To: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
References: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
Message-ID: <roPCi0YiyCvNYuu4jcFdnbFR96spcejgToX831TJoow=.1f42f311-286b-4b45-ab97-39155ecaa1ff@github.com>

> With this PR I'd like to make it easier to use dedicated installations of Xcode on Mac OS for OpenJDK builds without having to switch the active Xcode globally via `xcode-select`.
> 
> I propose adding a new configure flag `--with-xcode-path` that takes the path to an Xcode installation. If the option is set, this path is expanded to a valid `TOOLCHAIN_PATH`.
> 
> Furthermore, I fix detection of xcodebuild and correctly setting the sysroot from the toolchain by moving `AC_SUBST(TOOLCHAIN_PATH)` before calling `BASIC_SETUP_XCODE_SYSROOT` and honoring `TOOLCHAIN_PATH` in `BASIC_SETUP_XCODE_SYSROOT` in the case when no devkit is specified. As I see it, this is a viable fix, even if not introducing `--with-xcode-path`.

Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:

  Update html file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11113/files
  - new: https://git.openjdk.org/jdk/pull/11113/files/f066f764..df6d46f0

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

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

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


From clanger at openjdk.org  Fri Nov 18 12:06:39 2022
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 18 Nov 2022 12:06:39 GMT
Subject: RFR: 8296904: Improve handling of macos xcode toolchain [v8]
In-Reply-To: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
References: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
Message-ID: <5YbIcpQJvPO9c2oM87PR83dz1fYAQ5m1E1eGdeN8SNg=.f9f1650e-54c6-4c07-bf92-eec2cba3ed42@github.com>

> With this PR I'd like to make it easier to use dedicated installations of Xcode on Mac OS for OpenJDK builds without having to switch the active Xcode globally via `xcode-select`.
> 
> I propose adding a new configure flag `--with-xcode-path` that takes the path to an Xcode installation. If the option is set, this path is expanded to a valid `TOOLCHAIN_PATH`.
> 
> Furthermore, I fix detection of xcodebuild and correctly setting the sysroot from the toolchain by moving `AC_SUBST(TOOLCHAIN_PATH)` before calling `BASIC_SETUP_XCODE_SYSROOT` and honoring `TOOLCHAIN_PATH` in `BASIC_SETUP_XCODE_SYSROOT` in the case when no devkit is specified. As I see it, this is a viable fix, even if not introducing `--with-xcode-path`.

Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:

  Fix enumeration for html

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11113/files
  - new: https://git.openjdk.org/jdk/pull/11113/files/df6d46f0..f689fa15

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

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

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


From clanger at openjdk.org  Fri Nov 18 12:20:19 2022
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 18 Nov 2022 12:20:19 GMT
Subject: RFR: 8296904: Improve handling of macos xcode toolchain [v8]
In-Reply-To: <5YbIcpQJvPO9c2oM87PR83dz1fYAQ5m1E1eGdeN8SNg=.f9f1650e-54c6-4c07-bf92-eec2cba3ed42@github.com>
References: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
 <5YbIcpQJvPO9c2oM87PR83dz1fYAQ5m1E1eGdeN8SNg=.f9f1650e-54c6-4c07-bf92-eec2cba3ed42@github.com>
Message-ID: <ykEZH_Le4bV-jJpY8x6_eqQJ9t-_VBlY9YqqoJfHFjs=.48106b46-3c36-48b5-8938-9ce4a66f7611@github.com>

On Fri, 18 Nov 2022 12:06:39 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> With this PR I'd like to make it easier to use dedicated installations of Xcode on Mac OS for OpenJDK builds without having to switch the active Xcode globally via `xcode-select`.
>> 
>> I propose adding a new configure flag `--with-xcode-path` that takes the path to an Xcode installation. If the option is set, this path is expanded to a valid `TOOLCHAIN_PATH`.
>> 
>> Furthermore, I fix detection of xcodebuild and correctly setting the sysroot from the toolchain by moving `AC_SUBST(TOOLCHAIN_PATH)` before calling `BASIC_SETUP_XCODE_SYSROOT` and honoring `TOOLCHAIN_PATH` in `BASIC_SETUP_XCODE_SYSROOT` in the case when no devkit is specified. As I see it, this is a viable fix, even if not introducing `--with-xcode-path`.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix enumeration for html

> It is generated, and you can re-generate it using `make update-build-docs`. However, you need to have the same version of pandoc installed and configured, otherwise you'll get a lot of spurious changes.
> 
> To help you out, I checked out your branch and regenerated it for you. You can find it at [66ef4b7](https://github.com/openjdk/jdk/commit/66ef4b730656daeb4108f7118b92dea3e8da6475) (from https://github.com/magicus/jdk/tree/xcode-toolchain). If you are not a git wrangling pro, you can download it as a diff and apply it locally by appending `.diff`: https://github.com/openjdk/jdk/commit/66ef4b730656daeb4108f7118b92dea3e8da6475.diff

Woho, [66ef4b7] is a super power trick ? I've added it and then figured out that my new enumeration isn't displayed well in html. Can you please regnerate it once more?

Other than that, are my edits ok?

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

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


From jwaters at openjdk.org  Fri Nov 18 12:34:22 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 18 Nov 2022 12:34:22 GMT
Subject: RFR: 8296478: Rework 8282948 and 8282700 to use the new autoconf
 UTIL_ARG_WITH [v5]
In-Reply-To: <DFOaxSVc2s3jfKITRsn10IKr45zBiuNuSrX7Mh7G-X8=.f9dec2d0-5956-4f7c-831d-876d49b9edf7@github.com>
References: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
 <8S8N1iXr8G3iTrIlHh4BzaLxgNw6yFBNBKVS0uChsJI=.514e8478-3a44-4a6f-a38d-7304588c8213@github.com>
 <DFOaxSVc2s3jfKITRsn10IKr45zBiuNuSrX7Mh7G-X8=.f9dec2d0-5956-4f7c-831d-876d49b9edf7@github.com>
Message-ID: <VUyT_W0U4JcmMlpG8_gCmO_uQDwQY-MM-REibjMICIQ=.8e26258b-c71a-4eb2-887a-9760db0085cb@github.com>

On Fri, 18 Nov 2022 11:27:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Aaaahhh, **that** bug. I've run into that before. I did attempt to fix it but after wasting too many hours I gave up. :-( It seems to be a limitation in m4 that I cannot understand how to get around. At some point, the string literal, even though quoted inside the `[...]`, is expanded and parsed as m4 macro expansion arguments. In theory, I should have been able to add an additional layer of quoting and then un-quote it once it was past the problematic point, but that did not work.
> 
> I solved the problem by not solving it, and instead rephrased the message to not need the comma. (Imho, this limitation actually improved the quality of the descriptions, so it was not bad per se).
> 
> But I agree that it is annoying to have such a limitation in `UTIL_DEFUN_NAMED`. If you want to have a go at trying to solve it, please do! I'll fully admit my shortcomings and state that trying to solve this passes my knowledge and ability to manipulate m4.
> 
> Or, maybe, you could add some documentation to `UTIL_DEFUN_NAMED` and `UTIL_ARG_WITH`, saying that comma is not allowed in the values.

Oh dear, I was looking to you for help with that one :( I'll see if there's a way to solve this on my end, but I really doubt I'll be able to if even you couldn't...

What I'm more worried about though is that this same issue also seems to be causing the problem I found when using CHECK_VALUE (see above) where it's actually outright deleting the square brackets in the code passed inside the block. I don't know why this didn't initially happen earlier when I re-ran configure with different options as per Erik's request, but I can verify that this affects all the "predicate" parameters of UTIL_ARG_WITH (IF_GIVEN, IF_NOT_GIVEN, etc). This is a way more serious problem that I doubt can be commented away with some documentation since it destroys several widely shell constructs that don't have any valid replacements, which is going to be pretty problematic

Side tangent - Is my usage of DEFAULT_DESC correct?

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

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


From ihse at openjdk.org  Fri Nov 18 12:45:19 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 18 Nov 2022 12:45:19 GMT
Subject: RFR: 8296904: Improve handling of macos xcode toolchain [v8]
In-Reply-To: <5YbIcpQJvPO9c2oM87PR83dz1fYAQ5m1E1eGdeN8SNg=.f9f1650e-54c6-4c07-bf92-eec2cba3ed42@github.com>
References: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
 <5YbIcpQJvPO9c2oM87PR83dz1fYAQ5m1E1eGdeN8SNg=.f9f1650e-54c6-4c07-bf92-eec2cba3ed42@github.com>
Message-ID: <TSQaJhXA1vfHO9-HAT12bjmoTktrtB1sRdVML4pD4uc=.2b971164-3998-4a4c-a902-44dd0dbcc892@github.com>

On Fri, 18 Nov 2022 12:06:39 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> With this PR I'd like to make it easier to use dedicated installations of Xcode on Mac OS for OpenJDK builds without having to switch the active Xcode globally via `xcode-select`.
>> 
>> I propose adding a new configure flag `--with-xcode-path` that takes the path to an Xcode installation. If the option is set, this path is expanded to a valid `TOOLCHAIN_PATH`.
>> 
>> Furthermore, I fix detection of xcodebuild and correctly setting the sysroot from the toolchain by moving `AC_SUBST(TOOLCHAIN_PATH)` before calling `BASIC_SETUP_XCODE_SYSROOT` and honoring `TOOLCHAIN_PATH` in `BASIC_SETUP_XCODE_SYSROOT` in the case when no devkit is specified. As I see it, this is a viable fix, even if not introducing `--with-xcode-path`.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix enumeration for html

Yes, I thought your edits were okay. I'll re-generated the html for you, and then I think you're good to go.

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

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


From chagedorn at openjdk.org  Fri Nov 18 16:01:44 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 18 Nov 2022 16:01:44 GMT
Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed [v5]
In-Reply-To: <Cuo-hZ2dmp5Su2aMvYe3k_w_rEuzCk7F8wpeCsQuyMA=.911a0412-42c0-44a1-8863-e94e5a7970e7@github.com>
References: <Cuo-hZ2dmp5Su2aMvYe3k_w_rEuzCk7F8wpeCsQuyMA=.911a0412-42c0-44a1-8863-e94e5a7970e7@github.com>
Message-ID: <irqVZ-M8DFtPPlkymykuhvO4h-lCFDJ9MEApdDxq9Fs=.d641fd91-1bb3-4481-9f8b-5878507abdec@github.com>

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

 - Update algorithm to print char by char, skipping file separators on the fly and only caring about the actual filename (ignore prefix path when reading)
 - Merge branch 'master' into JDK-8293422
 - 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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10287/files
  - new: https://git.openjdk.org/jdk/pull/10287/files/24f624f8..0b759abe

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

  Stats: 265775 lines in 3415 files changed: 132953 ins; 91111 del; 41711 mod
  Patch: https://git.openjdk.org/jdk/pull/10287.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10287/head:pull/10287

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


From chagedorn at openjdk.org  Fri Nov 18 16:01:44 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 18 Nov 2022 16:01:44 GMT
Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed [v4]
In-Reply-To: <ofIMTnRPIIqTzVGjaaaBedoelHOGrD3aKbEi79M7RT8=.655c1544-0c68-4c21-90e1-38c276bb731e@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>
 <ZOj-Cb86tjWGXWJK8AQx4EB81bcerOGONb4P6vkPZkw=.0fb827e5-8c50-4174-a0fd-4f1142b8d4f2@github.com>
 <ofIMTnRPIIqTzVGjaaaBedoelHOGrD3aKbEi79M7RT8=.655c1544-0c68-4c21-90e1-38c276bb731e@github.com>
Message-ID: <WiqK7d5QLhQawRryMdQDnEG7-HVJXOohPSzIWgEQtzg=.729714c8-170d-4e08-8e12-f15333a49114@github.com>

On Wed, 16 Nov 2022 08:48:51 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Yes, I think it would be good to get a second review of the DWARF parser changes. Maybe @tstuefe?
>
>> Yes, I think it would be good to get a second review of the DWARF parser changes. Maybe @tstuefe?
> 
> I'm a bit swamped, but try to take a look later today.

I've pushed an update and changed the algorithm in the following way to address @tstuefe review comments:
- Just read and ignore the filenames from DWARF which do not correspond to the one we are looking for (i.e. when `current_index != file_index`).
- Reading the filename of interest (i.e. when `current_index == file_index`):
  - Read single chars and stop once the null terminator is found.
  - Reset buffer when file separator is found to skip the prefix path.
  - On `filename` buffer overflow: Keep reading, we could still be reading a path prefix and reset the buffer again when finding a file separator.
  - If filename does not fit into the provided buffer, use a generic overflow message `<OVERFLOW>`. If that does not fit either, use the minimal filename `L`. This allows to at least have the source information `L:line_no` which almost always is already enough to get to the actual source code location. Doing it in this way lets the parser succeed instead of failing.

I've added some additional tests for the overflow scenarios and enforced `get_source_info()` to only accept buffers with a length of at least 2 to always allow the minimal filename `L`.
 
Submitted some testing again in our CI (results look good so far) and additionally by running gtests with Clang slowdebug, fastdebug and release builds.

I've done some additional manual testing, both with GCC and Clang builds. I've also played around by changing the buffer size in `vmError.cpp`. It works as expected:
- buffer size 15, emitting `<OVERFLOW>` for filenames being too long:

V  [libjvm.so+0x8905fc]  CompileWrapper::~CompileWrapper()+0x56  (compile.cpp:492)
V  [libjvm.so+0x8921e6]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1652  (compile.cpp:864)
V  [libjvm.so+0x77d171]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x179  (c2compiler.cpp:113)
V  [libjvm.so+0x8b0fc4]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x8e8  (<OVERFLOW>:2237)
V  [libjvm.so+0x8afc3d]  CompileBroker::compiler_thread_loop()+0x3ed  (<OVERFLOW>:1916)
V  [libjvm.so+0x8d047c]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x72  (<OVERFLOW>:58)
V  [libjvm.so+0xc63342]  JavaThread::thread_main_inner()+0x144  (javaThread.cpp:699)
V  [libjvm.so+0xc631fa]  JavaThread::run()+0x182  (javaThread.cpp:684)
V  [libjvm.so+0x1337633]  Thread::call_run()+0x195  (thread.cpp:224)
V  [libjvm.so+0x10e38d7]  thread_native_entry(Thread*)+0x19b  (os_linux.cpp:710)

- buffer size 2, emitting `L` for all filenames (being too long):

V  [libjvm.so+0x8905fc]  CompileWrapper::~CompileWrapper()+0x56  (compile.cpp:492)
V  [libjvm.so+0x8921e6]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1652  (L:864)
V  [libjvm.so+0x77d171]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x179  (L:113)
V  [libjvm.so+0x8b0fc4]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x8e8  (L:2237)
V  [libjvm.so+0x8afc3d]  CompileBroker::compiler_thread_loop()+0x3ed  (L:1916)
V  [libjvm.so+0x8d047c]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x72  (L:58)
V  [libjvm.so+0xc6339c]  JavaThread::thread_main_inner()+0x144  (L:699)
V  [libjvm.so+0xc63254]  JavaThread::run()+0x182  (L:684)
V  [libjvm.so+0x1337693]  Thread::call_run()+0x195  (L:224)
V  [libjvm.so+0x10e3937]  thread_native_entry(Thread*)+0x19b  (L:710)

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

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


From chagedorn at openjdk.org  Fri Nov 18 16:01:44 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 18 Nov 2022 16:01:44 GMT
Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed [v4]
In-Reply-To: <S4pT9MhCorn5XvwppyTIKDMWmutvDzcZShwzGbvwGAA=.45cbb5d3-3ef0-4b9b-ba7c-0ad8ab7152b9@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>
 <3CD6ryhzVPUpiJTkeepDevEr96HfvCkLdCR2AzmxqoA=.db139ad6-cbb6-4791-a6d1-4d28e54fdcd1@github.com>
 <-LPuNwZylHWH7M8ifGeNw27j7T7-kQzbKa4y0H6cHvM=.8ea671b0-980d-4a81-94b6-1ddab48c1fea@github.com>
 <S4pT9MhCorn5XvwppyTIKDMWmutvDzcZShwzGbvwGAA=.45cbb5d3-3ef0-4b9b-ba7c-0ad8ab7152b9@github.com>
Message-ID: <B9rcIFrFva7wHxMfTGxdPIXDmKx6JUmfqdCKzcI6bpc=.b2af887c-6b7d-473d-a951-91e3598ae511@github.com>

On Wed, 16 Nov 2022 16:07:36 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> In theory, they don't need to be exposed in the sense of being declared in the header. But in terms of readability, I've decided to put them in the private block of class `LineNumberProgram` which is the only user of these methods. What would be the advantages of moving them completely to `elfFile.cpp` as static helper functions?
>
> Oh, I generally just prefer to keep things locally if possible. Slim interfaces, less polluted global namespace, possibly (though not here) less include deps. Don't worry, if you prefer it this way, keep it in.

I understand. I don't have a strong preference here but to be consistent with the existing DWARF parser code, I'd rather keep it like that.

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

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


From chagedorn at openjdk.org  Fri Nov 18 16:06:38 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 18 Nov 2022 16:06:38 GMT
Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed [v6]
In-Reply-To: <Cuo-hZ2dmp5Su2aMvYe3k_w_rEuzCk7F8wpeCsQuyMA=.911a0412-42c0-44a1-8863-e94e5a7970e7@github.com>
References: <Cuo-hZ2dmp5Su2aMvYe3k_w_rEuzCk7F8wpeCsQuyMA=.911a0412-42c0-44a1-8863-e94e5a7970e7@github.com>
Message-ID: <Npv8aIJVyGBNXUAtEStPlQfbUUaOsGjxulLp209l2bQ=.35ab9699-da60-4171-b04f-469c8d5f793a@github.com>

> 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 incrementally with one additional commit since the last revision:

  Remove unused local variable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10287/files
  - new: https://git.openjdk.org/jdk/pull/10287/files/0b759abe..3121d380

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

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

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


From stuefe at openjdk.org  Fri Nov 18 16:13:43 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 18 Nov 2022 16:13:43 GMT
Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed [v6]
In-Reply-To: <Npv8aIJVyGBNXUAtEStPlQfbUUaOsGjxulLp209l2bQ=.35ab9699-da60-4171-b04f-469c8d5f793a@github.com>
References: <Cuo-hZ2dmp5Su2aMvYe3k_w_rEuzCk7F8wpeCsQuyMA=.911a0412-42c0-44a1-8863-e94e5a7970e7@github.com>
 <Npv8aIJVyGBNXUAtEStPlQfbUUaOsGjxulLp209l2bQ=.35ab9699-da60-4171-b04f-469c8d5f793a@github.com>
Message-ID: <XfZSQ9aBPncxtqH_gXC2plIIxMjBq3huEbB4bmBDnCc=.635a6f46-e41b-4ff0-9ef1-5c3a0a6986e1@github.com>

On Fri, 18 Nov 2022 16:06:38 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 incrementally with one additional commit since the last revision:
> 
>   Remove unused local variable

Looks good. If tests are green, fine for me. Thanks!

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

Marked as reviewed by stuefe (Reviewer).

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


From ihse at openjdk.org  Fri Nov 18 16:34:19 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 18 Nov 2022 16:34:19 GMT
Subject: RFR: 8296904: Improve handling of macos xcode toolchain [v8]
In-Reply-To: <5YbIcpQJvPO9c2oM87PR83dz1fYAQ5m1E1eGdeN8SNg=.f9f1650e-54c6-4c07-bf92-eec2cba3ed42@github.com>
References: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
 <5YbIcpQJvPO9c2oM87PR83dz1fYAQ5m1E1eGdeN8SNg=.f9f1650e-54c6-4c07-bf92-eec2cba3ed42@github.com>
Message-ID: <Qu9c9diGDeAweYglJfMGJh5iYoRXbB7-kDLrv8ydasM=.d79682d5-7f07-4229-97da-8d16b19f38c7@github.com>

On Fri, 18 Nov 2022 12:06:39 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> With this PR I'd like to make it easier to use dedicated installations of Xcode on Mac OS for OpenJDK builds without having to switch the active Xcode globally via `xcode-select`.
>> 
>> I propose adding a new configure flag `--with-xcode-path` that takes the path to an Xcode installation. If the option is set, this path is expanded to a valid `TOOLCHAIN_PATH`.
>> 
>> Furthermore, I fix detection of xcodebuild and correctly setting the sysroot from the toolchain by moving `AC_SUBST(TOOLCHAIN_PATH)` before calling `BASIC_SETUP_XCODE_SYSROOT` and honoring `TOOLCHAIN_PATH` in `BASIC_SETUP_XCODE_SYSROOT` in the case when no devkit is specified. As I see it, this is a viable fix, even if not introducing `--with-xcode-path`.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix enumeration for html

Hm, the changes you made to the markdown file does not result in any changes in the generated html file. :( I fixed it by adding an additional empty line in the markdown file. The commit including both these fixes are here: https://github.com/magicus/jdk/commit/2844de1591ee8246dfb0fb5d19664b9db1d68c3a

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

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


From prr at openjdk.org  Fri Nov 18 16:39:24 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 18 Nov 2022 16:39:24 GMT
Subject: RFR: 8297088: Update LCMS to 2.14
In-Reply-To: <dNSastNjApaqQREyv3DDYY-uEfyXn9Mfjp_4hXgcpOk=.24e9897d-a556-4b34-b315-b1be2ba46735@github.com>
References: <dNSastNjApaqQREyv3DDYY-uEfyXn9Mfjp_4hXgcpOk=.24e9897d-a556-4b34-b315-b1be2ba46735@github.com>
Message-ID: <zWXs1bj5jYd7SMnxfUeV2Y3wpqH6K4-YSrLZXbwwCZw=.6e71408d-57cb-435a-a07f-5450ec4e077f@github.com>

On Thu, 17 Nov 2022 19:05:36 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Redo of 8295369: Update LCMS to 2.14
> Update LCMS to newest release.
> Updated DISABLED_WARNINGS_gcc for LCMS to include type limits to prevent a build error in linux.
> Automatic tests and J2D demo tests were run.

Marked as reviewed by prr (Reviewer).

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

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


From honkar at openjdk.org  Fri Nov 18 18:07:50 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 18 Nov 2022 18:07:50 GMT
Subject: RFR: 8297088: Update LCMS to 2.14
In-Reply-To: <dNSastNjApaqQREyv3DDYY-uEfyXn9Mfjp_4hXgcpOk=.24e9897d-a556-4b34-b315-b1be2ba46735@github.com>
References: <dNSastNjApaqQREyv3DDYY-uEfyXn9Mfjp_4hXgcpOk=.24e9897d-a556-4b34-b315-b1be2ba46735@github.com>
Message-ID: <xfgqDSf5Vag6wP-oe_ZFtE1bcJoql4Dz-EjcIZIA9RY=.d6c0bd39-c00e-4bd8-bb31-8ff7badd5a30@github.com>

On Thu, 17 Nov 2022 19:05:36 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Redo of 8295369: Update LCMS to 2.14
> Update LCMS to newest release.
> Updated DISABLED_WARNINGS_gcc for LCMS to include type limits to prevent a build error in linux.
> Automatic tests and J2D demo tests were run.

Marked as reviewed by honkar (Author).

File headers update, indentation & spacing looks good.

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

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


From achung at openjdk.org  Fri Nov 18 19:42:32 2022
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 18 Nov 2022 19:42:32 GMT
Subject: Integrated: 8297088: Update LCMS to 2.14
In-Reply-To: <dNSastNjApaqQREyv3DDYY-uEfyXn9Mfjp_4hXgcpOk=.24e9897d-a556-4b34-b315-b1be2ba46735@github.com>
References: <dNSastNjApaqQREyv3DDYY-uEfyXn9Mfjp_4hXgcpOk=.24e9897d-a556-4b34-b315-b1be2ba46735@github.com>
Message-ID: <mLQ-AqPtlWbm8j7PGAtJSMoN8OSnnt2ZB73IsPDY1y0=.8107db2d-9f60-41bd-bebb-4a52ffd363c7@github.com>

On Thu, 17 Nov 2022 19:05:36 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Redo of 8295369: Update LCMS to 2.14
> Update LCMS to newest release.
> Updated DISABLED_WARNINGS_gcc for LCMS to include type limits to prevent a build error in linux.
> Automatic tests and J2D demo tests were run.

This pull request has now been integrated.

Changeset: 2c692aa3
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2c692aa3567fff446b1a3263023077d8b4236945
Stats:     2138 lines in 32 files changed: 1546 ins; 134 del; 458 mod

8297088: Update LCMS to 2.14

Reviewed-by: erikj, serb, prr, honkar

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

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


From jwaters at openjdk.org  Mon Nov 21 02:45:19 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 21 Nov 2022 02:45:19 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <XXVqN4ByCrB34JRZSgiNYWsdrwEOTKjo5u81sTFG5bE=.7748c17a-4a13-42aa-b10d-219fe6775da2@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <gay-N6xDnfKHcngB9ddJIZD6Jfg2m_ZCzZn1gWPFN-o=.785036e8-1d1d-41d3-bac3-211b9d03cd71@github.com>
 <XXVqN4ByCrB34JRZSgiNYWsdrwEOTKjo5u81sTFG5bE=.7748c17a-4a13-42aa-b10d-219fe6775da2@github.com>
Message-ID: <nVCoCE9doWoQ54qhPSbn1xM79YLzhggfELps4CpI53o=.3af1e9bf-5389-439e-bd78-1b4fce336c2f@github.com>

On Tue, 15 Nov 2022 06:33:00 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert to using simpler solution similar to the original 8274980
>
> src/hotspot/share/utilities/globalDefinitions.hpp line 50:
> 
>> 48: 
>> 49: #ifndef ATTRIBUTE_ALIGNED
>> 50: #define ATTRIBUTE_ALIGNED(x) alignas(x)
> 
> HotSpot Group has not discussed or approved use of `alignas` - see https://bugs.openjdk.org/browse/JDK-8250269.  This is another change that is independent of most of the rest of this PR, and should be dealt with separately.  The various MSVC-conditional direct uses of `_declspec(align(N))` should probably currently be using `ATTRIBUTE_ALIGNED`.

Out of curiosity, is there a way to get the discussion on approving the use of alignas back up? I've read through 8250269 briefly and unlike the issues that come with C++ attributes, alignas looks relatively straightforward to switch to, without much effect on existing code. Seems like a bit of a waste to leave the JBS entry sitting on the shelf to me

> The various MSVC-conditional direct uses of __declspec(align(N)) should probably currently be using ATTRIBUTE_ALIGNED.

The instances of `__declspec(align())` changed here are in the native libraries written in C, not within HotSpot itself. From what I can see at least HotSpot never uses compiler alignment attributes directly and always strictly sticks to `ATTRIBUTE_ALIGNED` (which is probably a good thing)

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

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


From shade at openjdk.org  Mon Nov 21 07:25:30 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 21 Nov 2022 07:25:30 GMT
Subject: Integrated: 8294591: Fix cast-function-type warning in TemplateTable
In-Reply-To: <F9kScSH8YZ9kK8XAcl5pPPE6sPrHCBUc_zNriSaP8EU=.d5c7452c-72ed-4f41-9dea-5bd8a7fccbc0@github.com>
References: <F9kScSH8YZ9kK8XAcl5pPPE6sPrHCBUc_zNriSaP8EU=.d5c7452c-72ed-4f41-9dea-5bd8a7fccbc0@github.com>
Message-ID: <y5mp4Q1G8zFSA5nztte6rnSnSnYQiBY9kXlwxrGd9Eo=.db3a9003-b858-4a5f-9e84-63b669789e64@github.com>

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

> 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:

This pull request has now been integrated.

Changeset: fc616588
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fc616588c1bf731150a9d9b80033bb589bcb231f
Stats:     46 lines in 9 files changed: 6 ins; 1 del; 39 mod

8294591: Fix cast-function-type warning in TemplateTable

Reviewed-by: ihse, coleenp

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

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


From chagedorn at openjdk.org  Mon Nov 21 07:27:08 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 21 Nov 2022 07:27:08 GMT
Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed [v6]
In-Reply-To: <Npv8aIJVyGBNXUAtEStPlQfbUUaOsGjxulLp209l2bQ=.35ab9699-da60-4171-b04f-469c8d5f793a@github.com>
References: <Cuo-hZ2dmp5Su2aMvYe3k_w_rEuzCk7F8wpeCsQuyMA=.911a0412-42c0-44a1-8863-e94e5a7970e7@github.com>
 <Npv8aIJVyGBNXUAtEStPlQfbUUaOsGjxulLp209l2bQ=.35ab9699-da60-4171-b04f-469c8d5f793a@github.com>
Message-ID: <0dR70peukvwMgAwu0e7J9imsYk4jpobjMJb2EPr2PTA=.7b0c4c87-9c45-4fd9-a4b3-205159ee28b1@github.com>

On Fri, 18 Nov 2022 16:06:38 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 incrementally with one additional commit since the last revision:
> 
>   Remove unused local variable

Thanks Thomas for your review and your feedback! Testing looked good. 

@tschatzl do you also agree with the new approach?

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

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


From tschatzl at openjdk.org  Mon Nov 21 08:43:41 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 21 Nov 2022 08:43:41 GMT
Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed [v6]
In-Reply-To: <Npv8aIJVyGBNXUAtEStPlQfbUUaOsGjxulLp209l2bQ=.35ab9699-da60-4171-b04f-469c8d5f793a@github.com>
References: <Cuo-hZ2dmp5Su2aMvYe3k_w_rEuzCk7F8wpeCsQuyMA=.911a0412-42c0-44a1-8863-e94e5a7970e7@github.com>
 <Npv8aIJVyGBNXUAtEStPlQfbUUaOsGjxulLp209l2bQ=.35ab9699-da60-4171-b04f-469c8d5f793a@github.com>
Message-ID: <JepS4RFI09FbVwfY2l10r2AoNt_AChjtka0z8s85N2U=.bd5814f8-78f4-4a66-b289-e16db4715211@github.com>

On Fri, 18 Nov 2022 16:06:38 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 incrementally with one additional commit since the last revision:
> 
>   Remove unused local variable

Marked as reviewed by tschatzl (Reviewer).

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

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


From chagedorn at openjdk.org  Mon Nov 21 12:56:19 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 21 Nov 2022 12:56:19 GMT
Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed [v7]
In-Reply-To: <Cuo-hZ2dmp5Su2aMvYe3k_w_rEuzCk7F8wpeCsQuyMA=.911a0412-42c0-44a1-8863-e94e5a7970e7@github.com>
References: <Cuo-hZ2dmp5Su2aMvYe3k_w_rEuzCk7F8wpeCsQuyMA=.911a0412-42c0-44a1-8863-e94e5a7970e7@github.com>
Message-ID: <8uo2nH7Ans2cQz5QGDNsgPNirtkBKJP8pnrrbr474qw=.990e13c3-96a8-49c1-92c0-912ec0e834a1@github.com>

> 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 pull request now contains 10 commits:

 - Merge branch 'master' into JDK-8293422
 - Remove unused local variable
 - Update algorithm to print char by char, skipping file separators on the fly and only caring about the actual filename (ignore prefix path when reading)
 - Merge branch 'master' into JDK-8293422
 - 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

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

Changes: https://git.openjdk.org/jdk/pull/10287/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10287&range=06
  Stats: 162 lines in 5 files changed: 113 ins; 31 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/10287.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10287/head:pull/10287

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


From chagedorn at openjdk.org  Mon Nov 21 13:02:27 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 21 Nov 2022 13:02:27 GMT
Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed
In-Reply-To: <S8XIuc6_dJT8EHDa8qbhioeDpU_V1HtvbThkHTkG9x0=.f4cf594d-d6ae-4b1d-a8fb-196e14384362@github.com>
References: <Cuo-hZ2dmp5Su2aMvYe3k_w_rEuzCk7F8wpeCsQuyMA=.911a0412-42c0-44a1-8863-e94e5a7970e7@github.com>
 <F6wh_mBr34PgGPZ8EqRGW5QQGUCpSIz6biESoaLylpU=.ab95056f-5351-44b4-8607-d19660ef4118@github.com>
 <S8XIuc6_dJT8EHDa8qbhioeDpU_V1HtvbThkHTkG9x0=.f4cf594d-d6ae-4b1d-a8fb-196e14384362@github.com>
Message-ID: <_IadcH6MBdD1h_UnghBA2qvutX9OiBDl3l39yzOLtZE=.3b84e177-e17d-4040-a592-9fd4562122dc@github.com>

On Wed, 21 Sep 2022 10:47:38 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Thanks Thomas for that link. I was not aware of this `-gdwarf-aranges` flag. I've tried it out and it indeed seems to work. But I was not able to build with `-flto=thin` as it resulted in build failures. So, I'm not sure what would happen and if it's even possible to build with it in general. Nevertheless, I suggest to go with that `-gdwarf-aranges` flag solution for now and remove the previously suggested bailout fix for Clang.
>> 
>> However, `-gdwarf-aranges` (and `-gdwarf-4` which I think we should also add to avoid getting the unsupported DWARF 5 format) was only added in Clang 5.0. But we must support down to 3.5 according to:
>> https://github.com/openjdk/jdk/blob/cb72f80925965c73e32c44ce3196866272306d7f/doc/building.md?plain=1#L353-L354
>> 
>> I therefore changed the previous complete bailout fix to a bailout fix for Clang versions older than 5.0.
>> 
>> I've noticed that Clang is emitting a full relative path for the filename in the form of `src/hotspot/share/compiler/compilerThread.cpp:58` with debug builds (it only emits the filename with release builds). I therefore added an additional method `strip_path_prefix()` to get rid of the path prefix.
>
>> Thanks Thomas for that link. I was not aware of this `-gdwarf-aranges` flag. I've tried it out and it indeed seems to work. But I was not able to build with `-flto=thin` as it resulted in build failures. 
> 
> I only thought that maybe we do compile with `-flto=thin` already, and so we could not use these flags.
> 
>>So, I'm not sure what would happen and if it's even possible to build with it in general. Nevertheless, I suggest to go with that `-gdwarf-aranges` flag solution for now and remove the previously suggested bailout fix for Clang.
> 
> I agree.
> 
>> 
>> However, `-gdwarf-aranges` (and `-gdwarf-4` which I think we should also add to avoid getting the unsupported DWARF 5 format) was only added in Clang 5.0. But we must support down to 3.5 according to:
>> 
>> https://github.com/openjdk/jdk/blob/cb72f80925965c73e32c44ce3196866272306d7f/doc/building.md?plain=1#L353-L354
>> 
>> I therefore changed the previous complete bailout fix to a bailout fix for Clang versions older than 5.0.
>> 
>> I've noticed that Clang is emitting a full relative path for the filename in the form of `src/hotspot/share/compiler/compilerThread.cpp:58` with debug builds (it only emits the filename with release builds). I therefore added an additional method `strip_path_prefix()` to get rid of the path prefix.
> 
> Okay.

Thanks @tschatzl for reviewing it again!

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

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


From chagedorn at openjdk.org  Mon Nov 21 13:02:27 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 21 Nov 2022 13:02:27 GMT
Subject: Integrated: 8293422: DWARF emitted by Clang cannot be parsed
In-Reply-To: <Cuo-hZ2dmp5Su2aMvYe3k_w_rEuzCk7F8wpeCsQuyMA=.911a0412-42c0-44a1-8863-e94e5a7970e7@github.com>
References: <Cuo-hZ2dmp5Su2aMvYe3k_w_rEuzCk7F8wpeCsQuyMA=.911a0412-42c0-44a1-8863-e94e5a7970e7@github.com>
Message-ID: <LAsyhHmTeZEwyNSvd33HwQcf3VBBV884lfLDuk2xJGY=.612b7abe-7c6b-4cfd-89df-0f9d4a4a9eb7@github.com>

On Thu, 15 Sep 2022 11:59: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

This pull request has now been integrated.

Changeset: 8b8d8481
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8b8d8481bc05eec70a1df832668322e5c17694d8
Stats:     162 lines in 5 files changed: 113 ins; 31 del; 18 mod

8293422: DWARF emitted by Clang cannot be parsed

Reviewed-by: tschatzl, ihse, stuefe

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

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


From ihse at openjdk.org  Mon Nov 21 14:20:21 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 21 Nov 2022 14:20:21 GMT
Subject: RFR: 8297342: make LOG=debug is too verbose
Message-ID: <Uzcn4C6Gd6b-ChpNPyBaDN5Do7z36QXbxLdwrQ3P7rY=.94c022c5-ec09-41f2-a3ce-25d3c8a7b67d@github.com>

The `debug` level of make logging is not really useful, since it spits out a full expansion of all named param macro arguments and their values. 

With the NamedParamsMacroTemplate being stable for years, this is seldom useful, and the massive amount of logs drown out everything else.

We should move this debugging to the `trace` level.

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

Commit messages:
 - 8297342: make LOG=debug is too verbose

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

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


From ihse at openjdk.org  Mon Nov 21 14:20:21 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 21 Nov 2022 14:20:21 GMT
Subject: RFR: 8297342: make LOG=debug is too verbose
In-Reply-To: <Uzcn4C6Gd6b-ChpNPyBaDN5Do7z36QXbxLdwrQ3P7rY=.94c022c5-ec09-41f2-a3ce-25d3c8a7b67d@github.com>
References: <Uzcn4C6Gd6b-ChpNPyBaDN5Do7z36QXbxLdwrQ3P7rY=.94c022c5-ec09-41f2-a3ce-25d3c8a7b67d@github.com>
Message-ID: <rrm6ozQ5HR2r-gmFWEkDgU1SKgPxN9QdJFqrQNWL2Lk=.041cf865-6138-4f83-8d89-cd59a450942b@github.com>

On Mon, 21 Nov 2022 14:11:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The `debug` level of make logging is not really useful, since it spits out a full expansion of all named param macro arguments and their values. 
> 
> With the NamedParamsMacroTemplate being stable for years, this is seldom useful, and the massive amount of logs drown out everything else.
> 
> We should move this debugging to the `trace` level.

Without this fix, all debug logs would start by a massive amount of 

Building target 'jdk' in configuration 'macosx-aarch64'
make[2]: Entering directory '/Users/ihse/git/jdk-DOH/open'
SetupTarget buildtools-langtools  
 [2] MAKEFILE := ToolsLangtools                                                                                                                                                                                            
SetupTarget interim-langtools  
 [2] MAKEFILE := CompileInterimLangtools                                                                                                                                                                                            
SetupTarget interim-tzdb  
 [2] MAKEFILE := CopyInterimTZDB                                                                                                                                                                                            
SetupTarget buildtools-jdk  
 [2] MAKEFILE := CompileToolsJdk  
 [3] DEPS := interim-langtools interim-tzdb                                                                                                                                                                                          
SetupTarget buildtools-modules  
 [2] MAKEFILE := CompileModuleTools                                                                                                                                                                                            
SetupTarget buildtools-hotspot  
 [2] MAKEFILE := CompileToolsHotspot             


listing all make targets from Main.gmk.

With this fix, the log starts

Building target 'jdk' in configuration 'macosx-aarch64-server-release'
gmake[2]: Entering directory '/Users/ihse/git/jdk-DOH/open'
(cd /Users/ihse/git/jdk-DOH/open/make && /opt/homebrew/bin/gmake  -r -R -I /Users/ihse/git/jdk-DOH/open/make/common SPEC=/Users/ihse/git/jdk-DOH/open/build/macosx-aarch64-server-release/spec.gmk MAKE_LOG_FLAGS=""  -f ToolsLangtools.gmk  )
(cd /Users/ihse/git/jdk-DOH/open/make && /opt/homebrew/bin/gmake  -r -R -I /Users/ihse/git/jdk-DOH/open/make/common SPEC=/Users/ihse/git/jdk-DOH/open/build/macosx-aarch64-server-release/spec.gmk MAKE_LOG_FLAGS=""  -f CopyInterimTZDB.gmk  )
(cd /Users/ihse/git/jdk-DOH/open/make && /opt/homebrew/bin/gmake  -r -R -I /Users/ihse/git/jdk-DOH/open/make/common SPEC=/Users/ihse/git/jdk-DOH/open/build/macosx-aarch64-server-release/spec.gmk MAKE_LOG_FLAGS=""  -f ModuleWrapper.gmk -I /Users/ihse/git/jdk-DOH/open/make/common/modules -I/Users/ihse/git/jdk-DOH/open/make/modules/java.base MODULE=java.base MAKEFILE_PREFIX=Copy )
(cd /Users/ihse/git/jdk-DOH/open/make && /opt/homebrew/bin/gmake  -r -R -I /Users/ihse/git/jdk-DOH/open/make/common SPEC=/Users/ihse/git/jdk-DOH/open/build/macosx-aarch64-server-release/spec.gmk MAKE_LOG_FLAGS=""  -f CompileToolsHotspot.gmk  )
(cd /Users/ihse/git/jdk-DOH/open/make && /opt/homebrew/bin/gmake  -r -R -I /Users/ihse/git/jdk-DOH/open/make/common SPEC=/Users/ihse/git/jdk-DOH/open/build/macosx-aarch64-server-release/spec.gmk MAKE_LOG_FLAGS=""  -f ModuleWrapper.gmk -I /Users/ihse/git/jdk-DOH/open/make/common/modules -I/Users/ihse/git/jdk-DOH/open/make/modules/java.desktop MODULE=java.desktop MAKEFILE_PREFIX=Copy )
(cd /Users/ihse/git/jdk-DOH/open/make && /opt/homebrew/bin/gmake  -r -R -I /Users/ihse/git/jdk-DOH/open/make/common SPEC=/Users/ihse/git/jdk-DOH/open/build/macosx-aarch64-server-release/spec.gmk MAKE_LOG_FLAGS=""  -f ModuleWrapper.gmk -I /Users/ihse/git/jdk-DOH/open/make/common/modules -I/Users/ihse/git/jdk-DOH/open/make/modules/java.logging MODULE=java.logging MAKEFILE_PREFIX=Copy )
(cd /Users/ihse/git/jdk-DOH/open/make && /opt/homebrew/bin/gmake  -r -R -I /Users/ihse/git/jdk-DOH/open/make/common SPEC=/Users/ihse/git/jdk-DOH/open/build/macosx-aarch64-server-release/spec.gmk MAKE_LOG_FLAGS=""  -f ModuleWrapper.gmk -I /Users/ihse/git/jdk-DOH/open/make/common/modules -I/Users/ihse/git/jdk-DOH/open/make/modules/jdk.accessibility MODULE=jdk.accessibility MAKEFILE_PREFIX=Copy )
(cd /Users/ihse/git/jdk-DOH/open/make && /opt/homebrew/bin/gmake  -r -R -I /Users/ihse/git/jdk-DOH/open/make/common SPEC=/Users/ihse/git/jdk-DOH/open/build/macosx-aarch64-server-release/spec.gmk MAKE_LOG_FLAGS=""  -f ModuleWrapper.gmk -I /Users/ihse/git/jdk-DOH/open/make/common/modules -I/Users/ihse/git/jdk-DOH/open/make/modules/jdk.management.agent MODULE=jdk.management.agent MAKEFILE_PREFIX=Copy )
gmake[3]: Entering directory '/Users/ihse/git/jdk-DOH/open/make'


which is much more helpful in showing how the build system starts collecting initial dependencies.

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

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


From erikj at openjdk.org  Mon Nov 21 14:43:31 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 21 Nov 2022 14:43:31 GMT
Subject: RFR: 8297342: make LOG=debug is too verbose
In-Reply-To: <Uzcn4C6Gd6b-ChpNPyBaDN5Do7z36QXbxLdwrQ3P7rY=.94c022c5-ec09-41f2-a3ce-25d3c8a7b67d@github.com>
References: <Uzcn4C6Gd6b-ChpNPyBaDN5Do7z36QXbxLdwrQ3P7rY=.94c022c5-ec09-41f2-a3ce-25d3c8a7b67d@github.com>
Message-ID: <YmMjW-H9--2XWI78TSQ1LZkD3pFo3jdRAQl0v4qLeDk=.d10a5866-bdb1-41a7-8733-fbd8d27523a5@github.com>

On Mon, 21 Nov 2022 14:11:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The `debug` level of make logging is not really useful, since it spits out a full expansion of all named param macro arguments and their values. 
> 
> With the NamedParamsMacroTemplate being stable for years, this is seldom useful, and the massive amount of logs drown out everything else.
> 
> We should move this debugging to the `trace` level.

Marked as reviewed by erikj (Reviewer).

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

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


From ihse at openjdk.org  Mon Nov 21 15:16:34 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 21 Nov 2022 15:16:34 GMT
Subject: Integrated: 8297342: make LOG=debug is too verbose
In-Reply-To: <Uzcn4C6Gd6b-ChpNPyBaDN5Do7z36QXbxLdwrQ3P7rY=.94c022c5-ec09-41f2-a3ce-25d3c8a7b67d@github.com>
References: <Uzcn4C6Gd6b-ChpNPyBaDN5Do7z36QXbxLdwrQ3P7rY=.94c022c5-ec09-41f2-a3ce-25d3c8a7b67d@github.com>
Message-ID: <D0Fg22cZhRfOnhHrLnlOlQ6ecYelKUbudNZTTwsr9QI=.fd378803-007a-4e31-bf40-70901ca738df@github.com>

On Mon, 21 Nov 2022 14:11:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The `debug` level of make logging is not really useful, since it spits out a full expansion of all named param macro arguments and their values. 
> 
> With the NamedParamsMacroTemplate being stable for years, this is seldom useful, and the massive amount of logs drown out everything else.
> 
> We should move this debugging to the `trace` level.

This pull request has now been integrated.

Changeset: 0ac01485
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0ac01485d3cf65b35a6ae7431dafccbca7e21eee
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8297342: make LOG=debug is too verbose

Reviewed-by: erikj

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

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


From ihse at openjdk.org  Mon Nov 21 15:32:36 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 21 Nov 2022 15:32:36 GMT
Subject: RFR: 8297348: make CONF=xxx should match if xxx is an exact match
Message-ID: <bP_STskxJojtKCkC-FU5OAarLKpJNaudN63K3t2LtoM=.5f67f656-e18d-4985-b486-7999fa5ece07@github.com>

A typical use case for multiple configurations is that you have a release configuration (say `linux-x64`) and a debug configuration (say `linux-x64-debug`). You can now easily select the debug configuration with `CONF=debug`, or both configurations with `CONF=`, but there is no way to select just the release configuration. Instead, workarounds using `SPEC` or `CONF_NAME` (which always does an exact match) is needed.

Instead, we should modify the behavior of `CONF` slightly, so if it gets an exact match, it should behave like `CONF_NAME` and select just that configurations.

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

Commit messages:
 - 8297348: make CONF=xxx should match if xxx is an exact match

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

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


From shade at openjdk.org  Mon Nov 21 15:50:48 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 21 Nov 2022 15:50:48 GMT
Subject: RFR: 8297350: Update JMH devkit to 1.36
Message-ID: <pzG2m0-Iiv1HZMEgw1d84Gnnl56HjFAfUY3tKaV7ULA=.27833c6c-4aff-4081-9535-3098c8266e90@github.com>

JMH 1.36 was released, so we can bump the devkit too.

Additional testing:
 - [x] Ad-hoc benchmarks with newly generated devkit

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

Commit messages:
 - Fix

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

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


From ihse at openjdk.org  Mon Nov 21 16:24:26 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 21 Nov 2022 16:24:26 GMT
Subject: RFR: 8297352: configure should check pandoc version
Message-ID: <Bmj_HU71Y6dgN4o2uC2F48uTgdF6TB1P8d8i0OvOnyk=.e6103ca5-2305-402a-bd31-8325d0f7ebf0@github.com>

Following JDK-8297165, configure should check if pandoc is of the same version. Having the same version of pandoc guarantees consistent output of the generated files.

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

Commit messages:
 - 8297352: configure should check pandoc version

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

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


From ihse at openjdk.org  Mon Nov 21 16:28:52 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 21 Nov 2022 16:28:52 GMT
Subject: RFR: 8297353: Regenerated checked-in html files with new pandoc
Message-ID: <59yAWM8Cf3_0kEiv7cEmqR0bYq97i36JYvS9ceIfm1Q=.deec866e-f5d0-4d42-90f6-9061812b0578@github.com>

Following JDK-8297165, we should regenerate all checked in html files using pandoc 1.19.2, to avoid spurious changes to the files with future changes to the markdown source files.

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

Commit messages:
 - 8297353: Regenerated checked-in html files with new pandoc

Changes: https://git.openjdk.org/jdk/pull/11274/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11274&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297353
  Stats: 3583 lines in 5 files changed: 2526 ins; 13 del; 1044 mod
  Patch: https://git.openjdk.org/jdk/pull/11274.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11274/head:pull/11274

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


From lancea at openjdk.org  Mon Nov 21 16:40:24 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 21 Nov 2022 16:40:24 GMT
Subject: RFR: 8297353: Regenerated checked-in html files with new pandoc
In-Reply-To: <59yAWM8Cf3_0kEiv7cEmqR0bYq97i36JYvS9ceIfm1Q=.deec866e-f5d0-4d42-90f6-9061812b0578@github.com>
References: <59yAWM8Cf3_0kEiv7cEmqR0bYq97i36JYvS9ceIfm1Q=.deec866e-f5d0-4d42-90f6-9061812b0578@github.com>
Message-ID: <06kSf-_IPz80HOehm54NXno09GWtQzuc1pQOJmXbvws=.3c93ebfa-b71c-4d1c-a91f-572f67cc0416@github.com>

On Mon, 21 Nov 2022 16:20:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Following JDK-8297165, we should regenerate all checked in html files using pandoc 1.19.2, to avoid spurious changes to the files with future changes to the markdown source files.

Marked as reviewed by lancea (Reviewer).

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

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


From erikj at openjdk.org  Mon Nov 21 17:25:24 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 21 Nov 2022 17:25:24 GMT
Subject: RFR: 8297350: Update JMH devkit to 1.36
In-Reply-To: <pzG2m0-Iiv1HZMEgw1d84Gnnl56HjFAfUY3tKaV7ULA=.27833c6c-4aff-4081-9535-3098c8266e90@github.com>
References: <pzG2m0-Iiv1HZMEgw1d84Gnnl56HjFAfUY3tKaV7ULA=.27833c6c-4aff-4081-9535-3098c8266e90@github.com>
Message-ID: <N6F_z0ZoJu-1JNgq89a2gh0yAHw4MnfUa5qUwbviyUk=.56f6ee4b-de3e-4773-a393-93c2aa050740@github.com>

On Mon, 21 Nov 2022 15:36:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> JMH 1.36 was released, so we can bump the devkit too.
> 
> Additional testing:
>  - [x] Ad-hoc benchmarks with newly generated devkit

Marked as reviewed by erikj (Reviewer).

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

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


From erikj at openjdk.org  Mon Nov 21 17:26:40 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 21 Nov 2022 17:26:40 GMT
Subject: RFR: 8297348: make CONF=xxx should match if xxx is an exact match
In-Reply-To: <bP_STskxJojtKCkC-FU5OAarLKpJNaudN63K3t2LtoM=.5f67f656-e18d-4985-b486-7999fa5ece07@github.com>
References: <bP_STskxJojtKCkC-FU5OAarLKpJNaudN63K3t2LtoM=.5f67f656-e18d-4985-b486-7999fa5ece07@github.com>
Message-ID: <WjzUTghh3m8SGE2w40wN3lCkgaZanOQoUZL51i8Z8dc=.585716be-f970-42b5-bac1-bcfb4bfbf56d@github.com>

On Mon, 21 Nov 2022 15:18:33 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A typical use case for multiple configurations is that you have a release configuration (say `linux-x64`) and a debug configuration (say `linux-x64-debug`). You can now easily select the debug configuration with `CONF=debug`, or both configurations with `CONF=`, but there is no way to select just the release configuration. Instead, workarounds using `SPEC` or `CONF_NAME` (which always does an exact match) is needed.
> 
> Instead, we should modify the behavior of `CONF` slightly, so if it gets an exact match, it should behave like `CONF_NAME` and select just that configurations.

Marked as reviewed by erikj (Reviewer).

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

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


From erikj at openjdk.org  Mon Nov 21 17:26:38 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 21 Nov 2022 17:26:38 GMT
Subject: RFR: 8297352: configure should check pandoc version
In-Reply-To: <Bmj_HU71Y6dgN4o2uC2F48uTgdF6TB1P8d8i0OvOnyk=.e6103ca5-2305-402a-bd31-8325d0f7ebf0@github.com>
References: <Bmj_HU71Y6dgN4o2uC2F48uTgdF6TB1P8d8i0OvOnyk=.e6103ca5-2305-402a-bd31-8325d0f7ebf0@github.com>
Message-ID: <s7ZGQGHOj4pbDDZZS8IZKj4s4Au4E10CvIy5Dj3oaxQ=.906da480-dc92-46e7-988b-e2571d5138fc@github.com>

On Mon, 21 Nov 2022 16:17:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Following JDK-8297165, configure should check if pandoc is of the same version. Having the same version of pandoc guarantees consistent output of the generated files.

Marked as reviewed by erikj (Reviewer).

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

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


From erikj at openjdk.org  Mon Nov 21 17:27:32 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 21 Nov 2022 17:27:32 GMT
Subject: RFR: 8297353: Regenerated checked-in html files with new pandoc
In-Reply-To: <59yAWM8Cf3_0kEiv7cEmqR0bYq97i36JYvS9ceIfm1Q=.deec866e-f5d0-4d42-90f6-9061812b0578@github.com>
References: <59yAWM8Cf3_0kEiv7cEmqR0bYq97i36JYvS9ceIfm1Q=.deec866e-f5d0-4d42-90f6-9061812b0578@github.com>
Message-ID: <Qwdga3qWBU9OwzPLlQc54QIO3Ou-roJMUAAm8i8hp1w=.16d5dd69-f056-4570-a969-2b892879c997@github.com>

On Mon, 21 Nov 2022 16:20:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Following JDK-8297165, we should regenerate all checked in html files using pandoc 1.19.2, to avoid spurious changes to the files with future changes to the markdown source files.

Marked as reviewed by erikj (Reviewer).

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

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


From ihse at openjdk.org  Mon Nov 21 18:35:40 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 21 Nov 2022 18:35:40 GMT
Subject: Integrated: 8297353: Regenerated checked-in html files with new pandoc
In-Reply-To: <59yAWM8Cf3_0kEiv7cEmqR0bYq97i36JYvS9ceIfm1Q=.deec866e-f5d0-4d42-90f6-9061812b0578@github.com>
References: <59yAWM8Cf3_0kEiv7cEmqR0bYq97i36JYvS9ceIfm1Q=.deec866e-f5d0-4d42-90f6-9061812b0578@github.com>
Message-ID: <wFIcwoypoA5N6F0oO2cDikdw_Pluzylxgqr7wpt3XSQ=.dca3136c-967f-423e-b14f-f088fe455014@github.com>

On Mon, 21 Nov 2022 16:20:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Following JDK-8297165, we should regenerate all checked in html files using pandoc 1.19.2, to avoid spurious changes to the files with future changes to the markdown source files.

This pull request has now been integrated.

Changeset: 15e2e285
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/15e2e2852b7024cf9a6d58fd7ccb2474c1730e09
Stats:     3583 lines in 5 files changed: 2526 ins; 13 del; 1044 mod

8297353: Regenerated checked-in html files with new pandoc

Reviewed-by: lancea, erikj

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

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


From ihse at openjdk.org  Mon Nov 21 18:37:30 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 21 Nov 2022 18:37:30 GMT
Subject: Integrated: 8297352: configure should check pandoc version
In-Reply-To: <Bmj_HU71Y6dgN4o2uC2F48uTgdF6TB1P8d8i0OvOnyk=.e6103ca5-2305-402a-bd31-8325d0f7ebf0@github.com>
References: <Bmj_HU71Y6dgN4o2uC2F48uTgdF6TB1P8d8i0OvOnyk=.e6103ca5-2305-402a-bd31-8325d0f7ebf0@github.com>
Message-ID: <kr4bMO4ELxCcN2txnAAX1BAw0cbxC99fuk4E-tdsy30=.ec2d930c-ef87-429d-8043-819250c9ef9d@github.com>

On Mon, 21 Nov 2022 16:17:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Following JDK-8297165, configure should check if pandoc is of the same version. Having the same version of pandoc guarantees consistent output of the generated files.

This pull request has now been integrated.

Changeset: 817e039b
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/817e039bb5300e95ba60749f237f1243f72f4eeb
Stats:     19 lines in 1 file changed: 14 ins; 2 del; 3 mod

8297352: configure should check pandoc version

Reviewed-by: erikj

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

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


From ihse at openjdk.org  Mon Nov 21 18:37:38 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 21 Nov 2022 18:37:38 GMT
Subject: Integrated: 8297348: make CONF=xxx should match if xxx is an exact
 match
In-Reply-To: <bP_STskxJojtKCkC-FU5OAarLKpJNaudN63K3t2LtoM=.5f67f656-e18d-4985-b486-7999fa5ece07@github.com>
References: <bP_STskxJojtKCkC-FU5OAarLKpJNaudN63K3t2LtoM=.5f67f656-e18d-4985-b486-7999fa5ece07@github.com>
Message-ID: <5VdsOjYf26prjhSJ_RowE-QVXdNB88_F6NDNp05zlyk=.8827563a-99a1-49d8-89ac-dacf170e067f@github.com>

On Mon, 21 Nov 2022 15:18:33 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A typical use case for multiple configurations is that you have a release configuration (say `linux-x64`) and a debug configuration (say `linux-x64-debug`). You can now easily select the debug configuration with `CONF=debug`, or both configurations with `CONF=`, but there is no way to select just the release configuration. Instead, workarounds using `SPEC` or `CONF_NAME` (which always does an exact match) is needed.
> 
> Instead, we should modify the behavior of `CONF` slightly, so if it gets an exact match, it should behave like `CONF_NAME` and select just that configurations.

This pull request has now been integrated.

Changeset: cd6a203a
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd6a203a3e9e4e2f96f6c8649b10af92f8d9c27b
Stats:     9 lines in 1 file changed: 9 ins; 0 del; 0 mod

8297348: make CONF=xxx should match if xxx is an exact match

Reviewed-by: erikj

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

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


From ccheung at openjdk.org  Mon Nov 21 22:17:25 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 21 Nov 2022 22:17:25 GMT
Subject: RFR: 8296754: AutoCreateSharedArchive in JDK 20 is not compatible
 with JDK 19 [v5]
In-Reply-To: <aR-wSfDP2l1zX1Lxl19eHmoNtWn6bi7_iq_CADf_VJo=.3dbb5544-8142-4017-a403-432f557fc72c@github.com>
References: <bStp4S1ZwR75Ej89W2VAUL4Py7DfDgG03yggGWsZl8w=.200561aa-a37e-4a24-a70c-30be21601377@github.com>
 <aR-wSfDP2l1zX1Lxl19eHmoNtWn6bi7_iq_CADf_VJo=.3dbb5544-8142-4017-a403-432f557fc72c@github.com>
Message-ID: <yBlEh5xv73gcdyvYUjZteX28vvZcx8V0UaxThLDLYI8=.ba899788-436c-4677-8fb9-d432fd4ff213@github.com>

On Thu, 17 Nov 2022 21:46:45 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The -XX:+AutoCreateSharedArchive flag was implemented in JDK 19, however, this flag doesn't work across JDK 19 and 20.
>> 
>> Expected: JDK 20 should recreate the specified CDS archive
>> Actual: JDK 20 cannot recognize the archive file and gives up
>> 
>> The new field from GenericCDSFileMapHeader is now in FileMapHeader. Verified with tier 1-4 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added newline to end of test

Marked as reviewed by ccheung (Reviewer).

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

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


From iklam at openjdk.org  Tue Nov 22 06:34:29 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Nov 2022 06:34:29 GMT
Subject: RFR: 8296754: AutoCreateSharedArchive in JDK 20 is not compatible
 with JDK 19 [v5]
In-Reply-To: <aR-wSfDP2l1zX1Lxl19eHmoNtWn6bi7_iq_CADf_VJo=.3dbb5544-8142-4017-a403-432f557fc72c@github.com>
References: <bStp4S1ZwR75Ej89W2VAUL4Py7DfDgG03yggGWsZl8w=.200561aa-a37e-4a24-a70c-30be21601377@github.com>
 <aR-wSfDP2l1zX1Lxl19eHmoNtWn6bi7_iq_CADf_VJo=.3dbb5544-8142-4017-a403-432f557fc72c@github.com>
Message-ID: <wQzMYYMaG-c_8t9TmIHDguxkMGUYjaT4jDsqv5M7ccY=.5b4246ca-b653-4181-90e9-d76302951748@github.com>

On Thu, 17 Nov 2022 21:46:45 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The -XX:+AutoCreateSharedArchive flag was implemented in JDK 19, however, this flag doesn't work across JDK 19 and 20.
>> 
>> Expected: JDK 20 should recreate the specified CDS archive
>> Actual: JDK 20 cannot recognize the archive file and gives up
>> 
>> The new field from GenericCDSFileMapHeader is now in FileMapHeader. Verified with tier 1-4 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added newline to end of test

LGTM

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

Marked as reviewed by iklam (Reviewer).

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


From clanger at openjdk.org  Tue Nov 22 10:59:04 2022
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 22 Nov 2022 10:59:04 GMT
Subject: RFR: 8296904: Improve handling of macos xcode toolchain [v9]
In-Reply-To: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
References: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
Message-ID: <DCSYVmpqSNAq6YaMeUHOo8X2XlZdmMIK2yM_4kU-tfI=.2f2b1fe1-45a4-4d9e-adff-f4958bb6124e@github.com>

> With this PR I'd like to make it easier to use dedicated installations of Xcode on Mac OS for OpenJDK builds without having to switch the active Xcode globally via `xcode-select`.
> 
> I propose adding a new configure flag `--with-xcode-path` that takes the path to an Xcode installation. If the option is set, this path is expanded to a valid `TOOLCHAIN_PATH`.
> 
> Furthermore, I fix detection of xcodebuild and correctly setting the sysroot from the toolchain by moving `AC_SUBST(TOOLCHAIN_PATH)` before calling `BASIC_SETUP_XCODE_SYSROOT` and honoring `TOOLCHAIN_PATH` in `BASIC_SETUP_XCODE_SYSROOT` in the case when no devkit is specified. As I see it, this is a viable fix, even if not introducing `--with-xcode-path`.

Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge branch 'master' into xcode-toolchain
 - Fix bullet list formatting in markdown and update html
 - Fix enumeration for html
 - Update html file
 - Add dots
 - Whitespace stuff
 - Minor polishing
 - Updating building.md doc
 - Merge branch 'master' into xcode-toolchain
 - Review suggestion
 - ... and 2 more: https://git.openjdk.org/jdk/compare/42c20374...2a5e4e44

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

Changes: https://git.openjdk.org/jdk/pull/11113/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11113&range=08
  Stats: 86 lines in 3 files changed: 25 ins; 16 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/11113.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11113/head:pull/11113

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


From clanger at openjdk.org  Tue Nov 22 11:02:15 2022
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 22 Nov 2022 11:02:15 GMT
Subject: RFR: 8296904: Improve handling of macos xcode toolchain [v8]
In-Reply-To: <Qu9c9diGDeAweYglJfMGJh5iYoRXbB7-kDLrv8ydasM=.d79682d5-7f07-4229-97da-8d16b19f38c7@github.com>
References: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
 <5YbIcpQJvPO9c2oM87PR83dz1fYAQ5m1E1eGdeN8SNg=.f9f1650e-54c6-4c07-bf92-eec2cba3ed42@github.com>
 <Qu9c9diGDeAweYglJfMGJh5iYoRXbB7-kDLrv8ydasM=.d79682d5-7f07-4229-97da-8d16b19f38c7@github.com>
Message-ID: <GkZFV_fXIbQHA0gxbvzORSieywV2JJyA9OVbB-plb1w=.5df341b3-ac61-40f8-bbdf-36d6b09dd395@github.com>

On Fri, 18 Nov 2022 16:32:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix enumeration for html
>
> Hm, the changes you made to the markdown file does not result in any changes in the generated html file. :( I fixed it by adding an additional empty line in the markdown file. The commit including both these fixes are here: https://github.com/magicus/jdk/commit/2844de1591ee8246dfb0fb5d19664b9db1d68c3a

@magicus Thanks for fixing my enumeration. I recognized that you have regenerated all the html files with a newer pandoc and I had to resolve with master. I guess you'll need to regenerate with my current branch once more - otherwise I think I'm breaking some of the new style.

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

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


From ihse at openjdk.org  Tue Nov 22 14:13:32 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 22 Nov 2022 14:13:32 GMT
Subject: RFR: 8296904: Improve handling of macos xcode toolchain [v8]
In-Reply-To: <GkZFV_fXIbQHA0gxbvzORSieywV2JJyA9OVbB-plb1w=.5df341b3-ac61-40f8-bbdf-36d6b09dd395@github.com>
References: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
 <5YbIcpQJvPO9c2oM87PR83dz1fYAQ5m1E1eGdeN8SNg=.f9f1650e-54c6-4c07-bf92-eec2cba3ed42@github.com>
 <Qu9c9diGDeAweYglJfMGJh5iYoRXbB7-kDLrv8ydasM=.d79682d5-7f07-4229-97da-8d16b19f38c7@github.com>
 <GkZFV_fXIbQHA0gxbvzORSieywV2JJyA9OVbB-plb1w=.5df341b3-ac61-40f8-bbdf-36d6b09dd395@github.com>
Message-ID: <uDK7HioIzuXDQHB8aH-sH3oTvdLXiEHkVXbVd4u-sbY=.9f0e9789-2505-4668-8b30-083df3e61165@github.com>

On Tue, 22 Nov 2022 10:59:05 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Hm, the changes you made to the markdown file does not result in any changes in the generated html file. :( I fixed it by adding an additional empty line in the markdown file. The commit including both these fixes are here: https://github.com/magicus/jdk/commit/2844de1591ee8246dfb0fb5d19664b9db1d68c3a
>
> @magicus Thanks for fixing my enumeration. I recognized that you have regenerated all the html files with a newer pandoc and I had to resolve with master. I guess you'll need to regenerate with my current branch once more - otherwise I think I'm breaking some of the new style.

@RealCLanger Finally regenerated once more: [fcd20c73ed9f0a44c0614a54580c755a16387a6a](https://github.com/magicus/jdk/commit/fcd20c73ed9f0a44c0614a54580c755a16387a6a)

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

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


From matsaave at openjdk.org  Tue Nov 22 14:44:36 2022
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 22 Nov 2022 14:44:36 GMT
Subject: RFR: 8296754: AutoCreateSharedArchive in JDK 20 is not compatible
 with JDK 19 [v5]
In-Reply-To: <aR-wSfDP2l1zX1Lxl19eHmoNtWn6bi7_iq_CADf_VJo=.3dbb5544-8142-4017-a403-432f557fc72c@github.com>
References: <bStp4S1ZwR75Ej89W2VAUL4Py7DfDgG03yggGWsZl8w=.200561aa-a37e-4a24-a70c-30be21601377@github.com>
 <aR-wSfDP2l1zX1Lxl19eHmoNtWn6bi7_iq_CADf_VJo=.3dbb5544-8142-4017-a403-432f557fc72c@github.com>
Message-ID: <l-yCcyCiw4WRN-_eNf9wbg7gRxoJwCuMfDyTdcQa6zQ=.c130ce42-8c04-42f8-a8eb-7cf485d785b7@github.com>

On Thu, 17 Nov 2022 21:46:45 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The -XX:+AutoCreateSharedArchive flag was implemented in JDK 19, however, this flag doesn't work across JDK 19 and 20.
>> 
>> Expected: JDK 20 should recreate the specified CDS archive
>> Actual: JDK 20 cannot recognize the archive file and gives up
>> 
>> The new field from GenericCDSFileMapHeader is now in FileMapHeader. Verified with tier 1-4 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added newline to end of test

Thank you for the feedback Eric, Calvin, and Ioi!

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

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


From jwaters at openjdk.org  Tue Nov 22 16:04:33 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 22 Nov 2022 16:04:33 GMT
Subject: RFR: 8296478: Rework 8282948 and 8282700 to use the new autoconf
 UTIL_ARG_WITH [v5]
In-Reply-To: <DFOaxSVc2s3jfKITRsn10IKr45zBiuNuSrX7Mh7G-X8=.f9dec2d0-5956-4f7c-831d-876d49b9edf7@github.com>
References: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
 <8S8N1iXr8G3iTrIlHh4BzaLxgNw6yFBNBKVS0uChsJI=.514e8478-3a44-4a6f-a38d-7304588c8213@github.com>
 <DFOaxSVc2s3jfKITRsn10IKr45zBiuNuSrX7Mh7G-X8=.f9dec2d0-5956-4f7c-831d-876d49b9edf7@github.com>
Message-ID: <ssI33MqZnkLXxjc9wHMHR5oWYj5UUICOhLmrOjvkrB8=.a62add0a-d8c9-4080-bb4b-274a0b80bd2a@github.com>

On Fri, 18 Nov 2022 11:27:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Uh oh
>
> Aaaahhh, **that** bug. I've run into that before. I did attempt to fix it but after wasting too many hours I gave up. :-( It seems to be a limitation in m4 that I cannot understand how to get around. At some point, the string literal, even though quoted inside the `[...]`, is expanded and parsed as m4 macro expansion arguments. In theory, I should have been able to add an additional layer of quoting and then un-quote it once it was past the problematic point, but that did not work.
> 
> I solved the problem by not solving it, and instead rephrased the message to not need the comma. (Imho, this limitation actually improved the quality of the descriptions, so it was not bad per se).
> 
> But I agree that it is annoying to have such a limitation in `UTIL_DEFUN_NAMED`. If you want to have a go at trying to solve it, please do! I'll fully admit my shortcomings and state that trying to solve this passes my knowledge and ability to manipulate m4. 
> 
> Or, maybe, you could add some documentation to `UTIL_DEFUN_NAMED` and `UTIL_ARG_WITH`, saying that comma is not allowed in the values.

@magicus I need some of your input on this:

Typically when using AC_ARG_WITH one would surround the if block with an extra quote, for instance if we had `if ! [[ $JDK_RC_NAME =~ ^[[:print:]]*$ ]]` the code in m4 would have an extra set of brackets to quote it so m4 doesn't absolutely wreck the final script that we want to emit, such as `if [ ! [[ $JDK_RC_NAME =~ ^[[:print:]]*$ ]] ]`

I'm about halfway through fixing the whole issue with commas, and I'm fairly certain I could lump the problem with quoting expansion in there too. My question though is: When it comes to parameters that take "predicate" code blocks as arguments (Such as CHECK_VALUE), should I have UTIL_ARG_NAMED handle the annoying issue of quoting entirely so the caller can freely pass `if ! [[ $JDK_RC_NAME =~ ^[[:print:]]*$ ]]` without having to worry at all, or should I make users still have to keep passing that extra level of quotation into things like IF_GIVEN to match what is already being done?

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

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


From matsaave at openjdk.org  Tue Nov 22 17:46:01 2022
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 22 Nov 2022 17:46:01 GMT
Subject: RFR: 8296754: AutoCreateSharedArchive in JDK 20 is not compatible
 with JDK 19 [v6]
In-Reply-To: <bStp4S1ZwR75Ej89W2VAUL4Py7DfDgG03yggGWsZl8w=.200561aa-a37e-4a24-a70c-30be21601377@github.com>
References: <bStp4S1ZwR75Ej89W2VAUL4Py7DfDgG03yggGWsZl8w=.200561aa-a37e-4a24-a70c-30be21601377@github.com>
Message-ID: <PRhM2sHVGLHVqMChwLuBF3fuM3MnOd700yFDVE7G71Y=.4392802f-8af8-4183-bd48-c1bb6eef1038@github.com>

> The -XX:+AutoCreateSharedArchive flag was implemented in JDK 19, however, this flag doesn't work across JDK 19 and 20.
> 
> Expected: JDK 20 should recreate the specified CDS archive
> Actual: JDK 20 cannot recognize the archive file and gives up
> 
> The new field from GenericCDSFileMapHeader is now in FileMapHeader. Verified with tier 1-4 tests.

Matias Saavedra Silva 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:

 - Added newline to end of test
 - Removed unused import
 - Test now passes
 - Changed whitespace and comment
 - Adjusted whitespace
 - Added test
 - 8296754: AutoCreateSharedArchive in JDK 20 is not compatible with JDK 19
 - Merge branch 'master' of https://github.com/openjdk/jdk
 - Merge branch 'master' of https://github.com/openjdk/jdk
 - Merge branch 'master' of https://github.com/openjdk/jdk
 - ... and 2 more: https://git.openjdk.org/jdk/compare/d89288e1...66b03944

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11148/files
  - new: https://git.openjdk.org/jdk/pull/11148/files/718b4f64..66b03944

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

  Stats: 44518 lines in 696 files changed: 16672 ins; 16259 del; 11587 mod
  Patch: https://git.openjdk.org/jdk/pull/11148.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11148/head:pull/11148

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


From matsaave at openjdk.org  Tue Nov 22 19:21:51 2022
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 22 Nov 2022 19:21:51 GMT
Subject: RFR: 8296754: AutoCreateSharedArchive in JDK 20 is not compatible
 with JDK 19 [v7]
In-Reply-To: <bStp4S1ZwR75Ej89W2VAUL4Py7DfDgG03yggGWsZl8w=.200561aa-a37e-4a24-a70c-30be21601377@github.com>
References: <bStp4S1ZwR75Ej89W2VAUL4Py7DfDgG03yggGWsZl8w=.200561aa-a37e-4a24-a70c-30be21601377@github.com>
Message-ID: <Fl-PEeor6H7-9EaHV2Sa-67JUxCIXTB3tI-KZxPPEbw=.45f6adc8-62ec-4724-b16c-221641e8c20b@github.com>

> The -XX:+AutoCreateSharedArchive flag was implemented in JDK 19, however, this flag doesn't work across JDK 19 and 20.
> 
> Expected: JDK 20 should recreate the specified CDS archive
> Actual: JDK 20 cannot recognize the archive file and gives up
> 
> The new field from GenericCDSFileMapHeader is now in FileMapHeader. Verified with tier 1-4 tests.

Matias Saavedra Silva has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into autoCreateSharedArchive_8296754
 - Added newline to end of test
 - Removed unused import
 - Test now passes
 - Changed whitespace and comment
 - Adjusted whitespace
 - Added test
 - 8296754: AutoCreateSharedArchive in JDK 20 is not compatible with JDK 19

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

Changes: https://git.openjdk.org/jdk/pull/11148/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11148&range=06
  Stats: 249 lines in 8 files changed: 191 ins; 15 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/11148.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11148/head:pull/11148

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


From ihse at openjdk.org  Tue Nov 22 20:03:09 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 22 Nov 2022 20:03:09 GMT
Subject: RFR: 8297444: Refactor the javacserver build tool
Message-ID: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>

Now that the javacserver no longer has any ambitions outside being a buildtool customized for the JDK build process, a lot of abstractions and generalizations can be removed.

This will allow the actual behavior to be more clearly visible, and will help debugging the issues we are still seeing (most likely race conditions), and to convert the tool to use the ToolProvider API in the future.

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

Commit messages:
 - 8297444: Refactor the javacserver build tool

Changes: https://git.openjdk.org/jdk/pull/11298/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11298&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297444
  Stats: 3440 lines in 35 files changed: 1198 ins; 2212 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/11298.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11298/head:pull/11298

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


From ihse at openjdk.org  Tue Nov 22 20:05:38 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 22 Nov 2022 20:05:38 GMT
Subject: RFR: 8297444: Refactor the javacserver build tool
In-Reply-To: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
References: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
Message-ID: <n5JTP5PQ6sRa4aIyfffbdemmhwtQRnZ8fkvneOEz0kU=.32d3d85b-4073-4fe1-bdb5-b11e3f9130e1@github.com>

On Tue, 22 Nov 2022 19:54:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Now that the javacserver no longer has any ambitions outside being a buildtool customized for the JDK build process, a lot of abstractions and generalizations can be removed.
> 
> This will allow the actual behavior to be more clearly visible, and will help debugging the issues we are still seeing (most likely race conditions), and to convert the tool to use the ToolProvider API in the future.

I realize this PR can be a bit of a challenge to review. I'll explain the changes I have done.

The "actual" changes I have made is to how the javacserver tool is called from the makefiles, and how the client starts the server. 

The client now takes a `--conf=<conf file>` argument, instead of `--server:conf=<conf file>`. This argument has to be the first argument; the rest of the argument line is passed on to javac in the server. This allowed me to remove all the complex option processing stuff. Also, the client cannot any longer be called in "stand-alone" mode where no server is used (basically a complex version of plain `javac`).

Secondly, the server is now started with a separate main method in the Server class. This means the entry point need not determine if it is being called as a client or a server, simplifying further. The server takes exactly one argument, the path of the port file. That means the last of the option processing could go.

Third, the configuration file has changed slightly. Instead of a `servercmd` there is now a `javacmd`, which tells the client how to start java (suitable path to the java executable, and proper flags) when launching the server. The actual class used to launch the server is known by the client and does not have to be provided by the makefile. This change made new configuration files incompatible with old files; it turned out make had a bit of a problem of recognizing the file needed to be updated, so I chose a slightly different name for the configuration file, to avoid strange recompilation errors when this patch gets integrated.

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

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


From ihse at openjdk.org  Tue Nov 22 20:12:42 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 22 Nov 2022 20:12:42 GMT
Subject: RFR: 8297444: Refactor the javacserver build tool
In-Reply-To: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
References: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
Message-ID: <Bvs88hx9hk3mMxpuzqqh5PPCDw-D4Rz82h4kRBnGajA=.d5deeb8a-6c23-4b67-a43f-3f75317418ae@github.com>

On Tue, 22 Nov 2022 19:54:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Now that the javacserver no longer has any ambitions outside being a buildtool customized for the JDK build process, a lot of abstractions and generalizations can be removed.
> 
> This will allow the actual behavior to be more clearly visible, and will help debugging the issues we are still seeing (most likely race conditions), and to convert the tool to use the ToolProvider API in the future.

The remaining changes are "pure" refactorings. I have moved code around, and reworked the abstraction layers. Basically, I put everything pertaining to the client in a long sequence (calling the client is basically a trivial sequence of events), and similarly for the server. Code that were shared between both were put in the `shared` or `util` packages (the latter for more auxiliary classes, the former for more central). Everything else were mercilessly removed.

I then abstracted out what seemed like reasonable parts from the long sequences in Client and Server, in the process mostly recreating the thread pool and idle detection classes of the former structure (so git will present them as renames).

I've been extra careful not to change any behavior regarding the portfile locking and synchronization, or the actual protocol exchanged by the server and client (with one exception: the exit code from javac is now returned as an integer, and not as a string representing the `Result` enum.) I believe there are a number of places where races can be introduced, and I intend to come back later and try to patch this. But I deemed it essential that I do not change any behavior in that regard in this patch, otherwise it would be hopeless to know if a potential future regression was caused by a mistake in my refactoring, or that any changed behavior was faulty.

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

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


From ihse at openjdk.org  Tue Nov 22 20:59:02 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 22 Nov 2022 20:59:02 GMT
Subject: RFR: 8297455: Use the official ToolProvider API to call javac
Message-ID: <bDWs3z14_EcdEAHgM-Dm2hbcxgdtKXB3mewU0V6vO-8=.e10967c0-a334-4d73-ba49-062a90e7999a@github.com>

In JDK-8297041, the javacserver was moved out of the JDK itself, and lifted out as a separate buildtool. Due to this, internal classes in jdk.compiler were no longer available. Therefore, the closest way to calling javac as before were to use `com.sun.tools.javac.Main.compile()`. This method is however deprecated for removal, and relying on that was only needed as a temporary measure during the transition.

After the major refactoring of the javacserver tool in JDK-8297444, it will be easy to replace the Main.compile API with the official ToolProvider API instead.

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

Depends on: https://git.openjdk.org/jdk/pull/11298

Commit messages:
 - 8297455: Use the official ToolProvider API to call javac

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

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


From ihse at openjdk.org  Tue Nov 22 20:59:03 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 22 Nov 2022 20:59:03 GMT
Subject: RFR: 8297455: Use the official ToolProvider API to call javac
In-Reply-To: <bDWs3z14_EcdEAHgM-Dm2hbcxgdtKXB3mewU0V6vO-8=.e10967c0-a334-4d73-ba49-062a90e7999a@github.com>
References: <bDWs3z14_EcdEAHgM-Dm2hbcxgdtKXB3mewU0V6vO-8=.e10967c0-a334-4d73-ba49-062a90e7999a@github.com>
Message-ID: <unr9CfY_t_qUacibGc3W3K40tugWoymjsI8r4hT1C-0=.a5e8c5ac-e0ff-49ca-81d9-f4e1a88be1ba@github.com>

On Tue, 22 Nov 2022 20:50:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In JDK-8297041, the javacserver was moved out of the JDK itself, and lifted out as a separate buildtool. Due to this, internal classes in jdk.compiler were no longer available. Therefore, the closest way to calling javac as before were to use `com.sun.tools.javac.Main.compile()`. This method is however deprecated for removal, and relying on that was only needed as a temporary measure during the transition.
> 
> After the major refactoring of the javacserver tool in JDK-8297444, it will be easy to replace the Main.compile API with the official ToolProvider API instead.

Note that this PR is dependent on JDK-8297444 (PR: https://github.com/openjdk/jdk/pull/11298)

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

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


From clanger at openjdk.org  Tue Nov 22 21:02:58 2022
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 22 Nov 2022 21:02:58 GMT
Subject: RFR: 8296904: Improve handling of macos xcode toolchain [v10]
In-Reply-To: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
References: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
Message-ID: <6OWUNMu0NlOnK_1SHua9Fl9FjzPMpFVVYhOzQ1Ih5qY=.c9baa6e4-49d8-4186-8e53-c2b1de906922@github.com>

> With this PR I'd like to make it easier to use dedicated installations of Xcode on Mac OS for OpenJDK builds without having to switch the active Xcode globally via `xcode-select`.
> 
> I propose adding a new configure flag `--with-xcode-path` that takes the path to an Xcode installation. If the option is set, this path is expanded to a valid `TOOLCHAIN_PATH`.
> 
> Furthermore, I fix detection of xcodebuild and correctly setting the sysroot from the toolchain by moving `AC_SUBST(TOOLCHAIN_PATH)` before calling `BASIC_SETUP_XCODE_SYSROOT` and honoring `TOOLCHAIN_PATH` in `BASIC_SETUP_XCODE_SYSROOT` in the case when no devkit is specified. As I see it, this is a viable fix, even if not introducing `--with-xcode-path`.

Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:

  Regenerate once more

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11113/files
  - new: https://git.openjdk.org/jdk/pull/11113/files/2a5e4e44..733c300f

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

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

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


From ihse at openjdk.org  Tue Nov 22 21:47:37 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 22 Nov 2022 21:47:37 GMT
Subject: RFR: 8296904: Improve handling of macos xcode toolchain [v10]
In-Reply-To: <6OWUNMu0NlOnK_1SHua9Fl9FjzPMpFVVYhOzQ1Ih5qY=.c9baa6e4-49d8-4186-8e53-c2b1de906922@github.com>
References: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
 <6OWUNMu0NlOnK_1SHua9Fl9FjzPMpFVVYhOzQ1Ih5qY=.c9baa6e4-49d8-4186-8e53-c2b1de906922@github.com>
Message-ID: <Zt4mCmj3WPzuAd7xvDBkun5DBHd4P11fn3UAqvSqvXk=.28f74182-8a7e-4b30-b5a0-048d9c54af37@github.com>

On Tue, 22 Nov 2022 21:02:58 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> With this PR I'd like to make it easier to use dedicated installations of Xcode on Mac OS for OpenJDK builds without having to switch the active Xcode globally via `xcode-select`.
>> 
>> I propose adding a new configure flag `--with-xcode-path` that takes the path to an Xcode installation. If the option is set, this path is expanded to a valid `TOOLCHAIN_PATH`.
>> 
>> Furthermore, I fix detection of xcodebuild and correctly setting the sysroot from the toolchain by moving `AC_SUBST(TOOLCHAIN_PATH)` before calling `BASIC_SETUP_XCODE_SYSROOT` and honoring `TOOLCHAIN_PATH` in `BASIC_SETUP_XCODE_SYSROOT` in the case when no devkit is specified. As I see it, this is a viable fix, even if not introducing `--with-xcode-path`.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Regenerate once more

Marked as reviewed by ihse (Reviewer).

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

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


From erikj at openjdk.org  Tue Nov 22 23:17:25 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 22 Nov 2022 23:17:25 GMT
Subject: RFR: 8297444: Refactor the javacserver build tool
In-Reply-To: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
References: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
Message-ID: <TgMb35D7NBQlloSqy1x-jGTfukkD1bAdXC4TZIw5uEs=.9075cea9-951a-4ff7-86a8-2273e8151b65@github.com>

On Tue, 22 Nov 2022 19:54:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Now that the javacserver no longer has any ambitions outside being a buildtool customized for the JDK build process, a lot of abstractions and generalizations can be removed.
> 
> This will allow the actual behavior to be more clearly visible, and will help debugging the issues we are still seeing (most likely race conditions), and to convert the tool to use the ToolProvider API in the future.

Only some minor comments. Looks good to me overall. The proof is in the building.

Have you tried more than just full builds on all platforms? Things like incremental builds, some forced failure conditions etc?

make/langtools/tools/javacserver/client/Client.java line 140:

> 138: 
> 139:     /*
> 140:      * Fork a server process process and wait for server to come around

Suggestion:

     * Fork a server process and wait for server to come around

make/langtools/tools/javacserver/client/Client.java line 148:

> 146:         cmd.addAll(Arrays.asList(conf.javaCommand().split(" ")));
> 147:         // javacserver.server.Server is the server main class
> 148:         cmd.add("javacserver.server.Server");

Did you consider referencing the class name using `Server.class.getName()`?

make/langtools/tools/javacserver/server/Server.java line 200:

> 198: 
> 199:                 // Set up logging for this thread. Stream back logging messages to
> 200:                 // client on the format format "level:msg".

Suggestion:

                // client on the format "level:msg".

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

Marked as reviewed by erikj (Reviewer).

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


From erikj at openjdk.org  Tue Nov 22 23:20:06 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 22 Nov 2022 23:20:06 GMT
Subject: RFR: 8297455: Use the official ToolProvider API to call javac
In-Reply-To: <bDWs3z14_EcdEAHgM-Dm2hbcxgdtKXB3mewU0V6vO-8=.e10967c0-a334-4d73-ba49-062a90e7999a@github.com>
References: <bDWs3z14_EcdEAHgM-Dm2hbcxgdtKXB3mewU0V6vO-8=.e10967c0-a334-4d73-ba49-062a90e7999a@github.com>
Message-ID: <udbl8J8U6WPQZEJXIzYehxr5YNQ81iFJicrrTLEOZ78=.48d644af-224c-4cc0-9be0-79e79d79d112@github.com>

On Tue, 22 Nov 2022 20:50:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In JDK-8297041, the javacserver was moved out of the JDK itself, and lifted out as a separate buildtool. Due to this, internal classes in jdk.compiler were no longer available. Therefore, the closest way to calling javac as before were to use `com.sun.tools.javac.Main.compile()`. This method is however deprecated for removal, and relying on that was only needed as a temporary measure during the transition.
> 
> After the major refactoring of the javacserver tool in JDK-8297444, it will be easy to replace the Main.compile API with the official ToolProvider API instead.

Marked as reviewed by erikj (Reviewer).

Just to make sure, will this find the interim javac before the bootjdk javac? How is this enforced?

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

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


From ihse at openjdk.org  Tue Nov 22 23:40:30 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 22 Nov 2022 23:40:30 GMT
Subject: RFR: 8297444: Refactor the javacserver build tool [v2]
In-Reply-To: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
References: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
Message-ID: <JXJEikVK-ZQKZS1VbHglXyWe76XvWGJLMqQ_Sog8P18=.53584398-0392-4164-a692-49ff929ed136@github.com>

> Now that the javacserver no longer has any ambitions outside being a buildtool customized for the JDK build process, a lot of abstractions and generalizations can be removed.
> 
> This will allow the actual behavior to be more clearly visible, and will help debugging the issues we are still seeing (most likely race conditions), and to convert the tool to use the ToolProvider API in the future.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Fix typo #2
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Fix typo
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11298/files
  - new: https://git.openjdk.org/jdk/pull/11298/files/3dd8af2a..2a0e0975

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

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

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


From ihse at openjdk.org  Tue Nov 22 23:40:31 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 22 Nov 2022 23:40:31 GMT
Subject: RFR: 8297444: Refactor the javacserver build tool [v2]
In-Reply-To: <TgMb35D7NBQlloSqy1x-jGTfukkD1bAdXC4TZIw5uEs=.9075cea9-951a-4ff7-86a8-2273e8151b65@github.com>
References: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
 <TgMb35D7NBQlloSqy1x-jGTfukkD1bAdXC4TZIw5uEs=.9075cea9-951a-4ff7-86a8-2273e8151b65@github.com>
Message-ID: <g5TrBpGApGYMd3fNc2w3eeA1b7J4axMFT8l_bAIMW2M=.7caef6aa-26bc-472b-834c-a99def22cf06@github.com>

On Tue, 22 Nov 2022 23:15:20 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Things like incremental builds, some forced failure conditions etc?

I tested simple incremental builds but I should probably make a bit more advanced versions where I modify different files to trigger more real-life like scenarios, including compilation errors. Good point.

> make/langtools/tools/javacserver/client/Client.java line 148:
> 
>> 146:         cmd.addAll(Arrays.asList(conf.javaCommand().split(" ")));
>> 147:         // javacserver.server.Server is the server main class
>> 148:         cmd.add("javacserver.server.Server");
> 
> Did you consider referencing the class name using `Server.class.getName()`?

No, can't say I have. Do you think there is anything to gain by doing that? (Apart from possibly getting this right automatically if the class is renamed by IDE tools) (I'm not sure it would be a win in readability)

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

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


From ihse at openjdk.org  Tue Nov 22 23:48:49 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 22 Nov 2022 23:48:49 GMT
Subject: RFR: 8297455: Use the official ToolProvider API to call javac
In-Reply-To: <bDWs3z14_EcdEAHgM-Dm2hbcxgdtKXB3mewU0V6vO-8=.e10967c0-a334-4d73-ba49-062a90e7999a@github.com>
References: <bDWs3z14_EcdEAHgM-Dm2hbcxgdtKXB3mewU0V6vO-8=.e10967c0-a334-4d73-ba49-062a90e7999a@github.com>
Message-ID: <xLMfuwSf852VdOtQVXrUtiWlmear1MjKiFUYp4ofSFY=.409b6ba5-7c1f-4717-8c61-86fb07bfdaa7@github.com>

On Tue, 22 Nov 2022 20:50:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In JDK-8297041, the javacserver was moved out of the JDK itself, and lifted out as a separate buildtool. Due to this, internal classes in jdk.compiler were no longer available. Therefore, the closest way to calling javac as before were to use `com.sun.tools.javac.Main.compile()`. This method is however deprecated for removal, and relying on that was only needed as a temporary measure during the transition.
> 
> After the major refactoring of the javacserver tool in JDK-8297444, it will be easy to replace the Main.compile API with the official ToolProvider API instead.

Well, I assume so. If this does not work properly, the problem will most likely be already in JDK-8297444; this patch is just choosing a different path to end up in the same class, as far as I can understand.

The thing that makes (or should make) us chose the interim javac is the `$(INTERIM_LANGTOOLS_ARGS)` which is passed to java when launching the server. (This is since these flags are passed in the config file to the client as `javacmd`). 

I'll add some test output code to the interim compiler to verify that it is actually executed, both in JDK-8297444 and in this PR.

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

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


From erikj at openjdk.org  Tue Nov 22 23:55:19 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 22 Nov 2022 23:55:19 GMT
Subject: RFR: 8297444: Refactor the javacserver build tool [v2]
In-Reply-To: <g5TrBpGApGYMd3fNc2w3eeA1b7J4axMFT8l_bAIMW2M=.7caef6aa-26bc-472b-834c-a99def22cf06@github.com>
References: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
 <TgMb35D7NBQlloSqy1x-jGTfukkD1bAdXC4TZIw5uEs=.9075cea9-951a-4ff7-86a8-2273e8151b65@github.com>
 <g5TrBpGApGYMd3fNc2w3eeA1b7J4axMFT8l_bAIMW2M=.7caef6aa-26bc-472b-834c-a99def22cf06@github.com>
Message-ID: <MAtvRVWPv0Wvo6bTB-QfFhgb0NXa70shx8rAIlnweq4=.2b3918dc-8a7d-4e01-b8a9-5b521e8f817c@github.com>

On Tue, 22 Nov 2022 23:32:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/langtools/tools/javacserver/client/Client.java line 148:
>> 
>>> 146:         cmd.addAll(Arrays.asList(conf.javaCommand().split(" ")));
>>> 147:         // javacserver.server.Server is the server main class
>>> 148:         cmd.add("javacserver.server.Server");
>> 
>> Did you consider referencing the class name using `Server.class.getName()`?
>
> No, can't say I have. Do you think there is anything to gain by doing that? (Apart from possibly getting this right automatically if the class is renamed by IDE tools) (I'm not sure it would be a win in readability)

I like to reference class names that way so that it's typed instead of just a string. If the class changes name, you get a compilation error, and the IDE would handle refactoring automatically. Not a strong need in this particular instance, just something I generally tend to do.

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

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


From iklam at openjdk.org  Wed Nov 23 00:08:33 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 23 Nov 2022 00:08:33 GMT
Subject: RFR: 8296754: AutoCreateSharedArchive in JDK 20 is not compatible
 with JDK 19 [v7]
In-Reply-To: <Fl-PEeor6H7-9EaHV2Sa-67JUxCIXTB3tI-KZxPPEbw=.45f6adc8-62ec-4724-b16c-221641e8c20b@github.com>
References: <bStp4S1ZwR75Ej89W2VAUL4Py7DfDgG03yggGWsZl8w=.200561aa-a37e-4a24-a70c-30be21601377@github.com>
 <Fl-PEeor6H7-9EaHV2Sa-67JUxCIXTB3tI-KZxPPEbw=.45f6adc8-62ec-4724-b16c-221641e8c20b@github.com>
Message-ID: <I9VQbsmHnl3z8MFSnlTHYhJBh7I2wjvuL2Vdt9SvhRY=.d94f518d-5a3e-4e4c-a5da-c8abb496c147@github.com>

On Tue, 22 Nov 2022 19:21:51 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The -XX:+AutoCreateSharedArchive flag was implemented in JDK 19, however, this flag doesn't work across JDK 19 and 20.
>> 
>> Expected: JDK 20 should recreate the specified CDS archive
>> Actual: JDK 20 cannot recognize the archive file and gives up
>> 
>> The new field from GenericCDSFileMapHeader is now in FileMapHeader. Verified with tier 1-4 tests.
>
> Matias Saavedra Silva 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 eight additional commits since the last revision:
> 
>  - Merge branch 'master' into autoCreateSharedArchive_8296754
>  - Added newline to end of test
>  - Removed unused import
>  - Test now passes
>  - Changed whitespace and comment
>  - Adjusted whitespace
>  - Added test
>  - 8296754: AutoCreateSharedArchive in JDK 20 is not compatible with JDK 19

Approved latest changes again. Matias had to do second force-push which reverted the effects of the first force-push.

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

Marked as reviewed by iklam (Reviewer).

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


From dholmes at openjdk.org  Wed Nov 23 04:49:24 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Nov 2022 04:49:24 GMT
Subject: RFR: 8296886: Fix various include sort order issues [v2]
In-Reply-To: <JjDvqbScU0zoekDaaXbN4IUU0bv9tdm2Pvev5sqVggw=.e17fde8e-4462-4803-88e8-d1af700812e7@github.com>
References: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
 <JjDvqbScU0zoekDaaXbN4IUU0bv9tdm2Pvev5sqVggw=.e17fde8e-4462-4803-88e8-d1af700812e7@github.com>
Message-ID: <ZGtggo6m1dr3BWr4BqX6LmKm-G3TvlfkTonNHcvvNms=.5a4c0228-e5f0-4fc6-ace0-07374cd8b808@github.com>

On Wed, 16 Nov 2022 16:17:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The sorted blocks of includes have deteriorated to the point that I felt compelled to clean up some of the issues.
>> 
>> *EDIT*: The below discussion has been deferred out of this PR. Now this only deals with fixing the placement and sorting of includes, plus some surrounding blank lines.
>> 
>> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory, so I don't think that's a good enough argument, again IMHO. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share
 , just like the other platform-independent headers in HotSpot.
>> 
>> While going over the include headers I've also cleaned up surrounding whitespaces and incorrect include guards.
>
> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Cleanups
>  - Merge remote-tracking branch 'upstream/master' into various_include_order_fixes
>  - Various include order fixes

Seems okay and generally uncontroversial :)

I'm not sure why conditional includes (that don't rely on macros.hpp) need to come at the end rather than in normal sort order? I don't care either way but a rationale for this would be good if it is to be the preferred style.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

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


From kbarrett at openjdk.org  Wed Nov 23 05:02:09 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 23 Nov 2022 05:02:09 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <nVCoCE9doWoQ54qhPSbn1xM79YLzhggfELps4CpI53o=.3af1e9bf-5389-439e-bd78-1b4fce336c2f@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <gay-N6xDnfKHcngB9ddJIZD6Jfg2m_ZCzZn1gWPFN-o=.785036e8-1d1d-41d3-bac3-211b9d03cd71@github.com>
 <XXVqN4ByCrB34JRZSgiNYWsdrwEOTKjo5u81sTFG5bE=.7748c17a-4a13-42aa-b10d-219fe6775da2@github.com>
 <nVCoCE9doWoQ54qhPSbn1xM79YLzhggfELps4CpI53o=.3af1e9bf-5389-439e-bd78-1b4fce336c2f@github.com>
Message-ID: <4NLoUD7YZRPKuVc08q_QnsbuPpb0wZIdmAuMN2tqM_c=.a34c13d0-0a6b-495e-b48e-e88debf6b4da@github.com>

On Mon, 21 Nov 2022 02:43:12 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Out of curiosity, is there a way to get the discussion on approving the use of alignas back up? [...]

A PR to address JDK-8252584 would be welcomed by me. Just do the process for
Style Guide changes (see the Style Guide or previous PRs for such). I don't
expect it would be very controversial. I think the only reason it hasn't
already happened is because nobody has gotten around to it, or felt the need
for it.

JDK-8250269 touches a bit more code (mostly in stubGenerator_x86_64 and
macroAssembler_x86_32), but also seems like it should be straightforward.

> > The various MSVC-conditional direct uses of __declspec(align(N)) should probably currently be using ATTRIBUTE_ALIGNED.
> 
> The instances of `__declspec(align())` changed here are in the native libraries written in C, not within HotSpot itself. From what I can see at least HotSpot never uses compiler alignment attributes directly and always strictly sticks to `ATTRIBUTE_ALIGNED` (which is probably a good thing)

You are right that the Windows-conditionalized uses are in non-HotSpot code.
I missed that context when skimming through the changes.  Since Visual Studio
is always C++ (even though the shared files are written as C), using alignas
with appropriate conditionalization in those files should be fine.

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

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


From kbarrett at openjdk.org  Wed Nov 23 05:24:24 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 23 Nov 2022 05:24:24 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <UwMOA0K5cYSIeTkRgIl6QlPe2iTTA5z0vCH3jzUmx4E=.2b35fc6c-e96a-4807-863f-583631128a4e@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
 <0fVP40VVRuOoZCEJ1M3BLubshBHbD4m_lj-j1qaGTTk=.391ade50-b3fe-4d4e-ae71-ba8a975a31cd@github.com>
 <mowWW-lO9a5Zo4iT-sbh1YTZFXO4UjKuJK7OpfrhFFo=.c7e5430a-de42-4465-ba85-10dfb8c71184@github.com>
 <UwMOA0K5cYSIeTkRgIl6QlPe2iTTA5z0vCH3jzUmx4E=.2b35fc6c-e96a-4807-863f-583631128a4e@github.com>
Message-ID: <klNxsMmpOjXNtFhaX2Kqt-YqYSBCyCAoJkqnmFr_IeY=.b55c0f1a-4331-4d65-af05-a20b59f73f57@github.com>

On Mon, 14 Nov 2022 12:20:54 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Sorry my eyes must be playing tricks on me. ??
>> 
>> Why did you need to add this here?
>
> It's to avoid redefining the linkage as static in os_windows.cpp (where it's implemented) after an extern declaration (inside the class), which is forbidden by C++11:
> 
>> The linkages implied by successive declarations for a given entity shall agree. That is, within a given scope, each declaration declaring the same variable name or the same overloading of a function name shall imply the same linkage.
> 
> While 2019 by default seems to ignore this rule and accepts the conflicting linkage as a language extension, this can cause issues with newer and stricter versions of the Visual C++ compiler (especially with -permissive- passed during compilation, which Magnus and Daniel have pointed out in another discussion will become the default mode of compilation in the future). It's not possible to declare a static friend inside a class, so the addition above takes advantage of another C++ feature instead:
> 
>> ?11.3/4 [class.friend]
> A function first declared in a friend declaration has external linkage (3.5). Otherwise, the function retains its previous linkage (7.1.1).

I think the problem here is the friend declaration, which doesn't look like it's needed and could be deleted.

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

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


From clanger at openjdk.org  Wed Nov 23 07:08:20 2022
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 23 Nov 2022 07:08:20 GMT
Subject: RFR: 8296904: Improve handling of macos xcode toolchain [v8]
In-Reply-To: <uDK7HioIzuXDQHB8aH-sH3oTvdLXiEHkVXbVd4u-sbY=.9f0e9789-2505-4668-8b30-083df3e61165@github.com>
References: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
 <5YbIcpQJvPO9c2oM87PR83dz1fYAQ5m1E1eGdeN8SNg=.f9f1650e-54c6-4c07-bf92-eec2cba3ed42@github.com>
 <Qu9c9diGDeAweYglJfMGJh5iYoRXbB7-kDLrv8ydasM=.d79682d5-7f07-4229-97da-8d16b19f38c7@github.com>
 <GkZFV_fXIbQHA0gxbvzORSieywV2JJyA9OVbB-plb1w=.5df341b3-ac61-40f8-bbdf-36d6b09dd395@github.com>
 <uDK7HioIzuXDQHB8aH-sH3oTvdLXiEHkVXbVd4u-sbY=.9f0e9789-2505-4668-8b30-083df3e61165@github.com>
Message-ID: <hBYYR4Cj7Qp9GVvLY00qKoOd4b73KUOX0XmM_ktW94s=.025b40ee-c902-42b8-a95e-eab714216726@github.com>

On Tue, 22 Nov 2022 14:10:44 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> @magicus Thanks for fixing my enumeration. I recognized that you have regenerated all the html files with a newer pandoc and I had to resolve with master. I guess you'll need to regenerate with my current branch once more - otherwise I think I'm breaking some of the new style.
>
> @RealCLanger Finally regenerated once more: [fcd20c73ed9f0a44c0614a54580c755a16387a6a](https://github.com/magicus/jdk/commit/fcd20c73ed9f0a44c0614a54580c755a16387a6a)

Thanks @magicus for your help.

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

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


From clanger at openjdk.org  Wed Nov 23 07:10:33 2022
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 23 Nov 2022 07:10:33 GMT
Subject: Integrated: 8296904: Improve handling of macos xcode toolchain
In-Reply-To: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
References: <xfHTp2yyUZykETsXy2gLPMyAv_ldbIiR_7sanBUeOOs=.a7da3b6f-2a5a-4a14-92ff-dbe00e7abce3@github.com>
Message-ID: <CQHt4wOCEHg6M3bR0QlnR2v-LIPFXDzjX44tDhDkk9w=.ba75bccd-2a45-4f06-83b2-81d8ba72f501@github.com>

On Fri, 11 Nov 2022 22:22:51 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> With this PR I'd like to make it easier to use dedicated installations of Xcode on Mac OS for OpenJDK builds without having to switch the active Xcode globally via `xcode-select`.
> 
> I propose adding a new configure flag `--with-xcode-path` that takes the path to an Xcode installation. If the option is set, this path is expanded to a valid `TOOLCHAIN_PATH`.
> 
> Furthermore, I fix detection of xcodebuild and correctly setting the sysroot from the toolchain by moving `AC_SUBST(TOOLCHAIN_PATH)` before calling `BASIC_SETUP_XCODE_SYSROOT` and honoring `TOOLCHAIN_PATH` in `BASIC_SETUP_XCODE_SYSROOT` in the case when no devkit is specified. As I see it, this is a viable fix, even if not introducing `--with-xcode-path`.

This pull request has now been integrated.

Changeset: 470f3424
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/470f3424fcce0e41b75cccdd5e3a56771cd07ff5
Stats:     85 lines in 3 files changed: 31 ins; 5 del; 49 mod

8296904: Improve handling of macos xcode toolchain

Reviewed-by: erikj, ihse

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

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


From kbarrett at openjdk.org  Wed Nov 23 07:14:32 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 23 Nov 2022 07:14:32 GMT
Subject: RFR: 8296886: Fix various include sort order issues [v2]
In-Reply-To: <ZGtggo6m1dr3BWr4BqX6LmKm-G3TvlfkTonNHcvvNms=.5a4c0228-e5f0-4fc6-ace0-07374cd8b808@github.com>
References: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
 <JjDvqbScU0zoekDaaXbN4IUU0bv9tdm2Pvev5sqVggw=.e17fde8e-4462-4803-88e8-d1af700812e7@github.com>
 <ZGtggo6m1dr3BWr4BqX6LmKm-G3TvlfkTonNHcvvNms=.5a4c0228-e5f0-4fc6-ace0-07374cd8b808@github.com>
Message-ID: <Iz3sVAPFBaDf5dAbv7fpZzf6zDLC4CfJ378w6vuieWM=.04c5e321-45b9-42af-8707-4c00fa6a49d9@github.com>

On Wed, 23 Nov 2022 04:47:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm not sure why conditional includes (that don't rely on macros.hpp) need to come at the end rather than in normal sort order? I don't care either way but a rationale for this would be good if it is to be the preferred style.

Because the Style Guide says:
* Put conditional inclusions (`#if ...`) at the end of the include list.

I think most of our conditional includes these days are to support conditional features.  It makes sense to group all the additional includes related to a feature.

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

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


From shade at openjdk.org  Wed Nov 23 07:16:21 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 23 Nov 2022 07:16:21 GMT
Subject: Integrated: 8297350: Update JMH devkit to 1.36
In-Reply-To: <pzG2m0-Iiv1HZMEgw1d84Gnnl56HjFAfUY3tKaV7ULA=.27833c6c-4aff-4081-9535-3098c8266e90@github.com>
References: <pzG2m0-Iiv1HZMEgw1d84Gnnl56HjFAfUY3tKaV7ULA=.27833c6c-4aff-4081-9535-3098c8266e90@github.com>
Message-ID: <IdSN-y90PHx4Da--3rAjRxiKMt-lhgkIRobWwmhUxyo=.1a0f36d1-f0a6-4fc2-9276-a89c8ca0adcf@github.com>

On Mon, 21 Nov 2022 15:36:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> JMH 1.36 was released, so we can bump the devkit too.
> 
> Additional testing:
>  - [x] Ad-hoc benchmarks with newly generated devkit

This pull request has now been integrated.

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

8297350: Update JMH devkit to 1.36

Reviewed-by: erikj

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

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


From kbarrett at openjdk.org  Wed Nov 23 07:21:27 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 23 Nov 2022 07:21:27 GMT
Subject: RFR: 8296886: Fix various include sort order issues [v2]
In-Reply-To: <JjDvqbScU0zoekDaaXbN4IUU0bv9tdm2Pvev5sqVggw=.e17fde8e-4462-4803-88e8-d1af700812e7@github.com>
References: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
 <JjDvqbScU0zoekDaaXbN4IUU0bv9tdm2Pvev5sqVggw=.e17fde8e-4462-4803-88e8-d1af700812e7@github.com>
Message-ID: <AGubz9zAOrA4xdLxUemwyJ-Xf-QO2e7ycdTu03ZOers=.3897e5b5-1457-485c-a19c-b74211649ef3@github.com>

On Wed, 16 Nov 2022 16:17:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The sorted blocks of includes have deteriorated to the point that I felt compelled to clean up some of the issues.
>> 
>> *EDIT*: The below discussion has been deferred out of this PR. Now this only deals with fixing the placement and sorting of includes, plus some surrounding blank lines.
>> 
>> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory, so I don't think that's a good enough argument, again IMHO. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share
 , just like the other platform-independent headers in HotSpot.
>> 
>> While going over the include headers I've also cleaned up surrounding whitespaces and incorrect include guards.
>
> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Cleanups
>  - Merge remote-tracking branch 'upstream/master' into various_include_order_fixes
>  - Various include order fixes

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From dholmes at openjdk.org  Wed Nov 23 07:31:24 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Nov 2022 07:31:24 GMT
Subject: RFR: 8296886: Fix various include sort order issues [v2]
In-Reply-To: <Iz3sVAPFBaDf5dAbv7fpZzf6zDLC4CfJ378w6vuieWM=.04c5e321-45b9-42af-8707-4c00fa6a49d9@github.com>
References: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
 <JjDvqbScU0zoekDaaXbN4IUU0bv9tdm2Pvev5sqVggw=.e17fde8e-4462-4803-88e8-d1af700812e7@github.com>
 <ZGtggo6m1dr3BWr4BqX6LmKm-G3TvlfkTonNHcvvNms=.5a4c0228-e5f0-4fc6-ace0-07374cd8b808@github.com>
 <Iz3sVAPFBaDf5dAbv7fpZzf6zDLC4CfJ378w6vuieWM=.04c5e321-45b9-42af-8707-4c00fa6a49d9@github.com>
Message-ID: <U4uymnR5jYSg1zZFnsb1NVS0tY2yEvWU6--zqyVNmeI=.fc7a9e67-5aaf-494a-87ad-1482f868265c@github.com>

On Wed, 23 Nov 2022 07:12:13 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > I'm not sure why conditional includes (that don't rely on macros.hpp) need to come at the end rather than in normal sort order? I don't care either way but a rationale for this would be good if it is to be the preferred style.
> 
> Because the Style Guide says:
> 
>     * Put conditional inclusions (`#if ...`) at the end of the include list.

Ah I see. Thanks for that @kimbarrett  
> 
> I think most of our conditional includes these days are to support conditional features. It makes sense to group all the additional includes related to a feature.

True. There are a lot of single includes but it makes sense to have one simple rule.

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

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


From stuefe at openjdk.org  Wed Nov 23 07:49:28 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 23 Nov 2022 07:49:28 GMT
Subject: RFR: 8296886: Fix various include sort order issues [v2]
In-Reply-To: <JjDvqbScU0zoekDaaXbN4IUU0bv9tdm2Pvev5sqVggw=.e17fde8e-4462-4803-88e8-d1af700812e7@github.com>
References: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
 <JjDvqbScU0zoekDaaXbN4IUU0bv9tdm2Pvev5sqVggw=.e17fde8e-4462-4803-88e8-d1af700812e7@github.com>
Message-ID: <qqYzwYoDhBX_LYrsD_5UBu5JY1jVuwKutBfNp_3u06U=.a08b7766-cf81-4c96-8d4b-6949f220dd3a@github.com>

On Wed, 16 Nov 2022 16:17:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The sorted blocks of includes have deteriorated to the point that I felt compelled to clean up some of the issues.
>> 
>> *EDIT*: The below discussion has been deferred out of this PR. Now this only deals with fixing the placement and sorting of includes, plus some surrounding blank lines.
>> 
>> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory, so I don't think that's a good enough argument, again IMHO. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share
 , just like the other platform-independent headers in HotSpot.
>> 
>> While going over the include headers I've also cleaned up surrounding whitespaces and incorrect include guards.
>
> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Cleanups
>  - Merge remote-tracking branch 'upstream/master' into various_include_order_fixes
>  - Various include order fixes

Looks good and is an improvement. About the removed comments after includes, I am sometimes guilty of this to mark includes that came just for one specific little thing - the implied hope is that disentangling includes and removing unnecessary ones periodically is easier that way. However, this never worked. I wish we had an automatic include "GC" process to reduce the includes, like Ioi sometimes does manually.

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

Marked as reviewed by stuefe (Reviewer).

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


From cstein at openjdk.org  Wed Nov 23 09:41:18 2022
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 23 Nov 2022 09:41:18 GMT
Subject: RFR: 8297444: Refactor the javacserver build tool [v2]
In-Reply-To: <JXJEikVK-ZQKZS1VbHglXyWe76XvWGJLMqQ_Sog8P18=.53584398-0392-4164-a692-49ff929ed136@github.com>
References: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
 <JXJEikVK-ZQKZS1VbHglXyWe76XvWGJLMqQ_Sog8P18=.53584398-0392-4164-a692-49ff929ed136@github.com>
Message-ID: <6RfobOhE7uu5mMuHP_ea2iwL_IKBbEI0I3WMaNV38VY=.5538da47-c278-4603-8422-9b64fde7da8c@github.com>

On Tue, 22 Nov 2022 23:40:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Now that the javacserver no longer has any ambitions outside being a buildtool customized for the JDK build process, a lot of abstractions and generalizations can be removed.
>> 
>> This will allow the actual behavior to be more clearly visible, and will help debugging the issues we are still seeing (most likely race conditions), and to convert the tool to use the ToolProvider API in the future.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix typo #2
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Fix typo
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

Marked as reviewed by cstein (Committer).

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

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


From jwaters at openjdk.org  Wed Nov 23 12:00:49 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 23 Nov 2022 12:00:49 GMT
Subject: RFR: 8252584: HotSpot Style Guide should permit alignas
Message-ID: <wtpB01HooEIU2FxGS9E5KPIv1ogztEw-XYFRTUNw5Cw=.6e6625ee-5343-49d6-98f3-2962f269184d@github.com>

Add alignas to the permitted features set. Though the corresponding entry mentions this should not be done for classes, there's no actual difference in practice with all our supported compilers, because their nonstandard syntax also has the same limitations and issues with dynamic allocation as the C++ alignas, and including such a restriction of falling back to ATTRIBUTE_ALIGNED in the case of classes in the style guide would ultimately not really serve much of a point

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

Commit messages:
 - Include the correct pandoc emitted html files
 - Restore html files
 - HotSpot Style Guide

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

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


From lujaniuk at openjdk.org  Wed Nov 23 12:10:23 2022
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Wed, 23 Nov 2022 12:10:23 GMT
Subject: RFR: JDK-8297000 [jib] Add more friendly warning for proxy issues
 [v2]
In-Reply-To: <kFnWkvqxdHvbqf4hajjA2n9rBELOGWPTk_vLxPfU4P8=.dc3062c3-fcde-44b9-8433-2f04ccd9074b@github.com>
References: <kFnWkvqxdHvbqf4hajjA2n9rBELOGWPTk_vLxPfU4P8=.dc3062c3-fcde-44b9-8433-2f04ccd9074b@github.com>
Message-ID: <oDiYkTFbw_cfc96jxAtu1wyTaW8iZ6GNN53N_UuBGAE=.ec65ecc2-5c31-4a6e-808b-5535ae81a2b2@github.com>

> When jib tries to download itself behind a proxy, sometimes it can get a different file than it expected. This can result in cryptic errors that are hard to troubleshoot. Let's handle this a little more gracefully by detecting it in the bootstrapper and printing an error.

Ludvig Janiuk has updated the pull request incrementally with one additional commit since the last revision:

  sh-friendly version

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11159/files
  - new: https://git.openjdk.org/jdk/pull/11159/files/331b1c33..78e846ec

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

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

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


From lujaniuk at openjdk.org  Wed Nov 23 12:13:32 2022
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Wed, 23 Nov 2022 12:13:32 GMT
Subject: RFR: JDK-8297000 [jib] Add more friendly warning for proxy issues
 [v3]
In-Reply-To: <kFnWkvqxdHvbqf4hajjA2n9rBELOGWPTk_vLxPfU4P8=.dc3062c3-fcde-44b9-8433-2f04ccd9074b@github.com>
References: <kFnWkvqxdHvbqf4hajjA2n9rBELOGWPTk_vLxPfU4P8=.dc3062c3-fcde-44b9-8433-2f04ccd9074b@github.com>
Message-ID: <xRGnTcpDzXFE36A-IhuzJ1ozwjQ8_hyp6MReQBJJL5k=.bee4d8c9-6a6e-41d3-b30b-a533c1f231db@github.com>

> When jib tries to download itself behind a proxy, sometimes it can get a different file than it expected. This can result in cryptic errors that are hard to troubleshoot. Let's handle this a little more gracefully by detecting it in the bootstrapper and printing an error.

Ludvig Janiuk has updated the pull request incrementally with one additional commit since the last revision:

  ws

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11159/files
  - new: https://git.openjdk.org/jdk/pull/11159/files/78e846ec..fcd186bb

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

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

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


From lujaniuk at openjdk.org  Wed Nov 23 12:13:33 2022
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Wed, 23 Nov 2022 12:13:33 GMT
Subject: RFR: JDK-8297000 [jib] Add more friendly warning for proxy issues
 [v3]
In-Reply-To: <g7h5TV7ODyfO-vgxt-DIEpE082Y8ms5l6ZVpbglSNFg=.72d7b643-9f11-42bb-b06d-6d54f1996163@github.com>
References: <kFnWkvqxdHvbqf4hajjA2n9rBELOGWPTk_vLxPfU4P8=.dc3062c3-fcde-44b9-8433-2f04ccd9074b@github.com>
 <7KaGiYrIV_4cG9u5iGG9pf_WwZHs3lZezgqu6517Ph0=.621935dd-90bf-46e5-845f-5b2931ea2252@github.com>
 <g7h5TV7ODyfO-vgxt-DIEpE082Y8ms5l6ZVpbglSNFg=.72d7b643-9f11-42bb-b06d-6d54f1996163@github.com>
Message-ID: <BduXLxfglsKHNTZx1DtXUCBHw4ev5Br_jND5ZgUMPmY=.4332534a-0ce1-4dd3-856d-b3fd95437ad5@github.com>

On Wed, 16 Nov 2022 19:59:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> bin/jib.sh line 137:
>> 
>>> 135:     FILEOUTPUT=`file ${installed_jib_script}.gz`
>>> 136:     # ${X:${#Y}} gives X without the first ${#Y} characters, and ${#Y} is length of Y.
>>> 137:     FILEOUTPUT=${FILEOUTPUT:${#PREFIX}}
>> 
>> I think this is a bashism. While we do have /bin/bash in the shebang, this does not really matter since we have no executable bit on the script, so users will have to explicitly call it with a shell. So many users are likely to do `sh bin/jib.sh`, and then this will break.
>> 
>> My recommendation would be to use standard tools like cut or grep instead, something like:
>> 
>> file $installedscript.gz | grep "gzip compressed data" -q
>> if test $? -neq 0; then 
>> ...
>
> (Warning: untested code)
> 
> I also would like to clarify the use of bash. For configure script, and scripts started by the makefiles, we rely on and enforce bash, so in those cases bashisms are accepted (and almost encouraged, at least good ones). But in "user facing" scripts like this, or the top level `configure` script, we want to make minimal assumptions about the shell used, since the shebang path means nothing in our case.

@magicus I've changed to something inspired by your comment and tested on linux, solaris and macos. Do you think the current version would be ok?

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

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


From ihse at openjdk.org  Wed Nov 23 13:32:22 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 23 Nov 2022 13:32:22 GMT
Subject: RFR: JDK-8297000 [jib] Add more friendly warning for proxy issues
 [v3]
In-Reply-To: <xRGnTcpDzXFE36A-IhuzJ1ozwjQ8_hyp6MReQBJJL5k=.bee4d8c9-6a6e-41d3-b30b-a533c1f231db@github.com>
References: <kFnWkvqxdHvbqf4hajjA2n9rBELOGWPTk_vLxPfU4P8=.dc3062c3-fcde-44b9-8433-2f04ccd9074b@github.com>
 <xRGnTcpDzXFE36A-IhuzJ1ozwjQ8_hyp6MReQBJJL5k=.bee4d8c9-6a6e-41d3-b30b-a533c1f231db@github.com>
Message-ID: <rHg6scKjHgHB2rayoZgvP8PzSf8RntGGfC9DOiQuWLM=.403703fd-a2c8-40ae-bbac-673171c70659@github.com>

On Wed, 23 Nov 2022 12:13:32 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

>> When jib tries to download itself behind a proxy, sometimes it can get a different file than it expected. This can result in cryptic errors that are hard to troubleshoot. Let's handle this a little more gracefully by detecting it in the bootstrapper and printing an error.
>
> Ludvig Janiuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ws

Yes, this looks excellent!

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

Marked as reviewed by ihse (Reviewer).

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


From erikj at openjdk.org  Wed Nov 23 13:38:23 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 23 Nov 2022 13:38:23 GMT
Subject: RFR: JDK-8297000 [jib] Add more friendly warning for proxy issues
 [v3]
In-Reply-To: <xRGnTcpDzXFE36A-IhuzJ1ozwjQ8_hyp6MReQBJJL5k=.bee4d8c9-6a6e-41d3-b30b-a533c1f231db@github.com>
References: <kFnWkvqxdHvbqf4hajjA2n9rBELOGWPTk_vLxPfU4P8=.dc3062c3-fcde-44b9-8433-2f04ccd9074b@github.com>
 <xRGnTcpDzXFE36A-IhuzJ1ozwjQ8_hyp6MReQBJJL5k=.bee4d8c9-6a6e-41d3-b30b-a533c1f231db@github.com>
Message-ID: <kcvjfTv0FyQ1_oapVhMthJvoFs1fpbQhJUTcQ75yoko=.1491a93d-60d3-41d0-ab78-18ea2f1eff72@github.com>

On Wed, 23 Nov 2022 12:13:32 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

>> When jib tries to download itself behind a proxy, sometimes it can get a different file than it expected. This can result in cryptic errors that are hard to troubleshoot. Let's handle this a little more gracefully by detecting it in the bootstrapper and printing an error.
>
> Ludvig Janiuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ws

Marked as reviewed by erikj (Reviewer).

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

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


From jwaters at openjdk.org  Wed Nov 23 13:38:54 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 23 Nov 2022 13:38:54 GMT
Subject: RFR: 8296478: Rework 8282948 and 8282700 to use the new autoconf
 UTIL_ARG_WITH [v6]
In-Reply-To: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
References: <uMXtMhIf6XuWr4KSNdBEC2Bh4n3jHE5q6haccs0dYfE=.821be080-d88a-478e-8fef-0e8e0d438598@github.com>
Message-ID: <T3WjTwMhCQUmoTiZiEF3q4XKu_ZTdj-W-1Lj18CQgH4=.48409a87-7a5b-4e69-bc76-1ba9f2c1cd97@github.com>

> 8285093 introduced the new UTIL_ARG_WITH definition, which was not available when both 8282948 and 8282700 were written. They can now be moved to using the cleaner logic that UTIL_ARG_WITH grants.
> 
> There are many more options that still use AC_ARG_WITH in jdk-version.m4. They are out of the scope of this commit, which aims only to rework the previous integrated commits mentioned above.

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

  Include the broken options for now

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11020/files
  - new: https://git.openjdk.org/jdk/pull/11020/files/4cbd7207..47a5387c

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

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

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


From jwaters at openjdk.org  Wed Nov 23 13:41:01 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 23 Nov 2022 13:41:01 GMT
Subject: RFR: 8295884: Implement IDE support for Eclipse [v19]
In-Reply-To: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
Message-ID: <TEYuAZVJI90xtxJrsQyVBckIZd-SLZDRpLk6uthovKI=.b6b41da2-ea45-4126-9e07-4db5aa2c5895@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 Java Virtual Machine's source code, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's unique 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 pull request now contains 24 commits:

 - Resolve Conflict
 - Oversight
 - Include miscellaneous directories in any Workspace
 - Merge remote-tracking branch 'upstream/master' into eclipse
 - More Changes
 - Rename RAnDOM to WORKSPACE_ID
 - Merge remote-tracking branch 'upstream/master' into eclipse
 - Merge remote-tracking branch 'upstream/master' into eclipse
 - Merge remote-tracking branch 'upstream/master' into eclipse
 - Merge remote-tracking branch 'upstream/master' into eclipse
 - ... and 14 more: https://git.openjdk.org/jdk/compare/5b3d86f2...71a89d2c

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

Changes: https://git.openjdk.org/jdk/pull/10853/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=18
  Stats: 555 lines in 4 files changed: 555 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  Wed Nov 23 13:50:32 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 23 Nov 2022 13:50:32 GMT
Subject: RFR: 8295884: Implement IDE support for Eclipse [v20]
In-Reply-To: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
Message-ID: <TEcUftWkCcIWcJOCKV6k74CKVbOEvikxWCJmeJyk43g=.81824dea-759b-41e9-9230-2297c9cf1eb3@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 Java Virtual Machine's source code, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's unique 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 refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Merge remote-tracking branch 'upstream/master' into eclipse

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10853/files
  - new: https://git.openjdk.org/jdk/pull/10853/files/71a89d2c..bd5f620b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=18-19

  Stats: 79 lines in 1 file changed: 51 ins; 26 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 Nov 23 14:29:44 2022
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Wed, 23 Nov 2022 14:29:44 GMT
Subject: Integrated: JDK-8297000 [jib] Add more friendly warning for proxy
 issues
In-Reply-To: <kFnWkvqxdHvbqf4hajjA2n9rBELOGWPTk_vLxPfU4P8=.dc3062c3-fcde-44b9-8433-2f04ccd9074b@github.com>
References: <kFnWkvqxdHvbqf4hajjA2n9rBELOGWPTk_vLxPfU4P8=.dc3062c3-fcde-44b9-8433-2f04ccd9074b@github.com>
Message-ID: <37HFSCzGduZlcLaewN8KcyyyBQnJL-vdg0DHAnRW_r8=.3ed6d97c-c432-4989-8b4f-df83018c8196@github.com>

On Tue, 15 Nov 2022 09:55:38 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> When jib tries to download itself behind a proxy, sometimes it can get a different file than it expected. This can result in cryptic errors that are hard to troubleshoot. Let's handle this a little more gracefully by detecting it in the bootstrapper and printing an error.

This pull request has now been integrated.

Changeset: 0d93ab9d
Author:    Ludvig Janiuk <lujaniuk at openjdk.org>
Committer: Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0d93ab9dff04409469faa26d5cdb29c4d6488537
Stats:     9 lines in 1 file changed: 9 ins; 0 del; 0 mod

8297000: [jib] Add more friendly warning for proxy issues

Reviewed-by: erikj, ihse

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

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


From kbarrett at openjdk.org  Wed Nov 23 21:47:09 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 23 Nov 2022 21:47:09 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <klNxsMmpOjXNtFhaX2Kqt-YqYSBCyCAoJkqnmFr_IeY=.b55c0f1a-4331-4d65-af05-a20b59f73f57@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
 <0fVP40VVRuOoZCEJ1M3BLubshBHbD4m_lj-j1qaGTTk=.391ade50-b3fe-4d4e-ae71-ba8a975a31cd@github.com>
 <mowWW-lO9a5Zo4iT-sbh1YTZFXO4UjKuJK7OpfrhFFo=.c7e5430a-de42-4465-ba85-10dfb8c71184@github.com>
 <UwMOA0K5cYSIeTkRgIl6QlPe2iTTA5z0vCH3jzUmx4E=.2b35fc6c-e96a-4807-863f-583631128a4e@github.com>
 <klNxsMmpOjXNtFhaX2Kqt-YqYSBCyCAoJkqnmFr_IeY=.b55c0f1a-4331-4d65-af05-a20b59f73f57@github.com>
Message-ID: <3mBOtLQz_ulylm0XJkhUBwzPEV7AoPmMo20facw9Xn4=.c431ac9c-4f1f-4db6-bb46-745987f06777@github.com>

On Wed, 23 Nov 2022 05:22:10 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> It's to avoid redefining the linkage as static in os_windows.cpp (where it's implemented) after an extern declaration (inside the class), which is forbidden by C++11:
>> 
>>> The linkages implied by successive declarations for a given entity shall agree. That is, within a given scope, each declaration declaring the same variable name or the same overloading of a function name shall imply the same linkage.
>> 
>> While 2019 by default seems to ignore this rule and accepts the conflicting linkage as a language extension, this can cause issues with newer and stricter versions of the Visual C++ compiler (especially with -permissive- passed during compilation, which Magnus and Daniel have pointed out in another discussion will become the default mode of compilation in the future). It's not possible to declare a static friend inside a class, so the addition above takes advantage of another C++ feature instead:
>> 
>>> ?11.3/4 [class.friend]
>> A function first declared in a friend declaration has external linkage (3.5). Otherwise, the function retains its previous linkage (7.1.1).
>
> I think the problem here is the friend declaration, which doesn't look like it's needed and could be deleted.

Digging into this some more, the friend declaration exists to provide access to the private `os::win32::enum Ept`.

One obvious and cheap solution to that would be to make that enum public.  I think that would be an improvement vs the current friend declaration.  But there are some other things one could complain about there, such as the type of the function requiring a complicated function pointer cast where it's used.  Here's a patch that I think cleans this up.


diff --git a/src/hotspot/os/windows/os_windows.cpp b/src/hotspot/os/windows/os_windows.cpp
index 0651f0868f3..bf9e759b1d6 100644
--- a/src/hotspot/os/windows/os_windows.cpp
+++ b/src/hotspot/os/windows/os_windows.cpp
@@ -511,7 +511,9 @@ JNIEXPORT
 LONG WINAPI topLevelExceptionFilter(struct _EXCEPTION_POINTERS* exceptionInfo);
 
 // Thread start routine for all newly created threads
-static unsigned __stdcall thread_native_entry(Thread* thread) {
+// Called with the associated Thread* as the argument.
+unsigned __stdcall os::win32::thread_native_entry(void* t) {
+  Thread* thread = static_cast<Thread*>(t);
 
   thread->record_stack_base_and_size();
   thread->initialize_thread_current();
@@ -744,7 +746,7 @@ bool os::create_thread(Thread* thread, ThreadType thr_type,
     thread_handle =
       (HANDLE)_beginthreadex(NULL,
                              (unsigned)stack_size,
-                             (unsigned (__stdcall *)(void*)) thread_native_entry,
+                             &os::win32::thread_native_entry,
                              thread,
                              initflag,
                              &thread_id);
diff --git a/src/hotspot/os/windows/os_windows.hpp b/src/hotspot/os/windows/os_windows.hpp
index 94d7c3c5e2d..197797078d7 100644
--- a/src/hotspot/os/windows/os_windows.hpp
+++ b/src/hotspot/os/windows/os_windows.hpp
@@ -36,7 +36,6 @@ typedef void (*signal_handler_t)(int);
 
 class os::win32 {
   friend class os;
-  friend unsigned __stdcall thread_native_entry(Thread*);
 
  protected:
   static int    _processor_type;
@@ -70,6 +69,10 @@ class os::win32 {
   static HINSTANCE load_Windows_dll(const char* name, char *ebuf, int ebuflen);
 
  private:
+  // The handler passed to _beginthreadex().
+  // Called with the associated Thread* as the argument.
+  static unsigned __stdcall thread_native_entry(void*);
+
   enum Ept { EPT_THREAD, EPT_PROCESS, EPT_PROCESS_DIE };
   // Wrapper around _endthreadex(), exit() and _exit()
   static int exit_process_or_thread(Ept what, int exit_code);

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

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


From jwaters at openjdk.org  Thu Nov 24 07:05:02 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 24 Nov 2022 07:05:02 GMT
Subject: RFR: 8295884: Implement IDE support for Eclipse [v21]
In-Reply-To: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
Message-ID: <YzO7NgAYSjmhk5h7UsHQhYLRMjFLfsVU5lREXPD4fZ0=.418898b6-6718-4485-a499-863b980918bd@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 Java Virtual Machine's source code, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's unique 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 pull request now contains 25 commits:

 - Merge remote-tracking branch 'upstream/master' into eclipse
 - Merge remote-tracking branch 'upstream/master' into eclipse
 - Oversight
 - Include miscellaneous directories in any Workspace
 - Merge remote-tracking branch 'upstream/master' into eclipse
 - More Changes
 - Rename RAnDOM to WORKSPACE_ID
 - Merge remote-tracking branch 'upstream/master' into eclipse
 - Merge remote-tracking branch 'upstream/master' into eclipse
 - Merge remote-tracking branch 'upstream/master' into eclipse
 - ... and 15 more: https://git.openjdk.org/jdk/compare/abeddab9...b5ecdabc

-------------

Changes: https://git.openjdk.org/jdk/pull/10853/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=20
  Stats: 580 lines in 4 files changed: 580 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 stefank at openjdk.org  Thu Nov 24 13:21:32 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 24 Nov 2022 13:21:32 GMT
Subject: RFR: 8296886: Fix various include sort order issues [v3]
In-Reply-To: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
References: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
Message-ID: <cfAG-KZqSsFuVgG1zJ2w5lsRQK2LhioHEZZFCi4lcrY=.6ac8d359-4467-4bc9-83dc-28e6d64372d5@github.com>

> The sorted blocks of includes have deteriorated to the point that I felt compelled to clean up some of the issues.
> 
> *EDIT*: The below discussion has been deferred out of this PR. Now this only deals with fixing the placement and sorting of includes, plus some surrounding blank lines.
> 
> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory, so I don't think that's a good enough argument, again IMHO. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share,
  just like the other platform-independent headers in HotSpot.
> 
> While going over the include headers I've also cleaned up surrounding whitespaces and incorrect include guards.

Stefan Karlsson 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 remote-tracking branch 'upstream/master' into 8296886_various_include_order_fixes
 - Cleanups
 - Merge remote-tracking branch 'upstream/master' into various_include_order_fixes
 - Various include order fixes

-------------

Changes: https://git.openjdk.org/jdk/pull/11108/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11108&range=02
  Stats: 325 lines in 116 files changed: 143 ins; 164 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/11108.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11108/head:pull/11108

PR: https://git.openjdk.org/jdk/pull/11108


From stefank at openjdk.org  Thu Nov 24 13:21:33 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 24 Nov 2022 13:21:33 GMT
Subject: RFR: 8296886: Fix various include sort order issues [v2]
In-Reply-To: <JjDvqbScU0zoekDaaXbN4IUU0bv9tdm2Pvev5sqVggw=.e17fde8e-4462-4803-88e8-d1af700812e7@github.com>
References: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
 <JjDvqbScU0zoekDaaXbN4IUU0bv9tdm2Pvev5sqVggw=.e17fde8e-4462-4803-88e8-d1af700812e7@github.com>
Message-ID: <aB2D2T5oao8JflrSY4Z7sVOqRW9XaDbbwBXWaAvgxko=.5037b486-5396-4f8e-abfc-6bce36d9c5a1@github.com>

On Wed, 16 Nov 2022 16:17:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The sorted blocks of includes have deteriorated to the point that I felt compelled to clean up some of the issues.
>> 
>> *EDIT*: The below discussion has been deferred out of this PR. Now this only deals with fixing the placement and sorting of includes, plus some surrounding blank lines.
>> 
>> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory, so I don't think that's a good enough argument, again IMHO. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share
 , just like the other platform-independent headers in HotSpot.
>> 
>> While going over the include headers I've also cleaned up surrounding whitespaces and incorrect include guards.
>
> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Cleanups
>  - Merge remote-tracking branch 'upstream/master' into various_include_order_fixes
>  - Various include order fixes

Thanks all for reviewing! I'm going to let the GHA run before integrating this change.

-------------

PR: https://git.openjdk.org/jdk/pull/11108


From stefank at openjdk.org  Thu Nov 24 15:10:25 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 24 Nov 2022 15:10:25 GMT
Subject: Integrated: 8296886: Fix various include sort order issues
In-Reply-To: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
References: <qmA4OGVYmaXWA4xQMksmBuQPTFZuNTuLSB7qShPbtwI=.d43529a9-f963-44fc-b760-ea35d8e9ed0b@github.com>
Message-ID: <asFADZv1u0zYb1T9YA5_T7IUi1ul8A786WlEwh3vJyQ=.4896c3d5-6f4f-4b8e-be29-36e73580b956@github.com>

On Fri, 11 Nov 2022 14:26:20 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The sorted blocks of includes have deteriorated to the point that I felt compelled to clean up some of the issues.
> 
> *EDIT*: The below discussion has been deferred out of this PR. Now this only deals with fixing the placement and sorting of includes, plus some surrounding blank lines.
> 
> One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our written style guide around include files. One argument why it was OK have the files in include/ pushed up to the top of the sorted block, was that the file was included without specifying a directory. That's an argument that contradicts how we treat platform-dependent files, which (unfortunately) often also are specified without a prefixed directory, so I don't think that's a good enough argument, again IMHO. To remove this special case, I've removed the extraneous make file entry to have src/hotspot/share/include in the set of directories to search for headers when compiling HotSpot. Now all the header files in src/hotspot/share/include gets included by specifying the path from src/hotspot/share,
  just like the other platform-independent headers in HotSpot.
> 
> While going over the include headers I've also cleaned up surrounding whitespaces and incorrect include guards.

This pull request has now been integrated.

Changeset: df6cf1e4
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/df6cf1e41d0fc2dd5f5c094f66c7c8969cf5548d
Stats:     325 lines in 116 files changed: 143 ins; 164 del; 18 mod

8296886: Fix various include sort order issues

Reviewed-by: kbarrett, dholmes, stuefe

-------------

PR: https://git.openjdk.org/jdk/pull/11108


From aturbanov at openjdk.org  Thu Nov 24 20:22:12 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 24 Nov 2022 20:22:12 GMT
Subject: RFR: 8297444: Refactor the javacserver build tool [v2]
In-Reply-To: <JXJEikVK-ZQKZS1VbHglXyWe76XvWGJLMqQ_Sog8P18=.53584398-0392-4164-a692-49ff929ed136@github.com>
References: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
 <JXJEikVK-ZQKZS1VbHglXyWe76XvWGJLMqQ_Sog8P18=.53584398-0392-4164-a692-49ff929ed136@github.com>
Message-ID: <XRoBz-nmoTWrtm7P8OoZDgYQ1QA1FGgifOxd6VGpNFc=.15d3bc1f-2fc0-4fc6-8b07-94af49d0ab1c@github.com>

On Tue, 22 Nov 2022 23:40:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Now that the javacserver no longer has any ambitions outside being a buildtool customized for the JDK build process, a lot of abstractions and generalizations can be removed.
>> 
>> This will allow the actual behavior to be more clearly visible, and will help debugging the issues we are still seeing (most likely race conditions), and to convert the tool to use the ToolProvider API in the future.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix typo #2
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Fix typo
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

make/langtools/tools/javacserver/server/Server.java line 69:

> 67:     private static LazyInitFileLog errorLog;
> 68: 
> 69:     public static void main(String... args)  {

Nit:
Suggestion:

    public static void main(String... args) {

-------------

PR: https://git.openjdk.org/jdk/pull/11298


From ihse at openjdk.org  Thu Nov 24 20:36:06 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 24 Nov 2022 20:36:06 GMT
Subject: RFR: 8297444: Refactor the javacserver build tool [v3]
In-Reply-To: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
References: <s4dsLPoeiQfzzRyG0dt3KH1CdPRpliSFk-9AUHXV1SM=.8df4bead-cbca-44da-a488-c3801df6328e@github.com>
Message-ID: <OlS33zMeauZeFqPD85eKiYa4Pra2PypEp2_BKNdF3Tw=.5ab80a9f-94bc-4802-9c2a-be702f93e9ba@github.com>

> Now that the javacserver no longer has any ambitions outside being a buildtool customized for the JDK build process, a lot of abstractions and generalizations can be removed.
> 
> This will allow the actual behavior to be more clearly visible, and will help debugging the issues we are still seeing (most likely race conditions), and to convert the tool to use the ToolProvider API in the future.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11298/files
  - new: https://git.openjdk.org/jdk/pull/11298/files/2a0e0975..82998663

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11298&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11298&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11298.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11298/head:pull/11298

PR: https://git.openjdk.org/jdk/pull/11298


From clanger at openjdk.org  Fri Nov 25 13:34:21 2022
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 25 Nov 2022 13:34:21 GMT
Subject: RFR: 8291444: GHA builds/tests won't run manually if disabled from
 automatic running
Message-ID: <nmM0yoVE744sqK1B0OTzkXZRPhbPAAL9plYvg7twHbQ=.b7f04f09-ab82-4639-9a86-82d2ea19e1f6@github.com>

This is an attempt to fix the issue reported in JDK-8291444.

The check for secrets.JDK_SUBMIT_FILTER should only be applied to the push event but not on e.g. workflow_dispatch.
Currently setting JDK_SUBMIT_FILTER would lead to setting every platform to 'false', even when manually triggering the GHA run via workflow_dispatch.

I furthermore propose to relax the check for unknown events. In OpenJDK we only use/define workflow_dispatch and push. Other events would hence not trigger the workflow anyway. However, downstream vendors (like us in SapMachine) might use other events such as pull_request and they would then need to patch this away. This kind of downstream issue was also reported by [Amazon](https://mail.openjdk.org/pipermail/build-dev/2022-August/035102.html). If you agree, I would remove the commented lines 91-93. Otherwise I have to uncomment them.

-------------

Commit messages:
 - JDK-8291444

Changes: https://git.openjdk.org/jdk/pull/11365/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11365&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8291444
  Stats: 17 lines in 1 file changed: 7 ins; 6 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11365.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11365/head:pull/11365

PR: https://git.openjdk.org/jdk/pull/11365


From clanger at openjdk.org  Fri Nov 25 13:34:21 2022
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 25 Nov 2022 13:34:21 GMT
Subject: RFR: 8291444: GHA builds/tests won't run manually if disabled from
 automatic running
In-Reply-To: <nmM0yoVE744sqK1B0OTzkXZRPhbPAAL9plYvg7twHbQ=.b7f04f09-ab82-4639-9a86-82d2ea19e1f6@github.com>
References: <nmM0yoVE744sqK1B0OTzkXZRPhbPAAL9plYvg7twHbQ=.b7f04f09-ab82-4639-9a86-82d2ea19e1f6@github.com>
Message-ID: <F-GFs9dU6CYPxEgsJCamGCeTBac3o322lA02t2NjPgM=.639b6dad-aaa2-4174-900e-64529262c96c@github.com>

On Fri, 25 Nov 2022 13:24:09 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> This is an attempt to fix the issue reported in JDK-8291444.
> 
> The check for secrets.JDK_SUBMIT_FILTER should only be applied to the push event but not on e.g. workflow_dispatch.
> Currently setting JDK_SUBMIT_FILTER would lead to setting every platform to 'false', even when manually triggering the GHA run via workflow_dispatch.
> 
> I furthermore propose to relax the check for unknown events. In OpenJDK we only use/define workflow_dispatch and push. Other events would hence not trigger the workflow anyway. However, downstream vendors (like us in SapMachine) might use other events such as pull_request and they would then need to patch this away. This kind of downstream issue was also reported by [Amazon](https://mail.openjdk.org/pipermail/build-dev/2022-August/035102.html). If you agree, I would remove the commented lines 91-93. Otherwise I have to uncomment them.

@magicus @dholmes-ora FYA

-------------

PR: https://git.openjdk.org/jdk/pull/11365


From asotona at openjdk.org  Fri Nov 25 15:20:20 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 25 Nov 2022 15:20:20 GMT
Subject: RFR: [DRAFT] 8294982: Implementation of Classfile API
In-Reply-To: <SgfHbOybBS2rH24eOQDSgoS_Uc0YWdT0YlO6oJ79aFs=.9c07a20b-f21e-4610-b48a-82d9cce5eb98@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <l5TiO65JvoxaXsg8kYAs1ugfRWjNVd_6HstdFTb2nfg=.05b28b60-3c60-4d83-a3e9-cbba6b4567d0@github.com>
 <SgfHbOybBS2rH24eOQDSgoS_Uc0YWdT0YlO6oJ79aFs=.9c07a20b-f21e-4610-b48a-82d9cce5eb98@github.com>
Message-ID: <DlAuVj41--sgq4vJsJ9fylBqS8dRoDeGPArZhxex4do=.6e66937d-7b42-4ccd-95f5-43d66c374fa8@github.com>

On Mon, 7 Nov 2022 13:01:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> make/modules/java.base/Java.gmk line 37:
>> 
>>> 35: 
>>> 36: EXCLUDES += java/lang/doc-files
>>> 37: EXCLUDES += jdk/classfile/snippets
>> 
>> I don't like hard-coded excludes like this. Is this the first real-world example of snippets in the JDK? If not, how has this been resolved in other instances? Maybe we need a more general method to exclude snippets from compiling.
>
> I'll fix it, thanks.

Unfortunately I found only two use cases of external snippets in JDK. One is explicitly excluding the snippets package and the other does not care, so the snippets are included.

-------------

PR: https://git.openjdk.org/jdk/pull/10982


From serb at openjdk.org  Sat Nov 26 08:12:15 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 26 Nov 2022 08:12:15 GMT
Subject: RFR: 8291444: GHA builds/tests won't run manually if disabled from
 automatic running
In-Reply-To: <nmM0yoVE744sqK1B0OTzkXZRPhbPAAL9plYvg7twHbQ=.b7f04f09-ab82-4639-9a86-82d2ea19e1f6@github.com>
References: <nmM0yoVE744sqK1B0OTzkXZRPhbPAAL9plYvg7twHbQ=.b7f04f09-ab82-4639-9a86-82d2ea19e1f6@github.com>
Message-ID: <stfzoPgP1Tkx8o9Vin8-npD8-NH6b-myAnm1DS_ukW4=.08f043c7-2252-4a38-88b2-026eb5221cac@github.com>

On Fri, 25 Nov 2022 13:24:09 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> This is an attempt to fix the issue reported in JDK-8291444.
> 
> The check for secrets.JDK_SUBMIT_FILTER should only be applied to the push event but not on e.g. workflow_dispatch.
> Currently setting JDK_SUBMIT_FILTER would lead to setting every platform to 'false', even when manually triggering the GHA run via workflow_dispatch.
> 
> I furthermore propose to relax the check for unknown events. In OpenJDK we only use/define workflow_dispatch and push. Other events would hence not trigger the workflow anyway. However, downstream vendors (like us in SapMachine) might use other events such as pull_request and they would then need to patch this away. This kind of downstream issue was also reported by [Amazon](https://mail.openjdk.org/pipermail/build-dev/2022-August/035102.html). If you agree, I would remove the commented lines 91-93. Otherwise I have to uncomment them.

This should be reviewed by the build team. But I can confirm this change solve the problem I mentioned [here](https://mail.openjdk.org/pipermail/build-dev/2022-August/035102.html).

-------------

Marked as reviewed by serb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11365


From ihse at openjdk.org  Sat Nov 26 18:44:51 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sat, 26 Nov 2022 18:44:51 GMT
Subject: RFR: [DRAFT] 8294982: Implementation of Classfile API
In-Reply-To: <DlAuVj41--sgq4vJsJ9fylBqS8dRoDeGPArZhxex4do=.6e66937d-7b42-4ccd-95f5-43d66c374fa8@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <l5TiO65JvoxaXsg8kYAs1ugfRWjNVd_6HstdFTb2nfg=.05b28b60-3c60-4d83-a3e9-cbba6b4567d0@github.com>
 <SgfHbOybBS2rH24eOQDSgoS_Uc0YWdT0YlO6oJ79aFs=.9c07a20b-f21e-4610-b48a-82d9cce5eb98@github.com>
 <DlAuVj41--sgq4vJsJ9fylBqS8dRoDeGPArZhxex4do=.6e66937d-7b42-4ccd-95f5-43d66c374fa8@github.com>
Message-ID: <PLQc3Yv11kNl-fh1nE58BR3rUVH4VSJSgvB4ZAYyR5w=.dbaf8d8c-e9eb-4da9-a023-e4415ba22475@github.com>

On Fri, 25 Nov 2022 15:18:09 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> I'll fix it, thanks.
>
> Unfortunately I found only two use cases of external snippets in JDK. One is explicitly excluding the snippets package and the other does not care, so the snippets are included.

Is the practice of naming the directory `snippets` well-established or mandated? Otherwise I think a name like `snippet-files` (akin to `doc-files`) would be much better, since it indicates that is not a java package name. (These do not usually include `-`; I am unsure if this is prohibited by the specification, or just not used by convention.)

In fact, when checking, I see that there is already a handful of `snippet-files`:

./jdk.jfr/share/classes/jdk/jfr/snippet-files
./jdk.jfr/share/classes/jdk/jfr/consumer/snippet-files
./java.compiler/share/classes/javax/tools/snippet-files


So maybe rename it to `snippet-files`, and I'll look into making exclusion of `snippet-files` be done automatically.

-------------

PR: https://git.openjdk.org/jdk/pull/10982


From egahlin at openjdk.org  Sun Nov 27 01:40:14 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 27 Nov 2022 01:40:14 GMT
Subject: RFR: [DRAFT] 8294982: Implementation of Classfile API
In-Reply-To: <PLQc3Yv11kNl-fh1nE58BR3rUVH4VSJSgvB4ZAYyR5w=.dbaf8d8c-e9eb-4da9-a023-e4415ba22475@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <l5TiO65JvoxaXsg8kYAs1ugfRWjNVd_6HstdFTb2nfg=.05b28b60-3c60-4d83-a3e9-cbba6b4567d0@github.com>
 <SgfHbOybBS2rH24eOQDSgoS_Uc0YWdT0YlO6oJ79aFs=.9c07a20b-f21e-4610-b48a-82d9cce5eb98@github.com>
 <DlAuVj41--sgq4vJsJ9fylBqS8dRoDeGPArZhxex4do=.6e66937d-7b42-4ccd-95f5-43d66c374fa8@github.com>
 <PLQc3Yv11kNl-fh1nE58BR3rUVH4VSJSgvB4ZAYyR5w=.dbaf8d8c-e9eb-4da9-a023-e4415ba22475@github.com>
Message-ID: <y3w-JGRd8R1FukOrkM3tt0RFwkKAilLYiL2TexYTD_0=.3d9f6e85-b24e-443e-b625-80e147447a66@github.com>

On Sat, 26 Nov 2022 18:42:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Unfortunately I found only two use cases of external snippets in JDK. One is explicitly excluding the snippets package and the other does not care, so the snippets are included.
>
> Is the practice of naming the directory `snippets` well-established or mandated? Otherwise I think a name like `snippet-files` (akin to `doc-files`) would be much better, since it indicates that is not a java package name. (These do not usually include `-`; I am unsure if this is prohibited by the specification, or just not used by convention.)
> 
> In fact, when checking, I see that there is already a handful of `snippet-files`:
> 
> ./jdk.jfr/share/classes/jdk/jfr/snippet-files
> ./jdk.jfr/share/classes/jdk/jfr/consumer/snippet-files
> ./java.compiler/share/classes/javax/tools/snippet-files
> 
> 
> So maybe rename it to `snippet-files`, and I'll look into making exclusion of `snippet-files` be done automatically.

It would be nice to get the directory excluded by default. I used the snippet-files name since it was mentioned in the JEP https://openjdk.org/jeps/413

-------------

PR: https://git.openjdk.org/jdk/pull/10982


From jwaters at openjdk.org  Sun Nov 27 07:29:53 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 27 Nov 2022 07:29:53 GMT
Subject: RFR: 8295884: Implement IDE support for Eclipse [v22]
In-Reply-To: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
Message-ID: <qaK8noq7Pmf130EhxdCxUaGzPCKj9nOqxAKfNDPJ4Yk=.32c2cc12-bdf5-43ef-9819-a25cb2ca82a4@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 Java Virtual Machine's source code, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's unique 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 pull request now contains 27 commits:

 - Merge remote-tracking branch 'upstream/master' into eclipse
 - Format
 - Merge remote-tracking branch 'upstream/master' into eclipse
 - Merge remote-tracking branch 'upstream/master' into eclipse
 - Oversight
 - Include miscellaneous directories in any Workspace
 - Merge remote-tracking branch 'upstream/master' into eclipse
 - More Changes
 - Rename RAnDOM to WORKSPACE_ID
 - Merge remote-tracking branch 'upstream/master' into eclipse
 - ... and 17 more: https://git.openjdk.org/jdk/compare/50f9043c...d4c2ebf4

-------------

Changes: https://git.openjdk.org/jdk/pull/10853/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=21
  Stats: 580 lines in 4 files changed: 580 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 asotona at openjdk.org  Mon Nov 28 14:44:40 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 28 Nov 2022 14:44:40 GMT
Subject: RFR: [DRAFT] 8294982: Implementation of Classfile API [v2]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <ultxYcHiJii917KdyvKupIKa5CY3FPY5XOTzHOOce-Q=.1dfa2b42-8587-490e-a599-3ff22eeed62f@github.com>

> **This pull request is not intended for immediate integration to JDK mainline.**
> 
> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/jdk/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  PackageSnippets moved from jdk/classfile/snippets to jdk/classfile/snippet-files

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/4b3e63d5..3827e529

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=00-01

  Stats: 35 lines in 5 files changed: 1 ins; 3 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982


From asotona at openjdk.org  Mon Nov 28 14:46:41 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 28 Nov 2022 14:46:41 GMT
Subject: RFR: [DRAFT] 8294982: Implementation of Classfile API [v2]
In-Reply-To: <y3w-JGRd8R1FukOrkM3tt0RFwkKAilLYiL2TexYTD_0=.3d9f6e85-b24e-443e-b625-80e147447a66@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <l5TiO65JvoxaXsg8kYAs1ugfRWjNVd_6HstdFTb2nfg=.05b28b60-3c60-4d83-a3e9-cbba6b4567d0@github.com>
 <SgfHbOybBS2rH24eOQDSgoS_Uc0YWdT0YlO6oJ79aFs=.9c07a20b-f21e-4610-b48a-82d9cce5eb98@github.com>
 <DlAuVj41--sgq4vJsJ9fylBqS8dRoDeGPArZhxex4do=.6e66937d-7b42-4ccd-95f5-43d66c374fa8@github.com>
 <PLQc3Yv11kNl-fh1nE58BR3rUVH4VSJSgvB4ZAYyR5w=.dbaf8d8c-e9eb-4da9-a023-e4415ba22475@github.com>
 <y3w-JGRd8R1FukOrkM3tt0RFwkKAilLYiL2TexYTD_0=.3d9f6e85-b24e-443e-b625-80e147447a66@github.com>
Message-ID: <9DkX_WiKaon_oKZKOiZdkuUnsadGzwY7EGBsI4lh7k4=.c24e15ab-0490-441d-8e7b-41025be907b9@github.com>

On Sun, 27 Nov 2022 01:38:01 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Is the practice of naming the directory `snippets` well-established or mandated? Otherwise I think a name like `snippet-files` (akin to `doc-files`) would be much better, since it indicates that is not a java package name. (These do not usually include `-`; I am unsure if this is prohibited by the specification, or just not used by convention.)
>> 
>> In fact, when checking, I see that there is already a handful of `snippet-files`:
>> 
>> ./jdk.jfr/share/classes/jdk/jfr/snippet-files
>> ./jdk.jfr/share/classes/jdk/jfr/consumer/snippet-files
>> ./java.compiler/share/classes/javax/tools/snippet-files
>> 
>> 
>> So maybe rename it to `snippet-files`, and I'll look into making exclusion of `snippet-files` be done automatically.
>
> It would be nice to get the directory excluded (from packaging) by default. I used the snippet-files name since it was mentioned in the JEP https://openjdk.org/jeps/413

Snippets moved from `jdk/classfile/snippets` to `jdk/classfile/snippet-files` and explicit exclusion of `jdk/classfile/snippet-files` will be removed when excluded from compilation by default.

Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/10982


From matsaave at openjdk.org  Mon Nov 28 15:29:31 2022
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 28 Nov 2022 15:29:31 GMT
Subject: Integrated: 8296754: AutoCreateSharedArchive in JDK 20 is not
 compatible with JDK 19
In-Reply-To: <bStp4S1ZwR75Ej89W2VAUL4Py7DfDgG03yggGWsZl8w=.200561aa-a37e-4a24-a70c-30be21601377@github.com>
References: <bStp4S1ZwR75Ej89W2VAUL4Py7DfDgG03yggGWsZl8w=.200561aa-a37e-4a24-a70c-30be21601377@github.com>
Message-ID: <HmSmvXuqbcaH9EAfaTp2jUgJ6GDnVrcGL1sLJ-pLzOo=.962fd5f4-1ab5-4446-b076-0f5a7cd0a891@github.com>

On Mon, 14 Nov 2022 21:33:23 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> The -XX:+AutoCreateSharedArchive flag was implemented in JDK 19, however, this flag doesn't work across JDK 19 and 20.
> 
> Expected: JDK 20 should recreate the specified CDS archive
> Actual: JDK 20 cannot recognize the archive file and gives up
> 
> The new field from GenericCDSFileMapHeader is now in FileMapHeader. Verified with tier 1-4 tests.

This pull request has now been integrated.

Changeset: a249a525
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Committer: Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a249a52501f3cd7d4fbe5293d14ac8d0d6ffcc69
Stats:     249 lines in 8 files changed: 191 ins; 15 del; 43 mod

8296754: AutoCreateSharedArchive in JDK 20 is not compatible with JDK 19

Reviewed-by: ccheung, iklam, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/11148


From jwaters at openjdk.org  Tue Nov 29 01:13:39 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 29 Nov 2022 01:13:39 GMT
Subject: RFR: 8252584: HotSpot Style Guide should permit alignas
Message-ID: <CVHNRNKRV_f2n8F5s0AiQR7lgIrHBHzaUj5ewTDMU7I=.9920de89-7b18-4f22-9ca8-94479d4a292f@github.com>

Add alignas to the permitted features set with some restrictions. (Thanks @kimbarrett for the help)

-------------

Commit messages:
 - HotSpot Style Guide changes

Changes: https://git.openjdk.org/jdk/pull/11404/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11404&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8252584
  Stats: 94 lines in 2 files changed: 92 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11404.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11404/head:pull/11404

PR: https://git.openjdk.org/jdk/pull/11404


From darcy at openjdk.org  Tue Nov 29 04:21:14 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 29 Nov 2022 04:21:14 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21
Message-ID: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>

Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.

-------------

Commit messages:
 - Fix failed HotSpot regression tests.
 - Merge branch 'master' into JDK-8296149
 - Update symbol information to JDK 20 build 24.
 - Merge branch 'master' into JDK-8296149
 - Merge branch 'master' into JDK-8296149
 - Update symbols for JDK 20 b23.
 - Merge branch 'master' into JDK-8296149
 - Merge branch 'master' into JDK-8296149
 - Update symbols for JDK 20 build 22.
 - Update expected GA date.
 - ... and 1 more: https://git.openjdk.org/jdk/compare/105d9d75...5810345e

Changes: https://git.openjdk.org/jdk/pull/10924/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10924&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296149
  Stats: 3653 lines in 69 files changed: 3608 ins; 1 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/10924.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10924/head:pull/10924

PR: https://git.openjdk.org/jdk/pull/10924


From darcy at openjdk.org  Tue Nov 29 04:21:14 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 29 Nov 2022 04:21:14 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21
In-Reply-To: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
Message-ID: <TGeJqrnxUet9tYSc3IHlT70IZWweJTiXs9JgVYlU2BA=.ce15b8cc-f341-42fe-b944-33d07ab90e80@github.com>

On Tue, 1 Nov 2022 05:49:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.

Flipping the draft-bit off for this PR ahead of the upcoming start of JDK 21.

Symbol information now up-to-date as of JDK 20 b25.

-------------

PR: https://git.openjdk.org/jdk/pull/10924


From dholmes at openjdk.org  Tue Nov 29 04:52:28 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 29 Nov 2022 04:52:28 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21
In-Reply-To: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
Message-ID: <0KXjUacMHUpCfdwzClgnvCzB9iOtpr6xk10wBaVuucs=.0395129f-9740-4e6c-bce5-338569ee2d09@github.com>

On Tue, 1 Nov 2022 05:49:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.

I looked at everything bar the sym files. All seems fine/usual.

One query below (probably one I ask each release).

Thanks.

src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java line 47:

> 45:  * @since 14
> 46:  */
> 47: @SupportedSourceVersion(RELEASE_21)

It is a pity these have to be updated each release. Is there no way to say `latest` here?

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10924


From darcy at openjdk.org  Tue Nov 29 05:15:25 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 29 Nov 2022 05:15:25 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21
In-Reply-To: <0KXjUacMHUpCfdwzClgnvCzB9iOtpr6xk10wBaVuucs=.0395129f-9740-4e6c-bce5-338569ee2d09@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
 <0KXjUacMHUpCfdwzClgnvCzB9iOtpr6xk10wBaVuucs=.0395129f-9740-4e6c-bce5-338569ee2d09@github.com>
Message-ID: <K_tK32mL4luBi0Wbhkx2c2nsRt4FvZi0FZvjAW6LlCc=.c5708fc8-1ef9-4f91-97c4-5f737d1266df@github.com>

On Tue, 29 Nov 2022 04:45:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.
>
> src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java line 47:
> 
>> 45:  * @since 14
>> 46:  */
>> 47: @SupportedSourceVersion(RELEASE_21)
> 
> It is a pity these have to be updated each release. Is there no way to say `latest` here?

Not with the current language specification, no.

The only enum value "constant-enough" to use in an annotation is the name of an enum constant, a public static final field assigned an enum value is not enough.

On the flip side, I make the updates to these annotations using a one-line sed script I have saved away in a comment on one of the previous start-of-release-updates-for-JDK-N bugs. Using the annotations in this way is in lieu of adding another type specification for the JDK version. In other words, having AbstractAnnotationValueVisitor**14**.java with an annotation indicating RELEASE_21 prevents having AbstractAnnotationValueVisitor15, AbstractAnnotationValueVisitor16, ... , AbstractAnnotationValueVisitor21.

New visitors are now only introduced when adding new kinds of structures requires differences in behavior.

Thanks for the review.

-------------

PR: https://git.openjdk.org/jdk/pull/10924


From iris at openjdk.org  Tue Nov 29 07:29:53 2022
From: iris at openjdk.org (Iris Clark)
Date: Tue, 29 Nov 2022 07:29:53 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21
In-Reply-To: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
Message-ID: <3XmL-mIaH-juXigTJOSqPUWTLRwlBBvpYhpjQRLKofk=.e05f97cb-2ed6-468f-8184-07a0935c9645@github.com>

On Tue, 1 Nov 2022 05:49:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10924


From kbarrett at openjdk.org  Tue Nov 29 09:07:24 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 29 Nov 2022 09:07:24 GMT
Subject: RFR: 8252584: HotSpot Style Guide should permit alignas
In-Reply-To: <CVHNRNKRV_f2n8F5s0AiQR7lgIrHBHzaUj5ewTDMU7I=.9920de89-7b18-4f22-9ca8-94479d4a292f@github.com>
References: <CVHNRNKRV_f2n8F5s0AiQR7lgIrHBHzaUj5ewTDMU7I=.9920de89-7b18-4f22-9ca8-94479d4a292f@github.com>
Message-ID: <okiLiw-ASZcv9Cr4VaZX72_QsJz4V3lITjkfkdjetiU=.c293ff3d-1069-423d-b1ee-1c9630b8129a@github.com>

On Tue, 29 Nov 2022 01:03:55 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Add alignas to the permitted features set with some restrictions. (Thanks @kimbarrett for the help)

I think this is okay (not surprisingly).  Please add me as a contributor.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11404


From jwaters at openjdk.org  Tue Nov 29 13:26:48 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 29 Nov 2022 13:26:48 GMT
Subject: RFR: 8295884: Implement IDE support for Eclipse [v23]
In-Reply-To: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
Message-ID: <-iY5_QGbQ-lFmpTBZH-77kfcFsJGmxsE4blXDGKUoyk=.f00668c3-dffb-4fbb-b306-7fa794e9f245@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 Java Virtual Machine's source code, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's unique 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 pull request now contains 29 commits:

 - Merge remote-tracking branch 'upstream/master' into eclipse
 - Changes
 - Merge remote-tracking branch 'upstream/master' into eclipse
 - Format
 - Merge remote-tracking branch 'upstream/master' into eclipse
 - Merge remote-tracking branch 'upstream/master' into eclipse
 - Oversight
 - Include miscellaneous directories in any Workspace
 - Merge remote-tracking branch 'upstream/master' into eclipse
 - More Changes
 - ... and 19 more: https://git.openjdk.org/jdk/compare/2deb318c...f09d21cb

-------------

Changes: https://git.openjdk.org/jdk/pull/10853/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=22
  Stats: 592 lines in 4 files changed: 592 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 erikj at openjdk.org  Tue Nov 29 13:45:40 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 29 Nov 2022 13:45:40 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21
In-Reply-To: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
Message-ID: <t5vqaVJlp2R8PZy9nWDCDosphMLcV1DWzNRVEUBRKPs=.d143f6c5-190f-452e-ad97-07d1767a73d6@github.com>

On Tue, 1 Nov 2022 05:49:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10924


From cstein at openjdk.org  Tue Nov 29 14:52:57 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 29 Nov 2022 14:52:57 GMT
Subject: RFR: 8296710: Update to use jtreg 7.1
Message-ID: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>

Please review the change to update to using jtreg `7.1`.

The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

This pull request was created by copying the following and using `7.1` at appropriate places:
- https://github.com/openjdk/jdk/pull/9393

-------------

Commit messages:
 - 8296710: Update to use jtreg 7.1

Changes: https://git.openjdk.org/jdk/pull/11416/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11416&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296710
  Stats: 9 lines in 8 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/11416.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11416/head:pull/11416

PR: https://git.openjdk.org/jdk/pull/11416


From alanb at openjdk.org  Tue Nov 29 16:09:24 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Nov 2022 16:09:24 GMT
Subject: RFR: 8296710: Update to use jtreg 7.1
In-Reply-To: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>
References: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>
Message-ID: <H9LOzHSfN7PLpiF6oYdnlHFQLasj6FeRgZKUKm3XyXs=.591ef716-45eb-4bf5-a6d5-d9ebe887d82a@github.com>

On Tue, 29 Nov 2022 14:44:12 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `7.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using `7.1` at appropriate places:
> - https://github.com/openjdk/jdk/pull/9393

Can you confirm that you've run all the tests with the change? Sometimes these updates need changes to a small number of tests.

-------------

PR: https://git.openjdk.org/jdk/pull/11416


From jwaters at openjdk.org  Tue Nov 29 17:09:28 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 29 Nov 2022 17:09:28 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <3mBOtLQz_ulylm0XJkhUBwzPEV7AoPmMo20facw9Xn4=.c431ac9c-4f1f-4db6-bb46-745987f06777@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
 <0fVP40VVRuOoZCEJ1M3BLubshBHbD4m_lj-j1qaGTTk=.391ade50-b3fe-4d4e-ae71-ba8a975a31cd@github.com>
 <mowWW-lO9a5Zo4iT-sbh1YTZFXO4UjKuJK7OpfrhFFo=.c7e5430a-de42-4465-ba85-10dfb8c71184@github.com>
 <UwMOA0K5cYSIeTkRgIl6QlPe2iTTA5z0vCH3jzUmx4E=.2b35fc6c-e96a-4807-863f-583631128a4e@github.com>
 <klNxsMmpOjXNtFhaX2Kqt-YqYSBCyCAoJkqnmFr_IeY=.b55c0f1a-4331-4d65-af05-a20b59f73f57@github.com>
 <3mBOtLQz_ulylm0XJkhUBwzPEV7AoPmMo20facw9Xn4=.c431ac9c-4f1f-4db6-bb46-745987f06777@github.com>
Message-ID: <WgvP0-stpzWV4Z7nlCb2_bBFnP4W-siUmkatZ4I-2l0=.43cbd4c2-3475-4034-93ee-26a370be0016@github.com>

On Wed, 23 Nov 2022 21:36:24 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I think the problem here is the friend declaration, which doesn't look like it's needed and could be deleted.
>
> Digging into this some more, the friend declaration exists to provide access to the private `os::win32::enum Ept`.
> 
> One obvious and cheap solution to that would be to make that enum public.  I think that would be an improvement vs the current friend declaration.  But there are some other things one could complain about there, such as the type of the function requiring a complicated function pointer cast where it's used.  Here's a patch that I think cleans this up.
> 
> 
> diff --git a/src/hotspot/os/windows/os_windows.cpp b/src/hotspot/os/windows/os_windows.cpp
> index 0651f0868f3..bf9e759b1d6 100644
> --- a/src/hotspot/os/windows/os_windows.cpp
> +++ b/src/hotspot/os/windows/os_windows.cpp
> @@ -511,7 +511,9 @@ JNIEXPORT
>  LONG WINAPI topLevelExceptionFilter(struct _EXCEPTION_POINTERS* exceptionInfo);
>  
>  // Thread start routine for all newly created threads
> -static unsigned __stdcall thread_native_entry(Thread* thread) {
> +// Called with the associated Thread* as the argument.
> +unsigned __stdcall os::win32::thread_native_entry(void* t) {
> +  Thread* thread = static_cast<Thread*>(t);
>  
>    thread->record_stack_base_and_size();
>    thread->initialize_thread_current();
> @@ -744,7 +746,7 @@ bool os::create_thread(Thread* thread, ThreadType thr_type,
>      thread_handle =
>        (HANDLE)_beginthreadex(NULL,
>                               (unsigned)stack_size,
> -                             (unsigned (__stdcall *)(void*)) thread_native_entry,
> +                             &os::win32::thread_native_entry,
>                               thread,
>                               initflag,
>                               &thread_id);
> diff --git a/src/hotspot/os/windows/os_windows.hpp b/src/hotspot/os/windows/os_windows.hpp
> index 94d7c3c5e2d..197797078d7 100644
> --- a/src/hotspot/os/windows/os_windows.hpp
> +++ b/src/hotspot/os/windows/os_windows.hpp
> @@ -36,7 +36,6 @@ typedef void (*signal_handler_t)(int);
>  
>  class os::win32 {
>    friend class os;
> -  friend unsigned __stdcall thread_native_entry(Thread*);
>  
>   protected:
>    static int    _processor_type;
> @@ -70,6 +69,10 @@ class os::win32 {
>    static HINSTANCE load_Windows_dll(const char* name, char *ebuf, int ebuflen);
>  
>   private:
> +  // The handler passed to _beginthreadex().
> +  // Called with the associated Thread* as the argument.
> +  static unsigned __stdcall thread_native_entry(void*);
> +
>    enum Ept { EPT_THREAD, EPT_PROCESS, EPT_PROCESS_DIE };
>    // Wrapper around _endthreadex(), exit() and _exit()
>    static int exit_process_or_thread(Ept what, int exit_code);

The issue with that would be that thread_native_entry is declared as static to the compilation unit on other other Operating Systems as well, and having it as a static member on the win32 class instead would end up breaking this convention, for which I'm not sure if there's a reason why all of them are declared like this

-------------

PR: https://git.openjdk.org/jdk/pull/11081


From vromero at openjdk.org  Tue Nov 29 17:33:19 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 29 Nov 2022 17:33:19 GMT
Subject: RFR: JDK-8296149: Start of release updates for JDK 21
In-Reply-To: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com>
Message-ID: <mwcnBufA38Ydk1N9ghfGFvveyqmVXTmVmymYeUc4CAM=.10c9a603-813c-4404-b8ee-9afff26dce81@github.com>

On Tue, 1 Nov 2022 05:49:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21.

looks good

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10924


From erikj at openjdk.org  Tue Nov 29 17:57:22 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 29 Nov 2022 17:57:22 GMT
Subject: RFR: 8296710: Update to use jtreg 7.1
In-Reply-To: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>
References: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>
Message-ID: <3MbFV3Yz1mkexhdEMXTtpXXGdr-yJvvM7Z9FyyVu9Do=.2c003086-a5b8-45f7-86d0-4574425677c7@github.com>

On Tue, 29 Nov 2022 14:44:12 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `7.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using `7.1` at appropriate places:
> - https://github.com/openjdk/jdk/pull/9393

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11416


From ihse at openjdk.org  Tue Nov 29 19:26:36 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Nov 2022 19:26:36 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: <D-_pSm7C9d1Wdx-g6Tz0PTX_7CgFMitkkGCV907jv_8=.77ff6af8-466b-42ab-a015-73589600dab1@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

Yes bot, I know. I'll need to split this up into multiple steps, but please keep this open for a while more. Thank you.

-------------

PR: https://git.openjdk.org/jdk/pull/10792


From dholmes at openjdk.org  Wed Nov 30 06:07:30 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Nov 2022 06:07:30 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <WgvP0-stpzWV4Z7nlCb2_bBFnP4W-siUmkatZ4I-2l0=.43cbd4c2-3475-4034-93ee-26a370be0016@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <d4LIWjQh3RKW81WqqVCiXlQLRJDENyfAJYkQCwWwBZU=.b019f494-0d0c-4da2-8f07-09b6c589984e@github.com>
 <0fVP40VVRuOoZCEJ1M3BLubshBHbD4m_lj-j1qaGTTk=.391ade50-b3fe-4d4e-ae71-ba8a975a31cd@github.com>
 <mowWW-lO9a5Zo4iT-sbh1YTZFXO4UjKuJK7OpfrhFFo=.c7e5430a-de42-4465-ba85-10dfb8c71184@github.com>
 <UwMOA0K5cYSIeTkRgIl6QlPe2iTTA5z0vCH3jzUmx4E=.2b35fc6c-e96a-4807-863f-583631128a4e@github.com>
 <klNxsMmpOjXNtFhaX2Kqt-YqYSBCyCAoJkqnmFr_IeY=.b55c0f1a-4331-4d65-af05-a20b59f73f57@github.com>
 <3mBOtLQz_ulylm0XJkhUBwzPEV7AoPmMo20facw9Xn4=.c431ac9c-4f1f-4db6-bb46-745987f06777@github.com>
 <WgvP0-stpzWV4Z7nlCb2_bBFnP4W-siUmkatZ4I-2l0=.43cbd4c2-3475-4034-93ee-26a370be0016@github.com>
Message-ID: <5dO9bO57dyw99J9wxZceMOy1FujzO-JFXWxODl3LlCc=.e37a178a-21c9-4aec-97f0-ec01eb3903b0@github.com>

On Tue, 29 Nov 2022 17:07:02 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Digging into this some more, the friend declaration exists to provide access to the private `os::win32::enum Ept`.
>> 
>> One obvious and cheap solution to that would be to make that enum public.  I think that would be an improvement vs the current friend declaration.  But there are some other things one could complain about there, such as the type of the function requiring a complicated function pointer cast where it's used.  Here's a patch that I think cleans this up.
>> 
>> 
>> diff --git a/src/hotspot/os/windows/os_windows.cpp b/src/hotspot/os/windows/os_windows.cpp
>> index 0651f0868f3..bf9e759b1d6 100644
>> --- a/src/hotspot/os/windows/os_windows.cpp
>> +++ b/src/hotspot/os/windows/os_windows.cpp
>> @@ -511,7 +511,9 @@ JNIEXPORT
>>  LONG WINAPI topLevelExceptionFilter(struct _EXCEPTION_POINTERS* exceptionInfo);
>>  
>>  // Thread start routine for all newly created threads
>> -static unsigned __stdcall thread_native_entry(Thread* thread) {
>> +// Called with the associated Thread* as the argument.
>> +unsigned __stdcall os::win32::thread_native_entry(void* t) {
>> +  Thread* thread = static_cast<Thread*>(t);
>>  
>>    thread->record_stack_base_and_size();
>>    thread->initialize_thread_current();
>> @@ -744,7 +746,7 @@ bool os::create_thread(Thread* thread, ThreadType thr_type,
>>      thread_handle =
>>        (HANDLE)_beginthreadex(NULL,
>>                               (unsigned)stack_size,
>> -                             (unsigned (__stdcall *)(void*)) thread_native_entry,
>> +                             &os::win32::thread_native_entry,
>>                               thread,
>>                               initflag,
>>                               &thread_id);
>> diff --git a/src/hotspot/os/windows/os_windows.hpp b/src/hotspot/os/windows/os_windows.hpp
>> index 94d7c3c5e2d..197797078d7 100644
>> --- a/src/hotspot/os/windows/os_windows.hpp
>> +++ b/src/hotspot/os/windows/os_windows.hpp
>> @@ -36,7 +36,6 @@ typedef void (*signal_handler_t)(int);
>>  
>>  class os::win32 {
>>    friend class os;
>> -  friend unsigned __stdcall thread_native_entry(Thread*);
>>  
>>   protected:
>>    static int    _processor_type;
>> @@ -70,6 +69,10 @@ class os::win32 {
>>    static HINSTANCE load_Windows_dll(const char* name, char *ebuf, int ebuflen);
>>  
>>   private:
>> +  // The handler passed to _beginthreadex().
>> +  // Called with the associated Thread* as the argument.
>> +  static unsigned __stdcall thread_native_entry(void*);
>> +
>>    enum Ept { EPT_THREAD, EPT_PROCESS, EPT_PROCESS_DIE };
>>    // Wrapper around _endthreadex(), exit() and _exit()
>>    static int exit_process_or_thread(Ept what, int exit_code);
>
> The issue with that would be that thread_native_entry is declared as static to the compilation unit on other other Operating Systems as well, and having it as a static member on the win32 class instead would end up breaking this convention, for which I'm not sure if there's a reason why all of them are declared like this

The thread entry functions are expected to be plain C functions as we use C library calls to create threads (`_beginthreadex`, `pthread_create`) not C++. They don't need to be visible outside the compilation unit hence static.

-------------

PR: https://git.openjdk.org/jdk/pull/11081


From jwaters at openjdk.org  Wed Nov 30 07:26:46 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 30 Nov 2022 07:26:46 GMT
Subject: RFR: 8252584: HotSpot Style Guide should permit alignas [v2]
In-Reply-To: <CVHNRNKRV_f2n8F5s0AiQR7lgIrHBHzaUj5ewTDMU7I=.9920de89-7b18-4f22-9ca8-94479d4a292f@github.com>
References: <CVHNRNKRV_f2n8F5s0AiQR7lgIrHBHzaUj5ewTDMU7I=.9920de89-7b18-4f22-9ca8-94479d4a292f@github.com>
Message-ID: <q-_icded_J6Bu_FntBn_NzYa-o9ZplD4Mr5FmvsZYe4=.eedc699c-a423-4bf6-b97f-ea3367d6ec9d@github.com>

> Add alignas to the permitted features set with some restrictions. (Thanks @kimbarrett for the help)

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 two additional commits since the last revision:

 - Merge branch 'openjdk:master' into alignas
 - HotSpot Style Guide changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11404/files
  - new: https://git.openjdk.org/jdk/pull/11404/files/cec044b4..43683f1b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11404&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11404&range=00-01

  Stats: 5941 lines in 250 files changed: 3584 ins; 1175 del; 1182 mod
  Patch: https://git.openjdk.org/jdk/pull/11404.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11404/head:pull/11404

PR: https://git.openjdk.org/jdk/pull/11404


From jwaters at openjdk.org  Wed Nov 30 07:40:22 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 30 Nov 2022 07:40:22 GMT
Subject: Integrated: 8252584: HotSpot Style Guide should permit alignas
In-Reply-To: <CVHNRNKRV_f2n8F5s0AiQR7lgIrHBHzaUj5ewTDMU7I=.9920de89-7b18-4f22-9ca8-94479d4a292f@github.com>
References: <CVHNRNKRV_f2n8F5s0AiQR7lgIrHBHzaUj5ewTDMU7I=.9920de89-7b18-4f22-9ca8-94479d4a292f@github.com>
Message-ID: <Qd2UP38WqQbr2IsFhKGzd9d-CCG3Doth3GeRqrVdgtA=.8d17dfae-52c3-468e-b688-e6e91fdc0138@github.com>

On Tue, 29 Nov 2022 01:03:55 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Add alignas to the permitted features set with some restrictions. (Thanks @kimbarrett for the help)

This pull request has now been integrated.

Changeset: 22f5d014
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/22f5d014287a5cae2c0503ab3f9730f64725605a
Stats:     94 lines in 2 files changed: 92 ins; 0 del; 2 mod

8252584: HotSpot Style Guide should permit alignas

Co-authored-by: Kim Barrett <kbarrett at openjdk.org>
Reviewed-by: kbarrett

-------------

PR: https://git.openjdk.org/jdk/pull/11404


From jwaters at openjdk.org  Wed Nov 30 07:55:24 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 30 Nov 2022 07:55:24 GMT
Subject: RFR: 8295146: Clean up native code with newer C/C++ language
 features [v3]
In-Reply-To: <4NLoUD7YZRPKuVc08q_QnsbuPpb0wZIdmAuMN2tqM_c=.a34c13d0-0a6b-495e-b48e-e88debf6b4da@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
 <gay-N6xDnfKHcngB9ddJIZD6Jfg2m_ZCzZn1gWPFN-o=.785036e8-1d1d-41d3-bac3-211b9d03cd71@github.com>
 <XXVqN4ByCrB34JRZSgiNYWsdrwEOTKjo5u81sTFG5bE=.7748c17a-4a13-42aa-b10d-219fe6775da2@github.com>
 <nVCoCE9doWoQ54qhPSbn1xM79YLzhggfELps4CpI53o=.3af1e9bf-5389-439e-bd78-1b4fce336c2f@github.com>
 <4NLoUD7YZRPKuVc08q_QnsbuPpb0wZIdmAuMN2tqM_c=.a34c13d0-0a6b-495e-b48e-e88debf6b4da@github.com>
Message-ID: <X08uwA9tf91BTq70u3o3koABY-5ibEiJjUGuXECqoJ8=.496742e5-9430-4ff1-9944-9922e4070035@github.com>

On Wed, 23 Nov 2022 04:58:38 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Out of curiosity, is there a way to get the discussion on approving the use of alignas back up? I've read through 8250269 briefly and unlike the issues that come with C++ attributes, alignas looks relatively straightforward to switch to, without much effect on existing code. Seems like a bit of a waste to leave the JBS entry sitting on the shelf to me
>> 
>>> The various MSVC-conditional direct uses of __declspec(align(N)) should probably currently be using ATTRIBUTE_ALIGNED.
>> 
>> The instances of `__declspec(align())` changed here are in the native libraries written in C, not within HotSpot itself. From what I can see at least HotSpot never uses compiler alignment attributes directly and always strictly sticks to `ATTRIBUTE_ALIGNED` (which is probably a good thing)
>
>> Out of curiosity, is there a way to get the discussion on approving the use of alignas back up? [...]
> 
> A PR to address JDK-8252584 would be welcomed by me. Just do the process for
> Style Guide changes (see the Style Guide or previous PRs for such). I don't
> expect it would be very controversial. I think the only reason it hasn't
> already happened is because nobody has gotten around to it, or felt the need
> for it.
> 
> JDK-8250269 touches a bit more code (mostly in stubGenerator_x86_64 and
> macroAssembler_x86_32), but also seems like it should be straightforward.
> 
>> > The various MSVC-conditional direct uses of __declspec(align(N)) should probably currently be using ATTRIBUTE_ALIGNED.
>> 
>> The instances of `__declspec(align())` changed here are in the native libraries written in C, not within HotSpot itself. From what I can see at least HotSpot never uses compiler alignment attributes directly and always strictly sticks to `ATTRIBUTE_ALIGNED` (which is probably a good thing)
> 
> You are right that the Windows-conditionalized uses are in non-HotSpot code.
> I missed that context when skimming through the changes.  Since Visual Studio
> is always C++ (even though the shared files are written as C), using alignas
> with appropriate conditionalization in those files should be fine.

Resolved, will address re-implementing ATTRIBUTE_ALIGNED with alignas in another Pull Request

-------------

PR: https://git.openjdk.org/jdk/pull/11081


From alanb at openjdk.org  Wed Nov 30 09:51:26 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Nov 2022 09:51:26 GMT
Subject: RFR: 8296710: Update to use jtreg 7.1
In-Reply-To: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>
References: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>
Message-ID: <-n11nKKODtr-Mua5vvwmAVEvevjYu2pv3iSzs7tIzzU=.2c8711c8-daab-42b4-a186-4c3f71b4bc73@github.com>

On Tue, 29 Nov 2022 14:44:12 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `7.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using `7.1` at appropriate places:
> - https://github.com/openjdk/jdk/pull/9393

Christian has confirmed on the testing so I think this is good.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11416


From aph at openjdk.org  Wed Nov 30 10:20:27 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 30 Nov 2022 10:20: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: <5fa9i8vgmsZ-zBtja1VM7fEFBWbrP2dnDmEiolivRq0=.b9a33e09-1ec0-44a5-af3f-7cd12295ba72@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 ain't dead yet.

-------------

PR: https://git.openjdk.org/jdk/pull/10661


From ihse at openjdk.org  Wed Nov 30 14:11:27 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 30 Nov 2022 14:11:27 GMT
Subject: RFR: 8297851: Add devkit for RISC-V
Message-ID: <BIiFEEc2nUw1zgnwU8MNcrncWnbw1Iqnu0EgV1EQnxM=.4332a395-5ea6-488b-8529-cf9082df98a1@github.com>

We should add devkit support for linux/riscv64.

-------------

Commit messages:
 - 8297851: Add devkit for RISC-V

Changes: https://git.openjdk.org/jdk/pull/11432/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11432&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297851
  Stats: 83 lines in 3 files changed: 60 ins; 7 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/11432.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11432/head:pull/11432

PR: https://git.openjdk.org/jdk/pull/11432


From kbarrett at openjdk.org  Wed Nov 30 14:36:32 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 30 Nov 2022 14:36:32 GMT
Subject: RFR: 8252584: HotSpot Style Guide should permit alignas [v2]
In-Reply-To: <q-_icded_J6Bu_FntBn_NzYa-o9ZplD4Mr5FmvsZYe4=.eedc699c-a423-4bf6-b97f-ea3367d6ec9d@github.com>
References: <CVHNRNKRV_f2n8F5s0AiQR7lgIrHBHzaUj5ewTDMU7I=.9920de89-7b18-4f22-9ca8-94479d4a292f@github.com>
 <q-_icded_J6Bu_FntBn_NzYa-o9ZplD4Mr5FmvsZYe4=.eedc699c-a423-4bf6-b97f-ea3367d6ec9d@github.com>
Message-ID: <K_Zeb6O6NaqecfB9FGU-LE-FFhqM8JOCO3UHK_uyjZM=.5cedb73b-3077-47d9-aab0-892c6b4d3740@github.com>

On Wed, 30 Nov 2022 07:26:46 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Add alignas to the permitted features set with some restrictions. (Thanks @kimbarrett for the help)
>
> 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 two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into alignas
>  - HotSpot Style Guide changes

This change should not have been integrated yet.  Changes to the Style Guide have an approval process that is described in that document, including a 2 week voting period and final approval by the HotSpot lead.

-------------

PR: https://git.openjdk.org/jdk/pull/11404


From jwaters at openjdk.org  Wed Nov 30 14:57:35 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 30 Nov 2022 14:57:35 GMT
Subject: RFR: 8252584: HotSpot Style Guide should permit alignas [v2]
In-Reply-To: <q-_icded_J6Bu_FntBn_NzYa-o9ZplD4Mr5FmvsZYe4=.eedc699c-a423-4bf6-b97f-ea3367d6ec9d@github.com>
References: <CVHNRNKRV_f2n8F5s0AiQR7lgIrHBHzaUj5ewTDMU7I=.9920de89-7b18-4f22-9ca8-94479d4a292f@github.com>
 <q-_icded_J6Bu_FntBn_NzYa-o9ZplD4Mr5FmvsZYe4=.eedc699c-a423-4bf6-b97f-ea3367d6ec9d@github.com>
Message-ID: <03SfvVDuCNMAnuuZg0BVsDhDkbLufbkEC69WQPNJ3SQ=.432ccf2b-ce8f-40bc-a3a5-1f28809839a1@github.com>

On Wed, 30 Nov 2022 07:26:46 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Add alignas to the permitted features set with some restrictions. (Thanks @kimbarrett for the help)
>
> 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 two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into alignas
>  - HotSpot Style Guide changes

Oops, I did not realize that

Temporarily back this out for now? I can (hopefully) do that rather quickly

-------------

PR: https://git.openjdk.org/jdk/pull/11404


From jwaters at openjdk.org  Wed Nov 30 15:04:27 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 30 Nov 2022 15:04:27 GMT
Subject: RFR: 8252584: HotSpot Style Guide should permit alignas [v2]
In-Reply-To: <q-_icded_J6Bu_FntBn_NzYa-o9ZplD4Mr5FmvsZYe4=.eedc699c-a423-4bf6-b97f-ea3367d6ec9d@github.com>
References: <CVHNRNKRV_f2n8F5s0AiQR7lgIrHBHzaUj5ewTDMU7I=.9920de89-7b18-4f22-9ca8-94479d4a292f@github.com>
 <q-_icded_J6Bu_FntBn_NzYa-o9ZplD4Mr5FmvsZYe4=.eedc699c-a423-4bf6-b97f-ea3367d6ec9d@github.com>
Message-ID: <gQi726n-SmTuCluAy6HDFDnK_kRKU7cD8JDQIpA3uNg=.0fbc6037-8424-4b9a-a7bc-b1f60a81393e@github.com>

On Wed, 30 Nov 2022 07:26:46 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Add alignas to the permitted features set with some restrictions. (Thanks @kimbarrett for the help)
>
> 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 two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into alignas
>  - HotSpot Style Guide changes

I've created an "emergency" revert at https://github.com/openjdk/jdk/pull/11433, sorry for the mistake

-------------

PR: https://git.openjdk.org/jdk/pull/11404


From jwaters at openjdk.org  Wed Nov 30 15:11:21 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 30 Nov 2022 15:11:21 GMT
Subject: RFR: 8297852: Backout 8252584 for the time being
Message-ID: <9rSgaMOb56fcYoRPJX6rgi1jcvzxQXsMqAod76PmF4s=.97ad88c3-1250-4aea-a1f9-1c78987a3ad6@github.com>

Revert 8252584 temporarily (My mistake)

-------------

Commit messages:
 - Emergency Revert of 8252584

Changes: https://git.openjdk.org/jdk/pull/11433/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11433&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297852
  Stats: 94 lines in 2 files changed: 0 ins; 92 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11433.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11433/head:pull/11433

PR: https://git.openjdk.org/jdk/pull/11433