From jjg at openjdk.org  Thu Feb  1 00:22:10 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Feb 2024 00:22:10 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <9udnoUCtCVEEO3rIQypPb3f14bMp6wVRRO4x0yNKZpw=.b1245fbf-e2eb-44c1-9b44-76ccbefe200f@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <zrqu3x52AXuB6DBs1kg66rC0arBB3MUFFokkL8CIF_k=.7935ef71-4d3c-4246-bf5c-afe5fd5fb625@github.com>
 <UbOd3C2ZrB35hFrkossEp7LIUWFk9dpBZh6v8IS0HeA=.84a2e253-8eb2-40fc-8256-c38a8a4e4399@github.com>
 <t12_cx8L88XOIB668UOHrnt7TPsyJiVC48ic7BribrI=.4b9996e0-a930-48cb-a8f4-6f2f7e0d717a@github.com>
 <9udnoUCtCVEEO3rIQypPb3f14bMp6wVRRO4x0yNKZpw=.b1245fbf-e2eb-44c1-9b44-76ccbefe200f@github.com>
Message-ID: <xdbBz5jNKMyTzPYYjGZ993AJ53U6DQm-LZHahZLLKfc=.0de14de4-08fe-435b-a173-6d7c5518d21b@github.com>

On Wed, 31 Jan 2024 23:09:57 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Yes, you need to escape `[` and `]` within the label of any Markdown reference link, by preceding each with backslash.   (Remember, the label is the string used to find the URL for the link; not the displayed text of the link).
>> That's a CommonMark feature independent of this work.
>> 
>> While we could change that `replace` call into two separate ones, in reference signatures they always appear together as a pair, and can be replaced together.   We need to remove the escape characters in the generated URL so that the signature is a standard signature with unescaped `[]`
>> 
>> For fun/demo, try the following:
>> 
>> 
>> /// First sentence.
>> /// * Link 0 to [java.lang.Object]
>> /// * Link 1a to [Arrays-equals][java.util.Arrays#equals(Object[],Object[])]
>> /// * Link 1b to [Arrays-equals][java.util.Arrays#equals(Object[],Object[])]
>> /// * Link 2a to [java.util.Arrays#equals(Object[],Object[])]
>> /// * Link 2b to [java.util.Arrays#equals(Object[],Object[])]
>> public class C { }
>> 
>> 
>> Link 1a and 2a end up as unprocessed "literal" text (because the `[]` were not escaped.)  That is, they are not even recognized by the CommonMark parser as reference links.  Link 1b and 2b get processed as links, as expected.
>> 
>> FWIW, this issue with needing to escape `[]` pairs is specifically mentioned in the JEP as an inescapable (sic) limitation.
>
> I'll add a test case.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1473644884

From jjg at openjdk.org  Thu Feb  1 00:38:11 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Feb 2024 00:38:11 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <mYUhOCbMeG5EtIygSHpOAYyVun1Q8YcA3GucL1z1qcE=.33866d2d-c942-49c8-bc48-91df3021981d@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
 <vUJ0cyyLa08AppwEQ4Dzu_JQlkJWo9oJUhUHUbSnK_M=.e2172756-ad2e-411c-8961-d55b756551a9@github.com>
 <mYUhOCbMeG5EtIygSHpOAYyVun1Q8YcA3GucL1z1qcE=.33866d2d-c942-49c8-bc48-91df3021981d@github.com>
Message-ID: <vB0WjtcVwLcWakp_A0EpAX8XUtWVnPAyqUWN4q3mM7k=.4be9cb20-e6b7-4e13-8e1d-1da8277ca531@github.com>

On Tue, 30 Jan 2024 00:39:43 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 259:
>> 
>>> 257:         LineKind lineKind = textKind == DocTree.Kind.MARKDOWN ? peekLineKind() : null;
>>> 258: 
>>> 259:         if (DEBUG) System.err.println("starting content " + showPos(bp) + " " + newline);
>> 
>> Debug output is useful. I wonder if we should consider https://openjdk.org/jeps/264.
>
> My oops for leaving the code in, or at least not cleaning it up more.

yeah, the debug code was pretty obsolete; I removed all except the generally useful method to show the text surrounding a position in the input buffer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1473654007

From jjg at openjdk.org  Thu Feb  1 01:06:15 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Feb 2024 01:06:15 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <vVADmiqaRr_Vr4KBZLGZ84p7XFHjOnSu3YXHxT3R8ds=.9e9ac84c-d6e8-4f61-9a1f-90f33dbd4c07@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <vVADmiqaRr_Vr4KBZLGZ84p7XFHjOnSu3YXHxT3R8ds=.9e9ac84c-d6e8-4f61-9a1f-90f33dbd4c07@github.com>
Message-ID: <_gXMWS65YgIw407hA80Xje-d4ws86vbtNqJuv2AUuH0=.9a143695-1fb0-4862-b07e-9ae720fe4029@github.com>

On Fri, 26 Jan 2024 16:33:08 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons 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 with upstream/master
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 668:
> 
>> 666:          * U+FFFC characters that were found in the original document.
>> 667:          */
>> 668:         Iterator<?> replaceIter;
> 
> Suggestion:
> 
>         final Iterator<?> replaceIter;

actually, `private final` ... done

> src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 732:
> 
>> 730:                 offsets.add(m.end());
>> 731:             }
>> 732:             sourceLineOffsets = offsets.stream().mapToInt(Integer::intValue).toArray();
> 
> Here's an alternative, which you might find better (or not):
> Suggestion:
> 
>             sourceLineOffsets = Stream.concat(Stream.of(0), lineBreak.matcher(source).results()
>                             .map(MatchResult::end)).mapToInt(Integer::intValue).toArray();

done

it's borderline (to me) that it's worthwhile but given that my original code used streams to create the final array, it sort-of makes sense to go "all in".

> src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 831:
> 
>> 829:         /**
>> 830:          * {@return the position in the original comment for a position in {@code source},
>> 831:          * using {@link #replaceAdjustPos}}.
> 
> Suggestion:
> 
>          * using {@link #replaceAdjustPos}}

done

> src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 939:
> 
>> 937: 
>> 938:         /**
>> 939:          * Flush any text in the {@code text} buffer, by creating a new
> 
> Suggestion:
> 
>          * Flushes any text in the {@code text} buffer, by creating a new

done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1473668136
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1473670108
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1473668952
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1473668548

From jjg at openjdk.org  Thu Feb  1 01:12:52 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Feb 2024 01:12:52 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v15]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <PzTVKwDfSLmEqm4kFvgUO_yBBCj5aWSzsm4acfFE8Bc=.fa82e41e-6c65-4fde-b99d-48f9ac5561fd@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with four additional commits since the last revision:

 - MarkdownTransformer: tweak doc comments
 - MarkdownTransformer: change `Lower.replaceIter` to be `private final`
 - MarkdownTransformer: use suggested text for using streams
 - remove obsolete debug code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/586daddf..54d40b20

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

  Stats: 26 lines in 2 files changed: 2 ins; 13 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/16388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388

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

From clanger at openjdk.org  Thu Feb  1 07:54:01 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 1 Feb 2024 07:54:01 GMT
Subject: RFR: 8324937: GHA: Avoid multiple test suites per job
In-Reply-To: <ALKollhIpZNxHE1PLsmqqqqItOsbw6ZYGpNOp32y3wo=.0bd4a4d5-a4f6-42a4-b8b2-98f234783e33@github.com>
References: <ALKollhIpZNxHE1PLsmqqqqItOsbw6ZYGpNOp32y3wo=.0bd4a4d5-a4f6-42a4-b8b2-98f234783e33@github.com>
Message-ID: <gVlUSc3bCIdu0exhIU4bQVkJkHQfj9ABsxvB1eZSsDE=.c6fe65a0-f599-4976-9e5b-29d8357728ba@github.com>

On Tue, 30 Jan 2024 10:34:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the description in the bug. This mitigates the issue by splitting out the only test job that has two test suites in it.

Marked as reviewed by clanger (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17627#pullrequestreview-1855755356

From shade at openjdk.org  Thu Feb  1 08:14:09 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 1 Feb 2024 08:14:09 GMT
Subject: Integrated: 8324937: GHA: Avoid multiple test suites per job
In-Reply-To: <ALKollhIpZNxHE1PLsmqqqqItOsbw6ZYGpNOp32y3wo=.0bd4a4d5-a4f6-42a4-b8b2-98f234783e33@github.com>
References: <ALKollhIpZNxHE1PLsmqqqqItOsbw6ZYGpNOp32y3wo=.0bd4a4d5-a4f6-42a4-b8b2-98f234783e33@github.com>
Message-ID: <vw0QvRf0TphevVj1m9lxLK5sX0bdefE6SWx4icgbnIA=.108f4235-ed03-4921-af21-09cd16f83160@github.com>

On Tue, 30 Jan 2024 10:34:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the description in the bug. This mitigates the issue by splitting out the only test job that has two test suites in it.

This pull request has now been integrated.

Changeset: 1aba78f2
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1aba78f2720b581f18fc2cec5e84deba6b2bcd41
Stats:     6 lines in 1 file changed: 5 ins; 0 del; 1 mod

8324937: GHA: Avoid multiple test suites per job

Reviewed-by: erikj, clanger

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

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

From ihse at openjdk.org  Thu Feb  1 09:08:38 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 1 Feb 2024 09:08:38 GMT
Subject: RFR: 8324834: Use _LARGE_FILES on AIX [v3]
In-Reply-To: <HUF4KgYt93teqGiOkL6rf-71hhtC0dWY73U0_-S0GNc=.c5e339b8-a943-4340-b7e1-d574663fd8aa@github.com>
References: <HUF4KgYt93teqGiOkL6rf-71hhtC0dWY73U0_-S0GNc=.c5e339b8-a943-4340-b7e1-d574663fd8aa@github.com>
Message-ID: <wDZRyovUxtEZyCcbObN8AdR2Y5AVmxnHMiUXV-qpqvY=.af0639eb-3aae-4926-8873-346ad7dd4d57@github.com>

> In the same spirit as [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should adapt the AIX-specific code in hotspot so it uses the well-defined posix `<foo>` functions, instead of `<foo>64`. By setting the define _LARGE_FILES, this will make `<foo>` behave as `<foo>64`, just as _FILE_OFFSET_BITS=64 does on gcc. (Reference: https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-that-access-large-files)
> 
> In theory, it should not even be necessary to set this, since we only compile for 64-bit AIX platforms, and this is only relevant on 32-bit platforms. But let's add the define anyway, for good measure. It shows at least that we have thought about the matter. :-)
> 
> I have not been able to test this on AIX. I hope someone with AIX access can take this for a spin.
> 
> The reason I'm doing this is for [JDK-8324539](https://bugs.openjdk.org/browse/JDK-8324539). After both these bugs are fixed, there will be no more `<foo>64` function calls in the code base.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Add compile time check for _LARGE_FILES

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17611/files
  - new: https://git.openjdk.org/jdk/pull/17611/files/5119bdc9..3cb64b99

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

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

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

From mbaesken at openjdk.org  Thu Feb  1 09:08:38 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 1 Feb 2024 09:08:38 GMT
Subject: RFR: 8324834: Use _LARGE_FILES on AIX [v2]
In-Reply-To: <tDPybQDw_xfXB_-YCu75B_DthRAskmO707trHRW5QU8=.22e24ed9-7f5a-407e-ae0b-e9b0a10520a4@github.com>
References: <HUF4KgYt93teqGiOkL6rf-71hhtC0dWY73U0_-S0GNc=.c5e339b8-a943-4340-b7e1-d574663fd8aa@github.com>
 <tDPybQDw_xfXB_-YCu75B_DthRAskmO707trHRW5QU8=.22e24ed9-7f5a-407e-ae0b-e9b0a10520a4@github.com>
Message-ID: <VtalJ6M5hPnLYeO-1ggMvviGlcZ4sNsSY9DDlvY9gaE=.ecdba5e9-4c14-43fe-bac6-3afdb4fecf57@github.com>

On Tue, 30 Jan 2024 12:25:47 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> In the same spirit as [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should adapt the AIX-specific code in hotspot so it uses the well-defined posix `<foo>` functions, instead of `<foo>64`. By setting the define _LARGE_FILES, this will make `<foo>` behave as `<foo>64`, just as _FILE_OFFSET_BITS=64 does on gcc. (Reference: https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-that-access-large-files)
>> 
>> In theory, it should not even be necessary to set this, since we only compile for 64-bit AIX platforms, and this is only relevant on 32-bit platforms. But let's add the define anyway, for good measure. It shows at least that we have thought about the matter. :-)
>> 
>> I have not been able to test this on AIX. I hope someone with AIX access can take this for a spin.
>> 
>> The reason I'm doing this is for [JDK-8324539](https://bugs.openjdk.org/browse/JDK-8324539). After both these bugs are fixed, there will be no more `<foo>64` function calls in the code base.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "8324753: [AIX] adjust os_posix after JDK-8318696"
>   
>   This reverts commit 8950d68ddb36d35831fbb4b98969cd0537527070.

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17611#pullrequestreview-1855922518

From ihse at openjdk.org  Thu Feb  1 09:08:38 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 1 Feb 2024 09:08:38 GMT
Subject: RFR: 8324834: Use _LARGE_FILES on AIX [v2]
In-Reply-To: <tDPybQDw_xfXB_-YCu75B_DthRAskmO707trHRW5QU8=.22e24ed9-7f5a-407e-ae0b-e9b0a10520a4@github.com>
References: <HUF4KgYt93teqGiOkL6rf-71hhtC0dWY73U0_-S0GNc=.c5e339b8-a943-4340-b7e1-d574663fd8aa@github.com>
 <tDPybQDw_xfXB_-YCu75B_DthRAskmO707trHRW5QU8=.22e24ed9-7f5a-407e-ae0b-e9b0a10520a4@github.com>
Message-ID: <VctZ6RLbujQfxIvt4OgiQbEYRD_3qNG5W5w31VWrUO8=.4041dd0c-1d59-4820-8bb7-41663c8d4fec@github.com>

On Tue, 30 Jan 2024 12:25:47 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> In the same spirit as [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should adapt the AIX-specific code in hotspot so it uses the well-defined posix `<foo>` functions, instead of `<foo>64`. By setting the define _LARGE_FILES, this will make `<foo>` behave as `<foo>64`, just as _FILE_OFFSET_BITS=64 does on gcc. (Reference: https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-that-access-large-files)
>> 
>> In theory, it should not even be necessary to set this, since we only compile for 64-bit AIX platforms, and this is only relevant on 32-bit platforms. But let's add the define anyway, for good measure. It shows at least that we have thought about the matter. :-)
>> 
>> I have not been able to test this on AIX. I hope someone with AIX access can take this for a spin.
>> 
>> The reason I'm doing this is for [JDK-8324539](https://bugs.openjdk.org/browse/JDK-8324539). After both these bugs are fixed, there will be no more `<foo>64` function calls in the code base.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "8324753: [AIX] adjust os_posix after JDK-8318696"
>   
>   This reverts commit 8950d68ddb36d35831fbb4b98969cd0537527070.

I added a compile-time check that hotspot on AIX is indeed compiled with _LARGE_FILES.

@MBaesken Are you happy with this PR now?

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

PR Comment: https://git.openjdk.org/jdk/pull/17611#issuecomment-1920832341

From ihse at openjdk.org  Thu Feb  1 09:13:07 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 1 Feb 2024 09:13:07 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4]
In-Reply-To: <FXqfV9eIuqQE5fj65sXIKoou-w-ZOko1PbtbISfMIRQ=.558df97e-2941-47d0-9a45-1c450cf6dc39@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <rl5N6C24qN6mBIpOK951TbegJtUPmd-qc9mJEXBd6JM=.378619ec-17e5-4058-b6b3-7fb4ebb02879@github.com>
 <FXqfV9eIuqQE5fj65sXIKoou-w-ZOko1PbtbISfMIRQ=.558df97e-2941-47d0-9a45-1c450cf6dc39@github.com>
Message-ID: <L00Hz-UGbz2N1hNe66rRdTGJRmVhRUE65LwFrkcgzQI=.dab98502-ce23-4f0b-b57a-2d325efaadd0@github.com>

On Wed, 31 Jan 2024 09:19:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge branch 'master' into jdk-FOB64
>>  - Move #include <stdlib/io.h> out of debug_util.h
>>  - Restore AIX dirent64 et al defines
>>  - Rollback AIX changes since they are now tracked in JDK-8324834
>>  - Remove superfluous setting of FOB64
>>  - Replace all foo64() with foo() for large-file functions in the JDK
>>  - 8324539: Do not use LFS64 symbols in JDK libs
>
> After adding this additional patch I  fully build fastdebug on AIX (hav to admit it does not look very nice).
> 
> 
> diff --git a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c
> index 823475b0a23..ee0109b6806 100644
> --- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c
> +++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c
> @@ -31,6 +31,10 @@
>  #include "SpanIterator.h"
>  #include "Trace.h"
>  
> +#if defined(_AIX) && defined(open)
> +#undef open
> +#endif
> +
>  /* The "header" consists of a jint opcode and a jint span count value */
>  #define INTS_PER_HEADER  2
>  #define BYTES_PER_HEADER 8

@MBaesken So my fix in [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) did not help? Maybe then it is some other system library that drags in `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way too much that it does not need, so we can surely strip it of even more standard includes if that is what is required to fix this.

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1920844523

From alanb at openjdk.org  Thu Feb  1 12:16:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Feb 2024 12:16:06 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4]
In-Reply-To: <rl5N6C24qN6mBIpOK951TbegJtUPmd-qc9mJEXBd6JM=.378619ec-17e5-4058-b6b3-7fb4ebb02879@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <rl5N6C24qN6mBIpOK951TbegJtUPmd-qc9mJEXBd6JM=.378619ec-17e5-4058-b6b3-7fb4ebb02879@github.com>
Message-ID: <uBioONfZJFgtEhakQ0cDBh2dW-Ya1KysEf3fI6HC9ns=.fc11c731-3d79-43bd-ac74-510a70653afe@github.com>

On Tue, 30 Jan 2024 14:15:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-FOB64
>  - Move #include <stdlib/io.h> out of debug_util.h
>  - Restore AIX dirent64 et al defines
>  - Rollback AIX changes since they are now tracked in JDK-8324834
>  - Remove superfluous setting of FOB64
>  - Replace all foo64() with foo() for large-file functions in the JDK
>  - 8324539: Do not use LFS64 symbols in JDK libs

I skimmed through the changes and they look okay. Can you confirm that you've run tier1-4 at least? Some of the library code that is changed here is not tested in the lower tiers.

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921189429

From mbaesken at openjdk.org  Thu Feb  1 12:25:08 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 1 Feb 2024 12:25:08 GMT
Subject: RFR: 8324834: Use _LARGE_FILES on AIX [v2]
In-Reply-To: <VctZ6RLbujQfxIvt4OgiQbEYRD_3qNG5W5w31VWrUO8=.4041dd0c-1d59-4820-8bb7-41663c8d4fec@github.com>
References: <HUF4KgYt93teqGiOkL6rf-71hhtC0dWY73U0_-S0GNc=.c5e339b8-a943-4340-b7e1-d574663fd8aa@github.com>
 <tDPybQDw_xfXB_-YCu75B_DthRAskmO707trHRW5QU8=.22e24ed9-7f5a-407e-ae0b-e9b0a10520a4@github.com>
 <VctZ6RLbujQfxIvt4OgiQbEYRD_3qNG5W5w31VWrUO8=.4041dd0c-1d59-4820-8bb7-41663c8d4fec@github.com>
Message-ID: <ZAwP6jm1i0cblbZz8yuuPDoniTPijYJrBUdjMLAq_to=.f0943deb-8ddc-4394-a676-0dba5f5adec1@github.com>

On Thu, 1 Feb 2024 09:04:47 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I added a compile-time check that hotspot on AIX is indeed compiled with _LARGE_FILES.
> 
> @MBaesken Are you happy with this PR now?

Thanks for adding this, I approved the PR .

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

PR Comment: https://git.openjdk.org/jdk/pull/17611#issuecomment-1921204582

From tanksherman27 at gmail.com  Thu Feb  1 12:47:44 2024
From: tanksherman27 at gmail.com (Julian Waters)
Date: Thu, 1 Feb 2024 20:47:44 +0800
Subject: Which JDK in the build directory is the one that is shipped?
Message-ID: <CAP2b4GMnq=PHt=SzFttM1rTL7st5RnW3VK+huuNUpFP+A7ZSDQ@mail.gmail.com>

Hi all,

Quick question: Which JDK in the build directory is the one that is
officially shipped by Oracle? Is it the one in "jdk" that is directly
in the build directory, or the one in "images/jdk"?

best regards,
Julian

From ihse at openjdk.org  Thu Feb  1 13:12:06 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 1 Feb 2024 13:12:06 GMT
Subject: Integrated: 8324834: Use _LARGE_FILES on AIX
In-Reply-To: <HUF4KgYt93teqGiOkL6rf-71hhtC0dWY73U0_-S0GNc=.c5e339b8-a943-4340-b7e1-d574663fd8aa@github.com>
References: <HUF4KgYt93teqGiOkL6rf-71hhtC0dWY73U0_-S0GNc=.c5e339b8-a943-4340-b7e1-d574663fd8aa@github.com>
Message-ID: <GmLlxv3XPMtSvx9XzBKjhxnOyfeSs9DZjITTC7qQHRA=.485e2668-6b64-412e-9c0b-69c3b36ad3f2@github.com>

On Mon, 29 Jan 2024 11:44:34 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In the same spirit as [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should adapt the AIX-specific code in hotspot so it uses the well-defined posix `<foo>` functions, instead of `<foo>64`. By setting the define _LARGE_FILES, this will make `<foo>` behave as `<foo>64`, just as _FILE_OFFSET_BITS=64 does on gcc. (Reference: https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-that-access-large-files)
> 
> In theory, it should not even be necessary to set this, since we only compile for 64-bit AIX platforms, and this is only relevant on 32-bit platforms. But let's add the define anyway, for good measure. It shows at least that we have thought about the matter. :-)
> 
> I have not been able to test this on AIX. I hope someone with AIX access can take this for a spin.
> 
> The reason I'm doing this is for [JDK-8324539](https://bugs.openjdk.org/browse/JDK-8324539). After both these bugs are fixed, there will be no more `<foo>64` function calls in the code base.

This pull request has now been integrated.

Changeset: 8e451823
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8e45182357f4990c86fd0b711a7a91887945480b
Stats:     21 lines in 4 files changed: 4 ins; 0 del; 17 mod

8324834: Use _LARGE_FILES on AIX

Reviewed-by: erikj, mbaesken

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

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

From matthias.baesken at sap.com  Thu Feb  1 13:40:28 2024
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 1 Feb 2024 13:40:28 +0000
Subject: Result: New Build Group Member: Christoph Langer
Message-ID: <AM9PR02MB67702CBC836470919B92E9E493432@AM9PR02MB6770.eurprd02.prod.outlook.com>

The vote for Christoph Langer [1] is now closed.

Yes: 5
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus voting, this is sufficient to approve the nomination.


[1] https://mail.openjdk.org/pipermail/build-dev/2024-January/042845.html

Best regards, Matthias


>I hereby nominate Christoph Langer (clanger) to Membership in the Build Group.
>
>Christoph is a long standing member of the JVM team at SAP and a long time OpenJDK contributor [3].
>He is a member of the OpenJDK Members Group and the Vulnerability Group, and Reviewer in a number of projects.
>Christoph has contributed over 100 openjdk/jdk changes [4], among those also a number of build related changes.
>What is especially important is the fact that Christoph has build/production related expertise on a lot of different OS platforms
>(macOS, Windows, Linux, AIX).
>
>Votes are due by 1st February 2024, 13:00 CET.
>
>Only current Members of the Build Group [1] are eligible
>to vote on this nomination.  Votes must be cast in the open by
>replying to this mailing list
>
>For Lazy Consensus voting instructions, see [2].
>
>Matthias Baesken
>
> [1] https://openjdk.org/census#build
> [2] https://openjdk.org/groups/#member-vote
> [3] https://openjdk.org/census#clanger
> [4] https://github.com/search?q=repo%3Aopenjdk%2Fjdk+author-name%3A%22Christoph+Langer%22&type=commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240201/ee0bc0c7/attachment-0001.htm>

From mbaesken at openjdk.org  Thu Feb  1 13:50:15 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 1 Feb 2024 13:50:15 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4]
In-Reply-To: <FXqfV9eIuqQE5fj65sXIKoou-w-ZOko1PbtbISfMIRQ=.558df97e-2941-47d0-9a45-1c450cf6dc39@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <rl5N6C24qN6mBIpOK951TbegJtUPmd-qc9mJEXBd6JM=.378619ec-17e5-4058-b6b3-7fb4ebb02879@github.com>
 <FXqfV9eIuqQE5fj65sXIKoou-w-ZOko1PbtbISfMIRQ=.558df97e-2941-47d0-9a45-1c450cf6dc39@github.com>
Message-ID: <uPdcnyW7UVAuBP3tx50rV3PbHqdLTNH8Q7LddkJp-LQ=.838db9ca-2214-4e94-a37f-c8e48551b415@github.com>

On Wed, 31 Jan 2024 09:19:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge branch 'master' into jdk-FOB64
>>  - Move #include <stdlib/io.h> out of debug_util.h
>>  - Restore AIX dirent64 et al defines
>>  - Rollback AIX changes since they are now tracked in JDK-8324834
>>  - Remove superfluous setting of FOB64
>>  - Replace all foo64() with foo() for large-file functions in the JDK
>>  - 8324539: Do not use LFS64 symbols in JDK libs
>
> After adding this additional patch I  fully build fastdebug on AIX (hav to admit it does not look very nice).
> 
> 
> diff --git a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c
> index 823475b0a23..ee0109b6806 100644
> --- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c
> +++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c
> @@ -31,6 +31,10 @@
>  #include "SpanIterator.h"
>  #include "Trace.h"
>  
> +#if defined(_AIX) && defined(open)
> +#undef open
> +#endif
> +
>  /* The "header" consists of a jint opcode and a jint span count value */
>  #define INTS_PER_HEADER  2
>  #define BYTES_PER_HEADER 8

> @MBaesken So my fix in [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) did not help? Maybe then it is some other system library that drags in `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way too much that it does not need, so we can surely strip it of even more standard includes if that is what is required to fix this.


Unfortunately it did not help.

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921367368

From erik.joelsson at oracle.com  Thu Feb  1 13:52:00 2024
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 1 Feb 2024 05:52:00 -0800
Subject: Which JDK in the build directory is the one that is shipped?
In-Reply-To: <CAP2b4GMnq=PHt=SzFttM1rTL7st5RnW3VK+huuNUpFP+A7ZSDQ@mail.gmail.com>
References: <CAP2b4GMnq=PHt=SzFttM1rTL7st5RnW3VK+huuNUpFP+A7ZSDQ@mail.gmail.com>
Message-ID: <c4130dd2-7d47-4c2b-9755-1e0e91466dd3@oracle.com>

On 2/1/24 04:47, Julian Waters wrote:
> Hi all,
>
> Quick question: Which JDK in the build directory is the one that is
> officially shipped by Oracle? Is it the one in "jdk" that is directly
> in the build directory, or the one in "images/jdk"?

The one in images/jdk is the one we base the distribution on, but it's 
not actually exactly that. For historic reasons the image generated in 
images/jdk contains external debug symbols, which we do not ship. To get 
exactly what is shipped, run `make product-bundles` and check the 
zip/tar.gz in "bundles/".

The one directly in jdk, the "exploded image", just exists because it's 
faster to build, especially incrementally, so in some developer 
workflows it's preferred. Since the class files are all laid out on disk 
and not jlinked together, it has quite different performance 
characteristics.

/Erik


From ihse at openjdk.org  Thu Feb  1 13:53:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 1 Feb 2024 13:53:56 GMT
Subject: RFR: 8321373: Build should use LC_ALL=C.UTF-8 [v2]
In-Reply-To: <9CbEPFCW69TrCZHAEYtPrOLDJdDyPN3NN6jjKzPhEv4=.e70c5204-28a4-4f42-814f-927dad42b8d4@github.com>
References: <9CbEPFCW69TrCZHAEYtPrOLDJdDyPN3NN6jjKzPhEv4=.e70c5204-28a4-4f42-814f-927dad42b8d4@github.com>
Message-ID: <ii205qou3j858asqjLg59L8dgQhaxHKeC7FnkG3w1-c=.ffd6481e-5ef9-4eb1-a344-c0ef1a93aa95@github.com>

> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as their encoding of choice when they see this locale, but use an arbitrarily encoding, which might not properly handle all UTF-8 characters. Since in practice, all our encoding is utf8, we should tell our tools this as well.
> 
> This will at least have effect on how Java treats path names including unicode characters.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Explicitly load StandardCharsets ascii/utf-8 in HelloClasslist
 - Merge branch 'master' into c.utf-8
 - 8321373: Build should use LC_ALL=C.UTF-8

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16971/files
  - new: https://git.openjdk.org/jdk/pull/16971/files/5197845b..d5f5a257

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

  Stats: 108961 lines in 2375 files changed: 61009 ins; 38143 del; 9809 mod
  Patch: https://git.openjdk.org/jdk/pull/16971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16971/head:pull/16971

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

From ihse at openjdk.org  Thu Feb  1 13:53:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 1 Feb 2024 13:53:56 GMT
Subject: RFR: 8321373: Build should use LC_ALL=C.UTF-8
In-Reply-To: <9CbEPFCW69TrCZHAEYtPrOLDJdDyPN3NN6jjKzPhEv4=.e70c5204-28a4-4f42-814f-927dad42b8d4@github.com>
References: <9CbEPFCW69TrCZHAEYtPrOLDJdDyPN3NN6jjKzPhEv4=.e70c5204-28a4-4f42-814f-927dad42b8d4@github.com>
Message-ID: <NOwPBWgKVh1GrvOpaTNhaPY8myH3KZ7Fz85Sf2eYBog=.e2a3c006-6f3f-40d5-922c-0e5f6f51a3b3@github.com>

On Tue, 5 Dec 2023 10:35:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as their encoding of choice when they see this locale, but use an arbitrarily encoding, which might not properly handle all UTF-8 characters. Since in practice, all our encoding is utf8, we should tell our tools this as well.
> 
> This will at least have effect on how Java treats path names including unicode characters.

Of course this was not as easy. One does not simply add "utf8".

I got a diff in ./lib/classlist:

 401d400
 < java/nio/charset/StandardCharsets
 1182d1180
 < sun/nio/cs/ISO_8859_1
 1184,1185d1181
 < sun/nio/cs/StandardCharsets$Aliases
 < sun/nio/cs/StandardCharsets$Cache
 1187,1196d1182
 < sun/nio/cs/Surrogate
 < sun/nio/cs/Surrogate$Parser
 < sun/nio/cs/US_ASCII
 < sun/nio/cs/US_ASCII$Encoder
 < sun/nio/cs/UTF_16
 < sun/nio/cs/UTF_16BE
 < sun/nio/cs/UTF_16LE
 < sun/nio/cs/UTF_32
 < sun/nio/cs/UTF_32BE
 < sun/nio/cs/UTF_32LE
 1197a1184
 > sun/nio/cs/UTF_8$Encoder
 1232d1218
 < sun/util/PreHashedMap 


The PreHashedMap thing looks weird; the other seem definitely character set related. I'll have to investigate this.

Oh, shut up Wesley!

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

PR Comment: https://git.openjdk.org/jdk/pull/16971#issuecomment-1842838066
PR Comment: https://git.openjdk.org/jdk/pull/16971#issuecomment-1920847508

From ihse at openjdk.org  Thu Feb  1 14:18:05 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 1 Feb 2024 14:18:05 GMT
Subject: RFR: 8321373: Build should use LC_ALL=C.UTF-8 [v2]
In-Reply-To: <ii205qou3j858asqjLg59L8dgQhaxHKeC7FnkG3w1-c=.ffd6481e-5ef9-4eb1-a344-c0ef1a93aa95@github.com>
References: <9CbEPFCW69TrCZHAEYtPrOLDJdDyPN3NN6jjKzPhEv4=.e70c5204-28a4-4f42-814f-927dad42b8d4@github.com>
 <ii205qou3j858asqjLg59L8dgQhaxHKeC7FnkG3w1-c=.ffd6481e-5ef9-4eb1-a344-c0ef1a93aa95@github.com>
Message-ID: <0rZyQ3dySX3aUKiRko2AuMNjoCdJ2v-hRU4ulBxkcdQ=.b7c34b91-4750-4d25-94e4-d2cf713687ce@github.com>

On Thu, 1 Feb 2024 13:53:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as their encoding of choice when they see this locale, but use an arbitrarily encoding, which might not properly handle all UTF-8 characters. Since in practice, all our encoding is utf8, we should tell our tools this as well.
>> 
>> This will at least have effect on how Java treats path names including unicode characters.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Explicitly load StandardCharsets ascii/utf-8 in HelloClasslist
>  - Merge branch 'master' into c.utf-8
>  - 8321373: Build should use LC_ALL=C.UTF-8

With the changes in `HelloClasslist.java`, the following classes are added in `classlist` compared to mainline, and none are removed:


java/nio/StringCharBuffer
java/nio/charset/StandardCharsets
sun/nio/cs/ISO_8859_1
sun/nio/cs/ThreadLocalCoders
sun/nio/cs/ThreadLocalCoders$1
sun/nio/cs/ThreadLocalCoders$2
sun/nio/cs/ThreadLocalCoders$Cache
sun/nio/cs/UTF_16
sun/nio/cs/UTF_16BE
sun/nio/cs/UTF_16LE
sun/nio/cs/UTF_32
sun/nio/cs/UTF_32BE
sun/nio/cs/UTF_32LE
sun/nio/cs/UTF_8$Encoder


This seem highly reasonable to me. @cl4es Can you confirm that this is okay?

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

PR Comment: https://git.openjdk.org/jdk/pull/16971#issuecomment-1921436996

From ihse at openjdk.org  Thu Feb  1 14:21:37 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 1 Feb 2024 14:21:37 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v5]
In-Reply-To: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
Message-ID: <KQigAPdr_y3Xnbus6DqskppDY-G1CAO2PskNna7uq_I=.6dc7d90f-cfb9-44c7-937d-14c01fb44557@github.com>

> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Remove all system includes from debug_util.h

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17538/files
  - new: https://git.openjdk.org/jdk/pull/17538/files/d6c64bc4..6e9ec631

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

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

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

From ihse at openjdk.org  Thu Feb  1 14:27:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 1 Feb 2024 14:27:15 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v6]
In-Reply-To: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
Message-ID: <_ZwLqLPG2IQY-9lP4XO3KlStPatpZGye-Blofj9qfQQ=.dbffd3e3-1f37-4403-92de-63740436cde2@github.com>

> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Merge branch 'master' into jdk-FOB64
 - Remove all system includes from debug_util.h
 - Merge branch 'master' into jdk-FOB64
 - Move #include <stdlib/io.h> out of debug_util.h
 - Restore AIX dirent64 et al defines
 - Rollback AIX changes since they are now tracked in JDK-8324834
 - Remove superfluous setting of FOB64
 - Replace all foo64() with foo() for large-file functions in the JDK
 - 8324539: Do not use LFS64 symbols in JDK libs

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

Changes: https://git.openjdk.org/jdk/pull/17538/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=05
  Stats: 233 lines in 23 files changed: 14 ins; 105 del; 114 mod
  Patch: https://git.openjdk.org/jdk/pull/17538.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538

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

From ihse at openjdk.org  Thu Feb  1 14:27:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 1 Feb 2024 14:27:15 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4]
In-Reply-To: <uPdcnyW7UVAuBP3tx50rV3PbHqdLTNH8Q7LddkJp-LQ=.838db9ca-2214-4e94-a37f-c8e48551b415@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <rl5N6C24qN6mBIpOK951TbegJtUPmd-qc9mJEXBd6JM=.378619ec-17e5-4058-b6b3-7fb4ebb02879@github.com>
 <FXqfV9eIuqQE5fj65sXIKoou-w-ZOko1PbtbISfMIRQ=.558df97e-2941-47d0-9a45-1c450cf6dc39@github.com>
 <uPdcnyW7UVAuBP3tx50rV3PbHqdLTNH8Q7LddkJp-LQ=.838db9ca-2214-4e94-a37f-c8e48551b415@github.com>
Message-ID: <3c6OBIr0CfTFj2PGPn3n3rzLkNxiNavNj-sOx5dWqTw=.64b85b44-36f1-44de-b187-93c6c94ebc9d@github.com>

On Thu, 1 Feb 2024 13:47:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> After adding this additional patch I  fully build fastdebug on AIX (hav to admit it does not look very nice).
>> 
>> 
>> diff --git a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c
>> index 823475b0a23..ee0109b6806 100644
>> --- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c
>> +++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c
>> @@ -31,6 +31,10 @@
>>  #include "SpanIterator.h"
>>  #include "Trace.h"
>>  
>> +#if defined(_AIX) && defined(open)
>> +#undef open
>> +#endif
>> +
>>  /* The "header" consists of a jint opcode and a jint span count value */
>>  #define INTS_PER_HEADER  2
>>  #define BYTES_PER_HEADER 8
>
>> @MBaesken So my fix in [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) did not help? Maybe then it is some other system library that drags in `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way too much that it does not need, so we can surely strip it of even more standard includes if that is what is required to fix this.
> 
> 
> Unfortunately it did not help.

@MBaesken How annoying. :( I have now tried to remove *all* system includes from `debug_util.h`. Can you please try again building debug on AIX, to see if it works without the `#undef` in `BufferedRenderPipe.c`?

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921455438

From ihse at openjdk.org  Thu Feb  1 14:31:04 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 1 Feb 2024 14:31:04 GMT
Subject: RFR: 8321373: Build should use LC_ALL=C.UTF-8 [v2]
In-Reply-To: <ii205qou3j858asqjLg59L8dgQhaxHKeC7FnkG3w1-c=.ffd6481e-5ef9-4eb1-a344-c0ef1a93aa95@github.com>
References: <9CbEPFCW69TrCZHAEYtPrOLDJdDyPN3NN6jjKzPhEv4=.e70c5204-28a4-4f42-814f-927dad42b8d4@github.com>
 <ii205qou3j858asqjLg59L8dgQhaxHKeC7FnkG3w1-c=.ffd6481e-5ef9-4eb1-a344-c0ef1a93aa95@github.com>
Message-ID: <CXnYhNjfWqPySTkfcISICPHBODPctQzIJ1CO_ni3aH4=.be5243d0-d881-47f4-a606-c44944b8f7c7@github.com>

On Thu, 1 Feb 2024 13:53:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as their encoding of choice when they see this locale, but use an arbitrarily encoding, which might not properly handle all UTF-8 characters. Since in practice, all our encoding is utf8, we should tell our tools this as well.
>> 
>> This will at least have effect on how Java treats path names including unicode characters.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Explicitly load StandardCharsets ascii/utf-8 in HelloClasslist
>  - Merge branch 'master' into c.utf-8
>  - 8321373: Build should use LC_ALL=C.UTF-8

Actually, that diff was apparently platform specific. I'm not quite sure if that is caused by a different set of classes already being included in the different platforms. The above list was from macOS. On Linux, the diff look like this:


> java/nio/StringCharBuffer
1183,1184d1183
< sun/nio/cs/StandardCharsets$Aliases
< sun/nio/cs/StandardCharsets$Cache
1187a1187,1190
> sun/nio/cs/ThreadLocalCoders
> sun/nio/cs/ThreadLocalCoders$1
> sun/nio/cs/ThreadLocalCoders$2
> sun/nio/cs/ThreadLocalCoders$Cache
1196a1200
> sun/nio/cs/UTF_8$Encoder
1231d1234
< sun/util/PreHashedMap

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

PR Comment: https://git.openjdk.org/jdk/pull/16971#issuecomment-1921462770

From ihse at openjdk.org  Thu Feb  1 14:54:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 1 Feb 2024 14:54:03 GMT
Subject: RFR: 8321373: Build should use LC_ALL=C.UTF-8 [v2]
In-Reply-To: <ii205qou3j858asqjLg59L8dgQhaxHKeC7FnkG3w1-c=.ffd6481e-5ef9-4eb1-a344-c0ef1a93aa95@github.com>
References: <9CbEPFCW69TrCZHAEYtPrOLDJdDyPN3NN6jjKzPhEv4=.e70c5204-28a4-4f42-814f-927dad42b8d4@github.com>
 <ii205qou3j858asqjLg59L8dgQhaxHKeC7FnkG3w1-c=.ffd6481e-5ef9-4eb1-a344-c0ef1a93aa95@github.com>
Message-ID: <UpNOxFUy4ixm2BpX8lirY_A35cbOIjmCpE7aWWfLXKc=.a5cbd67b-9e74-4d23-a06e-2bd769e29ea7@github.com>

On Thu, 1 Feb 2024 13:53:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as their encoding of choice when they see this locale, but use an arbitrarily encoding, which might not properly handle all UTF-8 characters. Since in practice, all our encoding is utf8, we should tell our tools this as well.
>> 
>> This will at least have effect on how Java treats path names including unicode characters.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Explicitly load StandardCharsets ascii/utf-8 in HelloClasslist
>  - Merge branch 'master' into c.utf-8
>  - 8321373: Build should use LC_ALL=C.UTF-8

So on Linux, with this patch, we will no longer include sun/nio/cs/StandardCharsets$Aliases, sun/nio/cs/StandardCharsets$Cache or sun/util/PreHashedMap. Even prior to this PR, they were not included on macOS. 

My understanding is that these are only used when selecting a character encoding other than US ASCII, UTF-8, or Latin-1. See this snippet from the generated StandardCharsets.java:


    private Charset lookup(String charsetName) {
        // By checking these built-ins we can avoid initializing Aliases,
        // Classes and Cache eagerly during bootstrap.
        //
        // Initialization of java.nio.charset.StandardCharsets should be
        // avoided here to minimize time spent in System.initPhase1, as it
        // may delay initialization of performance critical VM subsystems.
        String csn;
        if (charsetName.equals("UTF-8")) {
            return UTF_8.INSTANCE;
        } else if (charsetName.equals("US-ASCII")) {
            return US_ASCII.INSTANCE;
        } else if (charsetName.equals("ISO-8859-1")) {
            return ISO_8859_1.INSTANCE;
        } else {
            csn = canonicalize(toLower(charsetName));
        }


So my guess is that this is not necessarily a bad thing; they will need to be loaded if we want to look up more esoteric encodings, but that is perhaps not a common use case in these days of UTF-8's global triumph.

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

PR Comment: https://git.openjdk.org/jdk/pull/16971#issuecomment-1921511589

From mbaesken at openjdk.org  Thu Feb  1 15:57:06 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 1 Feb 2024 15:57:06 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4]
In-Reply-To: <uPdcnyW7UVAuBP3tx50rV3PbHqdLTNH8Q7LddkJp-LQ=.838db9ca-2214-4e94-a37f-c8e48551b415@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <rl5N6C24qN6mBIpOK951TbegJtUPmd-qc9mJEXBd6JM=.378619ec-17e5-4058-b6b3-7fb4ebb02879@github.com>
 <FXqfV9eIuqQE5fj65sXIKoou-w-ZOko1PbtbISfMIRQ=.558df97e-2941-47d0-9a45-1c450cf6dc39@github.com>
 <uPdcnyW7UVAuBP3tx50rV3PbHqdLTNH8Q7LddkJp-LQ=.838db9ca-2214-4e94-a37f-c8e48551b415@github.com>
Message-ID: <7M86DsSoWaLOQmf_cK6mXD4hTI8NZ356Z7ZRugqETzM=.bb90569d-0386-4498-9f21-d4c7e66f864f@github.com>

On Thu, 1 Feb 2024 13:47:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> After adding this additional patch I  fully build fastdebug on AIX (hav to admit it does not look very nice).
>> 
>> 
>> diff --git a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c
>> index 823475b0a23..ee0109b6806 100644
>> --- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c
>> +++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c
>> @@ -31,6 +31,10 @@
>>  #include "SpanIterator.h"
>>  #include "Trace.h"
>>  
>> +#if defined(_AIX) && defined(open)
>> +#undef open
>> +#endif
>> +
>>  /* The "header" consists of a jint opcode and a jint span count value */
>>  #define INTS_PER_HEADER  2
>>  #define BYTES_PER_HEADER 8
>
>> @MBaesken So my fix in [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) did not help? Maybe then it is some other system library that drags in `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way too much that it does not need, so we can surely strip it of even more standard includes if that is what is required to fix this.
> 
> 
> Unfortunately it did not help.

> @MBaesken How annoying. :( I have now tried to remove _all_ system includes from `debug_util.h`. Can you please try again building debug on AIX, to see if it works without the `#undef` in `BufferedRenderPipe.c`?

The AIX (fast)debug  build still fails .

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921645170

From ihse at openjdk.org  Thu Feb  1 16:21:05 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 1 Feb 2024 16:21:05 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4]
In-Reply-To: <uBioONfZJFgtEhakQ0cDBh2dW-Ya1KysEf3fI6HC9ns=.fc11c731-3d79-43bd-ac74-510a70653afe@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <rl5N6C24qN6mBIpOK951TbegJtUPmd-qc9mJEXBd6JM=.378619ec-17e5-4058-b6b3-7fb4ebb02879@github.com>
 <uBioONfZJFgtEhakQ0cDBh2dW-Ya1KysEf3fI6HC9ns=.fc11c731-3d79-43bd-ac74-510a70653afe@github.com>
Message-ID: <1wzw4p_VVMn-Qkb6utSVBVN4HDK9uwRnr3MGDsxi51A=.5028d021-ecd3-45af-a9a1-2033a897cf9b@github.com>

On Thu, 1 Feb 2024 12:13:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can you confirm that you've run tier1-4 at least? Some of the library code that is changed here is not tested in the lower tiers.

I have run tier1-4 now, and it passes (bar the tests that are currently failing in mainline). However, this only tests 64-bit builds, and these changes do not affect 64-bit builds, only 32-bit linux. So the tier1-4 is more of a sanity check that I did not inadvertenly broke any 64-bit code.

To really test that this works properly, a 32-bit linux with an assortment of operations on > 2GB files would be needed. To the best of my knowledge, we have no such test environment available, and I could not even try to think of how to create such a test setup that does anything useful. (That is, if I even were to spend any time on creating new tests for 32-bit platforms...)

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921697168

From duke at openjdk.org  Thu Feb  1 20:14:08 2024
From: duke at openjdk.org (duke)
Date: Thu, 1 Feb 2024 20:14:08 GMT
Subject: Withdrawn: JDK-8313790: [arm32] Specify -marm when building without an
 ABI profile
In-Reply-To: <2KwZHmY7EQ4-dYtFkJSRyICBMybr2gibiut7JSqiPlA=.956137f5-635d-4a90-9b85-bcc834744fe5@github.com>
References: <2KwZHmY7EQ4-dYtFkJSRyICBMybr2gibiut7JSqiPlA=.956137f5-635d-4a90-9b85-bcc834744fe5@github.com>
Message-ID: <TCQA9p3-ubZjqsVch0nVmJwAXcnhWsmAK37OUyqQLR4=.0811d0f6-7a63-442f-a974-cbe48de524c2@github.com>

On Fri, 4 Aug 2023 16:17:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> See [JDK-8288719](https://bugs.openjdk.org/browse/JDK-8288719) and subsequent [discussion](https://mail.openjdk.org/pipermail/build-dev/2022-May/034635.html) back in 2022.
> 
> On Arm, we can generate either arm- or thumb-code (`-marm` or `-mthumb`). 
> 
> At the moment, if we don't specify an ABI profile (`--with_abi_profile`) when configuring the build, we call gcc without `-marm` or `-mthumb`. Then we use whatever the toolchain defaults too, which is pretty much random (it depends on how the toolchain itself had been built). That can cause really rare but tricky problems when combining static assembly and C++ code (See e.g. JDK-8288719).
> 
> I propose to always specify `-marm` as default, unless an ABI profile is given, to prevent such errors.
> 
> Thanks to @marchof for testing this.

This pull request has been closed without being integrated.

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

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

From darcy at openjdk.org  Thu Feb  1 21:16:24 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Feb 2024 21:16:24 GMT
Subject: RFR: JDK-8325148: Enable restricted javac warning in java.base
Message-ID: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com>

The restricted javac warning is disabled for java.base, but could be enabled by suppressing the warning in a handful of files.

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

Commit messages:
 - JDK-8325148: Enable restricted javac warning in java.base

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

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

From erikj at openjdk.org  Thu Feb  1 21:30:01 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 1 Feb 2024 21:30:01 GMT
Subject: RFR: JDK-8325148: Enable restricted javac warning in java.base
In-Reply-To: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com>
References: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com>
Message-ID: <4znJHUj228pJIUQcDaUteF1uD8WxW14V1dQhlQBCQ9s=.9b2df0f8-c154-43c4-8e64-6900baac4a32@github.com>

On Thu, 1 Feb 2024 21:10:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The restricted javac warning is disabled for java.base, but could be enabled by suppressing the warning in a handful of files.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17677#pullrequestreview-1857672295

From jjg at openjdk.org  Thu Feb  1 21:44:26 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Feb 2024 21:44:26 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v16]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <qS3B2GKOrKecN9jB0n07XU5EiDfPkhZh0nWqM8sMK5w=.cb6211a6-d67d-4ece-aa5e-c54ecbb3819f@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  add info about provenance of `jdk.internal.md` module

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/54d40b20..b02d4675

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

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

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

From jjg at openjdk.org  Thu Feb  1 21:44:26 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Feb 2024 21:44:26 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v15]
In-Reply-To: <PzTVKwDfSLmEqm4kFvgUO_yBBCj5aWSzsm4acfFE8Bc=.fa82e41e-6c65-4fde-b99d-48f9ac5561fd@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <PzTVKwDfSLmEqm4kFvgUO_yBBCj5aWSzsm4acfFE8Bc=.fa82e41e-6c65-4fde-b99d-48f9ac5561fd@github.com>
Message-ID: <SUHUUp0kmXRTlAB-q1G-vRJotgWqCAr4Zixl3CxdzLE=.79a709f8-77ed-46f3-9fb6-ed544ed721d8@github.com>

On Thu, 1 Feb 2024 01:12:52 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - MarkdownTransformer: tweak doc comments
>  - MarkdownTransformer: change `Lower.replaceIter` to be `private final`
>  - MarkdownTransformer: use suggested text for using streams
>  - remove obsolete debug code

> On CommonMark.
> 
> * `jdk.internal.md` contains 133 files, the vast majority of which are from commonmark-java 0.21.0. According to https://github.com/commonmark/commonmark-java/releases 0.21.0 is the latest/current release; good.
>   Questions:
>   
>   * Did we take the tagged commit or mainline at some point after the tagged commit? If it's the latter, we need to take the tagged version.
>   * What's the difference between those commonmark-java files in this PR and official commonmark-java? In other words, how do we adapt them? It would be nice to have a description of the procedure or a script to update those files.
> * `jdk.internal.md` exports packages to `jdk.jshell`. A question for @lahodaj, who maintains `jdk.jshell`: when do we need to create a new PR similar to that withdrawn [8299902: Support for MarkDown javadoc in JShell?#11936](https://github.com/openjdk/jdk/pull/11936)?

Added comment to `jdk.internal.md` `module-info.java`

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

PR Comment: https://git.openjdk.org/jdk/pull/16388#issuecomment-1922295907

From jvernee at openjdk.org  Thu Feb  1 22:04:01 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 1 Feb 2024 22:04:01 GMT
Subject: RFR: JDK-8325148: Enable restricted javac warning in java.base
In-Reply-To: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com>
References: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com>
Message-ID: <e58P89_NGks-3dm3SGebTa2uPruMu1lSR0fFKmThKAI=.40489ed7-daa2-4090-b214-9a9891037ac3@github.com>

On Thu, 1 Feb 2024 21:10:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The restricted javac warning is disabled for java.base, but could be enabled by suppressing the warning in a handful of files.

This looks good to me. It will be easier to find where we are doing restricted operations like this.

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

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17677#pullrequestreview-1857741290

From darcy at openjdk.org  Thu Feb  1 22:19:26 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Feb 2024 22:19:26 GMT
Subject: RFR: JDK-8325148: Enable restricted javac warning in java.base
 [v2]
In-Reply-To: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com>
References: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com>
Message-ID: <VFxid1Pa9QQPgsb_aipxiCJQQBbEDMLThPuWZnWTtlY=.62c258f7-89f1-4b1d-b5f7-069f85b73e34@github.com>

> The restricted javac warning is disabled for java.base, but could be enabled by suppressing the warning in a handful of files.

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

  Add comment highlighting restricted method calls.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17677/files
  - new: https://git.openjdk.org/jdk/pull/17677/files/4973b1fb..9ac261c0

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

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

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

From darcy at openjdk.org  Thu Feb  1 22:19:26 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Feb 2024 22:19:26 GMT
Subject: RFR: JDK-8325148: Enable restricted javac warning in java.base
 [v2]
In-Reply-To: <e58P89_NGks-3dm3SGebTa2uPruMu1lSR0fFKmThKAI=.40489ed7-daa2-4090-b214-9a9891037ac3@github.com>
References: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com>
 <e58P89_NGks-3dm3SGebTa2uPruMu1lSR0fFKmThKAI=.40489ed7-daa2-4090-b214-9a9891037ac3@github.com>
Message-ID: <VaCid9iYec5bvcKeckU64QcFomTHAuYaWhnoi5cMGKM=.ca63ab1c-550c-4e31-9a8a-f3d67ee2bdb2@github.com>

On Thu, 1 Feb 2024 22:01:49 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This looks good to me. It will be easier to find where we are doing restricted operations like this.

Right; follows the recommended approach of minimizing the scope of the SuppressWarnings annotations too. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/17677#issuecomment-1922360484

From jjg at openjdk.org  Thu Feb  1 22:27:14 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Feb 2024 22:27:14 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v16]
In-Reply-To: <h1baGO4_88DIboIvFWEK-QfaeWbjLrkuwFV5Xz1iOIw=.a878dcce-b168-4114-a842-a704ddb0caf3@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <HZQiJKB0i4jqcVhsKgdzF3_q0vXLC2IIEi6JeZpdq5w=.5cc0180c-8db2-4768-ad38-95aa3ec85403@github.com>
 <h1baGO4_88DIboIvFWEK-QfaeWbjLrkuwFV5Xz1iOIw=.a878dcce-b168-4114-a842-a704ddb0caf3@github.com>
Message-ID: <GOPf7tAXTikT_Ieo7WtAlOW1oCvhsgqSzkswZRp_SMw=.2246f478-4b6b-46df-a7b0-423cdbadea47@github.com>

On Tue, 30 Jan 2024 23:07:46 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java line 572:
>> 
>>> 570:                         }
>>> 571: 
>>> 572:                         case TEXT -> {
>> 
>> I haven't looked at `SentenceBreaker` in detail, but one thing that bothers me is that it sees a comment before that comment has been transformed. This means that `///` comments might not "feel" like Markdown to authors.
>
> First up: I do not understand your second sentence: _This means that /// comments might not "feel" like Markdown to authors._    Please rephrase or clarify that.
> 
> That aside, there's a big case of chickens and eggs here.  The API assumes that the first sentence is distinct from the rest of the description, so we cannot transform it at that early stage.  But generally, the first sentence is supposed to be reasonably simple text, and for cases where it is not, you can use the `summary` tag to circumvent any use of the sentence breaker.
> 
> Bottom line, I do not see any cause for concern at this time.

To add to that, regarding this:
> but one thing that bothers me is that it sees a comment before that comment has been transformed

I don't think we should support any transformations (i.e. custom extensions to Markdown) that would affect the detection of the end of the first sentence.  As of this review, the only custom extension is for enhanced links which simply infer link definitions for appropriate reference links.   If there is anything that is worth checking, it is the handling of any links, including reference links, in the first sentence.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1475229987

From jjg at openjdk.org  Fri Feb  2 00:51:32 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 2 Feb 2024 00:51:32 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v17]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <sHTEhyYjMOUx6Qb8SCSClyM9cVauuF4JCP8WnMzRS34=.06d836c2-edfc-4623-8aa9-f02df689f168@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  updates for "first sentence" issues and tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/b02d4675..f086aaab

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

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

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

From mcimadamore at openjdk.org  Fri Feb  2 05:36:01 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 2 Feb 2024 05:36:01 GMT
Subject: RFR: JDK-8325148: Enable restricted javac warning in java.base
 [v2]
In-Reply-To: <VFxid1Pa9QQPgsb_aipxiCJQQBbEDMLThPuWZnWTtlY=.62c258f7-89f1-4b1d-b5f7-069f85b73e34@github.com>
References: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com>
 <VFxid1Pa9QQPgsb_aipxiCJQQBbEDMLThPuWZnWTtlY=.62c258f7-89f1-4b1d-b5f7-069f85b73e34@github.com>
Message-ID: <3AB1PLupLZXqHdZuduNyWoVwqRRGJat55gE4rDXAgIQ=.7b6e6c0d-60f2-47fa-bc40-39aaaf77cd1f@github.com>

On Thu, 1 Feb 2024 22:19:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The restricted javac warning is disabled for java.base, but could be enabled by suppressing the warning in a handful of files.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment highlighting restricted method calls.

Looks good - a pity that we cannot disable the warning at the package level - I think it would make sense give blanket approval to the FFM implementation classes. But, even like this it's not too bad. Thanks.

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17677#pullrequestreview-1858347672

From ihse at openjdk.org  Fri Feb  2 06:49:05 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Feb 2024 06:49:05 GMT
Subject: RFR: 8324243: Fix GCC 14 build [v2]
In-Reply-To: <KQ1g8MrUF28MQ_EH6U-4PKFXOg85VnCVMVyynqhbD4g=.39a3aa2f-c85d-47e4-baf0-24ad10ed3a94@github.com>
References: <PmU0wltBwGECZ_1D3iQA3WCZE-evJ-Exf9f51-hXdBc=.353a8bb3-79e9-46e0-a85a-c53f62efa8aa@github.com>
 <KQ1g8MrUF28MQ_EH6U-4PKFXOg85VnCVMVyynqhbD4g=.39a3aa2f-c85d-47e4-baf0-24ad10ed3a94@github.com>
Message-ID: <vNlNVeM7sTLgLKfG1crCNHFfNCDtYI3Sd5GPsh0vDns=.24c791ca-bc67-41f2-a358-9fe85188b853@github.com>

On Fri, 2 Feb 2024 06:35:26 GMT, Sam James <duke at openjdk.org> wrote:

>> This fixes building with GCC 14:
>> * Cherry-pick a fix from Harfbuzz upstream
>> * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources
>> 
>> -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses
>> -Werror.
>> 
>> The calloc prototype is:
>> 
>> void *calloc(size_t nmemb, size_t size);
>> 
>> 
>> So, just swap the number of members and size arguments to match the prototype, as
>> we're initialising 1 struct of size `sizeof(struct ...)`. GCC then sees we're not
>> doing anything wrong.
>
> Sam James has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - fix whitespace
>  - Revert "harfbuzz: Cherry-pick upstream fix for GCC 14"
>    
>    This reverts commit acdd606c5d818baa783c6529ea58e66a061ec64a.
>  - Conditionally pass -Wno-transposed-calloc-args for bundled harfbuzz

Changes look good from a build perspective, but you need an ok from client as well for java.desktop changes.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17506#pullrequestreview-1858456679

From ihse at openjdk.org  Fri Feb  2 06:55:19 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Feb 2024 06:55:19 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
In-Reply-To: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
Message-ID: <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>

> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Add kludge to BufferedRenderPipe.c for AIX

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17538/files
  - new: https://git.openjdk.org/jdk/pull/17538/files/eb92119e..3c404183

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

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

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

From ihse at openjdk.org  Fri Feb  2 06:55:19 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Feb 2024 06:55:19 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4]
In-Reply-To: <7M86DsSoWaLOQmf_cK6mXD4hTI8NZ356Z7ZRugqETzM=.bb90569d-0386-4498-9f21-d4c7e66f864f@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <rl5N6C24qN6mBIpOK951TbegJtUPmd-qc9mJEXBd6JM=.378619ec-17e5-4058-b6b3-7fb4ebb02879@github.com>
 <FXqfV9eIuqQE5fj65sXIKoou-w-ZOko1PbtbISfMIRQ=.558df97e-2941-47d0-9a45-1c450cf6dc39@github.com>
 <uPdcnyW7UVAuBP3tx50rV3PbHqdLTNH8Q7LddkJp-LQ=.838db9ca-2214-4e94-a37f-c8e48551b415@github.com>
 <7M86DsSoWaLOQmf_cK6mXD4hTI8NZ356Z7ZRugqETzM=.bb90569d-0386-4498-9f21-d4c7e66f864f@github.com>
Message-ID: <zp-Nd7Jo-EQyjN6O7CssSfCp-k5eU5zgAdd2q2Q3-jQ=.ec83eee7-fb0a-4661-ad97-01d0308bd5e4@github.com>

On Thu, 1 Feb 2024 15:54:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>>> @MBaesken So my fix in [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) did not help? Maybe then it is some other system library that drags in `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way too much that it does not need, so we can surely strip it of even more standard includes if that is what is required to fix this.
>> 
>> 
>> Unfortunately it did not help.
>
>> @MBaesken How annoying. :( I have now tried to remove _all_ system includes from `debug_util.h`. Can you please try again building debug on AIX, to see if it works without the `#undef` in `BufferedRenderPipe.c`?
> 
> The AIX (fast)debug  build still fails .

@MBaesken Ok, I officially give up. :-( I added your patch from https://github.com/openjdk/jdk/pull/17538#issuecomment-1918699480. I agree that it is not elegant, but at least it works.

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1923062901

From duke at openjdk.org  Fri Feb  2 07:01:05 2024
From: duke at openjdk.org (Sam James)
Date: Fri, 2 Feb 2024 07:01:05 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
In-Reply-To: <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
Message-ID: <FBmcsfmbd1Nezd2uzu43WZeUQKgYdCfxoSHEgt4bDaM=.995c4bae-88b5-429a-9978-475e9b916b89@github.com>

On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add kludge to BufferedRenderPipe.c for AIX

First, huge thanks for doing this. I did have a very rough cut of this locally which I'd put to one side, and you and I have done essentially the same thing (but yours with more tact). That's a positive sign.

> > Can you confirm that you've run tier1-4 at least? Some of the library code that is changed here is not tested in the lower tiers.
> 
> I have run tier1-4 now, and it passes (bar the tests that are currently failing in mainline). However, this only tests 64-bit builds, and these changes do not affect 64-bit builds, only 32-bit linux. So the tier1-4 is more of a sanity check that I did not inadvertenly broke any 64-bit code.
> 
> To really test that this works properly, a 32-bit linux with an assortment of operations on > 2GB files would be needed. To the best of my knowledge, we have no such test environment available, and I could not even try to think of how to create such a test setup that does anything useful. (That is, if I even were to spend any time on creating new tests for 32-bit platforms...)

Yeah, let's not, I think. The only way of doing this is with libc shims and a huge mess. As long as we have tests which handle > 2GB files in general, and then also we can get someone to run this on a 32-bit system and tell us if the test suite passes as-is, then we're fine.

Really, even if it builds on a 32-bit system with strict `-Werror=x` for pointer conversions and such, then we're OK.

I'll leave comments inline for the rest.

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1923093781

From duke at openjdk.org  Fri Feb  2 07:05:07 2024
From: duke at openjdk.org (Sam James)
Date: Fri, 2 Feb 2024 07:05:07 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
In-Reply-To: <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
Message-ID: <Ve5i_GI5N-X0wSVaLavvfy62e6XL_jlN4Qs_CkbS3fs=.88f0d499-8edc-48c6-b92d-8d8f5d27c991@github.com>

On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add kludge to BufferedRenderPipe.c for AIX

make/modules/jdk.hotspot.agent/Lib.gmk line 31:

> 29: 
> 30: ifeq ($(call isTargetOs, linux), true)
> 31:   SA_CFLAGS := -D_FILE_OFFSET_BITS=64

We have two choices to feel a bit more comfortable:
1) We unconditionally `static_assert` in a few places for large `off_t`, or
2) We only do it for platforms we know definitely support F_O_B and aren't AIX (which we've handled separately).

Not sure that's strictly necessary though. Also, if something understands LARGEFILE*_SOURCE, then it probably understood F_O_B, or at least has some macro to control it. Just thinking aloud.

src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c line 94:

> 92:         return IOS_UNSUPPORTED_CASE;
> 93: 
> 94:     loff_t offset = (loff_t)position;

Is this `loff_t` for the benefit of `copy_file_range`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1475635336
PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1475636686

From duke at openjdk.org  Fri Feb  2 07:10:07 2024
From: duke at openjdk.org (Sam James)
Date: Fri, 2 Feb 2024 07:10:07 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
In-Reply-To: <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
Message-ID: <CMufBzTNqPcoV1Y2OgYzVC69x2MTH2X3ZkxBU7QL4TA=.fe3a568e-812e-4816-904a-573aae09efdc@github.com>

On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add kludge to BufferedRenderPipe.c for AIX

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 365:

> 363: #else
> 364:     // Make sure we link to the 64-bit version of the functions
> 365:     my_openat_func = (openat_func*) dlsym(RTLD_DEFAULT, "openat64");

Explain this part to me, if you wouldn't mind? (Why do we keep the `64` variants?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1475642841

From pminborg at openjdk.org  Fri Feb  2 07:26:01 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 2 Feb 2024 07:26:01 GMT
Subject: RFR: JDK-8325148: Enable restricted javac warning in java.base
 [v2]
In-Reply-To: <VFxid1Pa9QQPgsb_aipxiCJQQBbEDMLThPuWZnWTtlY=.62c258f7-89f1-4b1d-b5f7-069f85b73e34@github.com>
References: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com>
 <VFxid1Pa9QQPgsb_aipxiCJQQBbEDMLThPuWZnWTtlY=.62c258f7-89f1-4b1d-b5f7-069f85b73e34@github.com>
Message-ID: <1F2_HcNM-D5F0nOFXlBpBRbPpFQKPPUJxYMoKw4k7Ho=.7c11c0b1-5f4d-475c-b111-e2b0ed207e48@github.com>

On Thu, 1 Feb 2024 22:19:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The restricted javac warning is disabled for java.base, but could be enabled by suppressing the warning in a handful of files.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment highlighting restricted method calls.

Nice fix. Thanks.

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

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17677#pullrequestreview-1858547285

From kbarrett at openjdk.org  Fri Feb  2 09:53:06 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 2 Feb 2024 09:53:06 GMT
Subject: RFR: 8324243: Fix GCC 14 build [v2]
In-Reply-To: <KQ1g8MrUF28MQ_EH6U-4PKFXOg85VnCVMVyynqhbD4g=.39a3aa2f-c85d-47e4-baf0-24ad10ed3a94@github.com>
References: <PmU0wltBwGECZ_1D3iQA3WCZE-evJ-Exf9f51-hXdBc=.353a8bb3-79e9-46e0-a85a-c53f62efa8aa@github.com>
 <KQ1g8MrUF28MQ_EH6U-4PKFXOg85VnCVMVyynqhbD4g=.39a3aa2f-c85d-47e4-baf0-24ad10ed3a94@github.com>
Message-ID: <vpyID9GMwQVyDYGKvykzQ7taGx5DK4dXQ65A912Kcgs=.2a27771d-b3a3-4197-b5a6-7644c72aad3e@github.com>

On Fri, 2 Feb 2024 06:35:26 GMT, Sam James <duke at openjdk.org> wrote:

>> This fixes building with GCC 14:
>> * Cherry-pick a fix from Harfbuzz upstream
>> * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources
>> 
>> -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses
>> -Werror.
>> 
>> The calloc prototype is:
>> 
>> void *calloc(size_t nmemb, size_t size);
>> 
>> 
>> So, just swap the number of members and size arguments to match the prototype, as
>> we're initialising 1 struct of size `sizeof(struct ...)`. GCC then sees we're not
>> doing anything wrong.
>
> Sam James has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - fix whitespace
>  - Revert "harfbuzz: Cherry-pick upstream fix for GCC 14"
>    
>    This reverts commit acdd606c5d818baa783c6529ea58e66a061ec64a.
>  - Conditionally pass -Wno-transposed-calloc-args for bundled harfbuzz

(I'm not a member of the relevant teams, but...)
The changes to calloc calls are plainly an improvement.  The new gcc
warnings are correct in the sense of potentially confused code, though
in all of these cases I think it's "harmless".

Just a minor whitespace issue in the build changes.

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

> 512:    HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := class-memaccess noexcept-type \
> 513:        expansion-to-defined dangling-reference maybe-uninitialized \
> 514: 	calloc-transposed-args

Inconsistent indentation.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17506#pullrequestreview-1858762113
PR Review Comment: https://git.openjdk.org/jdk/pull/17506#discussion_r1475787093

From ihse at openjdk.org  Fri Feb  2 10:53:06 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Feb 2024 10:53:06 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
Message-ID: <max72aOIe8eZq_UWLHt0vxJWYl1y8K8GelV-0Wwuphw=.03b9b0d8-91bf-4047-988b-594d66515623@github.com>

On Thu, 11 Jan 2024 13:23:45 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Compile the JDK as C++17, enabling the use of all C++17 language features
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Require clang 13 in toolchain.m4

Nobody complained about raising gcc to 10, see https://mail.openjdk.org/pipermail/build-dev/2024-January/042802.html.

@TheShermanTanker Can you update this PR so it sets the minimum gcc to 10.0 instead of 9.0?

@shipilev Are you okay with us moving forward with this? If not, I'd like to see an concrete example of where this will create a problem, so we can discuss if the general good for the platform can be dictated by that use case.

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1923553875

From ihse at openjdk.org  Fri Feb  2 11:00:05 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Feb 2024 11:00:05 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <dPy4l9uw0sxvaaDrmDXLvtnfMBnfq6NN4_iGRZ47chA=.1cd2983b-6a75-4b92-a7b1-5a8f96e4b623@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
 <dPy4l9uw0sxvaaDrmDXLvtnfMBnfq6NN4_iGRZ47chA=.1cd2983b-6a75-4b92-a7b1-5a8f96e4b623@github.com>
Message-ID: <UT9u7dzmczU75H7RImYDO6rEQ_5AtWwrvs6PfUR_HqE=.52a325d7-06a7-4fef-9d1f-1a821be9b98e@github.com>

On Fri, 19 Jan 2024 12:08:21 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Require clang 13 in toolchain.m4
>
> Should I split the compiler upgrades into a different change and integrate that first? Going off the conversation in this thread it would seem like the compiler upgrade would benefit us a lot more than just having C++17 (The noreturn attribute is one big motivating factor for instance) and it might help if the compiler upgrades were not delayed by the discussion of when to jump to C++17

Also, @TheShermanTanker, can you please incorporate this patch that updates the build documentation to match the changes in configure?


diff --git a/doc/building.html b/doc/building.html
index 7fd530e9dbc..bb5fda24ba7 100644
--- a/doc/building.html
+++ b/doc/building.html
@@ -599,14 +599,14 @@ <h2 id="native-compiler-toolchain-requirements">Native Compiler
 <p>All compilers are expected to be able to handle the C11 language
 standard for C, and C++14 for C++.</p>
 <h3 id="gcc">gcc</h3>
-<p>The minimum accepted version of gcc is 6.0. Older versions will not
+<p>The minimum accepted version of gcc is 10.0. Older versions will not
 be accepted by <code>configure</code>.</p>
 <p>The JDK is currently known to compile successfully with gcc version
 13.2 or newer.</p>
 <p>In general, any version between these two should be usable.</p>
 <h3 id="clang">clang</h3>
-<p>The minimum accepted version of clang is 3.5. Older versions will not
-be accepted by <code>configure</code>.</p>
+<p>The minimum accepted version of clang is 13.0. Older versions will
+not be accepted by <code>configure</code>.</p>
 <p>To use clang instead of gcc on Linux, use
 <code>--with-toolchain-type=clang</code>.</p>
 <h3 id="apple-xcode">Apple Xcode</h3>
@@ -672,7 +672,9 @@ <h3 id="microsoft-visual-studio">Microsoft Visual Studio</h3>
 <code>BuildTools</code>, but e.g. <code>Professional</code>, adjust the
 product ID accordingly.</p>
 <h3 id="ibm-xl-cc">IBM XL C/C++</h3>
-<p>Please consult the AIX section of the <a
+<p>The minimum accepted version of xlc is 17.1.1.4. Older versions will
+not be accepted by <code>configure</code>.</p>
+<p>For further information, please consult the AIX section of the <a
 href="https://wiki.openjdk.org/display/Build/Supported+Build+Platforms">Supported
 Build Platforms</a> OpenJDK Build Wiki page for details about which
 versions of XLC are supported.</p>
diff --git a/doc/building.md b/doc/building.md
index de410439446..9113e0243bd 100644
--- a/doc/building.md
+++ b/doc/building.md
@@ -403,7 +403,7 @@ ## Native Compiler (Toolchain) Requirements
 
 ### gcc
 
-The minimum accepted version of gcc is 6.0. Older versions will not be accepted
+The minimum accepted version of gcc is 10.0. Older versions will not be accepted
 by `configure`.
 
 The JDK is currently known to compile successfully with gcc version 13.2 or
@@ -413,7 +413,7 @@ ### gcc
 
 ### clang
 
-The minimum accepted version of clang is 3.5. Older versions will not be
+The minimum accepted version of clang is 13.0. Older versions will not be
 accepted by `configure`.
 
 To use clang instead of gcc on Linux, use `--with-toolchain-type=clang`.
@@ -489,9 +489,12 @@ ### Microsoft Visual Studio
 
 ### IBM XL C/C++
 
-Please consult the AIX section of the [Supported Build Platforms](
-https://wiki.openjdk.org/display/Build/Supported+Build+Platforms) OpenJDK Build
-Wiki page for details about which versions of XLC are supported.
+The minimum accepted version of xlc is 17.1.1.4. Older versions will not be
+accepted by `configure`.
+
+For further information, please consult the AIX section of the [Supported Build
+Platforms](https://wiki.openjdk.org/display/Build/Supported+Build+Platforms)
+OpenJDK Build Wiki page for details about which versions of XLC are supported.
 
 ## Boot JDK Requirements

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1923565064

From ihse at openjdk.org  Fri Feb  2 15:27:12 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Feb 2024 15:27:12 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang
Message-ID: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>

Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.

Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:


#define DEBUG_ONLY(code) code;

DEBUG_ONLY(foo());


will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.

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

Commit messages:
 - 8325163: Enable -Wpedantic on clang

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

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

From ihse at openjdk.org  Fri Feb  2 15:31:09 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Feb 2024 15:31:09 GMT
Subject: RFR: 8325176: Compiling native tests with clang on linux fails
Message-ID: <f292-EONfatu-W5cFpJrEDgOJtde3FjAwceBS7QI_GE=.4f28b292-e052-4066-bbcb-9196ccd66ec3@github.com>

While we do not have automatic testing of using clang instead of gcc on linux, we try to keep it in working condition. This is still the case for the JDK itself, but there is a native test which fails to compile with clang. This should be fixed.

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

Commit messages:
 - 8325176: Compiling native tests with clang on linux fails

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

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

From ihse at openjdk.org  Fri Feb  2 15:41:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Feb 2024 15:41:00 GMT
Subject: RFR: 8325176: Compiling native tests with clang on linux fails
In-Reply-To: <f292-EONfatu-W5cFpJrEDgOJtde3FjAwceBS7QI_GE=.4f28b292-e052-4066-bbcb-9196ccd66ec3@github.com>
References: <f292-EONfatu-W5cFpJrEDgOJtde3FjAwceBS7QI_GE=.4f28b292-e052-4066-bbcb-9196ccd66ec3@github.com>
Message-ID: <-UbEG83ZKJEE7NjKZtEB8am45RRLs-sxqje0Hoo85Kg=.2f2a462b-df5a-4c6f-8e96-6e9b319b6f29@github.com>

On Fri, 2 Feb 2024 15:27:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> While we do not have automatic testing of using clang instead of gcc on linux, we try to keep it in working condition. This is still the case for the JDK itself, but there is a native test which fails to compile with clang. This should be fixed.

The errors reported are:

/localhome/git/jdk-BAR/closed/test/jdk/java/awt/sizecalc/SafeAllocationTest/libSafeAllocationTest.c:75:13: error: format specifies type 'unsigned long long' but the argument has type 'int64_t' (aka 'long') [-Werror,-Wformat]
            m, n, allocated);
            ^
/localhome/git/jdk-BAR/closed/test/jdk/java/awt/sizecalc/SafeAllocationTest/libSafeAllocationTest.c:75:16: error: format specifies type 'unsigned long long' but the argument has type 'int64_t' (aka 'long') [-Werror,-Wformat]
            m, n, allocated);


There seem to be some underlying type confusion. A (probably better) alternative to hiding the warning is to actually fix the problem. I'll leave that question up for the client team to decide if they want to address this.

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

PR Comment: https://git.openjdk.org/jdk/pull/17688#issuecomment-1924119343

From ihse at openjdk.org  Fri Feb  2 15:48:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Feb 2024 15:48:00 GMT
Subject: RFR: JDK-8325148: Enable restricted javac warning in java.base
 [v2]
In-Reply-To: <VFxid1Pa9QQPgsb_aipxiCJQQBbEDMLThPuWZnWTtlY=.62c258f7-89f1-4b1d-b5f7-069f85b73e34@github.com>
References: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com>
 <VFxid1Pa9QQPgsb_aipxiCJQQBbEDMLThPuWZnWTtlY=.62c258f7-89f1-4b1d-b5f7-069f85b73e34@github.com>
Message-ID: <Pxo1ZknFixybCWWU6c-ahkoOeoG9z571qzabzYrO_dE=.f8ba733a-82e3-4cc4-911d-09964a63b62c@github.com>

On Thu, 1 Feb 2024 22:19:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The restricted javac warning is disabled for java.base, but could be enabled by suppressing the warning in a handful of files.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment highlighting restricted method calls.

Great, thanks for cleaning up!

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17677#pullrequestreview-1859561572

From ihse at openjdk.org  Fri Feb  2 15:53:07 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Feb 2024 15:53:07 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
In-Reply-To: <Ve5i_GI5N-X0wSVaLavvfy62e6XL_jlN4Qs_CkbS3fs=.88f0d499-8edc-48c6-b92d-8d8f5d27c991@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
 <Ve5i_GI5N-X0wSVaLavvfy62e6XL_jlN4Qs_CkbS3fs=.88f0d499-8edc-48c6-b92d-8d8f5d27c991@github.com>
Message-ID: <160IUiEFfgHTenlTpN4C2yL2oMdZPpV1fsK0YysXcr8=.cf71797d-9e10-4713-804e-368b481efde0@github.com>

On Fri, 2 Feb 2024 07:02:43 GMT, Sam James <duke at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add kludge to BufferedRenderPipe.c for AIX
>
> src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c line 94:
> 
>> 92:         return IOS_UNSUPPORTED_CASE;
>> 93: 
>> 94:     loff_t offset = (loff_t)position;
> 
> Is this `loff_t` for the benefit of `copy_file_range`?

That is how copy_file_range is defined. The cast to off64_t was technically incorrect (but they ended up being the same type).

> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 365:
> 
>> 363: #else
>> 364:     // Make sure we link to the 64-bit version of the functions
>> 365:     my_openat_func = (openat_func*) dlsym(RTLD_DEFAULT, "openat64");
> 
> Explain this part to me, if you wouldn't mind? (Why do we keep the `64` variants?)

I wrote earlier:

> There is one change that merit highlighting: In src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c, I kept the dlsym lookup for openat64, fstatat64 and fdopendir64, on non-BSD OSes (i.e. Linux and AIX), and on AIX, respectively. This seems to me to be the safest choice, as we do not need to know if a lookup of openat would yield a 32-bit or a 64-bit version. (I frankly don't know, but I'm guessing it would yield the 32-bit version.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1476232283
PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1476229335

From ihse at openjdk.org  Fri Feb  2 15:53:08 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Feb 2024 15:53:08 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
In-Reply-To: <160IUiEFfgHTenlTpN4C2yL2oMdZPpV1fsK0YysXcr8=.cf71797d-9e10-4713-804e-368b481efde0@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
 <Ve5i_GI5N-X0wSVaLavvfy62e6XL_jlN4Qs_CkbS3fs=.88f0d499-8edc-48c6-b92d-8d8f5d27c991@github.com>
 <160IUiEFfgHTenlTpN4C2yL2oMdZPpV1fsK0YysXcr8=.cf71797d-9e10-4713-804e-368b481efde0@github.com>
Message-ID: <U-SS1eldBMrY51y5s7bn7Ehh4vg4tZncIz3bbFZ_Uv4=.03d7aaa1-c25d-4d7a-a1c9-b5b5c139d960@github.com>

On Fri, 2 Feb 2024 15:48:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 365:
>> 
>>> 363: #else
>>> 364:     // Make sure we link to the 64-bit version of the functions
>>> 365:     my_openat_func = (openat_func*) dlsym(RTLD_DEFAULT, "openat64");
>> 
>> Explain this part to me, if you wouldn't mind? (Why do we keep the `64` variants?)
>
> I wrote earlier:
> 
>> There is one change that merit highlighting: In src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c, I kept the dlsym lookup for openat64, fstatat64 and fdopendir64, on non-BSD OSes (i.e. Linux and AIX), and on AIX, respectively. This seems to me to be the safest choice, as we do not need to know if a lookup of openat would yield a 32-bit or a 64-bit version. (I frankly don't know, but I'm guessing it would yield the 32-bit version.)

Basically, my understanding is that a call to "openat" in the source file will be converted into a call to openat64 on 32-bit platforms. When we look up the function using dlsym, I assume we need to find the 64-bit version directly. 

Even if this is incorrect, it seems at least *safe* to do it this way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1476231574

From jwaters at openjdk.org  Fri Feb  2 15:58:00 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 2 Feb 2024 15:58:00 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang
In-Reply-To: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
Message-ID: <kqaCPxom6Z_IixX1z43pQHfqYW70CA1AjnwXM6rfwdk=.5fc13f50-046f-4ac1-9eae-a6593033e7e5@github.com>

On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
> 
> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
> 
> 
> #define DEBUG_ONLY(code) code;
> 
> DEBUG_ONLY(foo());
> 
> 
> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.

+++++1 for this, anything to help Standard conformance is great! Just a few questions...

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1924155329

From jwaters at openjdk.org  Fri Feb  2 16:03:01 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 2 Feb 2024 16:03:01 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang
In-Reply-To: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
Message-ID: <YMRzj3pmqMVJN0Ff8eLk55JfHWduWFlIxtUH56QKiFY=.c48f33b9-e7b6-4701-a124-1bbf70dd034c@github.com>

On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
> 
> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
> 
> 
> #define DEBUG_ONLY(code) code;
> 
> DEBUG_ONLY(foo());
> 
> 
> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.

Guess I could work on the gcc counterpart and find a way around the inability to disable -Wpedantic with it in tandem with this change...

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1924163226

From ihse at openjdk.org  Fri Feb  2 15:57:07 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Feb 2024 15:57:07 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
In-Reply-To: <Ve5i_GI5N-X0wSVaLavvfy62e6XL_jlN4Qs_CkbS3fs=.88f0d499-8edc-48c6-b92d-8d8f5d27c991@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
 <Ve5i_GI5N-X0wSVaLavvfy62e6XL_jlN4Qs_CkbS3fs=.88f0d499-8edc-48c6-b92d-8d8f5d27c991@github.com>
Message-ID: <HMssbNMaqC4T9AW490wzaepvct6qcBfhsws_lunDVeA=.5f786540-6946-4b7a-a7fd-b0f2903585d3@github.com>

On Fri, 2 Feb 2024 07:01:33 GMT, Sam James <duke at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add kludge to BufferedRenderPipe.c for AIX
>
> make/modules/jdk.hotspot.agent/Lib.gmk line 31:
> 
>> 29: 
>> 30: ifeq ($(call isTargetOs, linux), true)
>> 31:   SA_CFLAGS := -D_FILE_OFFSET_BITS=64
> 
> We have two choices to feel a bit more comfortable:
> 1) We unconditionally `static_assert` in a few places for large `off_t`, or
> 2) We only do it for platforms we know definitely support F_O_B and aren't AIX (which we've handled separately).
> 
> Not sure that's strictly necessary though. Also, if something understands LARGEFILE*_SOURCE, then it probably understood F_O_B, or at least has some macro to control it. Just thinking aloud.

I'm guessing your comment was really more general, and just happened to be placed here? The reason I am removing `-D_FILE_OFFSET_BITS=64` here is that it is always set for all JDK compilations.

1. I don't know why you would not trust that compiler flags in the build system would work, but if you really want to add a static_assert, let me know where you want it.

2. No, AIX is not handled separately. It is handled as part of this PR. You are probably thinking about JDK-8324834, but that was only about Hotspot. This PR is about all the other JDK native libraries.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1476236956

From darcy at openjdk.org  Fri Feb  2 17:50:24 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 2 Feb 2024 17:50:24 GMT
Subject: RFR: JDK-8325148: Enable restricted javac warning in java.base
 [v3]
In-Reply-To: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com>
References: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com>
Message-ID: <NO1UXIn5A8kK4iUVkuI1vqQhNRlKeH6y-GdfrxfOIwk=.582cc82b-c39e-49ed-b0e0-90c84ba570fb@github.com>

> The restricted javac warning is disabled for java.base, but could be enabled by suppressing the warning in a handful of files.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into JDK-8325148
 - Add comment highlighting restricted method calls.
 - JDK-8325148: Enable restricted javac warning in java.base

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17677/files
  - new: https://git.openjdk.org/jdk/pull/17677/files/9ac261c0..23c93895

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

  Stats: 521 lines in 20 files changed: 317 ins; 95 del; 109 mod
  Patch: https://git.openjdk.org/jdk/pull/17677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17677/head:pull/17677

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

From darcy at openjdk.org  Fri Feb  2 17:50:24 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 2 Feb 2024 17:50:24 GMT
Subject: Integrated: JDK-8325148: Enable restricted javac warning in java.base
In-Reply-To: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com>
References: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com>
Message-ID: <h5CNWQbpqWJVNJr5OreehNtWzSYGoZ8AkaCYTdDHYxo=.58adb9de-7f6c-4a6c-a935-b032e25d863c@github.com>

On Thu, 1 Feb 2024 21:10:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The restricted javac warning is disabled for java.base, but could be enabled by suppressing the warning in a handful of files.

This pull request has now been integrated.

Changeset: adc36040
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/adc36040278049b118ea49fba41cb4bcfb9b85f2
Stats:     28 lines in 9 files changed: 10 ins; 0 del; 18 mod

8325148: Enable restricted javac warning in java.base

Reviewed-by: erikj, jvernee, mcimadamore, pminborg, ihse

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

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

From erikj at openjdk.org  Fri Feb  2 19:15:02 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 2 Feb 2024 19:15:02 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang
In-Reply-To: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
Message-ID: <BK_f2Hk9HLuzcYa67kf-dvsC-jUZMAGV4vThmDTv62A=.a67b79e5-7664-4f6b-a64e-541d48120963@github.com>

On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
> 
> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
> 
> 
> #define DEBUG_ONLY(code) code;
> 
> DEBUG_ONLY(foo());
> 
> 
> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.

Marked as reviewed by erikj (Reviewer).

Looks like GHA found some more issues.

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

PR Review: https://git.openjdk.org/jdk/pull/17687#pullrequestreview-1860130881
PR Review: https://git.openjdk.org/jdk/pull/17687#pullrequestreview-1860132459

From darcy at openjdk.org  Fri Feb  2 23:41:11 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 2 Feb 2024 23:41:11 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
Message-ID: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>

After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

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

Commit messages:
 - JDK-8325189: Enable this-escape javac warning in java.base

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

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

From darcy at openjdk.org  Fri Feb  2 23:41:11 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 2 Feb 2024 23:41:11 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <J4KsMc172dHXeWHKTJcglHhIp5QhcpSTw8hGdAwrzLc=.03bb7f31-d5e5-4b6d-9e44-4e86e96746c9@github.com>

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

In its initial form, the changes are tested on Linux. Later on, I'll do cross-platform builds to make sure there aren't any, say, windows-specific changes that are needed as well.

I can file a follow-up umbrella bug with the original list of ~200 warnings so the constructors and initializers in question can be examined to see if they should be updated.

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

PR Comment: https://git.openjdk.org/jdk/pull/17692#issuecomment-1924907536

From darcy at openjdk.org  Sat Feb  3 01:37:03 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 3 Feb 2024 01:37:03 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <J4KsMc172dHXeWHKTJcglHhIp5QhcpSTw8hGdAwrzLc=.03bb7f31-d5e5-4b6d-9e44-4e86e96746c9@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
 <J4KsMc172dHXeWHKTJcglHhIp5QhcpSTw8hGdAwrzLc=.03bb7f31-d5e5-4b6d-9e44-4e86e96746c9@github.com>
Message-ID: <hmsbB5ZziJeSbUENbG-vzzu9kLVUFI9-UBCDJiWMy1w=.ec5c78db-223d-42ee-bc1c-f7f3a01af31f@github.com>

On Fri, 2 Feb 2024 23:38:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> In its initial form, the changes are tested on Linux. Later on, I'll do cross-platform builds to make sure there aren't any, say, windows-specific changes that are needed as well.
> 

PS Builds pass on all platforms (linux, mac, and windows) on Oracle's internal build system.

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

PR Comment: https://git.openjdk.org/jdk/pull/17692#issuecomment-1925001815

From duke at openjdk.org  Sat Feb  3 10:07:26 2024
From: duke at openjdk.org (Sam James)
Date: Sat, 3 Feb 2024 10:07:26 GMT
Subject: RFR: 8324243: Fix GCC 14 build [v3]
In-Reply-To: <PmU0wltBwGECZ_1D3iQA3WCZE-evJ-Exf9f51-hXdBc=.353a8bb3-79e9-46e0-a85a-c53f62efa8aa@github.com>
References: <PmU0wltBwGECZ_1D3iQA3WCZE-evJ-Exf9f51-hXdBc=.353a8bb3-79e9-46e0-a85a-c53f62efa8aa@github.com>
Message-ID: <HdMQd-rsi1Ry5jT7ffesgEm8kzjdD80VO3REUlzBQMs=.c52c56a1-b118-4833-afc9-08798afd6581@github.com>

> This fixes building with GCC 14:
> * Cherry-pick a fix from Harfbuzz upstream
> * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources
> 
> -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses
> -Werror.
> 
> The calloc prototype is:
> 
> void *calloc(size_t nmemb, size_t size);
> 
> 
> So, just swap the number of members and size arguments to match the prototype, as
> we're initialising 1 struct of size `sizeof(struct ...)`. GCC then sees we're not
> doing anything wrong.

Sam James has updated the pull request incrementally with one additional commit since the last revision:

  whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17506/files
  - new: https://git.openjdk.org/jdk/pull/17506/files/ef698d82..ef79e7ab

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

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

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

From gdams at openjdk.org  Sat Feb  3 11:34:12 2024
From: gdams at openjdk.org (George Adams)
Date: Sat, 3 Feb 2024 11:34:12 GMT
Subject: RFR: 8325194: GHA: Add macOS M1 testing
Message-ID: <AajUHnzAeT8VngtyariR_vfo-FTkoRbv5d1OJsbeuw4=.6eb2d4c3-0260-4d6c-9342-6587dacdc05b@github.com>

Now that macOS M1 executors are [available in GitHub actions](https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/) it makes sense to move the build to run on M1 (rather than cross-compiled) and also enable testing on the platform.

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

Commit messages:
 - 8325194: GHA: Add macOS M1 testing

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

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

From gdams at openjdk.org  Sat Feb  3 11:43:23 2024
From: gdams at openjdk.org (George Adams)
Date: Sat, 3 Feb 2024 11:43:23 GMT
Subject: RFR: 8325194: GHA: Add macOS M1 testing [v2]
In-Reply-To: <AajUHnzAeT8VngtyariR_vfo-FTkoRbv5d1OJsbeuw4=.6eb2d4c3-0260-4d6c-9342-6587dacdc05b@github.com>
References: <AajUHnzAeT8VngtyariR_vfo-FTkoRbv5d1OJsbeuw4=.6eb2d4c3-0260-4d6c-9342-6587dacdc05b@github.com>
Message-ID: <nM-TJrHOLxoSPePM6_DfeUfiDjszn73ZXtWxSZxvFKs=.c680fc1b-fd62-47d5-becf-360513e06eec@github.com>

> Now that macOS M1 executors are [available in GitHub actions](https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/) it makes sense to move the build to run on M1 (rather than cross-compiled) and also enable testing on the platform.

George Adams has updated the pull request incrementally with one additional commit since the last revision:

  fix jtreg action

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17694/files
  - new: https://git.openjdk.org/jdk/pull/17694/files/308f9437..36fefbbc

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

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

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

From gdams at openjdk.org  Sat Feb  3 11:49:24 2024
From: gdams at openjdk.org (George Adams)
Date: Sat, 3 Feb 2024 11:49:24 GMT
Subject: RFR: 8325194: GHA: Add macOS M1 testing [v3]
In-Reply-To: <AajUHnzAeT8VngtyariR_vfo-FTkoRbv5d1OJsbeuw4=.6eb2d4c3-0260-4d6c-9342-6587dacdc05b@github.com>
References: <AajUHnzAeT8VngtyariR_vfo-FTkoRbv5d1OJsbeuw4=.6eb2d4c3-0260-4d6c-9342-6587dacdc05b@github.com>
Message-ID: <qOSXmCA3e_vztDOlB5v0sJTOTzslV-x2gFKjJbiNKOM=.79155b2d-dc51-4856-9456-66f07d607858@github.com>

> Now that macOS M1 executors are [available in GitHub actions](https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/) it makes sense to move the build to run on M1 (rather than cross-compiled) and also enable testing on the platform.

George Adams has updated the pull request incrementally with two additional commits since the last revision:

 - fix boot JDK URL
 - fix boot JDK

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17694/files
  - new: https://git.openjdk.org/jdk/pull/17694/files/36fefbbc..33fe9fa3

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

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

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

From clanger at openjdk.org  Sat Feb  3 14:12:00 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Sat, 3 Feb 2024 14:12:00 GMT
Subject: RFR: 8325194: GHA: Add macOS M1 testing [v3]
In-Reply-To: <qOSXmCA3e_vztDOlB5v0sJTOTzslV-x2gFKjJbiNKOM=.79155b2d-dc51-4856-9456-66f07d607858@github.com>
References: <AajUHnzAeT8VngtyariR_vfo-FTkoRbv5d1OJsbeuw4=.6eb2d4c3-0260-4d6c-9342-6587dacdc05b@github.com>
 <qOSXmCA3e_vztDOlB5v0sJTOTzslV-x2gFKjJbiNKOM=.79155b2d-dc51-4856-9456-66f07d607858@github.com>
Message-ID: <az3sMGidoGWfWnuDA7HB5InQqN184WAoXNsIezMxVZQ=.3e3f9451-05a6-4378-9790-608bb908a41e@github.com>

On Sat, 3 Feb 2024 11:49:24 GMT, George Adams <gdams at openjdk.org> wrote:

>> Now that macOS M1 executors are [available in GitHub actions](https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/) it makes sense to move the build to run on M1 (rather than cross-compiled) and also enable testing on the platform.
>
> George Adams has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix boot JDK URL
>  - fix boot JDK

Overall this looks like a good idea.

Do we maybe want to go to 'macos-14' on both MacOS architectures? Maybe do it in a prior, separate change?

Other than that I also think you still need to update a few copyright years.

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

PR Comment: https://git.openjdk.org/jdk/pull/17694#issuecomment-1925337753

From gdams at openjdk.org  Sat Feb  3 16:18:00 2024
From: gdams at openjdk.org (George Adams)
Date: Sat, 3 Feb 2024 16:18:00 GMT
Subject: RFR: 8325194: GHA: Add macOS M1 testing [v3]
In-Reply-To: <az3sMGidoGWfWnuDA7HB5InQqN184WAoXNsIezMxVZQ=.3e3f9451-05a6-4378-9790-608bb908a41e@github.com>
References: <AajUHnzAeT8VngtyariR_vfo-FTkoRbv5d1OJsbeuw4=.6eb2d4c3-0260-4d6c-9342-6587dacdc05b@github.com>
 <qOSXmCA3e_vztDOlB5v0sJTOTzslV-x2gFKjJbiNKOM=.79155b2d-dc51-4856-9456-66f07d607858@github.com>
 <az3sMGidoGWfWnuDA7HB5InQqN184WAoXNsIezMxVZQ=.3e3f9451-05a6-4378-9790-608bb908a41e@github.com>
Message-ID: <HThdvM5ziz8Ij4OS5uVr6d5IeJp7zuK-IDd3jA6Kj10=.5195f96c-d375-4dae-80b7-b106aec65edd@github.com>

On Sat, 3 Feb 2024 14:09:50 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Do we maybe want to go to 'macos-14' on both MacOS architectures? Maybe do it in a prior, separate change?

Noting that macos-14 is arm64 only in GitHub so such a change might not be intentional in this scenario. 

> Other than that I also think you still need to update a few copyright years.

Yeah I'll check now

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

PR Comment: https://git.openjdk.org/jdk/pull/17694#issuecomment-1925371318

From gdams at openjdk.org  Sat Feb  3 16:22:14 2024
From: gdams at openjdk.org (George Adams)
Date: Sat, 3 Feb 2024 16:22:14 GMT
Subject: RFR: 8325194: GHA: Add macOS M1 testing [v4]
In-Reply-To: <AajUHnzAeT8VngtyariR_vfo-FTkoRbv5d1OJsbeuw4=.6eb2d4c3-0260-4d6c-9342-6587dacdc05b@github.com>
References: <AajUHnzAeT8VngtyariR_vfo-FTkoRbv5d1OJsbeuw4=.6eb2d4c3-0260-4d6c-9342-6587dacdc05b@github.com>
Message-ID: <fVSg0lTzkiVSC4cw5904KTBb0n6WRlgrp0aHUZTk_tA=.c71a7fe3-bebf-4e86-a3b4-063eb42a60de@github.com>

> Now that macOS M1 executors are [available in GitHub actions](https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/) it makes sense to move the build to run on M1 (rather than cross-compiled) and also enable testing on the platform.

George Adams has updated the pull request incrementally with one additional commit since the last revision:

  update copyright headers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17694/files
  - new: https://git.openjdk.org/jdk/pull/17694/files/33fe9fa3..5240aed3

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

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

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

From gdams at openjdk.org  Sat Feb  3 21:55:25 2024
From: gdams at openjdk.org (George Adams)
Date: Sat, 3 Feb 2024 21:55:25 GMT
Subject: RFR: 8325194: GHA: Add macOS M1 testing [v5]
In-Reply-To: <AajUHnzAeT8VngtyariR_vfo-FTkoRbv5d1OJsbeuw4=.6eb2d4c3-0260-4d6c-9342-6587dacdc05b@github.com>
References: <AajUHnzAeT8VngtyariR_vfo-FTkoRbv5d1OJsbeuw4=.6eb2d4c3-0260-4d6c-9342-6587dacdc05b@github.com>
Message-ID: <GrRXOT-hiuBaJWl2JU5_gZhLFvisGr1oZm09hK2zGVI=.28c43e47-50d6-46b7-a055-abc5db204c2d@github.com>

> Now that macOS M1 executors are [available in GitHub actions](https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/) it makes sense to move the build to run on M1 (rather than cross-compiled) and also enable testing on the platform.

George Adams has updated the pull request incrementally with one additional commit since the last revision:

  simplify jtreg

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17694/files
  - new: https://git.openjdk.org/jdk/pull/17694/files/5240aed3..acffbee8

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

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

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

From shade at openjdk.org  Sat Feb  3 21:55:25 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Sat, 3 Feb 2024 21:55:25 GMT
Subject: RFR: 8325194: GHA: Add macOS M1 testing [v4]
In-Reply-To: <fVSg0lTzkiVSC4cw5904KTBb0n6WRlgrp0aHUZTk_tA=.c71a7fe3-bebf-4e86-a3b4-063eb42a60de@github.com>
References: <AajUHnzAeT8VngtyariR_vfo-FTkoRbv5d1OJsbeuw4=.6eb2d4c3-0260-4d6c-9342-6587dacdc05b@github.com>
 <fVSg0lTzkiVSC4cw5904KTBb0n6WRlgrp0aHUZTk_tA=.c71a7fe3-bebf-4e86-a3b4-063eb42a60de@github.com>
Message-ID: <mBWh7lKBzqhOeui3_jDEnGIrBjJ9zsWRFKUYJLwoKJc=.a7bf7eee-d3f2-48ec-9950-d79097a566ac@github.com>

On Sat, 3 Feb 2024 16:22:14 GMT, George Adams <gdams at openjdk.org> wrote:

>> Now that macOS M1 executors are [available in GitHub actions](https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/) it makes sense to move the build to run on M1 (rather than cross-compiled) and also enable testing on the platform.
>
> George Adams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright headers

.github/actions/get-jtreg/action.yml line 66:

> 64:         fi
> 65:         # Build JTReg and move files to the proper locations
> 66:         bash make/build.sh --jdk "$JDK"

We did this `JAVA_HOME_17_X64` change for https://github.com/openjdk/jdk/commit/959a61fdd483c9523764b9ba0972f59ca06db0ee, which is partially reverted during upgrade of GH actions. (...and I forgot to revert this hunk, apparently.) I wonder if it would be simpler if we switch back to boot JDK for building jtreg again, which would eliminate this hunk? Might make backports easier too. 

I have no strong opinion here, though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17694#discussion_r1477130456

From gdams at openjdk.org  Sat Feb  3 21:55:25 2024
From: gdams at openjdk.org (George Adams)
Date: Sat, 3 Feb 2024 21:55:25 GMT
Subject: RFR: 8325194: GHA: Add macOS M1 testing [v4]
In-Reply-To: <mBWh7lKBzqhOeui3_jDEnGIrBjJ9zsWRFKUYJLwoKJc=.a7bf7eee-d3f2-48ec-9950-d79097a566ac@github.com>
References: <AajUHnzAeT8VngtyariR_vfo-FTkoRbv5d1OJsbeuw4=.6eb2d4c3-0260-4d6c-9342-6587dacdc05b@github.com>
 <fVSg0lTzkiVSC4cw5904KTBb0n6WRlgrp0aHUZTk_tA=.c71a7fe3-bebf-4e86-a3b4-063eb42a60de@github.com>
 <mBWh7lKBzqhOeui3_jDEnGIrBjJ9zsWRFKUYJLwoKJc=.a7bf7eee-d3f2-48ec-9950-d79097a566ac@github.com>
Message-ID: <bwHYCB1rDv8TE9NiWhILesV7ZfxChX5qjf5ZOFdkO5M=.18a4af64-cc24-44bc-90d5-cc7f40aad130@github.com>

On Sat, 3 Feb 2024 21:45:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> George Adams has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyright headers
>
> .github/actions/get-jtreg/action.yml line 66:
> 
>> 64:         fi
>> 65:         # Build JTReg and move files to the proper locations
>> 66:         bash make/build.sh --jdk "$JDK"
> 
> We did this `JAVA_HOME_17_X64` change for https://github.com/openjdk/jdk/commit/959a61fdd483c9523764b9ba0972f59ca06db0ee, which is partially reverted during upgrade of GH actions. (...and I forgot to revert this hunk, apparently.) I wonder if it would be simpler if we switch back to boot JDK for building jtreg again, which would eliminate this hunk? Might make backports easier too. 
> 
> I have no strong opinion here, though.

yeah this does make sense, anything to remove a horrible if statement ??

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17694#discussion_r1477131017

From alanb at openjdk.org  Sun Feb  4 06:58:03 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 4 Feb 2024 06:58:03 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <LEnAFb3hUSyQMp4opFV1q8aiMDKd21r7C9OyADn11Ik=.c4fa23c1-ebca-451f-b799-eab90d03a2d9@github.com>

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

I skimmed through the use sites and don't see any issues. There is one bucket of escaping "this" that will go away once the support for running with the SM goes away.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1861282672

From gdams at openjdk.org  Sun Feb  4 09:04:03 2024
From: gdams at openjdk.org (George Adams)
Date: Sun, 4 Feb 2024 09:04:03 GMT
Subject: RFR: 8325194: GHA: Add macOS M1 testing [v4]
In-Reply-To: <mBWh7lKBzqhOeui3_jDEnGIrBjJ9zsWRFKUYJLwoKJc=.a7bf7eee-d3f2-48ec-9950-d79097a566ac@github.com>
References: <AajUHnzAeT8VngtyariR_vfo-FTkoRbv5d1OJsbeuw4=.6eb2d4c3-0260-4d6c-9342-6587dacdc05b@github.com>
 <fVSg0lTzkiVSC4cw5904KTBb0n6WRlgrp0aHUZTk_tA=.c71a7fe3-bebf-4e86-a3b4-063eb42a60de@github.com>
 <mBWh7lKBzqhOeui3_jDEnGIrBjJ9zsWRFKUYJLwoKJc=.a7bf7eee-d3f2-48ec-9950-d79097a566ac@github.com>
Message-ID: <AnYqZLATlZbpL7eMm06oabDqU6uJqAkd7oDmmAtDGgw=.a96338c4-b54b-438a-9cb6-dd8563eb2c1c@github.com>

On Sat, 3 Feb 2024 21:45:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> George Adams has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyright headers
>
> .github/actions/get-jtreg/action.yml line 66:
> 
>> 64:         fi
>> 65:         # Build JTReg and move files to the proper locations
>> 66:         bash make/build.sh --jdk "$JDK"
> 
> We did this `JAVA_HOME_17_X64` change for https://github.com/openjdk/jdk/commit/959a61fdd483c9523764b9ba0972f59ca06db0ee, which is partially reverted during upgrade of GH actions. (...and I forgot to revert this hunk, apparently.) I wonder if it would be simpler if we switch back to boot JDK for building jtreg again, which would eliminate this hunk? Might make backports easier too. 
> 
> I have no strong opinion here, though.

@shipilev updated PTAL

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17694#discussion_r1477222603

From jwaters at openjdk.org  Sun Feb  4 15:33:04 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 4 Feb 2024 15:33:04 GMT
Subject: RFR: 8324243: Fix GCC 14 build [v2]
In-Reply-To: <KQ1g8MrUF28MQ_EH6U-4PKFXOg85VnCVMVyynqhbD4g=.39a3aa2f-c85d-47e4-baf0-24ad10ed3a94@github.com>
References: <PmU0wltBwGECZ_1D3iQA3WCZE-evJ-Exf9f51-hXdBc=.353a8bb3-79e9-46e0-a85a-c53f62efa8aa@github.com>
 <KQ1g8MrUF28MQ_EH6U-4PKFXOg85VnCVMVyynqhbD4g=.39a3aa2f-c85d-47e4-baf0-24ad10ed3a94@github.com>
Message-ID: <LndVLJguJxodrJg08Yra8uZS0iQZS_B8L8UiV3EUCrA=.b24d0ff4-fcea-469d-9ee9-32b52cc46d28@github.com>

On Fri, 2 Feb 2024 06:35:26 GMT, Sam James <duke at openjdk.org> wrote:

>> This fixes building with GCC 14:
>> * ~Cherry-pick a fix from Harfbuzz upstream~
>> * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources
>> 
>> -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses
>> -Werror.
>> 
>> The calloc prototype is:
>> 
>> void *calloc(size_t nmemb, size_t size);
>> 
>> 
>> So, just swap the number of members and size arguments to match the prototype, as
>> we're initialising 1 struct of size `sizeof(struct ...)`. GCC then sees we're not
>> doing anything wrong.
>
> Sam James has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - fix whitespace
>  - Revert "harfbuzz: Cherry-pick upstream fix for GCC 14"
>    
>    This reverts commit acdd606c5d818baa783c6529ea58e66a061ec64a.
>  - Conditionally pass -Wno-transposed-calloc-args for bundled harfbuzz

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

> 512:    HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := class-memaccess noexcept-type \
> 513:        expansion-to-defined dangling-reference maybe-uninitialized \
> 514: 	calloc-transposed-args

Nit: Align the calloc-transposed-args with the rest of the disabled warnings

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17506#discussion_r1475611942

From jwaters at openjdk.org  Sun Feb  4 15:33:05 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 4 Feb 2024 15:33:05 GMT
Subject: RFR: 8324243: Fix GCC 14 build [v2]
In-Reply-To: <vpyID9GMwQVyDYGKvykzQ7taGx5DK4dXQ65A912Kcgs=.2a27771d-b3a3-4197-b5a6-7644c72aad3e@github.com>
References: <PmU0wltBwGECZ_1D3iQA3WCZE-evJ-Exf9f51-hXdBc=.353a8bb3-79e9-46e0-a85a-c53f62efa8aa@github.com>
 <KQ1g8MrUF28MQ_EH6U-4PKFXOg85VnCVMVyynqhbD4g=.39a3aa2f-c85d-47e4-baf0-24ad10ed3a94@github.com>
 <vpyID9GMwQVyDYGKvykzQ7taGx5DK4dXQ65A912Kcgs=.2a27771d-b3a3-4197-b5a6-7644c72aad3e@github.com>
Message-ID: <Dl8xKvw3S8OxOhEkinv52EyZ30ZF6UQ2dHtD0MpGxh0=.92bae333-a14f-4df2-8031-fff41c464bae@github.com>

On Fri, 2 Feb 2024 09:26:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Sam James has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - fix whitespace
>>  - Revert "harfbuzz: Cherry-pick upstream fix for GCC 14"
>>    
>>    This reverts commit acdd606c5d818baa783c6529ea58e66a061ec64a.
>>  - Conditionally pass -Wno-transposed-calloc-args for bundled harfbuzz
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 514:
> 
>> 512:    HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := class-memaccess noexcept-type \
>> 513:        expansion-to-defined dangling-reference maybe-uninitialized \
>> 514: 	calloc-transposed-args
> 
> Inconsistent indentation.

Hey, you stole my line!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17506#discussion_r1475821303

From jwaters at openjdk.org  Sun Feb  4 15:33:03 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 4 Feb 2024 15:33:03 GMT
Subject: RFR: 8324243: Fix GCC 14 build [v3]
In-Reply-To: <HdMQd-rsi1Ry5jT7ffesgEm8kzjdD80VO3REUlzBQMs=.c52c56a1-b118-4833-afc9-08798afd6581@github.com>
References: <PmU0wltBwGECZ_1D3iQA3WCZE-evJ-Exf9f51-hXdBc=.353a8bb3-79e9-46e0-a85a-c53f62efa8aa@github.com>
 <HdMQd-rsi1Ry5jT7ffesgEm8kzjdD80VO3REUlzBQMs=.c52c56a1-b118-4833-afc9-08798afd6581@github.com>
Message-ID: <WKW149WY2O0GtMaot9HUQCADXOSFeC5VZTO9c6CDtSg=.8bb0dae1-6ee0-4cf9-8b75-71a1f825d786@github.com>

On Sat, 3 Feb 2024 10:07:26 GMT, Sam James <duke at openjdk.org> wrote:

>> This fixes building with GCC 14:
>> * ~Cherry-pick a fix from Harfbuzz upstream~
>> * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources
>> 
>> -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses
>> -Werror.
>> 
>> The calloc prototype is:
>> 
>> void *calloc(size_t nmemb, size_t size);
>> 
>> 
>> So, just swap the number of members and size arguments to match the prototype, as
>> we're initialising 1 struct of size `sizeof(struct ...)`. GCC then sees we're not
>> doing anything wrong.
>
> Sam James has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace

Marked as reviewed by jwaters (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/17506#pullrequestreview-1858460113

From ihse at openjdk.org  Sun Feb  4 17:27:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sun, 4 Feb 2024 17:27:00 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang
In-Reply-To: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
Message-ID: <v_to-lPZUaNJDkWpiN592eQMIUku9w8LWNvxJErx2Mk=.98cfbbc2-17dc-436f-8679-d81e3fc201e9@github.com>

On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
> 
> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
> 
> 
> #define DEBUG_ONLY(code) code;
> 
> DEBUG_ONLY(foo());
> 
> 
> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.

Ah, dtrace triggers `dollar-in-identifier-extension`. Of course...  *sigh*

I actually had this disabled for hotspot on an earlier version of the patch (that had lied dormant in my personal fork for about a year), but I could not reproduce the problem it was supposed to solve now, so I removed it again. Now I know why I had it.

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1925848001

From clanger at openjdk.org  Sun Feb  4 22:42:01 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Sun, 4 Feb 2024 22:42:01 GMT
Subject: RFR: 8325194: GHA: Add macOS M1 testing [v5]
In-Reply-To: <GrRXOT-hiuBaJWl2JU5_gZhLFvisGr1oZm09hK2zGVI=.28c43e47-50d6-46b7-a055-abc5db204c2d@github.com>
References: <AajUHnzAeT8VngtyariR_vfo-FTkoRbv5d1OJsbeuw4=.6eb2d4c3-0260-4d6c-9342-6587dacdc05b@github.com>
 <GrRXOT-hiuBaJWl2JU5_gZhLFvisGr1oZm09hK2zGVI=.28c43e47-50d6-46b7-a055-abc5db204c2d@github.com>
Message-ID: <qz7tbrI0Ulz2kUflGrjBKSJgXrlXG07XiQvxZj6nAQA=.17233d87-5e16-4488-85f9-62f5bbe5f8d8@github.com>

On Sat, 3 Feb 2024 21:55:25 GMT, George Adams <gdams at openjdk.org> wrote:

>> Now that macOS M1 executors are [available in GitHub actions](https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/) it makes sense to move the build to run on M1 (rather than cross-compiled) and also enable testing on the platform.
>
> George Adams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify jtreg

Looks good to me now. But please let another build group member give give their blessing before integrating.

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17694#pullrequestreview-1861592810

From ihse at openjdk.org  Sun Feb  4 22:55:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sun, 4 Feb 2024 22:55:01 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang
In-Reply-To: <YMRzj3pmqMVJN0Ff8eLk55JfHWduWFlIxtUH56QKiFY=.c48f33b9-e7b6-4701-a124-1bbf70dd034c@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <YMRzj3pmqMVJN0Ff8eLk55JfHWduWFlIxtUH56QKiFY=.c48f33b9-e7b6-4701-a124-1bbf70dd034c@github.com>
Message-ID: <94Ifly9StBGB9Qnoatj1MLo4txRcerzPx9-D2Am1b7U=.6a80b6f5-50ec-4b63-b1b1-8035fb6948db@github.com>

On Fri, 2 Feb 2024 15:59:56 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Guess I could work on the gcc counterpart and find a way around the inability to disable -Wpedantic with it in tandem with this change...

I don't think that is possible. The double semicolon rule can only be disabled by disabling pedantic completely. This is not the first time we've run into trouble because gcc do not have fine-grained enough warnings. :( (While clang has always excelled in this area.)

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1925954578

From kbarrett at openjdk.org  Mon Feb  5 03:12:01 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 5 Feb 2024 03:12:01 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang
In-Reply-To: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
Message-ID: <C8lvIkaCHYs8JdS0Cj_z6GPbMXO4OcT3zSBsQpg0Ubs=.88065bcc-6755-4925-912d-8eb49f4b56a6@github.com>

On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> #define DEBUG_ONLY(code) code;
> 
> DEBUG_ONLY(foo());
> ```
> 
> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.

All of the -Wpedantic warnings for extra ';' in C++ code I looked at look to
me like a gcc bug (or bugs). C++11 added "empty-declaration", which is
permitted anywhere a normal declaration is permitted (C++14 7), as well as for
class member declarations (C++14 9.2).

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96068
seems to have fixed some, but not all, cases.  It looks like it only removed
the warnings for empty declarations at namespace scope.  I couldn't find
anything for other cases, including empty class member declarations.

I consider the "format '%p' expects argument of type 'void*" warnings to be
not at all helpful.  Fortunately we don't use '%p' in HotSpot, but I don't
know how other groups might feel having this inflicted on them.

Because of the vast numbers of those, I ran out of patience trying to find and
examine other warnings triggered by this option.

Based on that, I'm not feeling very keen on this change, at least not for a future
version applying to gcc builds.

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926154325

From kbarrett at openjdk.org  Mon Feb  5 03:24:01 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 5 Feb 2024 03:24:01 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang
In-Reply-To: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
Message-ID: <5YoWExp50qGIjilv-9yq38jGsb3Fw7MJCQ8Sfc3Wp3c=.189956da-6f76-4723-9d4a-11d20b43eeb4@github.com>

On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.

Rather than first turning on pedantic warnings and then (maybe) going back and perhaps fixing things, I'd really prefer
things be done in the other order.  (That's how I handled the recent `-Wparentheses` changes, for example.)

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926164327

From dholmes at openjdk.org  Mon Feb  5 06:18:03 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 5 Feb 2024 06:18:03 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang
In-Reply-To: <C8lvIkaCHYs8JdS0Cj_z6GPbMXO4OcT3zSBsQpg0Ubs=.88065bcc-6755-4925-912d-8eb49f4b56a6@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <C8lvIkaCHYs8JdS0Cj_z6GPbMXO4OcT3zSBsQpg0Ubs=.88065bcc-6755-4925-912d-8eb49f4b56a6@github.com>
Message-ID: <nsuairR0HSKFR8E3n0ny2zD5MXkPwNr2rHFfVih3bGA=.dc657db7-0c9c-4887-9afa-343298c479e2@github.com>

On Mon, 5 Feb 2024 03:07:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> I consider the "format '%p' expects argument of type 'void*" warnings to be not at all helpful. Fortunately we don't use '%p' in HotSpot,

We do use it in hotspot. Not a huge amount as we have the legacy format specifiers for PTR_FORMAT etc.

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926298655

From jwaters at openjdk.org  Mon Feb  5 07:00:01 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 5 Feb 2024 07:00:01 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang
In-Reply-To: <94Ifly9StBGB9Qnoatj1MLo4txRcerzPx9-D2Am1b7U=.6a80b6f5-50ec-4b63-b1b1-8035fb6948db@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <YMRzj3pmqMVJN0Ff8eLk55JfHWduWFlIxtUH56QKiFY=.c48f33b9-e7b6-4701-a124-1bbf70dd034c@github.com>
 <94Ifly9StBGB9Qnoatj1MLo4txRcerzPx9-D2Am1b7U=.6a80b6f5-50ec-4b63-b1b1-8035fb6948db@github.com>
Message-ID: <_M36efmD8eSGI9KzSC7DJdtQkRnfnA2x7kO0syzXAks=.37fc99bc-9d21-4b48-96fb-b5da431c95ad@github.com>

On Sun, 4 Feb 2024 22:52:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > Guess I could work on the gcc counterpart and find a way around the inability to disable -Wpedantic with it in tandem with this change...
> 
> I don't think that is possible. The double semicolon rule can only be disabled by disabling pedantic completely. This is not the first time we've run into trouble because gcc do not have fine-grained enough warnings. :( (While clang has always excelled in this area.)

I tried compiling this on both Linux and Windows, and it seems like there are only a few places where the double semicolons are actually a problem (The strangest case was in a NOT_LP64 macro in mallocHeader.hpp where gcc exploded when parsing a perfectly valid semicolon). This is more of a code style cleanliness check than anything, but as Kim said, it is probably a bug within gcc somewhere. I'll file a gcc bug for this in the meantime

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926339574

From jwaters at openjdk.org  Mon Feb  5 07:21:01 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 5 Feb 2024 07:21:01 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang
In-Reply-To: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
Message-ID: <RgcmmFgnA9S0Y4ZnqQ_FW4t_J4UXerl7r1nBYO8tscQ=.02068746-e8e2-404e-8a48-455322007ac0@github.com>

On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
> 
> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
> 
> 
> #define DEBUG_ONLY(code) code;
> 
> DEBUG_ONLY(foo());
> 
> 
> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.

Created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760
Interestingly a gcc maintainer cannot reproduce the issue at all

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926361490

From jwaters at openjdk.org  Mon Feb  5 07:30:01 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 5 Feb 2024 07:30:01 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang
In-Reply-To: <5YoWExp50qGIjilv-9yq38jGsb3Fw7MJCQ8Sfc3Wp3c=.189956da-6f76-4723-9d4a-11d20b43eeb4@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <5YoWExp50qGIjilv-9yq38jGsb3Fw7MJCQ8Sfc3Wp3c=.189956da-6f76-4723-9d4a-11d20b43eeb4@github.com>
Message-ID: <2KKteHViBJ4B5J2FCpGBFuy1tfoC7kaQWMKq3Ncimes=.d4bed0e1-e307-4b2e-b12e-f495514a4158@github.com>

On Mon, 5 Feb 2024 03:21:35 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
>> 
>> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
>> 
>> 
>> #define DEBUG_ONLY(code) code;
>> 
>> DEBUG_ONLY(foo());
>> 
>> 
>> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.
>
>> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
> 
> Rather than first turning on pedantic warnings and then (maybe) going back and perhaps fixing things, I'd really prefer
> things be done in the other order.  (That's how I handled the recent `-Wparentheses` changes, for example.)

@kimbarrett quoting the gcc maintainers

> Yes because the C++ defect report was only for `Spurious semicolons at namespace scope should be allowed`.  See https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#569 .
> 
> 
> ```
> struct f
> {
>   int t;  ;
> };
> ```
> 
> Is not allowed by the C++ standard currently and is a GCC extension, maybe it should have a seperate flag to control that but I am not 100% sure.

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926372614

From mbaesken at openjdk.org  Mon Feb  5 08:29:06 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 5 Feb 2024 08:29:06 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
In-Reply-To: <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
Message-ID: <7R-vR6xRkCutTiGye-lVtYvEjWVKLFYDWFCaj-Drcbc=.963a2048-d87a-4f4e-b93e-79a62b432138@github.com>

On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add kludge to BufferedRenderPipe.c for AIX

I noticed that in the file src/java.base/share/native/libzip/zlib/zconf.h
we seem to still use `off64_t` , is this okay (at most other locations it was replaced) 
https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libzip/zlib/zconf.h#L541

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926448109

From mdoerr at openjdk.org  Mon Feb  5 08:30:04 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 5 Feb 2024 08:30:04 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v5]
In-Reply-To: <EOE6UCFGWlTNsizD1fjPn_-rVy02Rdq4s8g8H471iPM=.37940ce8-ff5a-4f41-8851-02095ae0be4a@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <aFP4brPqhix6XQsDaH2dxokMi2yTEoClwBt4JqAVOtQ=.04e313b1-70d7-4f28-8354-77bd4fb398c1@github.com>
 <ZmBzXcxwndh1ZO9_vbsdY3KoHmUx0LSycjzh3JDLbTo=.3cb30ad4-a4d9-4c92-82f7-118d6cc6702e@github.com>
 <EOE6UCFGWlTNsizD1fjPn_-rVy02Rdq4s8g8H471iPM=.37940ce8-ff5a-4f41-8851-02095ae0be4a@github.com>
Message-ID: <0Ga1XPW8G48Dip-k3vLbvFg8sI-ywjcMQytuQRAvSLo=.0cbcfa73-0b32-4ec5-bfbc-a15a27e7f1f2@github.com>

On Thu, 11 Jan 2024 13:04:35 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> There is a typo in adlc:
> 
> ```
> diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk b/make/hotspot/gensrc/GensrcAdlc.gmk
> index 0898d91e1c2..bb356476847 100644
> --- a/make/hotspot/gensrc/GensrcAdlc.gmk
> +++ b/make/hotspot/gensrc/GensrcAdlc.gmk
> @@ -51,7 +51,7 @@ ifeq ($(call check-jvm-feature, compiler2), true)
>    endif
>  
>    # Set the C++ standard
> -  ADLC_CFLAGS += $(ADLC_LANGSTD_CXXFLAG)
> +  ADLC_CFLAGS += $(ADLC_LANGSTD_CXXFLAGS)
>  
>    # NOTE: The old build didn't set -DASSERT for windows but it doesn't seem to
>    # hurt.
> ```

Created a PR for that: https://github.com/openjdk/jdk/pull/17705

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1926450195

From mdoerr at openjdk.org  Mon Feb  5 08:30:12 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 5 Feb 2024 08:30:12 GMT
Subject: RFR: 8325213: Flags introduced by configure script are not passed to
 ADLC build
Message-ID: <6cK72nd6uq2D_R-oBmQ5B3nEzr2V25F3tyXYta1BDEI=.75499f03-9a3e-4b0b-9126-d4ec4cfe87e8@github.com>

A trivial ADLC build fix. The ADLC_LANGSTD_CXXFLAGS should get passed.

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

Commit messages:
 - 8325213: Flags introduced by configure script are not passed to ADLC build

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

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

From jwaters at openjdk.org  Mon Feb  5 08:36:00 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 5 Feb 2024 08:36:00 GMT
Subject: RFR: 8325213: Flags introduced by configure script are not passed
 to ADLC build
In-Reply-To: <6cK72nd6uq2D_R-oBmQ5B3nEzr2V25F3tyXYta1BDEI=.75499f03-9a3e-4b0b-9126-d4ec4cfe87e8@github.com>
References: <6cK72nd6uq2D_R-oBmQ5B3nEzr2V25F3tyXYta1BDEI=.75499f03-9a3e-4b0b-9126-d4ec4cfe87e8@github.com>
Message-ID: <x2qp7LgaPl_rnMfOVaU-wLzTTbaGs2iZXXhS3J4D6GE=.9ed1477e-86b3-4dca-bf88-b242bf356ae5@github.com>

On Mon, 5 Feb 2024 08:26:55 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> A trivial ADLC build fix. The ADLC_LANGSTD_CXXFLAGS should get passed.

Marked as reviewed by jwaters (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/17705#pullrequestreview-1862133568

From ihse at openjdk.org  Mon Feb  5 09:19:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 09:19:03 GMT
Subject: RFR: 8325213: Flags introduced by configure script are not passed
 to ADLC build
In-Reply-To: <6cK72nd6uq2D_R-oBmQ5B3nEzr2V25F3tyXYta1BDEI=.75499f03-9a3e-4b0b-9126-d4ec4cfe87e8@github.com>
References: <6cK72nd6uq2D_R-oBmQ5B3nEzr2V25F3tyXYta1BDEI=.75499f03-9a3e-4b0b-9126-d4ec4cfe87e8@github.com>
Message-ID: <R_9blAN4dEMdUDC3iE3fyeVdu-roVVvIb4FeFaYjHeo=.3ca5dde7-8ce3-4f11-9de9-bbd9363f16c6@github.com>

On Mon, 5 Feb 2024 08:26:55 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> A trivial ADLC build fix. The ADLC_LANGSTD_CXXFLAGS should get passed.

LGTM. Thanks!

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17705#pullrequestreview-1862219166

From ihse at openjdk.org  Mon Feb  5 09:19:07 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 09:19:07 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
In-Reply-To: <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
Message-ID: <UaEf99FEHfuBa-a8Corxwx3MBWR1aLBZ1WIJfthozdc=.11c153b3-ab65-4f09-8840-8e4706a2433d@github.com>

On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add kludge to BufferedRenderPipe.c for AIX

zlib is 3rd party source, I did not touch those.

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926532998

From aph at openjdk.org  Mon Feb  5 09:20:04 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 5 Feb 2024 09:20:04 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <i3bo22m6I5cYhAMfktX-W_4-rrtyK6EPyK57QUi6Tco=.a18ddecb-440b-4c70-95ec-4b21fd1b3144@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
 <i3bo22m6I5cYhAMfktX-W_4-rrtyK6EPyK57QUi6Tco=.a18ddecb-440b-4c70-95ec-4b21fd1b3144@github.com>
Message-ID: <KCC78U2X_if2XTRu1qNkeVXSQ672EyZFHbkl-OtP3U8=.9695b185-dc76-4d26-ae32-ceb254f5f275@github.com>

On Wed, 17 Jan 2024 11:19:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We have been stuck on a very old gcc for a long time, due to various reasons. Partly because old gcc versions were not as terrible as old versions of cl.exe, and partly to support odd linux platforms where newer gcc versions were not available.
> 
> It is tempting to raise the bar to get better functionality available on all platforms. In the end, it is a balance between supporting older platforms, and getting a better common language level for the code.
> 
> gcc 10 was released 3+ years ago. I guess that is good enough to consider it a reasonable new minimum.

I guess so, but that sounds rather aggressive to me. Sure, you can always install a newer GCC than the system one, but it's another thing that makes it harder for people to build OpenJDK. Having said that, C++17 is nice to have.

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1926533675

From ihse at openjdk.org  Mon Feb  5 09:31:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 09:31:01 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang
In-Reply-To: <5YoWExp50qGIjilv-9yq38jGsb3Fw7MJCQ8Sfc3Wp3c=.189956da-6f76-4723-9d4a-11d20b43eeb4@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <5YoWExp50qGIjilv-9yq38jGsb3Fw7MJCQ8Sfc3Wp3c=.189956da-6f76-4723-9d4a-11d20b43eeb4@github.com>
Message-ID: <av9NYmZfXrVqn3TdmebHc2SIirRzB9byNRJwdZQ9Nrc=.0240dede-4aae-4529-9b62-17476c89bf62@github.com>

On Mon, 5 Feb 2024 03:21:35 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
>> 
>> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
>> 
>> 
>> #define DEBUG_ONLY(code) code;
>> 
>> DEBUG_ONLY(foo());
>> 
>> 
>> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.
>
>> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
> 
> Rather than first turning on pedantic warnings and then (maybe) going back and perhaps fixing things, I'd really prefer
> things be done in the other order.  (That's how I handled the recent `-Wparentheses` changes, for example.)

@kimbarrett 
> Rather than first turning on pedantic warnings and then (maybe) going back and perhaps fixing things, I'd really prefer
things be done in the other order. 

I hear what you are saying, but I respectfully disagree. If we do things in the order you suggest, the global flag cannot be turned on until all component teams have fixed their source code. That essentially makes the most overworked group putting an effective veto to this change (when your workload is too high, fixing warnings is not on top of your priority.) In contrast, if the global warning can be turned on now, it will have a positive effect on all new and modified code from now on. And the teams can work on their individual warnings, and remove them in their own time.

This is the same method I used for turning on -Wall and -Wextra. Some teams are very eager to fix warnings, and others still have almost all their "DISABLED_WARNINGS" left several years later. (I will not mention any names; you both know who you are ;-)). If I had followed the route you suggest, we would not have -Wall -Wextra on all source code (sans a few, marked files) now.

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926553386

From ihse at openjdk.org  Mon Feb  5 09:35:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 09:35:03 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang
In-Reply-To: <C8lvIkaCHYs8JdS0Cj_z6GPbMXO4OcT3zSBsQpg0Ubs=.88065bcc-6755-4925-912d-8eb49f4b56a6@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <C8lvIkaCHYs8JdS0Cj_z6GPbMXO4OcT3zSBsQpg0Ubs=.88065bcc-6755-4925-912d-8eb49f4b56a6@github.com>
Message-ID: <zoYNT_D3vzcTLkbkCvHyNNXk-2inh4_bEBfSG6UmfJw=.d7687c57-83aa-4e74-a6c9-15b91157db1c@github.com>

On Mon, 5 Feb 2024 03:07:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> at least not for a future version applying to gcc builds.

@kimbarrett @TheShermanTanker Please do not drag gcc into this PR. This is just about clang. Unless gcc makes a serious effort to shape up their inferior warning handling, I don't think we will ever be able to do something similar for gcc. 

But that is not a reason to avoid doing it on clang. In general, we have tried to utilize the strength of every compiler, regardless of if all the other compilers could detect the same problem or not.

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926559951

From ihse at openjdk.org  Mon Feb  5 09:40:02 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 09:40:02 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang
In-Reply-To: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
Message-ID: <2eBjcv6yofxCGu0-QfWUdsMPBXcy-XEcm_d2ajzXbjg=.c4f93413-339f-4a39-aab9-cb8a4b4a7528@github.com>

On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
> 
> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
> 
> 
> #define DEBUG_ONLY(code) code;
> 
> DEBUG_ONLY(foo());
> 
> 
> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.

Also, a general note about the parts of `pedantic` that is globally disabled in this PR (like `extra-semi` and `format-pedantic`). It might very well be that the offending code is restricted to a few places (if these places are in commonly included header files, I was forced to disable the warning globally), and that it can be rather easily fixed.

All the better! But there is still no reason to do that *before* checking in this PR. Let's just get the minimum bar raised first. Then we can adress the issue of fixing the code to get rid of the exceptions for `extra-semi` and `format-pedantic`, if it is possible and if we want it. The latter is not at all clear; the rest of the list of globally disabled warnings (like `unused-parameter`) are warnings that we have agreed is useless, and only unfortunately dragged in with a catch-all flag like `-Wall` or `-Wextra`. From my PoV, the same could be said about `extra-semi`.

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926569091

From ihse at openjdk.org  Mon Feb  5 09:47:05 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 09:47:05 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <KCC78U2X_if2XTRu1qNkeVXSQ672EyZFHbkl-OtP3U8=.9695b185-dc76-4d26-ae32-ceb254f5f275@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
 <i3bo22m6I5cYhAMfktX-W_4-rrtyK6EPyK57QUi6Tco=.a18ddecb-440b-4c70-95ec-4b21fd1b3144@github.com>
 <KCC78U2X_if2XTRu1qNkeVXSQ672EyZFHbkl-OtP3U8=.9695b185-dc76-4d26-ae32-ceb254f5f275@github.com>
Message-ID: <yq-FT47x7QF7L78fMxw3VvYAo_osUWzeUzxb5iJU3hE=.1899b72a-41f7-44b7-946f-84ca1339f1f8@github.com>

On Mon, 5 Feb 2024 09:17:11 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Sure, you can always install a newer GCC than the system one, but it's another thing that makes it harder for people to build OpenJDK. Having said that, C++17 is nice to have.

@theRealAph  I am still just hearing hand-waving "perhaps someone somewhere will have a somewhat harder time building the JDK". Yes, perhaps that is so. But that is very uncertain, and I have still not heard a single concrete example of where this would apply. In contrast, going to gcc 10 will clearly bring a benefit to all other platforms, since it allows us to synchronize the code base at C++17.

In light of this, I think we need to hear some really compelling evidence of problems that would ensue if we raise the minimum to gcc 10. If nobody can produce such evidence, then to me it is a sign that this fear is not well-grounded, and we should proceed with this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1926580836

From ihse at openjdk.org  Mon Feb  5 10:15:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 10:15:01 GMT
Subject: RFR: 8325176: Compiling native tests with clang on linux fails
In-Reply-To: <f292-EONfatu-W5cFpJrEDgOJtde3FjAwceBS7QI_GE=.4f28b292-e052-4066-bbcb-9196ccd66ec3@github.com>
References: <f292-EONfatu-W5cFpJrEDgOJtde3FjAwceBS7QI_GE=.4f28b292-e052-4066-bbcb-9196ccd66ec3@github.com>
Message-ID: <znGM5OFyBD4fYcEki3fYwHIgpQ_yRIziHpH-pFxxN50=.8782b421-ff48-44ee-9bc1-09cd5bd5ea68@github.com>

On Fri, 2 Feb 2024 15:27:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> While we do not have automatic testing of using clang instead of gcc on linux, we try to keep it in working condition. This is still the case for the JDK itself, but there is a native test which fails to compile with clang. This should be fixed.

Any takers on this?

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

PR Comment: https://git.openjdk.org/jdk/pull/17688#issuecomment-1926634243

From jwaters at openjdk.org  Mon Feb  5 10:20:04 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 5 Feb 2024 10:20:04 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang
In-Reply-To: <zoYNT_D3vzcTLkbkCvHyNNXk-2inh4_bEBfSG6UmfJw=.d7687c57-83aa-4e74-a6c9-15b91157db1c@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <C8lvIkaCHYs8JdS0Cj_z6GPbMXO4OcT3zSBsQpg0Ubs=.88065bcc-6755-4925-912d-8eb49f4b56a6@github.com>
 <zoYNT_D3vzcTLkbkCvHyNNXk-2inh4_bEBfSG6UmfJw=.d7687c57-83aa-4e74-a6c9-15b91157db1c@github.com>
Message-ID: <rPcughH04_4MjTQVRHfsyH7ntSOGF4Key-E34p_rQjw=.f4661caf-8124-4a82-9c5e-e3bc31d15f64@github.com>

On Mon, 5 Feb 2024 09:32:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > at least not for a future version applying to gcc builds.
> 
> @kimbarrett @TheShermanTanker Please do not drag gcc into this PR. This is just about clang. Unless gcc makes a serious effort to shape up their inferior warning handling, I don't think we will ever be able to do something similar for gcc.
> 
> But that is not a reason to avoid doing it on clang. In general, we have tried to utilize the strength of every compiler, regardless of if all the other compilers could detect the same problem or not.

Hey, I never said anything about gcc compatibility being a blocker for this changeset :)
(I do have however a couple a questions which are listed above)

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926642510

From jwaters at openjdk.org  Mon Feb  5 10:26:00 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 5 Feb 2024 10:26:00 GMT
Subject: RFR: 8325176: Compiling native tests with clang on linux fails
In-Reply-To: <f292-EONfatu-W5cFpJrEDgOJtde3FjAwceBS7QI_GE=.4f28b292-e052-4066-bbcb-9196ccd66ec3@github.com>
References: <f292-EONfatu-W5cFpJrEDgOJtde3FjAwceBS7QI_GE=.4f28b292-e052-4066-bbcb-9196ccd66ec3@github.com>
Message-ID: <Dfzi8o3xNlgpTcwRcQoPkAGVXdReEqo2TO6QAjcZoeA=.d01bfbd2-bf5d-4547-87e5-0ba3e128f561@github.com>

On Fri, 2 Feb 2024 15:27:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> While we do not have automatic testing of using clang instead of gcc on linux, we try to keep it in working condition. This is still the case for the JDK itself, but there is a native test which fails to compile with clang. This should be fixed.

Marked as reviewed by jwaters (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/17688#pullrequestreview-1862361991

From jwaters at openjdk.org  Mon Feb  5 10:26:01 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 5 Feb 2024 10:26:01 GMT
Subject: RFR: 8325176: Compiling native tests with clang on linux fails
In-Reply-To: <znGM5OFyBD4fYcEki3fYwHIgpQ_yRIziHpH-pFxxN50=.8782b421-ff48-44ee-9bc1-09cd5bd5ea68@github.com>
References: <f292-EONfatu-W5cFpJrEDgOJtde3FjAwceBS7QI_GE=.4f28b292-e052-4066-bbcb-9196ccd66ec3@github.com>
 <znGM5OFyBD4fYcEki3fYwHIgpQ_yRIziHpH-pFxxN50=.8782b421-ff48-44ee-9bc1-09cd5bd5ea68@github.com>
Message-ID: <QmoUp48lZgiG-FeIapPPWCNJ-viIfHbhoCb2Pf4bgWc=.9ef72fee-9e58-45e6-85cd-1c61e921df8c@github.com>

On Mon, 5 Feb 2024 10:12:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Any takers on this?

Have an obligatory +1 for the build changes I suppose, but isn't there the ability to use DISABLED_WARNINGS or a #pragma clang for this?

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

PR Comment: https://git.openjdk.org/jdk/pull/17688#issuecomment-1926654201

From ihse at openjdk.org  Mon Feb  5 10:38:26 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 10:38:26 GMT
Subject: RFR: 8321373: Build should use LC_ALL=C.UTF-8 [v3]
In-Reply-To: <9CbEPFCW69TrCZHAEYtPrOLDJdDyPN3NN6jjKzPhEv4=.e70c5204-28a4-4f42-814f-927dad42b8d4@github.com>
References: <9CbEPFCW69TrCZHAEYtPrOLDJdDyPN3NN6jjKzPhEv4=.e70c5204-28a4-4f42-814f-927dad42b8d4@github.com>
Message-ID: <9STA_Xf9xn0LpZJ-KF2KAVxKYIm4NnP0jIdKeBaBfRE=.2555eb46-e8a7-4f56-8815-ffe98d652470@github.com>

> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as their encoding of choice when they see this locale, but use an arbitrarily encoding, which might not properly handle all UTF-8 characters. Since in practice, all our encoding is utf8, we should tell our tools this as well.
> 
> This will at least have effect on how Java treats path names including unicode characters.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Update copyright year
 - check for utf-8 first

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16971/files
  - new: https://git.openjdk.org/jdk/pull/16971/files/d5f5a257..c09bc9b1

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

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

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

From ihse at openjdk.org  Mon Feb  5 10:41:02 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 10:41:02 GMT
Subject: RFR: 8325176: Compiling native tests with clang on linux fails
In-Reply-To: <f292-EONfatu-W5cFpJrEDgOJtde3FjAwceBS7QI_GE=.4f28b292-e052-4066-bbcb-9196ccd66ec3@github.com>
References: <f292-EONfatu-W5cFpJrEDgOJtde3FjAwceBS7QI_GE=.4f28b292-e052-4066-bbcb-9196ccd66ec3@github.com>
Message-ID: <DEChDUJZrOuxyv5p5tOYYO-pMzoqyggllrFjOH4ymoI=.801cd53a-68d1-473e-b87d-24defb722a91@github.com>

On Fri, 2 Feb 2024 15:27:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> While we do not have automatic testing of using clang instead of gcc on linux, we try to keep it in working condition. This is still the case for the JDK itself, but there is a native test which fails to compile with clang. This should be fixed.

The test native libraries are special, so I did not think DISABLED_WARNINGS would work very well. But maybe it does. (Even I am getting lost in the rules for combining arguments to SetupNativeCompilation, even if I wrote most of them :-))

I'll have a look. It is definitely cleaner if it works. (Even though the best would probably be to fix the test.)

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

PR Comment: https://git.openjdk.org/jdk/pull/17688#issuecomment-1926681840

From ihse at openjdk.org  Mon Feb  5 10:48:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 10:48:01 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang
In-Reply-To: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
Message-ID: <YW_ZPtItiUYeJV2le0Um8yb1UQN0lwOBeMUICNXQ7tI=.366669cf-3bd6-4e30-90a9-ce90759fea55@github.com>

On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
> 
> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
> 
> 
> #define DEBUG_ONLY(code) code;
> 
> DEBUG_ONLY(foo());
> 
> 
> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.

I am sorry, but all I can see is:

> Just a few questions...

and then your comment ends. And I can't find any other comment with a list of questions.

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926693945

From ihse at openjdk.org  Mon Feb  5 10:58:17 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 10:58:17 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang [v2]
In-Reply-To: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
Message-ID: <qja7u1WGpMGYvymUwKDAfovke8Kplizcby_j0hNN-r4=.9a3603e4-1446-4b57-9059-7553d21c64a1@github.com>

> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
> 
> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
> 
> 
> #define DEBUG_ONLY(code) code;
> 
> DEBUG_ONLY(foo());
> 
> 
> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  FIx dtrace build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17687/files
  - new: https://git.openjdk.org/jdk/pull/17687/files/4de3c446..ffa70af6

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

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

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

From jwaters at openjdk.org  Mon Feb  5 10:58:17 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 5 Feb 2024 10:58:17 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang
In-Reply-To: <YW_ZPtItiUYeJV2le0Um8yb1UQN0lwOBeMUICNXQ7tI=.366669cf-3bd6-4e30-90a9-ce90759fea55@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <YW_ZPtItiUYeJV2le0Um8yb1UQN0lwOBeMUICNXQ7tI=.366669cf-3bd6-4e30-90a9-ce90759fea55@github.com>
Message-ID: <vEnvEfrFizpT-7E9rt1A-NQpkuvPQHUVC6ISoSlrYHI=.003d728e-a594-4540-b295-49d828c9b6f8@github.com>

On Mon, 5 Feb 2024 10:44:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I am sorry, but all I can see is:
> 
> > Just a few questions...
> 
> and then your comment ends. And I can't find any other comment with a list of questions.

Eh? Aren't they in the code review section? But in any case:

> Shouldn't this be -pedantic -Wpedantic, and wouldn't this be better positioned at where HotSpot currently sets -permissive- for Microsoft Visual C++ (In other words, TOOLCHAIN_CFLAGS_JVM and TOOLCHAIN_CFLAGS_JDK)? The 2 options are not the same, at least on gcc, and I'm unsure if the same is true for clang

The other concern I had was that there are a ton of disabled warnings added by this change, but I guess that's already been answered by that other reply

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926701211

From ihse at openjdk.org  Mon Feb  5 11:06:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 11:06:01 GMT
Subject: RFR: 8325176: Compiling native tests with clang on linux fails
In-Reply-To: <DEChDUJZrOuxyv5p5tOYYO-pMzoqyggllrFjOH4ymoI=.801cd53a-68d1-473e-b87d-24defb722a91@github.com>
References: <f292-EONfatu-W5cFpJrEDgOJtde3FjAwceBS7QI_GE=.4f28b292-e052-4066-bbcb-9196ccd66ec3@github.com>
 <DEChDUJZrOuxyv5p5tOYYO-pMzoqyggllrFjOH4ymoI=.801cd53a-68d1-473e-b87d-24defb722a91@github.com>
Message-ID: <8vXlMbtDQuSxKQEOu0XNBphj9jyw1KTIO3XyLKdiquo=.d4836639-0c6d-48f1-a873-9203d061a1ba@github.com>

On Mon, 5 Feb 2024 10:37:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I'll have a look. It is definitely cleaner if it works. 

Yeah, no, as expected it did not work.

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

PR Comment: https://git.openjdk.org/jdk/pull/17688#issuecomment-1926726543

From mbaesken at openjdk.org  Mon Feb  5 12:10:08 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 5 Feb 2024 12:10:08 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
In-Reply-To: <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
Message-ID: <hC_YrVUBlpEVuDU3J6kBBeoDyIDwfd61ZLMRAv3WD_Y=.df2ca023-54ea-40b7-872f-59f0efb60443@github.com>

On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add kludge to BufferedRenderPipe.c for AIX

Current commit compiles nicely on AIX.
One issue we might still have
statvfs/statvfs64  is not mentioned here in the table of functions/structs redefined on AIX
https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-that-access-large-files
so would we fall back to statvfs from the *64  - variant ?
The define _LARGE_FILES might not help in this case on AIX .

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926848063

From ihse at openjdk.org  Mon Feb  5 12:18:04 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 12:18:04 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang
In-Reply-To: <vEnvEfrFizpT-7E9rt1A-NQpkuvPQHUVC6ISoSlrYHI=.003d728e-a594-4540-b295-49d828c9b6f8@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <YW_ZPtItiUYeJV2le0Um8yb1UQN0lwOBeMUICNXQ7tI=.366669cf-3bd6-4e30-90a9-ce90759fea55@github.com>
 <vEnvEfrFizpT-7E9rt1A-NQpkuvPQHUVC6ISoSlrYHI=.003d728e-a594-4540-b295-49d828c9b6f8@github.com>
Message-ID: <uRxe8OUklRWjfdU8ePwmWKFxv18BlF0kfo1ruARIKXQ=.1893dcef-b6cd-4b3b-a084-7f2667cb6da8@github.com>

On Mon, 5 Feb 2024 10:49:07 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Shouldn't this be -pedantic -Wpedantic, and wouldn't this be better positioned at where HotSpot currently sets -permissive- for Microsoft Visual C++ (In other words, TOOLCHAIN_CFLAGS_JVM and TOOLCHAIN_CFLAGS_JDK)? The 2 options are not the same, at least on gcc, and I'm unsure if the same is true for clang

(It is really weird, I cannot find that original comment anywhere in the Github PR :-()

As far as I have been able to determine, -Wpedantic and -pedantic are aliases on gcc > 5, and the same is true for clang. -Wpedantic seems to be the preferred way nowadays.

`TOOLCHAIN_CFLAGS_JVM` is arguably if not wrong so at least not the best place to put `-permissive-`. `-Wpermissive` belongs with `-Wall -Wextra`.

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926861360

From jkern at openjdk.org  Mon Feb  5 12:20:07 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 5 Feb 2024 12:20:07 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
In-Reply-To: <hC_YrVUBlpEVuDU3J6kBBeoDyIDwfd61ZLMRAv3WD_Y=.df2ca023-54ea-40b7-872f-59f0efb60443@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
 <hC_YrVUBlpEVuDU3J6kBBeoDyIDwfd61ZLMRAv3WD_Y=.df2ca023-54ea-40b7-872f-59f0efb60443@github.com>
Message-ID: <b6ClMQsdrNCjeGNUkUc-LpJVWGUzrbMvZu33n4rUd_I=.12f37f46-7ba4-49dc-a4b9-9a908499fbf9@github.com>

On Mon, 5 Feb 2024 12:07:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Current commit compiles nicely on AIX. One issue we might still have statvfs/statvfs64 is not mentioned here in the table of functions/structs redefined on AIX https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-that-access-large-files so would we fall back to statvfs from the *64 - variant ? The define _LARGE_FILES might not help in this case on AIX .

Yes, if statvfs64() is replaced by statvfs() in the code, we will fallback on AIX to 32-Bit. _LARGE_FILES really does not help in this case!

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926865295

From ihse at openjdk.org  Mon Feb  5 12:21:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 12:21:01 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang
In-Reply-To: <vEnvEfrFizpT-7E9rt1A-NQpkuvPQHUVC6ISoSlrYHI=.003d728e-a594-4540-b295-49d828c9b6f8@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <YW_ZPtItiUYeJV2le0Um8yb1UQN0lwOBeMUICNXQ7tI=.366669cf-3bd6-4e30-90a9-ce90759fea55@github.com>
 <vEnvEfrFizpT-7E9rt1A-NQpkuvPQHUVC6ISoSlrYHI=.003d728e-a594-4540-b295-49d828c9b6f8@github.com>
Message-ID: <u85sFbMBS3pXF50Ys1frNdQ42orSUDKkBV9Tex5e4ps=.4857e1b0-c33a-47eb-a575-2765b1f51e54@github.com>

On Mon, 5 Feb 2024 10:49:07 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> The other concern I had was that there are a ton of disabled warnings added by this change, but I guess that's already been answered by that other reply

Just to be clear: these warnings have never been turned on. They are implicitly turned on by `-Wpedantic`; and this works fine with most files, but this improved scrutiny catches issues in some files. My idea is to file bugs on these individual disabled warnings, to have the actual problem fixed, but as follow up to this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926867260

From mbaesken at openjdk.org  Mon Feb  5 12:25:07 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 5 Feb 2024 12:25:07 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
In-Reply-To: <b6ClMQsdrNCjeGNUkUc-LpJVWGUzrbMvZu33n4rUd_I=.12f37f46-7ba4-49dc-a4b9-9a908499fbf9@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
 <hC_YrVUBlpEVuDU3J6kBBeoDyIDwfd61ZLMRAv3WD_Y=.df2ca023-54ea-40b7-872f-59f0efb60443@github.com>
 <b6ClMQsdrNCjeGNUkUc-LpJVWGUzrbMvZu33n4rUd_I=.12f37f46-7ba4-49dc-a4b9-9a908499fbf9@github.com>
Message-ID: <c6tvYf0Rb4P6dSp5970EqmJrkFhMtJuDMQE059rrotU=.03e9d065-4aea-4210-955c-269f9aebf7f6@github.com>

On Mon, 5 Feb 2024 12:17:33 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> Yes, if statvfs64() is replaced by statvfs() in the code, we will fallback on AIX to 32-Bit. _LARGE_FILES really does not help in this case!

Thanks for confirming. I think we do not want to fallback on AIX, so the <*>64 variant needs to stay on AIX.

Seems the other symbols are covered by _LARGE_FILES according to the table in the linked IBM AIX doc (table in  https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-that-access-large-files ) , is that correct (Joachim?) or did I miss something ?

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926874075

From ihse at openjdk.org  Mon Feb  5 12:41:11 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 12:41:11 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
In-Reply-To: <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
Message-ID: <eiwl1FO-3YoSQB5x7EQBtXhB-zwYy76syT4Mb9nS7oc=.4f41eb9f-9b1f-4685-bf08-83f3276d4295@github.com>

On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add kludge to BufferedRenderPipe.c for AIX

It seems like the statvfs64 is a pre-existing bug in AIX in that case. I have not removed any statvfs64 for AIX; all such changes are guarded by `#ifdef _ALLBSD_SOURCE`, which I presume is not defined on AIX.

I recommend that I push this PR as-is first, and then you can do a follow-up fix to define statvfs to statvfs64 on AIX.

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926903203

From redestad at openjdk.org  Mon Feb  5 12:45:01 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 5 Feb 2024 12:45:01 GMT
Subject: RFR: 8321373: Build should use LC_ALL=C.UTF-8 [v3]
In-Reply-To: <9STA_Xf9xn0LpZJ-KF2KAVxKYIm4NnP0jIdKeBaBfRE=.2555eb46-e8a7-4f56-8815-ffe98d652470@github.com>
References: <9CbEPFCW69TrCZHAEYtPrOLDJdDyPN3NN6jjKzPhEv4=.e70c5204-28a4-4f42-814f-927dad42b8d4@github.com>
 <9STA_Xf9xn0LpZJ-KF2KAVxKYIm4NnP0jIdKeBaBfRE=.2555eb46-e8a7-4f56-8815-ffe98d652470@github.com>
Message-ID: <wTfxDFwvoTsVFrIJXo0EAGituzFVDMvHqaSZ1W8b3D4=.1c0f363b-1920-4156-b472-14059471e764@github.com>

On Mon, 5 Feb 2024 10:38:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as their encoding of choice when they see this locale, but use an arbitrarily encoding, which might not properly handle all UTF-8 characters. Since in practice, all our encoding is utf8, we should tell our tools this as well.
>> 
>> This will at least have effect on how Java treats path names including unicode characters.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright year
>  - check for utf-8 first

Explicitly adding java/nio/charset/StandardCharsets and slightly growing the default set seems quite reasonable. IME using this explicitly seems very common in real applications.

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

PR Comment: https://git.openjdk.org/jdk/pull/16971#issuecomment-1926913952

From jwaters at openjdk.org  Mon Feb  5 12:51:06 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 5 Feb 2024 12:51:06 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang
In-Reply-To: <uRxe8OUklRWjfdU8ePwmWKFxv18BlF0kfo1ruARIKXQ=.1893dcef-b6cd-4b3b-a084-7f2667cb6da8@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <YW_ZPtItiUYeJV2le0Um8yb1UQN0lwOBeMUICNXQ7tI=.366669cf-3bd6-4e30-90a9-ce90759fea55@github.com>
 <vEnvEfrFizpT-7E9rt1A-NQpkuvPQHUVC6ISoSlrYHI=.003d728e-a594-4540-b295-49d828c9b6f8@github.com>
 <uRxe8OUklRWjfdU8ePwmWKFxv18BlF0kfo1ruARIKXQ=.1893dcef-b6cd-4b3b-a084-7f2667cb6da8@github.com>
Message-ID: <MQCEn0Y_KIQGxlqnhahK-NhTImcWBo_uCG9Kp1ahJdY=.49efd0b0-f8d9-4cdb-9fa3-e052d92ed586@github.com>

On Mon, 5 Feb 2024 12:15:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > Shouldn't this be -pedantic -Wpedantic, and wouldn't this be better positioned at where HotSpot currently sets -permissive- for Microsoft Visual C++ (In other words, TOOLCHAIN_CFLAGS_JVM and TOOLCHAIN_CFLAGS_JDK)? The 2 options are not the same, at least on gcc, and I'm unsure if the same is true for clang
> 
> (It is really weird, I cannot find that original comment anywhere in the Github PR :-()
> 
> As far as I have been able to determine, -Wpedantic and -pedantic are aliases on gcc > 5, and the same is true for clang. -Wpedantic seems to be the preferred way nowadays.
> 
> `TOOLCHAIN_CFLAGS_JVM` is arguably if not wrong so at least not the best place to put `-permissive-`. `-Wpermissive` belongs with `-Wall -Wextra`.

TOOLCHAIN_CFLAGS_JVM and TOOLCHAIN_CFLAGS_JDK have, until now, been where the -Zc: conformance options are passed, which is why I recommended adding them there, to match what Visual C++ does at the moment. Maybe I have it the other way around, and it is Visual C++ that needs to be changed to match clang (Both for permissive- and -Zc: options)

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926925644

From mbaesken at openjdk.org  Mon Feb  5 12:51:08 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 5 Feb 2024 12:51:08 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
In-Reply-To: <eiwl1FO-3YoSQB5x7EQBtXhB-zwYy76syT4Mb9nS7oc=.4f41eb9f-9b1f-4685-bf08-83f3276d4295@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
 <eiwl1FO-3YoSQB5x7EQBtXhB-zwYy76syT4Mb9nS7oc=.4f41eb9f-9b1f-4685-bf08-83f3276d4295@github.com>
Message-ID: <_bDxv8SN2pD8KNWdhQ4SsTJMkbNyA2m9ERs87kg_yIk=.d76dcb5f-8f11-4515-ab0c-ceff66c09ffa@github.com>

On Mon, 5 Feb 2024 12:38:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> It seems like the statvfs64 is a pre-existing bug in AIX in that case. I have not removed any statvfs64 for AIX; all such changes are guarded by `#ifdef _ALLBSD_SOURCE`, which I presume is not defined on AIX.
> 
> I recommend that I push this PR as-is first, and then you can do a follow-up fix to define statvfs to statvfs64 on AIX.

Java_sun_nio_fs_UnixNativeDispatcher_statvfs0  is changed from statvfs64 to  statvfs,  did I miss  something ?

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926925394

From redestad at openjdk.org  Mon Feb  5 12:53:02 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 5 Feb 2024 12:53:02 GMT
Subject: RFR: 8321373: Build should use LC_ALL=C.UTF-8 [v3]
In-Reply-To: <9STA_Xf9xn0LpZJ-KF2KAVxKYIm4NnP0jIdKeBaBfRE=.2555eb46-e8a7-4f56-8815-ffe98d652470@github.com>
References: <9CbEPFCW69TrCZHAEYtPrOLDJdDyPN3NN6jjKzPhEv4=.e70c5204-28a4-4f42-814f-927dad42b8d4@github.com>
 <9STA_Xf9xn0LpZJ-KF2KAVxKYIm4NnP0jIdKeBaBfRE=.2555eb46-e8a7-4f56-8815-ffe98d652470@github.com>
Message-ID: <Z_wuIUalU-hNuXQ0ogwTL95Mq9sImkXeexSNYd1L6zc=.8693b4b8-e439-4b81-9323-56590f9f3546@github.com>

On Mon, 5 Feb 2024 10:38:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as their encoding of choice when they see this locale, but use an arbitrarily encoding, which might not properly handle all UTF-8 characters. Since in practice, all our encoding is utf8, we should tell our tools this as well.
>> 
>> This will at least have effect on how Java treats path names including unicode characters.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright year
>  - check for utf-8 first

I think the tradeoff here of explicitly loading `StandardCharsets` but not doing a lookup that triggers `StandardCharsets$Aliases` and a few others to load seem appropriate as it optimize for the recommended use pattern, while not penalizing too severely `Charset.forName`-based flows.

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

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16971#pullrequestreview-1862693331

From jwaters at openjdk.org  Mon Feb  5 13:03:01 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 5 Feb 2024 13:03:01 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang [v2]
In-Reply-To: <qja7u1WGpMGYvymUwKDAfovke8Kplizcby_j0hNN-r4=.9a3603e4-1446-4b57-9059-7553d21c64a1@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <qja7u1WGpMGYvymUwKDAfovke8Kplizcby_j0hNN-r4=.9a3603e4-1446-4b57-9059-7553d21c64a1@github.com>
Message-ID: <IhMaki_EsjbdLkNayWIt4eUI1RIE35hN8b5_OynLUp8=.3f8822b7-3c13-44aa-87c9-0e19f5241f83@github.com>

On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
>> 
>> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
>> 
>> 
>> #define DEBUG_ONLY(code) code;
>> 
>> DEBUG_ONLY(foo());
>> 
>> 
>> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   FIx dtrace build

The following is all that I was able to find, on the latest gcc docs. Nothing came up for clang for the search term "-pedantic vs -Wpedantic"

> -pedantic-errors
> Give an error whenever the base standard (see -Wpedantic) requires a diagnostic, in some cases where there is undefined behavior at compile-time and in some other cases that do not prevent compilation of programs that are valid according to the standard. This is not equivalent to -Werror=pedantic: the latter option is unlikely to be useful, as it only makes errors of the diagnostics that are controlled by -Wpedantic, whereas this option also affects required diagnostics that are always enabled or controlled by options other than -Wpedantic.

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926946873

From ihse at openjdk.org  Mon Feb  5 13:37:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 13:37:03 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang [v2]
In-Reply-To: <qja7u1WGpMGYvymUwKDAfovke8Kplizcby_j0hNN-r4=.9a3603e4-1446-4b57-9059-7553d21c64a1@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <qja7u1WGpMGYvymUwKDAfovke8Kplizcby_j0hNN-r4=.9a3603e4-1446-4b57-9059-7553d21c64a1@github.com>
Message-ID: <Y3TzQZUAOOWQsjCw9i2GXxJMXuDOof1UfTEMUmITvJI=.195faef2-abf1-4ff3-bd76-1194c77bb8b1@github.com>

On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
>> 
>> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
>> 
>> 
>> #define DEBUG_ONLY(code) code;
>> 
>> DEBUG_ONLY(foo());
>> 
>> 
>> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   FIx dtrace build

The split in different categories of flags is perhaps not perfect, and more a heuristic to help us manage them. However, I think we are talking about two different categories here. The `/Z` flags change the behavior of the compiler to be more standards compliant (similar to `-std=c++1` on gcc/clang). The `-Wpedantic" flag enables a batch of additional warnings on top of `-Wall` and `-Wextra`. The only way this makes it more "standards compliant" is that the standard requires the compiler to produce a warning in these situations. But that is not really why we want to turn it on; we want it to be able to catch bad or suboptimal code.

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1927025804

From erikj at openjdk.org  Mon Feb  5 13:38:02 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 5 Feb 2024 13:38:02 GMT
Subject: RFR: 8321373: Build should use LC_ALL=C.UTF-8 [v3]
In-Reply-To: <9STA_Xf9xn0LpZJ-KF2KAVxKYIm4NnP0jIdKeBaBfRE=.2555eb46-e8a7-4f56-8815-ffe98d652470@github.com>
References: <9CbEPFCW69TrCZHAEYtPrOLDJdDyPN3NN6jjKzPhEv4=.e70c5204-28a4-4f42-814f-927dad42b8d4@github.com>
 <9STA_Xf9xn0LpZJ-KF2KAVxKYIm4NnP0jIdKeBaBfRE=.2555eb46-e8a7-4f56-8815-ffe98d652470@github.com>
Message-ID: <5LhUf5BMFklA6kIbjdUi3Tbmppq3rIwTY3txR4YMKNs=.ecd9cf41-fbf9-4ca1-9217-6e627c573c61@github.com>

On Mon, 5 Feb 2024 10:38:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as their encoding of choice when they see this locale, but use an arbitrarily encoding, which might not properly handle all UTF-8 characters. Since in practice, all our encoding is utf8, we should tell our tools this as well.
>> 
>> This will at least have effect on how Java treats path names including unicode characters.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright year
>  - check for utf-8 first

Marked as reviewed by erikj (Reviewer).

make/autoconf/basic.m4 line 136:

> 134:     fi
> 135:   else
> 136:       AC_MSG_WARN([locale command not not found, using C locale])

Inconsistent indentation here.

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

PR Review: https://git.openjdk.org/jdk/pull/16971#pullrequestreview-1862818344
PR Review Comment: https://git.openjdk.org/jdk/pull/16971#discussion_r1478262965

From ihse at openjdk.org  Mon Feb  5 13:58:08 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 13:58:08 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
In-Reply-To: <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
Message-ID: <TCmXJMHj7JcdTcRmkNAKGYVej2DAzcZRZ4gCw9ddO0w=.9ffcc054-4ec9-401a-ac9c-44941ae576ec@github.com>

On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add kludge to BufferedRenderPipe.c for AIX

RIght, my bad. I apologize, you are completely correct, I turned the defines around in my head. I will add a redefine for AIX that turns  statvfs into  statvfs64. Thanks for noticing!

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1927065583

From ihse at openjdk.org  Mon Feb  5 14:06:21 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 14:06:21 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v8]
In-Reply-To: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
Message-ID: <DsX5YWCbdiDy_c9BfxEuic9eO1QqgPzYZ7Pqgh28TvI=.18af62dc-ee26-43c6-be92-4adda72662e5@github.com>

> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Redefine statvfs as statvfs64 on AIX

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17538/files
  - new: https://git.openjdk.org/jdk/pull/17538/files/3c404183..2de377cd

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

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

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

From ihse at openjdk.org  Mon Feb  5 14:06:21 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 14:06:21 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
In-Reply-To: <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
Message-ID: <js04r6dJGMDL_c1dfpNEGvhDD53Y1H2JRCJxtJ7Xtjs=.d1b19610-206b-4809-a559-842c69f90f59@github.com>

On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add kludge to BufferedRenderPipe.c for AIX

I hope finally the AIX part of this PR is done.

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1927082091

From ihse at openjdk.org  Mon Feb  5 14:09:29 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 14:09:29 GMT
Subject: RFR: 8321373: Build should use LC_ALL=C.UTF-8 [v4]
In-Reply-To: <9CbEPFCW69TrCZHAEYtPrOLDJdDyPN3NN6jjKzPhEv4=.e70c5204-28a4-4f42-814f-927dad42b8d4@github.com>
References: <9CbEPFCW69TrCZHAEYtPrOLDJdDyPN3NN6jjKzPhEv4=.e70c5204-28a4-4f42-814f-927dad42b8d4@github.com>
Message-ID: <E3Qz9a3CxQLZ4eNfFcRW8n6TttorpQY1QZwiDQnOHaQ=.4e622bb2-cac5-4b1c-9123-7e192dcb6f87@github.com>

> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as their encoding of choice when they see this locale, but use an arbitrarily encoding, which might not properly handle all UTF-8 characters. Since in practice, all our encoding is utf8, we should tell our tools this as well.
> 
> This will at least have effect on how Java treats path names including unicode characters.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix bad indentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16971/files
  - new: https://git.openjdk.org/jdk/pull/16971/files/c09bc9b1..bf9530f0

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

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

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

From ihse at openjdk.org  Mon Feb  5 14:09:30 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 14:09:30 GMT
Subject: Integrated: 8321373: Build should use LC_ALL=C.UTF-8
In-Reply-To: <9CbEPFCW69TrCZHAEYtPrOLDJdDyPN3NN6jjKzPhEv4=.e70c5204-28a4-4f42-814f-927dad42b8d4@github.com>
References: <9CbEPFCW69TrCZHAEYtPrOLDJdDyPN3NN6jjKzPhEv4=.e70c5204-28a4-4f42-814f-927dad42b8d4@github.com>
Message-ID: <EDmNlFNOUhGcmYryuee9JxvRnU6w8rWKz_j0hh1PyyA=.33a2ee06-db88-4ef0-8d82-6fd45fea5740@github.com>

On Tue, 5 Dec 2023 10:35:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as their encoding of choice when they see this locale, but use an arbitrarily encoding, which might not properly handle all UTF-8 characters. Since in practice, all our encoding is utf8, we should tell our tools this as well.
> 
> This will at least have effect on how Java treats path names including unicode characters.

This pull request has now been integrated.

Changeset: d395ac28
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d395ac287900f2c22739751e39831dea8a189b5c
Stats:     26 lines in 4 files changed: 20 ins; 0 del; 6 mod

8321373: Build should use LC_ALL=C.UTF-8

Reviewed-by: redestad, erikj

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

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

From mbaesken at openjdk.org  Mon Feb  5 14:18:08 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 5 Feb 2024 14:18:08 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
In-Reply-To: <js04r6dJGMDL_c1dfpNEGvhDD53Y1H2JRCJxtJ7Xtjs=.d1b19610-206b-4809-a559-842c69f90f59@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
 <js04r6dJGMDL_c1dfpNEGvhDD53Y1H2JRCJxtJ7Xtjs=.d1b19610-206b-4809-a559-842c69f90f59@github.com>
Message-ID: <tWCBjZIzUFDJxIec37zQeyB3LjUHXIy0NpFDMpTf5-Q=.71f4ada6-3dda-4f0d-8ecf-178c154eb1c3@github.com>

On Mon, 5 Feb 2024 14:03:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I hope finally the AIX part of this PR is done.

Thanks for the AIX related effort ; I put it again into our internal build/test queue.

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1927105669

From kbarrett at openjdk.org  Mon Feb  5 14:59:03 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 5 Feb 2024 14:59:03 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang
In-Reply-To: <5YoWExp50qGIjilv-9yq38jGsb3Fw7MJCQ8Sfc3Wp3c=.189956da-6f76-4723-9d4a-11d20b43eeb4@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <5YoWExp50qGIjilv-9yq38jGsb3Fw7MJCQ8Sfc3Wp3c=.189956da-6f76-4723-9d4a-11d20b43eeb4@github.com>
Message-ID: <3AE9BcnKj566JJ4k4SyxWqOHcG-WBmg3IvuM2LRS1zk=.49557d58-19ce-41f6-88fc-8042e184f380@github.com>

On Mon, 5 Feb 2024 03:21:35 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
>> 
>> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
>> 
>> 
>> #define DEBUG_ONLY(code) code;
>> 
>> DEBUG_ONLY(foo());
>> 
>> 
>> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.
>
>> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
> 
> Rather than first turning on pedantic warnings and then (maybe) going back and perhaps fixing things, I'd really prefer
> things be done in the other order.  (That's how I handled the recent `-Wparentheses` changes, for example.)

> @kimbarrett quoting the gcc maintainers
> 
> > Yes because the C++ defect report was only for `Spurious semicolons at namespace scope should be allowed`.  See https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#569 .
> > ```
> > struct f
> > {
> >   int t;  ;
> > };
> > ```
> >   
> > Is not allowed by the C++ standard currently and is a GCC extension, maybe it should have a seperate flag to control that but I am not 100% sure.

That's incorrect, and I've replied in the gcc bug.  C++14 added "empty-declaration" to "member-declaration" (C++ 9.2).

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1927189316

From erikj at openjdk.org  Mon Feb  5 15:12:01 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 5 Feb 2024 15:12:01 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <qpu0rr5ib5ZvRO6hylKRD5KO0rfmUO1gNNemxhXv-eU=.dfc31d2c-4623-4a51-8234-c1858b792cb8@github.com>

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1863050713

From kim.barrett at oracle.com  Mon Feb  5 15:30:02 2024
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 5 Feb 2024 15:30:02 +0000
Subject: RFR: 8325163: Enable -Wpedantic on clang
In-Reply-To: <av9NYmZfXrVqn3TdmebHc2SIirRzB9byNRJwdZQ9Nrc=.0240dede-4aae-4529-9b62-17476c89bf62@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <5YoWExp50qGIjilv-9yq38jGsb3Fw7MJCQ8Sfc3Wp3c=.189956da-6f76-4723-9d4a-11d20b43eeb4@github.com>
 <av9NYmZfXrVqn3TdmebHc2SIirRzB9byNRJwdZQ9Nrc=.0240dede-4aae-4529-9b62-17476c89bf62@github.com>
Message-ID: <1AD04C4D-E8E0-461B-99E4-0FDABBF48F4D@oracle.com>

> On Feb 5, 2024, at 4:31 AM, Magnus Ihse Bursie <ihse at openjdk.org> wrote:
> 
> On Mon, 5 Feb 2024 03:21:35 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
> 
>>> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
>>> 
>>> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
>>> 
>>> 
>>> #define DEBUG_ONLY(code) code;
>>> 
>>> DEBUG_ONLY(foo());
>>> 
>>> 
>>> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.
>> 
>>> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
>> 
>> Rather than first turning on pedantic warnings and then (maybe) going back and perhaps fixing things, I'd really prefer
>> things be done in the other order.  (That's how I handled the recent `-Wparentheses` changes, for example.)
> 
> @kimbarrett
>> Rather than first turning on pedantic warnings and then (maybe) going back and perhaps fixing things, I'd really prefer
> things be done in the other order.
> 
> I hear what you are saying, but I respectfully disagree. If we do things in the order you suggest, the global flag cannot be turned on until all component teams have fixed their source code. That essentially makes the most overworked group putting an effective veto to this change (when your workload is too high, fixing warnings is not on top of your priority.) In contrast, if the global warning can be turned on now, it will have a positive effect on all new and modified code from now on. And the teams can work on their individual warnings, and remove them in their own time.

Without knowing what the actual warnings are that are being triggered and then
suppressed, I can't even begin to evaluate this change. Not all warnings are
good and useful. Sometimes the avoidance effort is really not worth the
benefit. Sometimes there is a future change to the Standard that is already
supported as an extension. Sometimes there is a widely supported extension
that has perhaps just not yet made it into the Standard. Sometimes
platform-specific code uses platform-specific extensions.  And so on.

Enabling -Wpedantic requires an evaluation of the costs and benefits and a
decision that there's a good tradeoff there.  So far, this PR doesn't do that.
Fixing the warnings first, or at least having the relevant bug reports, would
provide that information.

> This is the same method I used for turning on -Wall and -Wextra. Some teams are very eager to fix warnings, and others still have almost all their "DISABLED_WARNINGS" left several years later. (I will not mention any names; you both know who you are ;-)). If I had followed the route you suggest, we would not have -Wall -Wextra on all source code (sans a few, marked files) now.

For -Wparentheses I took the opposite approach and fixed all occurrences
(finding and fixing a couple of bugs in the process) before enabling them.
We've also been approaching -Wconversion from that direction. I think the
enabled but then suppressed warnings has led to an out-of-sight out-of-mind
situation for the suppressed warnings.

I was not particularly happy with adding -Wextra, for example, because I think
some of the warnings it triggers are questionable. You and I went through a
very similar discussion for enabling that option for HotSpot. Right now I
don't even have the information needed for such a discussion.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240205/c2b799b1/signature.asc>

From kbarrett at openjdk.org  Mon Feb  5 15:45:02 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 5 Feb 2024 15:45:02 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang
In-Reply-To: <nsuairR0HSKFR8E3n0ny2zD5MXkPwNr2rHFfVih3bGA=.dc657db7-0c9c-4887-9afa-343298c479e2@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <C8lvIkaCHYs8JdS0Cj_z6GPbMXO4OcT3zSBsQpg0Ubs=.88065bcc-6755-4925-912d-8eb49f4b56a6@github.com>
 <nsuairR0HSKFR8E3n0ny2zD5MXkPwNr2rHFfVih3bGA=.dc657db7-0c9c-4887-9afa-343298c479e2@github.com>
Message-ID: <NRzLUnCAsLbFSN-wKACB1sRqpehQyPO1ZkUupSMDpVk=.b38b13b4-d5a2-452d-b663-cea7d1dfdceb@github.com>

On Mon, 5 Feb 2024 06:15:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > I consider the "format '%p' expects argument of type 'void*" warnings to be not at all helpful. Fortunately we don't use '%p' in HotSpot,
> 
> We do use it in hotspot. Not a huge amount as we have the legacy format specifiers for PTR_FORMAT etc.

You are correct, we do use "%p" a fair amount (107 lines today).

I thought we didn't, because we were instead supposed to use INTPTR_FORMAT and
the (currently?) equivalent PTR_FORMAT. Those macros aren't legacy, they are
to provide consistent output across platforms. "%p" provides implementation
defined output. For example, if I remember correctly, gcc "%p" prints "(null)"
for nullptr, with no mechanism (such as a conversion flag) to control that. If
you are printing a table of pointers, and you expect only numeric values
because you are going to be processing the table or copying it into a
spreadsheet or the like, that gcc-specific behavior isn't very helpful.

Instead, we're "supposed" to use the `p2i` function and PTR_FORMAT for
printing pointers, to get the same output on all platforms. That idiom also
avoids the not very helpful -Wpedantic warnings.

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1927288508

From kbarrett at openjdk.org  Mon Feb  5 15:50:04 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 5 Feb 2024 15:50:04 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang
In-Reply-To: <NRzLUnCAsLbFSN-wKACB1sRqpehQyPO1ZkUupSMDpVk=.b38b13b4-d5a2-452d-b663-cea7d1dfdceb@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <C8lvIkaCHYs8JdS0Cj_z6GPbMXO4OcT3zSBsQpg0Ubs=.88065bcc-6755-4925-912d-8eb49f4b56a6@github.com>
 <nsuairR0HSKFR8E3n0ny2zD5MXkPwNr2rHFfVih3bGA=.dc657db7-0c9c-4887-9afa-343298c479e2@github.com>
 <NRzLUnCAsLbFSN-wKACB1sRqpehQyPO1ZkUupSMDpVk=.b38b13b4-d5a2-452d-b663-cea7d1dfdceb@github.com>
Message-ID: <B8sZJtSlZvlr53ur8NikKEidzYLU_abm8B8vRqBIVaM=.99fc9787-0482-4f2e-8754-c3648b6501a8@github.com>

On Mon, 5 Feb 2024 15:42:40 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>>> I consider the "format '%p' expects argument of type 'void*" warnings to be not at all helpful. Fortunately we don't use '%p' in HotSpot,
>> 
>> We do use it in hotspot. Not a huge amount as we have the legacy format specifiers for PTR_FORMAT etc.
>
>> > I consider the "format '%p' expects argument of type 'void*" warnings to be not at all helpful. Fortunately we don't use '%p' in HotSpot,
>> 
>> We do use it in hotspot. Not a huge amount as we have the legacy format specifiers for PTR_FORMAT etc.
> 
> You are correct, we do use "%p" a fair amount (107 lines today).
> 
> I thought we didn't, because we were instead supposed to use INTPTR_FORMAT and
> the (currently?) equivalent PTR_FORMAT. Those macros aren't legacy, they are
> to provide consistent output across platforms. "%p" provides implementation
> defined output. For example, if I remember correctly, gcc "%p" prints "(null)"
> for nullptr, with no mechanism (such as a conversion flag) to control that. If
> you are printing a table of pointers, and you expect only numeric values
> because you are going to be processing the table or copying it into a
> spreadsheet or the like, that gcc-specific behavior isn't very helpful.
> 
> Instead, we're "supposed" to use the `p2i` function and PTR_FORMAT for
> printing pointers, to get the same output on all platforms. That idiom also
> avoids the not very helpful -Wpedantic warnings.

> > @kimbarrett quoting the gcc maintainers
> > > Yes because the C++ defect report was only for `Spurious semicolons at namespace scope should be allowed`.  See https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#569 .
> > > ```
> > > struct f
> > > {
> > >   int t;  ;
> > > };
> > > ```
> > > 
> > > 
> > >     
> > >       
> > >     
> > > 
> > >       
> > >     
> > > 
> > >     
> > >   
> > > Is not allowed by the C++ standard currently and is a GCC extension, maybe it should have a seperate flag to control that but I am not 100% sure.
> 
> That's incorrect, and I've replied in the gcc bug. C++14 added "empty-declaration" to "member-declaration" (C++ 9.2).

With my additional information the gcc bug has now been confirmed.

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1927299264

From jwaters at openjdk.org  Mon Feb  5 16:03:02 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 5 Feb 2024 16:03:02 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang [v2]
In-Reply-To: <qja7u1WGpMGYvymUwKDAfovke8Kplizcby_j0hNN-r4=.9a3603e4-1446-4b57-9059-7553d21c64a1@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <qja7u1WGpMGYvymUwKDAfovke8Kplizcby_j0hNN-r4=.9a3603e4-1446-4b57-9059-7553d21c64a1@github.com>
Message-ID: <erwEm5JCAlU2d1pU2MpIyZPAEbVjiy0zaDrgDrehxYo=.2b91b514-4c5b-4510-b648-b4735ed4c26d@github.com>

On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
>> 
>> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
>> 
>> 
>> #define DEBUG_ONLY(code) code;
>> 
>> DEBUG_ONLY(foo());
>> 
>> 
>> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   FIx dtrace build

I can't seem to find the post now but there was one mentioning about needing information on what warnings -Wpedantic enables, and well... It's quite a lot: https://clang.llvm.org/docs/DiagnosticsReference.html#wpedantic

I also have Jonathan Wakely's confirmation that -pedantic and -Wpedantic aren't the same, but this may not be as relevant to the discussion at hand

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1927325037

From ihse at openjdk.org  Mon Feb  5 16:16:05 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 16:16:05 GMT
Subject: Withdrawn: 8325176: Compiling native tests with clang on linux fails
In-Reply-To: <f292-EONfatu-W5cFpJrEDgOJtde3FjAwceBS7QI_GE=.4f28b292-e052-4066-bbcb-9196ccd66ec3@github.com>
References: <f292-EONfatu-W5cFpJrEDgOJtde3FjAwceBS7QI_GE=.4f28b292-e052-4066-bbcb-9196ccd66ec3@github.com>
Message-ID: <s3E0pInKyuHLQMNLG5GusendNmGp0aIIjiP2S1XYJkg=.f92e23f5-c881-4077-b48b-4721a88e3493@github.com>

On Fri, 2 Feb 2024 15:27:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> While we do not have automatic testing of using clang instead of gcc on linux, we try to keep it in working condition. This is still the case for the JDK itself, but there is a native test which fails to compile with clang. This should be fixed.

This pull request has been closed without being integrated.

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

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

From ihse at openjdk.org  Mon Feb  5 16:23:02 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 16:23:02 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang [v2]
In-Reply-To: <qja7u1WGpMGYvymUwKDAfovke8Kplizcby_j0hNN-r4=.9a3603e4-1446-4b57-9059-7553d21c64a1@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <qja7u1WGpMGYvymUwKDAfovke8Kplizcby_j0hNN-r4=.9a3603e4-1446-4b57-9059-7553d21c64a1@github.com>
Message-ID: <sbGt9DRjpCUi5Hjr2AYQDnbLThuL-f9t7KS8MbwJwno=.2a24b7b9-e3c0-4a01-b453-2a6365b8b589@github.com>

On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
>> 
>> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
>> 
>> 
>> #define DEBUG_ONLY(code) code;
>> 
>> DEBUG_ONLY(foo());
>> 
>> 
>> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   FIx dtrace build

This PR triggered a lot of discussion about C++ standards, gcc behavior, and possible breaches of coding standards in Hotspot -- but not a lot of discussion about the actual content of the PR.

Is there anything in this proposed PR that you gentlemen disagree with or object to? Or is this fine to push as a step in our ongoing pursuit of increasing the code quality, that can (and will) be followed by many more?

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1927365995

From jwaters at openjdk.org  Mon Feb  5 16:36:04 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 5 Feb 2024 16:36:04 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang [v2]
In-Reply-To: <qja7u1WGpMGYvymUwKDAfovke8Kplizcby_j0hNN-r4=.9a3603e4-1446-4b57-9059-7553d21c64a1@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <qja7u1WGpMGYvymUwKDAfovke8Kplizcby_j0hNN-r4=.9a3603e4-1446-4b57-9059-7553d21c64a1@github.com>
Message-ID: <yhqjA9w2TOoEglYybqlIflueNWEbNbjCK0JdJAMRDRE=.9f1ff367-2696-420b-867b-e88d5c5a4ec1@github.com>

On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
>> 
>> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
>> 
>> 
>> #define DEBUG_ONLY(code) code;
>> 
>> DEBUG_ONLY(foo());
>> 
>> 
>> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   FIx dtrace build

No objections from me, though I still think -pedantic -Wpedantic should be placed where Visual Studio currently places -permissive- for HotSpot

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17687#pullrequestreview-1863251939

From smarks at openjdk.org  Mon Feb  5 23:49:52 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 5 Feb 2024 23:49:52 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <3ItCUEGtxTObo5TxNsOIPfMr15fWdQPm3CAi7eNcOv4=.506a52bb-ad1a-429a-9906-5ae1dccfdad2@github.com>

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

Changes in java.util and java.util.concurrent look fine.

There are a startling number of places where `this` is potentially leaked to a subclass. It would be interesting to analyze the pathologies and have a discussion of potential fixes. There may also be compatibility issues with potential fixes (nothing in this PR that I can see) because the behavior can change from the point of view of subclasses.

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

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1863853251

From darcy at openjdk.org  Mon Feb  5 23:49:58 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 5 Feb 2024 23:49:58 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <J4KsMc172dHXeWHKTJcglHhIp5QhcpSTw8hGdAwrzLc=.03bb7f31-d5e5-4b6d-9e44-4e86e96746c9@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
 <J4KsMc172dHXeWHKTJcglHhIp5QhcpSTw8hGdAwrzLc=.03bb7f31-d5e5-4b6d-9e44-4e86e96746c9@github.com>
Message-ID: <fE8yWz13Mf_WGqTZ1gE7MpJespk8nc06W-xVbWXeZVA=.d63183bb-fddc-47f2-8ff4-1258c10d7337@github.com>

On Fri, 2 Feb 2024 23:38:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> In its initial form, the changes are tested on Linux. Later on, I'll do cross-platform builds to make sure there aren't any, say, windows-specific changes that are needed as well.
> 
> I can file a follow-up umbrella bug with the original list of ~200 warnings so the constructors and initializers in question can be examined to see if they should be updated.

Filed [JDK-8325263](https://bugs.openjdk.org/browse/JDK-8325263) .

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

PR Comment: https://git.openjdk.org/jdk/pull/17692#issuecomment-1928049947

From kbarrett at openjdk.org  Mon Feb  5 23:50:01 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 5 Feb 2024 23:50:01 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang [v2]
In-Reply-To: <sbGt9DRjpCUi5Hjr2AYQDnbLThuL-f9t7KS8MbwJwno=.2a24b7b9-e3c0-4a01-b453-2a6365b8b589@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <qja7u1WGpMGYvymUwKDAfovke8Kplizcby_j0hNN-r4=.9a3603e4-1446-4b57-9059-7553d21c64a1@github.com>
 <sbGt9DRjpCUi5Hjr2AYQDnbLThuL-f9t7KS8MbwJwno=.2a24b7b9-e3c0-4a01-b453-2a6365b8b589@github.com>
Message-ID: <cp7ejjA5gOya2cjQJLc8P0oaYOo6DkWTzN43DFc96IQ=.3bbd131f-2af8-4582-8730-f66b0ca3a5bd@github.com>

On Mon, 5 Feb 2024 16:19:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Is there anything in this proposed PR that you gentlemen disagree with or object to? Or is this fine to push as a step in our ongoing pursuit of increasing the code quality, that can (and will) be followed by many more?

Yes.  As I said earlier:
"Without knowing what the actual warnings are that are being triggered and then
suppressed, I can't even begin to evaluate this change."

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1928006901

From naoto at openjdk.org  Mon Feb  5 23:49:48 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 5 Feb 2024 23:49:48 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <SZHlwkWLaMVo8BYNpOoPoaiQpxadXA3LfEfG219Hp-o=.5e93abfb-bd13-4b72-8dd6-4fa5a41fce8c@github.com>

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1863359999

From ihse at openjdk.org  Mon Feb  5 23:50:13 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 23:50:13 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang [v2]
In-Reply-To: <qja7u1WGpMGYvymUwKDAfovke8Kplizcby_j0hNN-r4=.9a3603e4-1446-4b57-9059-7553d21c64a1@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <qja7u1WGpMGYvymUwKDAfovke8Kplizcby_j0hNN-r4=.9a3603e4-1446-4b57-9059-7553d21c64a1@github.com>
Message-ID: <56uYGhLCcDFBfuEV2TpDDYcOzLjBtKKerH03q-L_wlk=.37ca1c75-45e9-42ad-af40-7cfb34c77725@github.com>

On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
>> 
>> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
>> 
>> 
>> #define DEBUG_ONLY(code) code;
>> 
>> DEBUG_ONLY(foo());
>> 
>> 
>> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   FIx dtrace build

Here is the full list: https://clang.llvm.org/docs/DiagnosticsReference.html#wpedantic

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1928141600

From darcy at openjdk.org  Mon Feb  5 23:51:06 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 5 Feb 2024 23:51:06 GMT
Subject: RFR: JDK-8325266: Enable this-escape javac warning in jdk.javadoc
Message-ID: <sw0NYBCtIyeNjVJYL9ksn-3kneWSy1HQoXHBhIhW51U=.31559504-63e8-46df-b625-3b6df8ebc435@github.com>

The jdk.javadoc module doesn't need the this-escape warning disabled to build; it should be enabled.

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

Commit messages:
 - JDK-8325266: Enable this-escape javac warning in jdk.javadoc

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

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

From jjg at openjdk.org  Mon Feb  5 23:51:11 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 5 Feb 2024 23:51:11 GMT
Subject: RFR: JDK-8325266: Enable this-escape javac warning in jdk.javadoc
In-Reply-To: <sw0NYBCtIyeNjVJYL9ksn-3kneWSy1HQoXHBhIhW51U=.31559504-63e8-46df-b625-3b6df8ebc435@github.com>
References: <sw0NYBCtIyeNjVJYL9ksn-3kneWSy1HQoXHBhIhW51U=.31559504-63e8-46df-b625-3b6df8ebc435@github.com>
Message-ID: <Yzx5VQXmTZrOulkgKbG-mXueVKunu-Hk0OJ_QOyCjT4=.a4cc24ef-8c3e-48ce-b5ff-749a88e00a24@github.com>

On Mon, 5 Feb 2024 21:03:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The jdk.javadoc module doesn't need the this-escape warning disabled to build; it should be enabled.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17715#pullrequestreview-1863818840

From duke at openjdk.org  Mon Feb  5 23:58:33 2024
From: duke at openjdk.org (duke)
Date: Mon, 5 Feb 2024 23:58:33 GMT
Subject: Withdrawn: 8312425: [vectorapi] AArch64: Optimize vector math
 operations with SLEEF
In-Reply-To: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
Message-ID: <C13TewWQ_H-Jq44YTNJbvNHU3rHmzz0FR9sAMHsnbZQ=.568298f5-82a2-4a88-9444-c64477af020d@github.com>

On Wed, 18 Oct 2023 06:12:29 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
> 
> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
> 
> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
> 
> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
> 
> [1] https://github.com/openjdk/jdk/pull/3638
> [2] https://sleef.org/
> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
> [4] https://packages.debian.org/bookworm/libsleef3
> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html

This pull request has been closed without being integrated.

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

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

From erikj at openjdk.org  Tue Feb  6 00:12:31 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 6 Feb 2024 00:12:31 GMT
Subject: RFR: JDK-8325266: Enable this-escape javac warning in jdk.javadoc
In-Reply-To: <sw0NYBCtIyeNjVJYL9ksn-3kneWSy1HQoXHBhIhW51U=.31559504-63e8-46df-b625-3b6df8ebc435@github.com>
References: <sw0NYBCtIyeNjVJYL9ksn-3kneWSy1HQoXHBhIhW51U=.31559504-63e8-46df-b625-3b6df8ebc435@github.com>
Message-ID: <2RBCWUh4TAYCWYPmIJObp0T7kdm3Q-tSnUYlFgoSSNw=.814b03d0-5663-42d4-9522-0d84fca8be0f@github.com>

On Mon, 5 Feb 2024 21:03:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The jdk.javadoc module doesn't need the this-escape warning disabled to build; it should be enabled.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17715#pullrequestreview-1864049267

From jwilhelm at openjdk.org  Tue Feb  6 00:18:30 2024
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 6 Feb 2024 00:18:30 GMT
Subject: [jdk22] RFR: 8319547: Remove EA from the JDK 22 version string with
 first RC promotion
Message-ID: <9AeSUk-soL8IoiraIuDUjYSTkCI-9vm0WjR9Tn9S_Ys=.30c84b29-d321-40a5-9e65-578197c17a6d@github.com>

Removed ea from the version string

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

Commit messages:
 - 8319547: Remove EA from the JDK 22 version string with first RC promotion

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

PR: https://git.openjdk.org/jdk22/pull/106

From mikael at openjdk.org  Tue Feb  6 00:24:02 2024
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 6 Feb 2024 00:24:02 GMT
Subject: [jdk22] RFR: 8319547: Remove EA from the JDK 22 version string
 with first RC promotion
In-Reply-To: <9AeSUk-soL8IoiraIuDUjYSTkCI-9vm0WjR9Tn9S_Ys=.30c84b29-d321-40a5-9e65-578197c17a6d@github.com>
References: <9AeSUk-soL8IoiraIuDUjYSTkCI-9vm0WjR9Tn9S_Ys=.30c84b29-d321-40a5-9e65-578197c17a6d@github.com>
Message-ID: <5TodDceqYt1pXHPrkf7tK7qfRFHpDfReaGw0j5voeUk=.213a52ed-cb3f-4238-ad75-ccd98bb2394d@github.com>

On Tue, 6 Feb 2024 00:14:40 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Removed ea from the version string

Marked as reviewed by mikael (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/106#pullrequestreview-1864071852

From jwilhelm at openjdk.org  Tue Feb  6 00:24:03 2024
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 6 Feb 2024 00:24:03 GMT
Subject: [jdk22] Integrated: 8319547: Remove EA from the JDK 22 version string
 with first RC promotion
In-Reply-To: <9AeSUk-soL8IoiraIuDUjYSTkCI-9vm0WjR9Tn9S_Ys=.30c84b29-d321-40a5-9e65-578197c17a6d@github.com>
References: <9AeSUk-soL8IoiraIuDUjYSTkCI-9vm0WjR9Tn9S_Ys=.30c84b29-d321-40a5-9e65-578197c17a6d@github.com>
Message-ID: <zhxnDPV3i9OG3RomheMQQr0dnMZ1cNOepegsJIMtvxs=.96799cdc-3d52-4934-bb77-5cda27f97373@github.com>

On Tue, 6 Feb 2024 00:14:40 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Removed ea from the version string

This pull request has now been integrated.

Changeset: bff5e903
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/bff5e903591276b4c9bdb2714370931d31598579
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8319547: Remove EA from the JDK 22 version string with first RC promotion

Reviewed-by: mikael

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

PR: https://git.openjdk.org/jdk22/pull/106

From jjg at openjdk.org  Tue Feb  6 01:36:58 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 6 Feb 2024 01:36:58 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v18]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <RIP-4xQbHyEjoPx-PHy-YFMYjq5xq1pjV5SCdVWbQNo=.c6fa9a51-39c3-4ef9-bfe9-1382b9bc016f@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  First pass at remove DocCommentTransformer from the public API.
  
  It is still declared internally, and installed by default, using the service-provider mechanism.
  If the standard impl is not available, an identity transformer is used.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/f086aaab..203532b2

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

  Stats: 191 lines in 11 files changed: 89 ins; 90 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/16388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388

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

From darcy at openjdk.org  Tue Feb  6 02:13:56 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Feb 2024 02:13:56 GMT
Subject: Integrated: JDK-8325266: Enable this-escape javac warning in
 jdk.javadoc
In-Reply-To: <sw0NYBCtIyeNjVJYL9ksn-3kneWSy1HQoXHBhIhW51U=.31559504-63e8-46df-b625-3b6df8ebc435@github.com>
References: <sw0NYBCtIyeNjVJYL9ksn-3kneWSy1HQoXHBhIhW51U=.31559504-63e8-46df-b625-3b6df8ebc435@github.com>
Message-ID: <jgY3YkUfQoXbMAsSOJRl6k1S2Vyxbn-K9oJCFz8Q7qE=.c02f7abe-6122-475f-986a-ee656025633a@github.com>

On Mon, 5 Feb 2024 21:03:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The jdk.javadoc module doesn't need the this-escape warning disabled to build; it should be enabled.

This pull request has now been integrated.

Changeset: 729ae1d7
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/729ae1d78716a3830837e49376b5340eb60f9449
Stats:     3 lines in 1 file changed: 0 ins; 2 del; 1 mod

8325266: Enable this-escape javac warning in jdk.javadoc

Reviewed-by: jjg, erikj

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

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

From darcy at openjdk.org  Tue Feb  6 02:33:46 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Feb 2024 02:33:46 GMT
Subject: RFR: JDK-8325268: Add policy statement to langtools makefiles
 concerning warnings
Message-ID: <SDIA7FXQnkrauJHNBE5Ziz5YoRkEdYi5TTUZSKDAiYo=.85170a59-a6aa-4940-b5ad-3cdcdac8d6ab@github.com>

Add policy statement about lint warnings to various langtools modules.

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

Commit messages:
 - JDK-8325268: Add policy statement to langtools makefiles concerning warnings

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

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

From dholmes at openjdk.org  Tue Feb  6 05:33:29 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 6 Feb 2024 05:33:29 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang
In-Reply-To: <NRzLUnCAsLbFSN-wKACB1sRqpehQyPO1ZkUupSMDpVk=.b38b13b4-d5a2-452d-b663-cea7d1dfdceb@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <C8lvIkaCHYs8JdS0Cj_z6GPbMXO4OcT3zSBsQpg0Ubs=.88065bcc-6755-4925-912d-8eb49f4b56a6@github.com>
 <nsuairR0HSKFR8E3n0ny2zD5MXkPwNr2rHFfVih3bGA=.dc657db7-0c9c-4887-9afa-343298c479e2@github.com>
 <NRzLUnCAsLbFSN-wKACB1sRqpehQyPO1ZkUupSMDpVk=.b38b13b4-d5a2-452d-b663-cea7d1dfdceb@github.com>
Message-ID: <CnxszRtILpIuCxuGTZd_1x2ifgKoWWsYaIEkId5RICc=.b658380c-6827-4a65-b6a9-d766d1d5c1a3@github.com>

On Mon, 5 Feb 2024 15:42:40 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> I thought we didn't, because we were instead supposed to use INTPTR_FORMAT and
the (currently?) equivalent PTR_FORMAT. Those macros aren't legacy, they are
to provide consistent output across platforms. "%p" provides implementation
defined output. 

My understanding/recollection was that those issues with `%p` had gone away and so we could start using it.

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1928814503

From dholmes at openjdk.org  Tue Feb  6 05:47:59 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 6 Feb 2024 05:47:59 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang [v2]
In-Reply-To: <qja7u1WGpMGYvymUwKDAfovke8Kplizcby_j0hNN-r4=.9a3603e4-1446-4b57-9059-7553d21c64a1@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <qja7u1WGpMGYvymUwKDAfovke8Kplizcby_j0hNN-r4=.9a3603e4-1446-4b57-9059-7553d21c64a1@github.com>
Message-ID: <eICfvROwlykrmsq8G794QKX0IA_MP9s2xAc2XJKFekY=.88919c65-9b20-430a-a1da-f6263ea4e7ee@github.com>

On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
>> 
>> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
>> 
>> 
>> #define DEBUG_ONLY(code) code;
>> 
>> DEBUG_ONLY(foo());
>> 
>> 
>> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   FIx dtrace build

I think given the warnings have been enabled globally, but disabled locally where they cause build failures, and JBS issues will be filed for each of those special cases, then this is a reasonable change to make. It is then up to component teams to fix code where applicable, and enable disabled warnings in the future.

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1928824757

From mdoerr at openjdk.org  Tue Feb  6 07:01:00 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 6 Feb 2024 07:01:00 GMT
Subject: Integrated: 8325213: Flags introduced by configure script are not
 passed to ADLC build
In-Reply-To: <6cK72nd6uq2D_R-oBmQ5B3nEzr2V25F3tyXYta1BDEI=.75499f03-9a3e-4b0b-9126-d4ec4cfe87e8@github.com>
References: <6cK72nd6uq2D_R-oBmQ5B3nEzr2V25F3tyXYta1BDEI=.75499f03-9a3e-4b0b-9126-d4ec4cfe87e8@github.com>
Message-ID: <XDz87YZRWbHPK7M5A7TZblyT9Co0ttl9LTjEWzvo3Ks=.2b1034be-c4f4-4e29-930d-8637f21e09f7@github.com>

On Mon, 5 Feb 2024 08:26:55 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> A trivial ADLC build fix. The ADLC_LANGSTD_CXXFLAGS should get passed.

This pull request has now been integrated.

Changeset: 9ee9f288
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9ee9f288497268d64ddd48783ecb68f7e5426084
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8325213: Flags introduced by configure script are not passed to ADLC build

Reviewed-by: jwaters, ihse

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

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

From mdoerr at openjdk.org  Tue Feb  6 07:01:00 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 6 Feb 2024 07:01:00 GMT
Subject: RFR: 8325213: Flags introduced by configure script are not passed
 to ADLC build
In-Reply-To: <6cK72nd6uq2D_R-oBmQ5B3nEzr2V25F3tyXYta1BDEI=.75499f03-9a3e-4b0b-9126-d4ec4cfe87e8@github.com>
References: <6cK72nd6uq2D_R-oBmQ5B3nEzr2V25F3tyXYta1BDEI=.75499f03-9a3e-4b0b-9126-d4ec4cfe87e8@github.com>
Message-ID: <LWHeted9QqZvlhf0K-_EfyqdW0sy9-u6g9PRgC3dH58=.13206ed9-6dad-4260-b7e5-a45d37b04828@github.com>

On Mon, 5 Feb 2024 08:26:55 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> A trivial ADLC build fix. The ADLC_LANGSTD_CXXFLAGS should get passed.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/17705#issuecomment-1928892061

From jlahoda at openjdk.org  Tue Feb  6 07:11:02 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 6 Feb 2024 07:11:02 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v18]
In-Reply-To: <RIP-4xQbHyEjoPx-PHy-YFMYjq5xq1pjV5SCdVWbQNo=.c6fa9a51-39c3-4ef9-bfe9-1382b9bc016f@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <RIP-4xQbHyEjoPx-PHy-YFMYjq5xq1pjV5SCdVWbQNo=.c6fa9a51-39c3-4ef9-bfe9-1382b9bc016f@github.com>
Message-ID: <l62YkgsxqBHwYu5AzzN6v-rMMuUARmbIOVdQnlEfQ4c=.5b166998-4f34-4526-96de-3a6ea9030c76@github.com>

On Tue, 6 Feb 2024 01:36:58 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   First pass at remove DocCommentTransformer from the public API.
>   
>   It is still declared internally, and installed by default, using the service-provider mechanism.
>   If the standard impl is not available, an identity transformer is used.

src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 1:

> 1: /*

This transformer seems to break positions of the `RawTextTree`.
For javadoc like:

                        /// Markdown test
                        ///
                        /// @author testAuthor

without this transformer, taking the start and end positions of the `RawTextTree` and taking the text between these positions will lead to: `[Markdown test, testAuthor]`. With this transfomer, it leads to `[Markdown test, Markdown t]`, which is clearly suspicious.

Testcase:

/*
 * Copyright (c) 2024, 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
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 */

/*
 * @test
 * @bug 9999999
 * @summary XXX
 * @run main/othervm --limit-modules jdk.compiler MarkdownTransformerPositionTest
 * @run main MarkdownTransformerPositionTest
 */

import com.sun.source.doctree.DocCommentTree;
import com.sun.source.doctree.RawTextTree;
import com.sun.source.tree.*;
import com.sun.source.util.*;

import java.net.URI;
import java.util.*;
import javax.lang.model.element.Element;
import javax.tools.*;


public class MarkdownTransformerPositionTest {

    public static void main(String... args) throws Exception {
        String source = """
                        /// Markdown test
                        ///
                        /// @author testAuthor
                        public class Test {
                        }
                        """;
        JavaCompiler comp = ToolProvider.getSystemJavaCompiler();
        JavacTask task = (JavacTask)comp.getTask(null, null, null, null, null, Arrays.asList(new JavaSource(source)));
        CompilationUnitTree cu = task.parse().iterator().next();
        task.analyze();
        DocTrees trees = DocTrees.instance(task);
        List<String> rawSpans = new ArrayList<>();
        TreePath clazzTP = new TreePath(new TreePath(cu), cu.getTypeDecls().get(0));
        Element clazz = trees.getElement(clazzTP);
        DocCommentTree docComment = trees.getDocCommentTree(clazz);

        new DocTreeScanner<Void, Void>() {
            @Override
            public Void visitRawText(RawTextTree node, Void p) {
                int start = (int) trees.getSourcePositions().getStartPosition(cu, docComment, node);
                int end = (int) trees.getSourcePositions().getEndPosition(cu, docComment, node);
                rawSpans.add(source.substring(start, end));
                return super.visitRawText(node, p);
            }
        }.scan(docComment, null);

        List<String> expectedRawSpans = List.of("Markdown test", "testAuthor");

        if (!expectedRawSpans.equals(rawSpans)) {
            throw new AssertionError("Incorrect raw text spans, should be: " +
                                     expectedRawSpans + ", but is: " + rawSpans);
        }

        System.err.println("Test result: success, boot modules: " + ModuleLayer.boot().modules());
    }

    static class JavaSource extends SimpleJavaFileObject {

        private final String source;

        public JavaSource(String source) {
            super(URI.create("myfo:/Test.java"), JavaFileObject.Kind.SOURCE);
            this.source = source;
        }

        @Override
        public CharSequence getCharContent(boolean ignoreEncodingErrors) {
            return source;
        }
    }
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1479306878

From mbaesken at openjdk.org  Tue Feb  6 08:07:22 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 6 Feb 2024 08:07:22 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
In-Reply-To: <tWCBjZIzUFDJxIec37zQeyB3LjUHXIy0NpFDMpTf5-Q=.71f4ada6-3dda-4f0d-8ecf-178c154eb1c3@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
 <js04r6dJGMDL_c1dfpNEGvhDD53Y1H2JRCJxtJ7Xtjs=.d1b19610-206b-4809-a559-842c69f90f59@github.com>
 <tWCBjZIzUFDJxIec37zQeyB3LjUHXIy0NpFDMpTf5-Q=.71f4ada6-3dda-4f0d-8ecf-178c154eb1c3@github.com>
Message-ID: <XYZD6zO-3fdkLSnGf2WVRgIC1v0VmdKtl0da9h_Mofg=.58cf03dd-8e2c-4608-90f1-01992ba9cd4d@github.com>

On Mon, 5 Feb 2024 14:15:44 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> 
> Thanks for the AIX related effort ; I put it again into our internal build/test queue.

With the latest commit the build again fails on AIX with this error

/jdk/src/java.base/unix/native/libnio/ch/UnixFileDispatcherImpl.c:381:27: error: incompatible pointer types passing 'struct statvfs64 *' to parameter of type 'struct statvfs *' [-Werror,-Wincompatible-pointer-types]
    result = fstatvfs(fd, &file_stat);
                          ^~~~~~~~~~
/usr/include/sys/statvfs.h:102:42: note: passing argument to parameter here
extern int fstatvfs(int, struct statvfs *);

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1928972961

From ihse at openjdk.org  Tue Feb  6 08:07:28 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Feb 2024 08:07:28 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v9]
In-Reply-To: <b96RhEmwIImjWS3oyk9PxePfyguzdnMH99r5ehZymyM=.713daa09-855a-48e7-9aff-af671cc947c9@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
 <b96RhEmwIImjWS3oyk9PxePfyguzdnMH99r5ehZymyM=.713daa09-855a-48e7-9aff-af671cc947c9@github.com>
Message-ID: <nnJLdTCIakaXM-E8YEJcXbH0S3JHfM96703ogcfeyxk=.72dbeffd-7401-4707-9b54-b21b0c9377ad@github.com>

On Fri, 8 Dec 2023 00:50:59 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix potential attribute issue
>
>> Build changes finally look good. Great, actually! Thanks for persisting, despite the many rounds of review.
>> 
>> You will still need the 2 hotspot reviews for the hotspot part of the patch.
>> 
>> /reviewers 3
> 
> Thanks for the review and all the comments!

@XiaohongGong What happened? Did you not intend to continue working to get this integrated?

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1928968764

From xgong at openjdk.org  Tue Feb  6 08:15:08 2024
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 6 Feb 2024 08:15:08 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v9]
In-Reply-To: <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
Message-ID: <fd1bzFHzekbbS36hdUrlmmOz0K9aMt7vID_xZkfVL1s=.4036c93c-ed88-401c-b083-044c520504d6@github.com>

On Thu, 7 Dec 2023 09:30:01 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix potential attribute issue

Yeah, I,m so sorry for that due to some uncontrollable changes to my work. I have to stop it. Maybe others from Arm will revisit this feature in future. Thanks for your time on this PR and all your comments!

---- Replied Message ----
| From | Magnus Ihse ***@***.***> |
| Date | 02/06/2024 16:02 |
| To | openjdk/jdk ***@***.***> |
| Cc | XiaohongGong ***@***.***>,
Mention ***@***.***> |
| Subject | Re: [openjdk/jdk] 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF (PR #16234) |

@XiaohongGong What happened? Did you not intend to continue working to get this integrated?

?
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1928983785

From ihse at openjdk.org  Tue Feb  6 08:18:14 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Feb 2024 08:18:14 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v9]
In-Reply-To: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
Message-ID: <Yzf-wMAQDgEIeSJZpHiz8toO2PJrhVSeI4D6O8AZABk=.2ac6a005-a3b4-45fd-aa3b-54f83bbcef1f@github.com>

> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Also fix fstatvfs on AIX

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17538/files
  - new: https://git.openjdk.org/jdk/pull/17538/files/2de377cd..1fd34b10

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

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

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

From ihse at openjdk.org  Tue Feb  6 08:18:14 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Feb 2024 08:18:14 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v8]
In-Reply-To: <DsX5YWCbdiDy_c9BfxEuic9eO1QqgPzYZ7Pqgh28TvI=.18af62dc-ee26-43c6-be92-4adda72662e5@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <DsX5YWCbdiDy_c9BfxEuic9eO1QqgPzYZ7Pqgh28TvI=.18af62dc-ee26-43c6-be92-4adda72662e5@github.com>
Message-ID: <JMT6gsJEV6QhtZXoMKzStIJ69Ses7oleGEdEJDNh4Ws=.c210f1cf-f057-40a4-a19c-2963f4e6828f@github.com>

On Mon, 5 Feb 2024 14:06:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Redefine statvfs as statvfs64 on AIX

Yeah, I missed `fstatvfs`. ? 

Now, then maybe `n`th time's a charm?

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1928987789

From ihse at openjdk.org  Tue Feb  6 08:20:05 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Feb 2024 08:20:05 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v9]
In-Reply-To: <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
Message-ID: <_Md9YBUxFkpVBHq4CwX1S5qFkQKiqiQ40rem3OA_zUU=.20785d53-06ad-4d15-9b06-42ed1061a818@github.com>

On Thu, 7 Dec 2023 09:30:01 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix potential attribute issue

Ooookay. I hope someone picks it up. I've spent quite a lot of time trying to get this PR into shape.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1928991506

From ihse at openjdk.org  Tue Feb  6 08:23:05 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Feb 2024 08:23:05 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <l5WD1cEIW8M7NHd72gK16F1_2cglU3Leeie4zdyCdR4=.6bb73168-2f49-4091-960c-e332694586fa@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
 <3cK9QjVQNIgZoWWhrWKEb3XxfbLjprjRMBbStWegH7M=.6df92651-b97d-445a-aa42-302ea791bbea@github.com>
 <lQJoZ_hXjfLO-MRGDLar9L0yD6xAXF1QAu2AIAjwnKk=.390b6b58-3e5d-42af-90e6-2dd76b29172f@github.com>
 <AnHvp-NR-sLPEha8BivPv-pBAmquGjSge4TIludLVHM=.e2866a94-78bb-40d7-8506-9807c5a3d786@github.com>
 <l5WD1cEIW8M7NHd72gK16F1_2cglU3Leeie4zdyCdR4=.6bb73168-2f49-4091-960c-e332694586fa@github.com>
Message-ID: <3jgZL57F_aikTsAnrGINeQgFHryGBNJZI24-WusdYKM=.f1f64b34-bfbb-4222-afba-c200152075dc@github.com>

On Mon, 11 Dec 2023 18:25:09 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> @theRealAph 
>>> Or is there likely to be a plan to e.g. build Oracle's releases with SLEEF support?
>> 
>> I can't say anything for sure, but I picked up some positive vibes from our internal chat. I think the idea was that libsleef could potentially cover up vector math for all platforms that the current Intel lib solution is missing (basically, everything but linux+windows x64). So I this can be seen as a bit of a trial balloon if it is worth a more complete integration of libsleef in the JDK.
>> 
>> And I can't say anything at all about what Oracle JDKs are going to release with, but I am fully open towards adding libsleef to the GHA builds. And I'm guessing that Adoptium has no reason not to include libsleef, but then again, I cannot of course speak for them.
>
>> I can't say anything for sure, but I picked up some positive vibes from our internal chat. I think the idea was that libsleef could potentially cover up vector math for all platforms that the current Intel lib solution is missing (basically, everything but linux+windows x64). So I this can be seen as a bit of a trial balloon if it is worth a more complete integration of libsleef in the JDK.
> 
> I can add that we are interested to use that for Linux + RISC-V support given the RISC-V support was recently merged into sleef upstream. https://github.com/shibatch/sleef/pull/477

@luhenry Maybe you are interested in helping with bringing this forward? I can assist with risc-v related fixes in the makefiles. I'd just hate to see all this work go to waste.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1928995458

From jwaters at openjdk.org  Tue Feb  6 09:53:01 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 6 Feb 2024 09:53:01 GMT
Subject: RFR: 8325316: Enable -pedantic -Wpedantic for gcc
Message-ID: <5-fL8vy-065EhMR2SzE21o7UFrOOoDVfnhDG06G-kkE=.0c2dab10-c458-4178-89f7-004f8f921a3f@github.com>

Similarly to [JDK-8325163](https://bugs.openjdk.org/browse/JDK-8325163), this enables pedantic mode for gcc, ensuring stricter Standard conformance and allowing for buggy and broken code previously undetectable by gcc to be caught

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

Commit messages:
 - Semicolon in compilerWarnings_gcc.hpp
 - compilerWarnings_gcc.hpp
 - 8325316

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

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

From ihse at openjdk.org  Tue Feb  6 12:23:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Feb 2024 12:23:55 GMT
Subject: RFR: 8324243: Fix GCC 14 build [v3]
In-Reply-To: <HdMQd-rsi1Ry5jT7ffesgEm8kzjdD80VO3REUlzBQMs=.c52c56a1-b118-4833-afc9-08798afd6581@github.com>
References: <PmU0wltBwGECZ_1D3iQA3WCZE-evJ-Exf9f51-hXdBc=.353a8bb3-79e9-46e0-a85a-c53f62efa8aa@github.com>
 <HdMQd-rsi1Ry5jT7ffesgEm8kzjdD80VO3REUlzBQMs=.c52c56a1-b118-4833-afc9-08798afd6581@github.com>
Message-ID: <rcxBGktyyHoUvk_77w0ZDKy8eHjYINqdzFq3y3YEJmw=.b0b0def6-2d70-4c42-b48e-c16e577a7ba3@github.com>

On Sat, 3 Feb 2024 10:07:26 GMT, Sam James <duke at openjdk.org> wrote:

>> This fixes building with GCC 14:
>> * ~Cherry-pick a fix from Harfbuzz upstream~
>> * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources
>> 
>> -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses
>> -Werror.
>> 
>> The calloc prototype is:
>> 
>> void *calloc(size_t nmemb, size_t size);
>> 
>> 
>> So, just swap the number of members and size arguments to match the prototype, as
>> we're initialising 1 struct of size `sizeof(struct ...)`. GCC then sees we're not
>> doing anything wrong.
>
> Sam James has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17506#pullrequestreview-1865013534

From ihse at openjdk.org  Tue Feb  6 12:27:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Feb 2024 12:27:56 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <XSGj9zsG14OM3pa1GR8qlZmOC6bp0pMb3bMj8UOCFF4=.7880f388-3caf-49d4-95ec-f5405974ba53@github.com>

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

Build changes look fine, but there is really a *lot* of places where the warning is individually disabled. This indicates either that the warning is too broad, or that the code base is potentially very buggy; neither of which sounds very good. :(

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1865022402

From ihse at openjdk.org  Tue Feb  6 12:29:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Feb 2024 12:29:55 GMT
Subject: RFR: JDK-8325268: Add policy statement to langtools makefiles
 concerning warnings
In-Reply-To: <SDIA7FXQnkrauJHNBE5Ziz5YoRkEdYi5TTUZSKDAiYo=.85170a59-a6aa-4940-b5ad-3cdcdac8d6ab@github.com>
References: <SDIA7FXQnkrauJHNBE5Ziz5YoRkEdYi5TTUZSKDAiYo=.85170a59-a6aa-4940-b5ad-3cdcdac8d6ab@github.com>
Message-ID: <e2spIarpf_7he-D94CEm8hf-jaEZz1YpkFLjxBCvg_c=.2eadd425-9c4d-4644-948d-512b9af67fa1@github.com>

On Tue, 6 Feb 2024 02:28:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add policy statement about lint warnings to various langtools modules.

LGTM

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17718#pullrequestreview-1865030163

From ihse at openjdk.org  Tue Feb  6 12:38:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Feb 2024 12:38:54 GMT
Subject: RFR: 8325194: GHA: Add macOS M1 testing [v5]
In-Reply-To: <GrRXOT-hiuBaJWl2JU5_gZhLFvisGr1oZm09hK2zGVI=.28c43e47-50d6-46b7-a055-abc5db204c2d@github.com>
References: <AajUHnzAeT8VngtyariR_vfo-FTkoRbv5d1OJsbeuw4=.6eb2d4c3-0260-4d6c-9342-6587dacdc05b@github.com>
 <GrRXOT-hiuBaJWl2JU5_gZhLFvisGr1oZm09hK2zGVI=.28c43e47-50d6-46b7-a055-abc5db204c2d@github.com>
Message-ID: <fwefbIM2Zqq5qbNmoHZBsw5EZSHwSaYrqIGfqWclH38=.3ae48925-0f5e-4b6a-b0d9-e6edd466a96c@github.com>

On Sat, 3 Feb 2024 21:55:25 GMT, George Adams <gdams at openjdk.org> wrote:

>> Now that macOS M1 executors are [available in GitHub actions](https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/) it makes sense to move the build to run on M1 (rather than cross-compiled) and also enable testing on the platform.
>
> George Adams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify jtreg

Looks fine, I guess. Replacing one cross-compilation with native build is OK. 

Adding the testing is... well, I guess it is reasonable given the popularity of macosx-aarch64, but note that it will add to the creeping increase in the github test suite. At some point, we will only be able to add more testing if we remove some existing.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17694#pullrequestreview-1865047739

From ihse at openjdk.org  Tue Feb  6 12:38:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Feb 2024 12:38:55 GMT
Subject: RFR: 8325194: GHA: Add macOS M1 testing [v3]
In-Reply-To: <HThdvM5ziz8Ij4OS5uVr6d5IeJp7zuK-IDd3jA6Kj10=.5195f96c-d375-4dae-80b7-b106aec65edd@github.com>
References: <AajUHnzAeT8VngtyariR_vfo-FTkoRbv5d1OJsbeuw4=.6eb2d4c3-0260-4d6c-9342-6587dacdc05b@github.com>
 <qOSXmCA3e_vztDOlB5v0sJTOTzslV-x2gFKjJbiNKOM=.79155b2d-dc51-4856-9456-66f07d607858@github.com>
 <az3sMGidoGWfWnuDA7HB5InQqN184WAoXNsIezMxVZQ=.3e3f9451-05a6-4378-9790-608bb908a41e@github.com>
 <HThdvM5ziz8Ij4OS5uVr6d5IeJp7zuK-IDd3jA6Kj10=.5195f96c-d375-4dae-80b7-b106aec65edd@github.com>
Message-ID: <WXWoK-eWC44cAXsMJWzgZhWcjsG9S6tnYJjRSb6e6mQ=.4cb5873b-fe5b-4b01-a899-56ce9a24b955@github.com>

On Sat, 3 Feb 2024 16:15:11 GMT, George Adams <gdams at openjdk.org> wrote:

> Noting that macos-14 is arm64 only in GitHub so such a change might not be useful in this scenario.

That's a shame, really. It would be good if we switched x64 to macos-14 as soon as it is available, so we are on the same version.

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

PR Comment: https://git.openjdk.org/jdk/pull/17694#issuecomment-1929437395

From ngasson at openjdk.org  Tue Feb  6 12:48:06 2024
From: ngasson at openjdk.org (Nick Gasson)
Date: Tue, 6 Feb 2024 12:48:06 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v9]
In-Reply-To: <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
Message-ID: <DYz4aZBnVpwvFLOoaV_cbUgrkgNF-SFMeakpXTs4dfQ=.e78ee5fa-70f6-49dc-8ef5-3861f31a79bd@github.com>

On Thu, 7 Dec 2023 09:30:01 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix potential attribute issue

We are planning to pick this up again later in the year, thanks for your help so far!

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1929451905

From gdams at openjdk.org  Tue Feb  6 13:30:59 2024
From: gdams at openjdk.org (George Adams)
Date: Tue, 6 Feb 2024 13:30:59 GMT
Subject: Integrated: 8325194: GHA: Add macOS M1 testing
In-Reply-To: <AajUHnzAeT8VngtyariR_vfo-FTkoRbv5d1OJsbeuw4=.6eb2d4c3-0260-4d6c-9342-6587dacdc05b@github.com>
References: <AajUHnzAeT8VngtyariR_vfo-FTkoRbv5d1OJsbeuw4=.6eb2d4c3-0260-4d6c-9342-6587dacdc05b@github.com>
Message-ID: <Flu5Sg7Loi6lXcQxoqhyGI-HCs1vNjcQoHG9E2ivuqA=.ee65c007-9158-40bb-9790-145723be1323@github.com>

On Sat, 3 Feb 2024 11:29:55 GMT, George Adams <gdams at openjdk.org> wrote:

> Now that macOS M1 executors are [available in GitHub actions](https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/) it makes sense to move the build to run on M1 (rather than cross-compiled) and also enable testing on the platform.

This pull request has now been integrated.

Changeset: d1c82156
Author:    George Adams <gdams at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d1c82156ba6ede4b798ac15f935289cfcc99d1a0
Stats:     28 lines in 4 files changed: 19 ins; 1 del; 8 mod

8325194: GHA: Add macOS M1 testing

Reviewed-by: clanger, ihse

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

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

From mbaesken at openjdk.org  Tue Feb  6 14:01:00 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 6 Feb 2024 14:01:00 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v9]
In-Reply-To: <Yzf-wMAQDgEIeSJZpHiz8toO2PJrhVSeI4D6O8AZABk=.2ac6a005-a3b4-45fd-aa3b-54f83bbcef1f@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <Yzf-wMAQDgEIeSJZpHiz8toO2PJrhVSeI4D6O8AZABk=.2ac6a005-a3b4-45fd-aa3b-54f83bbcef1f@github.com>
Message-ID: <zB0nlnlr8nZF95nRnRANCqSwL_YGSnuuzkuH-tUQT9E=.60fcbae0-d374-4d3c-997e-d55b3a14178c@github.com>

On Tue, 6 Feb 2024 08:18:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also fix fstatvfs on AIX

AIX build is fixed now after latest commit, thanks for handling the AIX special cases.

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

Marked as reviewed by mbaesken (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17538#pullrequestreview-1865270571

From luhenry at openjdk.org  Tue Feb  6 14:20:05 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Tue, 6 Feb 2024 14:20:05 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <3jgZL57F_aikTsAnrGINeQgFHryGBNJZI24-WusdYKM=.f1f64b34-bfbb-4222-afba-c200152075dc@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
 <3cK9QjVQNIgZoWWhrWKEb3XxfbLjprjRMBbStWegH7M=.6df92651-b97d-445a-aa42-302ea791bbea@github.com>
 <lQJoZ_hXjfLO-MRGDLar9L0yD6xAXF1QAu2AIAjwnKk=.390b6b58-3e5d-42af-90e6-2dd76b29172f@github.com>
 <AnHvp-NR-sLPEha8BivPv-pBAmquGjSge4TIludLVHM=.e2866a94-78bb-40d7-8506-9807c5a3d786@github.com>
 <l5WD1cEIW8M7NHd72gK16F1_2cglU3Leeie4zdyCdR4=.6bb73168-2f49-4091-960c-e332694586fa@github.com>
 <3jgZL57F_aikTsAnrGINeQgFHryGBNJZI24-WusdYKM=.f1f64b34-bfbb-4222-afba-c200152075dc@github.com>
Message-ID: <a96a9JuTN8h-WV32oy8r-GQuX3V0pTid2RtMbihwWu4=.373b1b97-0d26-47fc-b0ce-1fbccb8f7596@github.com>

On Tue, 6 Feb 2024 08:20:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I'd just hate to see all this work go to waste.

Same here!

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1929780538

From dfuchs at openjdk.org  Tue Feb  6 14:41:56 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 6 Feb 2024 14:41:56 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <wf_fVPg2J0TOSzRXXFw6_9uHCT0CRcMaNpbySW5J3es=.387a3da3-3724-4669-8000-c27ced315f0b@github.com>

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

I looked at the modifications in java.net / sun.net. Looks generally good though I have some comments.

src/java.base/share/classes/java/net/Socket.java line 323:

> 321:      * @see        SecurityManager#checkConnect
> 322:      */
> 323:     @SuppressWarnings("this-escape")

This is a weird one. I guess the issue here is that the escape happens in the chained constructor, and is propagated recursively up the constructor chain. Is the suppress warning here still needed after disabling this-escape warning at line 358?

Actually - these are all weird since the only place where the escape happens is in the private constructor at line 548 - and it doesn't even get flagged there (presumably because it's a private constructor?) 

I guess that the rationale is that subclasses cannot override the private constructor (where the escape happen), but can override the public constructor that calls the private constructor where the escape happen. I can't help feeling that the warning would be better placed on the private constructor though. Seeing it here confused me a lot.

src/java.base/share/classes/sun/net/www/MessageHeader.java line 53:

> 51:     }
> 52: 
> 53:     @SuppressWarnings("this-escape")

An alternative here could be to make the class final. AFAICS it's not subclassed anywhere. If you'd prefer not to do this here then maybe a followup issue could be logged?

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

PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1865378355
PR Review Comment: https://git.openjdk.org/jdk/pull/17692#discussion_r1479922189
PR Review Comment: https://git.openjdk.org/jdk/pull/17692#discussion_r1479936447

From ihse at openjdk.org  Tue Feb  6 16:13:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Feb 2024 16:13:01 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v9]
In-Reply-To: <Ve5i_GI5N-X0wSVaLavvfy62e6XL_jlN4Qs_CkbS3fs=.88f0d499-8edc-48c6-b92d-8d8f5d27c991@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
 <Ve5i_GI5N-X0wSVaLavvfy62e6XL_jlN4Qs_CkbS3fs=.88f0d499-8edc-48c6-b92d-8d8f5d27c991@github.com>
Message-ID: <Tk-oYD9tIeVq4hEwn3_vHmJrAErya7_lpIzKcotYdn0=.4090e8b8-0107-4662-b674-f49f92cfc499@github.com>

On Fri, 2 Feb 2024 07:01:33 GMT, Sam James <duke at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Also fix fstatvfs on AIX
>
> make/modules/jdk.hotspot.agent/Lib.gmk line 31:
> 
>> 29: 
>> 30: ifeq ($(call isTargetOs, linux), true)
>> 31:   SA_CFLAGS := -D_FILE_OFFSET_BITS=64
> 
> We have two choices to feel a bit more comfortable:
> 1) We unconditionally `static_assert` in a few places for large `off_t`, or
> 2) We only do it for platforms we know definitely support F_O_B and aren't AIX (which we've handled separately).
> 
> Not sure that's strictly necessary though. Also, if something understands LARGEFILE*_SOURCE, then it probably understood F_O_B, or at least has some macro to control it. Just thinking aloud.

@thesamesam Do you want a `static_assert`? As I said, please let me know where you want to put it. I don't think it provides much, but if it makes you feel more comfortable, I'm okay with adding it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1480125790

From ihse at openjdk.org  Tue Feb  6 16:59:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Feb 2024 16:59:03 GMT
Subject: RFR: 8325342: Remove unneeded exceptions in compare.sh
Message-ID: <q_YwcRN3VaNpSve_xwZZkZUbMVN-4buHoiN1X-I_8s4=.945a33f3-6331-423e-afdd-bdd00933a474@github.com>

Over time, we have been better at addressing inconsistencies in the build, but the exceptions put in place in compare.sh have not been updated to reflect this.

This attempts to make sure we only keep those exceptions that are currently actually needed to verify a reproducible build (the primary usecase for the compare script these days).

I also discovered bugs in the script, where mismatches in a zip file did not make us report a failed comparison. I added extra code to make sure we always set the REGRESSION flag whenever we detect a problem.

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

Commit messages:
 - 8325342: Remove unneeded exceptions in compare.sh

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

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

From darcy at openjdk.org  Tue Feb  6 17:31:54 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Feb 2024 17:31:54 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <wf_fVPg2J0TOSzRXXFw6_9uHCT0CRcMaNpbySW5J3es=.387a3da3-3724-4669-8000-c27ced315f0b@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
 <wf_fVPg2J0TOSzRXXFw6_9uHCT0CRcMaNpbySW5J3es=.387a3da3-3724-4669-8000-c27ced315f0b@github.com>
Message-ID: <DcnnBx1j3OpugEZ32t_a6c5TtUXihl7TW6W4A1c7wfc=.750d04e1-f9c0-4c58-ac83-6fd387ec00ac@github.com>

On Tue, 6 Feb 2024 14:35:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.
>
> src/java.base/share/classes/sun/net/www/MessageHeader.java line 53:
> 
>> 51:     }
>> 52: 
>> 53:     @SuppressWarnings("this-escape")
> 
> An alternative here could be to make the class final. AFAICS it's not subclassed anywhere. If you'd prefer not to do this here then maybe a followup issue could be logged?

I'd prefer if that kind of change were done as a subtask of

[JDK-8325263](https://bugs.openjdk.org/browse/JDK-8325263): Address this-escape lint warnings java.base (umbrella)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17692#discussion_r1480307107

From darcy at openjdk.org  Tue Feb  6 17:43:56 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Feb 2024 17:43:56 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <ZI2YqS40yBOAxgajCExkdG7NcOpPjvYywu25NZcw104=.6da918fc-c28d-42a8-b28d-b40c674c3b11@github.com>

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

> Build changes look fine, but there is really a _lot_ of places where the warning is individually disabled. This indicates either that the warning is too broad, or that the code base is potentially very buggy; neither of which sounds very good. :(

I deliberately choose to suppress the warning at each constructor location rather than at the class level so there are more SuppressWarnings annotations than strictly needed to get the build to be clean. However, I thought limiting the scope of the annotations was preferable for several reasons, including more precisely indicating where any code updates are needed.

This is a new warning run over old code, in some cases very old code. I don't find it surprising that there were several hundred instances of this warning in java.base given the amount of code there.

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

PR Comment: https://git.openjdk.org/jdk/pull/17692#issuecomment-1930451875

From erikj at openjdk.org  Tue Feb  6 17:57:55 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 6 Feb 2024 17:57:55 GMT
Subject: RFR: 8325342: Remove unneeded exceptions in compare.sh
In-Reply-To: <q_YwcRN3VaNpSve_xwZZkZUbMVN-4buHoiN1X-I_8s4=.945a33f3-6331-423e-afdd-bdd00933a474@github.com>
References: <q_YwcRN3VaNpSve_xwZZkZUbMVN-4buHoiN1X-I_8s4=.945a33f3-6331-423e-afdd-bdd00933a474@github.com>
Message-ID: <kjD_Nd3RkRNJkapLBobcO9Eq31OFzkSM8rHMAaEHolc=.6b6f5a96-d58c-467b-abb5-1e1d806254e5@github.com>

On Tue, 6 Feb 2024 16:53:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Over time, we have been better at addressing inconsistencies in the build, but the exceptions put in place in compare.sh have not been updated to reflect this.
> 
> This attempts to make sure we only keep those exceptions that are currently actually needed to verify a reproducible build (the primary usecase for the compare script these days).
> 
> I also discovered bugs in the script, where mismatches in a zip file did not make us report a failed comparison. I added extra code to make sure we always set the REGRESSION flag whenever we detect a problem.

make/scripts/compare.sh line 298:

> 296:         | $GREP -v "/hotspot/gtest/server/gtestLauncher" \
> 297:         | $GREP -v "/hotspot/gtest/server/libjvm.dylib" \
> 298:         | $SORT | $FILTER)

This list of exclusion, or at least most of it, isn't for handling exceptions but because those files are handled explicitly by other comparison functions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17735#discussion_r1480337401

From joehw at openjdk.org  Tue Feb  6 18:07:56 2024
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 6 Feb 2024 18:07:56 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <AUmgRDOc_xd5B0oFZboOpaE1TMccN4gf-IKkfcmJUyk=.c00e299e-b04b-4688-816c-e1e89693e466@github.com>

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

The two XML changes look good to me. There would be a lot of warnings in the java.xml module as well, if we had to do it in the future.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1866004351

From lancea at openjdk.org  Tue Feb  6 18:13:54 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 6 Feb 2024 18:13:54 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <cRl8n_pGXA3YeoIGsx-i4W2PXqLckhyZDGcW_QkH8og=.6a6c38d6-be24-4087-abcd-fbff9ffa4d62@github.com>

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1866015274

From dfuchs at openjdk.org  Tue Feb  6 18:20:54 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 6 Feb 2024 18:20:54 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <DcnnBx1j3OpugEZ32t_a6c5TtUXihl7TW6W4A1c7wfc=.750d04e1-f9c0-4c58-ac83-6fd387ec00ac@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
 <wf_fVPg2J0TOSzRXXFw6_9uHCT0CRcMaNpbySW5J3es=.387a3da3-3724-4669-8000-c27ced315f0b@github.com>
 <DcnnBx1j3OpugEZ32t_a6c5TtUXihl7TW6W4A1c7wfc=.750d04e1-f9c0-4c58-ac83-6fd387ec00ac@github.com>
Message-ID: <bGEDEinASOI1ApbLv_K_WXRu3iHlLb5usSo_gMfQwWc=.dd721bf7-052b-4d9f-9ca3-3f46a171302c@github.com>

On Tue, 6 Feb 2024 17:29:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/MessageHeader.java line 53:
>> 
>>> 51:     }
>>> 52: 
>>> 53:     @SuppressWarnings("this-escape")
>> 
>> An alternative here could be to make the class final. AFAICS it's not subclassed anywhere. If you'd prefer not to do this here then maybe a followup issue could be logged?
>
> I'd prefer if that kind of change were done as a subtask of
> 
> [JDK-8325263](https://bugs.openjdk.org/browse/JDK-8325263): Address this-escape lint warnings java.base (umbrella)

Thanks Joe. I logged [JDK-8325361](https://bugs.openjdk.org/browse/JDK-8325361): Make sun.net.www.MessageHeader final

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17692#discussion_r1480362736

From jjg at openjdk.org  Tue Feb  6 19:31:06 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 6 Feb 2024 19:31:06 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v18]
In-Reply-To: <l62YkgsxqBHwYu5AzzN6v-rMMuUARmbIOVdQnlEfQ4c=.5b166998-4f34-4526-96de-3a6ea9030c76@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <RIP-4xQbHyEjoPx-PHy-YFMYjq5xq1pjV5SCdVWbQNo=.c6fa9a51-39c3-4ef9-bfe9-1382b9bc016f@github.com>
 <l62YkgsxqBHwYu5AzzN6v-rMMuUARmbIOVdQnlEfQ4c=.5b166998-4f34-4526-96de-3a6ea9030c76@github.com>
Message-ID: <UVXpzCUqXHCV4DX8cuZ35YSyGI5zWmqItEaxgtV4WVc=.563257a5-d67c-4d38-adf6-8b03b94de37c@github.com>

On Tue, 6 Feb 2024 07:08:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   First pass at remove DocCommentTransformer from the public API.
>>   
>>   It is still declared internally, and installed by default, using the service-provider mechanism.
>>   If the standard impl is not available, an identity transformer is used.
>
> src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 1:
> 
>> 1: /*
> 
> This transformer seems to break positions of the `RawTextTree`.
> For javadoc like:
> 
>                         /// Markdown test
>                         ///
>                         /// @author testAuthor
> 
> without this transformer, taking the start and end positions of the `RawTextTree` and taking the text between these positions will lead to: `[Markdown test, testAuthor]`. With this transfomer, it leads to `[Markdown test, Markdown t]`, which is clearly suspicious.
> 
> Testcase:
> 
> /*
>  * Copyright (c) 2024, 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
>  * under the terms of the GNU General Public License version 2 only, as
>  * published by the Free Software Foundation.
>  *
>  * This code is distributed in the hope that it will be useful, but WITHOUT
>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>  * version 2 for more details (a copy is included in the LICENSE file that
>  * accompanied this code).
>  *
>  * You should have received a copy of the GNU General Public License version
>  * 2 along with this work; if not, write to the Free Software Foundation,
>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>  *
>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>  * or visit www.oracle.com if you need additional information or have any
>  * questions.
>  */
> 
> /*
>  * @test
>  * @bug 9999999
>  * @summary XXX
>  * @run main/othervm --limit-modules jdk.compiler MarkdownTransformerPositionTest
>  * @run main MarkdownTransformerPositionTest
>  */
> 
> import com.sun.source.doctree.DocCommentTree;
> import com.sun.source.doctree.RawTextTree;
> import com.sun.source.tree.*;
> import com.sun.source.util.*;
> 
> import java.net.URI;
> import java.util.*;
> import javax.lang.model.element.Element;
> import javax.tools.*;
> 
> 
> public class MarkdownTransformerPositionTest {
> 
>     public static void main(String... args) throws Exception {
>         String source = """
>                         /// Markdown test
>                         ///
>                         /// @author testAuthor
>                         public class Test {
>                         }
>                         """;
>         JavaCompiler comp = ToolProvider.getSystemJavaCompiler();
>         JavacTask ...

Uugh.  Noted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1480437320

From jjg at openjdk.org  Tue Feb  6 20:00:01 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 6 Feb 2024 20:00:01 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v18]
In-Reply-To: <UVXpzCUqXHCV4DX8cuZ35YSyGI5zWmqItEaxgtV4WVc=.563257a5-d67c-4d38-adf6-8b03b94de37c@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <RIP-4xQbHyEjoPx-PHy-YFMYjq5xq1pjV5SCdVWbQNo=.c6fa9a51-39c3-4ef9-bfe9-1382b9bc016f@github.com>
 <l62YkgsxqBHwYu5AzzN6v-rMMuUARmbIOVdQnlEfQ4c=.5b166998-4f34-4526-96de-3a6ea9030c76@github.com>
 <UVXpzCUqXHCV4DX8cuZ35YSyGI5zWmqItEaxgtV4WVc=.563257a5-d67c-4d38-adf6-8b03b94de37c@github.com>
Message-ID: <6EEwmjOExugvg9w74ZEhDGZ37af9ott0EdQfTPpU5i4=.2279f998-cf78-47ad-8ef7-8a0da0831be6@github.com>

On Tue, 6 Feb 2024 19:27:55 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 1:
>> 
>>> 1: /*
>> 
>> This transformer seems to break positions of the `RawTextTree`.
>> For javadoc like:
>> 
>>                         /// Markdown test
>>                         ///
>>                         /// @author testAuthor
>> 
>> without this transformer, taking the start and end positions of the `RawTextTree` and taking the text between these positions will lead to: `[Markdown test, testAuthor]`. With this transfomer, it leads to `[Markdown test, Markdown t]`, which is clearly suspicious.
>> 
>> Testcase:
>> 
>> /*
>>  * Copyright (c) 2024, 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
>>  * under the terms of the GNU General Public License version 2 only, as
>>  * published by the Free Software Foundation.
>>  *
>>  * This code is distributed in the hope that it will be useful, but WITHOUT
>>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>  * version 2 for more details (a copy is included in the LICENSE file that
>>  * accompanied this code).
>>  *
>>  * You should have received a copy of the GNU General Public License version
>>  * 2 along with this work; if not, write to the Free Software Foundation,
>>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>  *
>>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>>  * or visit www.oracle.com if you need additional information or have any
>>  * questions.
>>  */
>> 
>> /*
>>  * @test
>>  * @bug 9999999
>>  * @summary XXX
>>  * @run main/othervm --limit-modules jdk.compiler MarkdownTransformerPositionTest
>>  * @run main MarkdownTransformerPositionTest
>>  */
>> 
>> import com.sun.source.doctree.DocCommentTree;
>> import com.sun.source.doctree.RawTextTree;
>> import com.sun.source.tree.*;
>> import com.sun.source.util.*;
>> 
>> import java.net.URI;
>> import java.util.*;
>> import javax.lang.model.element.Element;
>> import javax.tools.*;
>> 
>> 
>> public class MarkdownTransformerPositionTest {
>> 
>>     public static void main(String... args) throws Exception {
>>         String source = """
>>                         /// Markdown test
>>                         ///
>>                         /// @author testAuthor
>>                         public class Test {
>>         ...
>
> Uugh.  Noted.

There are two cases that need consideration:
1. A tree that is not modified during the transformation, as in the test case here, so that all nodes should be "as before"
2. A tree that is modified during the transformation, raising the issue of the positions of the new node and any enclosing node

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1480467208

From jjg at openjdk.org  Tue Feb  6 22:05:44 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 6 Feb 2024 22:05:44 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v19]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <Y3aFNXN3o5yr8X0JE59s4DCZ49XEsKn40JntdncuBA8=.5bda22c4-0fd5-4906-864f-43b7fd201788@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  remove unused imports

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/203532b2..2a20c74b

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

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

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

From jjg at openjdk.org  Wed Feb  7 00:20:21 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Feb 2024 00:20:21 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v20]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <QWiZQpzCfBJwXNfe4QZljJnuhzXZeInI0IGt38FI1UM=.8b2e090a-0a75-4eec-9c68-bddbed99014c@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  initial fix for source offset problem

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/2a20c74b..7c631688

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=18-19

  Stats: 32 lines in 3 files changed: 22 ins; 1 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/16388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388

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

From jjg at openjdk.org  Wed Feb  7 00:20:21 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Feb 2024 00:20:21 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v18]
In-Reply-To: <6EEwmjOExugvg9w74ZEhDGZ37af9ott0EdQfTPpU5i4=.2279f998-cf78-47ad-8ef7-8a0da0831be6@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <RIP-4xQbHyEjoPx-PHy-YFMYjq5xq1pjV5SCdVWbQNo=.c6fa9a51-39c3-4ef9-bfe9-1382b9bc016f@github.com>
 <l62YkgsxqBHwYu5AzzN6v-rMMuUARmbIOVdQnlEfQ4c=.5b166998-4f34-4526-96de-3a6ea9030c76@github.com>
 <UVXpzCUqXHCV4DX8cuZ35YSyGI5zWmqItEaxgtV4WVc=.563257a5-d67c-4d38-adf6-8b03b94de37c@github.com>
 <6EEwmjOExugvg9w74ZEhDGZ37af9ott0EdQfTPpU5i4=.2279f998-cf78-47ad-8ef7-8a0da0831be6@github.com>
Message-ID: <43UGpbzrBbISoThN_wch1kQQD0FYeWlAvaTM_pH6dTs=.4250aff5-cc0e-41e9-9a1b-f62fd8989b25@github.com>

On Tue, 6 Feb 2024 19:57:45 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Uugh.  Noted.
>
> There are two cases that need consideration:
> 1. A tree that is not modified during the transformation, as in the test case here, so that all nodes should be "as before"
> 2. A tree that is modified during the transformation, raising the issue of the positions of the new node and any enclosing node

I found what I think was the issue, and I've pushed an initial fix for it, which passes improved versions of existing tests.
I'll follow up with more tests and perhaps include your test case here as well; thanks for providing it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1480710301

From jjg at openjdk.org  Wed Feb  7 00:34:04 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Feb 2024 00:34:04 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v18]
In-Reply-To: <43UGpbzrBbISoThN_wch1kQQD0FYeWlAvaTM_pH6dTs=.4250aff5-cc0e-41e9-9a1b-f62fd8989b25@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <RIP-4xQbHyEjoPx-PHy-YFMYjq5xq1pjV5SCdVWbQNo=.c6fa9a51-39c3-4ef9-bfe9-1382b9bc016f@github.com>
 <l62YkgsxqBHwYu5AzzN6v-rMMuUARmbIOVdQnlEfQ4c=.5b166998-4f34-4526-96de-3a6ea9030c76@github.com>
 <UVXpzCUqXHCV4DX8cuZ35YSyGI5zWmqItEaxgtV4WVc=.563257a5-d67c-4d38-adf6-8b03b94de37c@github.com>
 <6EEwmjOExugvg9w74ZEhDGZ37af9ott0EdQfTPpU5i4=.2279f998-cf78-47ad-8ef7-8a0da0831be6@github.com>
 <43UGpbzrBbISoThN_wch1kQQD0FYeWlAvaTM_pH6dTs=.4250aff5-cc0e-41e9-9a1b-f62fd8989b25@github.com>
Message-ID: <ZCAy44_3fhDhjiKkwhwvAXwRLLN8jzVXxYpFjObedrY=.fe895cdf-352d-464b-8a56-5b73ab4465be@github.com>

On Wed, 7 Feb 2024 00:16:57 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> There are two cases that need consideration:
>> 1. A tree that is not modified during the transformation, as in the test case here, so that all nodes should be "as before"
>> 2. A tree that is modified during the transformation, raising the issue of the positions of the new node and any enclosing node
>
> I found what I think was the issue, and I've pushed an initial fix for it, which passes improved versions of existing tests.
> I'll follow up with more tests and perhaps include your test case here as well; thanks for providing it.

Update: I've added your test case, which now passes OK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1480724330

From jjg at openjdk.org  Wed Feb  7 00:38:59 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Feb 2024 00:38:59 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v21]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <QGBunllNXVQ5XgdRQtV0xjD5F47qn7r3S200rLsWAfs=.959af0c7-8cd7-4715-aad6-41f2a7053625@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  add test case contributed by @lahodaj

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/7c631688..5710c285

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=19-20

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

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

From ihse at openjdk.org  Wed Feb  7 08:46:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 7 Feb 2024 08:46:56 GMT
Subject: RFR: 8325342: Remove unneeded exceptions in compare.sh
In-Reply-To: <kjD_Nd3RkRNJkapLBobcO9Eq31OFzkSM8rHMAaEHolc=.6b6f5a96-d58c-467b-abb5-1e1d806254e5@github.com>
References: <q_YwcRN3VaNpSve_xwZZkZUbMVN-4buHoiN1X-I_8s4=.945a33f3-6331-423e-afdd-bdd00933a474@github.com>
 <kjD_Nd3RkRNJkapLBobcO9Eq31OFzkSM8rHMAaEHolc=.6b6f5a96-d58c-467b-abb5-1e1d806254e5@github.com>
Message-ID: <R8zztXTwk5rJSNBo6LKyUr-TvvgNfY81v5X7_rhXYes=.20fb7a3b-1b87-4492-ad74-cbe25cd0aacf@github.com>

On Tue, 6 Feb 2024 17:54:24 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Over time, we have been better at addressing inconsistencies in the build, but the exceptions put in place in compare.sh have not been updated to reflect this.
>> 
>> This attempts to make sure we only keep those exceptions that are currently actually needed to verify a reproducible build (the primary usecase for the compare script these days).
>> 
>> I also discovered bugs in the script, where mismatches in a zip file did not make us report a failed comparison. I added extra code to make sure we always set the REGRESSION flag whenever we detect a problem.
>
> make/scripts/compare.sh line 298:
> 
>> 296:         | $GREP -v "/hotspot/gtest/server/gtestLauncher" \
>> 297:         | $GREP -v "/hotspot/gtest/server/libjvm.dylib" \
>> 298:         | $SORT | $FILTER)
> 
> This list of exclusion, or at least most of it, isn't for handling exceptions but because those files are handled explicitly by other comparison functions.

I see. I'll split it into two parts then, one that deselects files that are guaranteed to be processed elsewhere, and one to filter out problematic files (currently only the gtest binaries and *.pdb).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17735#discussion_r1481096939

From mli at openjdk.org  Wed Feb  7 14:43:06 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 7 Feb 2024 14:43:06 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v9]
In-Reply-To: <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
Message-ID: <1BPmeP4mK5G40pZ8X6Hu64DXMgQVvBk_CayhmP9Dj5I=.fafa29a2-3ad6-4ac0-9d89-244c739e4598@github.com>

On Thu, 7 Dec 2023 09:30:01 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix potential attribute issue

I could also take a look at it by the end of this month if no one are going to do it.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1932188622

From jkern at openjdk.org  Wed Feb  7 15:56:00 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Wed, 7 Feb 2024 15:56:00 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v9]
In-Reply-To: <Yzf-wMAQDgEIeSJZpHiz8toO2PJrhVSeI4D6O8AZABk=.2ac6a005-a3b4-45fd-aa3b-54f83bbcef1f@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <Yzf-wMAQDgEIeSJZpHiz8toO2PJrhVSeI4D6O8AZABk=.2ac6a005-a3b4-45fd-aa3b-54f83bbcef1f@github.com>
Message-ID: <aXxYle1abHlpTwdPGzF1PGpc9IDQA9-vK7hcBbXcP50=.b1d02804-2541-410e-867f-337510b2da34@github.com>

On Tue, 6 Feb 2024 08:18:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also fix fstatvfs on AIX

My apologies the additional defines 
`#define DIR DIR64`
`#define dirent dirent64`
`#define opendir opendir64`
`#define readdir readdir64`
`#define closedir closedir64`
are not necessary. Indeed they do not react on _LARGE_FILES, but the DIR struct and the functions are automatically 64 when compiling in 64bit mode (-m64) as we do.

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1932343048

From shade at openjdk.org  Wed Feb  7 16:03:57 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 7 Feb 2024 16:03:57 GMT
Subject: RFR: 8325194: GHA: Add macOS M1 testing [v5]
In-Reply-To: <GrRXOT-hiuBaJWl2JU5_gZhLFvisGr1oZm09hK2zGVI=.28c43e47-50d6-46b7-a055-abc5db204c2d@github.com>
References: <AajUHnzAeT8VngtyariR_vfo-FTkoRbv5d1OJsbeuw4=.6eb2d4c3-0260-4d6c-9342-6587dacdc05b@github.com>
 <GrRXOT-hiuBaJWl2JU5_gZhLFvisGr1oZm09hK2zGVI=.28c43e47-50d6-46b7-a055-abc5db204c2d@github.com>
Message-ID: <cOd_jAx0ZpWcj27MQPZyHma4KebQqiJpnLu-pVfz9Ew=.e994c305-070e-4b71-9e36-7baaf7702544@github.com>

On Sat, 3 Feb 2024 21:55:25 GMT, George Adams <gdams at openjdk.org> wrote:

>> Now that macOS M1 executors are [available in GitHub actions](https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/) it makes sense to move the build to run on M1 (rather than cross-compiled) and also enable testing on the platform.
>
> George Adams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify jtreg

Okay, this one regressed GHA for new PRs: https://github.com/stefank/jdk/actions/runs/7817217154/job/21324582843


Run # Build JTReg and move files to the proper locations
realpath: bootjdk/jdk: No such file or directory


I think it slipped testing here, because bootjdk was cached before.

@gdams, please see if you can fix it?

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

PR Comment: https://git.openjdk.org/jdk/pull/17694#issuecomment-1932356208

From jjg at openjdk.org  Wed Feb  7 18:05:58 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Feb 2024 18:05:58 GMT
Subject: RFR: JDK-8325268: Add policy statement to langtools makefiles
 concerning warnings
In-Reply-To: <SDIA7FXQnkrauJHNBE5Ziz5YoRkEdYi5TTUZSKDAiYo=.85170a59-a6aa-4940-b5ad-3cdcdac8d6ab@github.com>
References: <SDIA7FXQnkrauJHNBE5Ziz5YoRkEdYi5TTUZSKDAiYo=.85170a59-a6aa-4940-b5ad-3cdcdac8d6ab@github.com>
Message-ID: <wiGEfp9dnvgvcfkOQc7qFPbkDmdGSocpHqMbO3q4vNc=.296dbbc6-d872-4ddc-a0ef-2189f9dbe05d@github.com>

On Tue, 6 Feb 2024 02:28:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add policy statement about lint warnings to various langtools modules.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17718#pullrequestreview-1868462643

From vromero at openjdk.org  Wed Feb  7 18:05:58 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 7 Feb 2024 18:05:58 GMT
Subject: RFR: JDK-8325268: Add policy statement to langtools makefiles
 concerning warnings
In-Reply-To: <SDIA7FXQnkrauJHNBE5Ziz5YoRkEdYi5TTUZSKDAiYo=.85170a59-a6aa-4940-b5ad-3cdcdac8d6ab@github.com>
References: <SDIA7FXQnkrauJHNBE5Ziz5YoRkEdYi5TTUZSKDAiYo=.85170a59-a6aa-4940-b5ad-3cdcdac8d6ab@github.com>
Message-ID: <7_cvctT07uXpZwxVt3BUnFdN7qbHuxYrhD-9wKBdGGg=.fcf5e6ab-bb66-4342-9fa0-a4b681c73bae@github.com>

On Tue, 6 Feb 2024 02:28:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add policy statement about lint warnings to various langtools modules.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17718#pullrequestreview-1868464016

From darcy at openjdk.org  Wed Feb  7 18:05:59 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 Feb 2024 18:05:59 GMT
Subject: Integrated: JDK-8325268: Add policy statement to langtools makefiles
 concerning warnings
In-Reply-To: <SDIA7FXQnkrauJHNBE5Ziz5YoRkEdYi5TTUZSKDAiYo=.85170a59-a6aa-4940-b5ad-3cdcdac8d6ab@github.com>
References: <SDIA7FXQnkrauJHNBE5Ziz5YoRkEdYi5TTUZSKDAiYo=.85170a59-a6aa-4940-b5ad-3cdcdac8d6ab@github.com>
Message-ID: <X7jJ7y0V9PgToIy8MRYLrn7Aw_6oG3TzvKkA6Hgq5qQ=.16dee8a3-9375-4cee-9cc6-46cb7765afcb@github.com>

On Tue, 6 Feb 2024 02:28:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add policy statement about lint warnings to various langtools modules.

This pull request has now been integrated.

Changeset: 3a1f4d0f
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3a1f4d0f484f4c68e240ca3f2f36730805ee7dc0
Stats:     14 lines in 3 files changed: 12 ins; 0 del; 2 mod

8325268: Add policy statement to langtools makefiles concerning warnings

Reviewed-by: ihse, jjg, vromero

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

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

From jjg at openjdk.org  Wed Feb  7 18:14:24 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Feb 2024 18:14:24 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v22]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <vrwe2U_b9K6EUSg760EHhm3x7sz2tp0D4thYIqknnGw=.e5c1c331-644a-4473-8a8b-d3c8f3128303@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:

 - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3 # Please enter a commit message to explain why this merge is necessary, # especially if it
   merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the commit.
 - add test case contributed by @lahodaj
 - initial fix for source offset problem
 - remove unused imports
 - First pass at remove DocCommentTransformer from the public API.
   
   It is still declared internally, and installed by default, using the service-provider mechanism.
   If the standard impl is not available, an identity transformer is used.
 - updates for "first sentence" issues and tests
 - add info about provenance of `jdk.internal.md` module
 - MarkdownTransformer: tweak doc comments
 - MarkdownTransformer: change `Lower.replaceIter` to be `private final`
 - MarkdownTransformer: use suggested text for using streams
 - ... and 18 more: https://git.openjdk.org/jdk/compare/18e24d06...63dd8bf4

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

Changes: https://git.openjdk.org/jdk/pull/16388/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=21
  Stats: 21713 lines in 193 files changed: 21042 ins; 274 del; 397 mod
  Patch: https://git.openjdk.org/jdk/pull/16388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388

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

From weijun at openjdk.org  Wed Feb  7 19:08:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 7 Feb 2024 19:08:54 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <25rXR-RgzW2Qib1E4ngpo8oG3E6pGJYr42QEWLi1fJw=.75e7164c-04dd-4d73-a44d-85b3a9c50406@github.com>

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

Security changes look fine. Although I don't know how to remove those annotations later. A lot of compatibility impact.

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

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1868572210

From clanger at openjdk.org  Wed Feb  7 19:23:58 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 7 Feb 2024 19:23:58 GMT
Subject: RFR: 8325194: GHA: Add macOS M1 testing [v5]
In-Reply-To: <cOd_jAx0ZpWcj27MQPZyHma4KebQqiJpnLu-pVfz9Ew=.e994c305-070e-4b71-9e36-7baaf7702544@github.com>
References: <AajUHnzAeT8VngtyariR_vfo-FTkoRbv5d1OJsbeuw4=.6eb2d4c3-0260-4d6c-9342-6587dacdc05b@github.com>
 <GrRXOT-hiuBaJWl2JU5_gZhLFvisGr1oZm09hK2zGVI=.28c43e47-50d6-46b7-a055-abc5db204c2d@github.com>
 <cOd_jAx0ZpWcj27MQPZyHma4KebQqiJpnLu-pVfz9Ew=.e994c305-070e-4b71-9e36-7baaf7702544@github.com>
Message-ID: <C5O8pLSu4H09fiZAnEMdYEiI0-ZIeNSt6T6dspndO9A=.ee8c71cf-6676-4c6b-a0a2-ba58939e54cf@github.com>

On Wed, 7 Feb 2024 15:59:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Okay, this one regressed GHA for new PRs: https://github.com/stefank/jdk/actions/runs/7817217154/job/21324582843
> 
> ```
> Run # Build JTReg and move files to the proper locations
> realpath: bootjdk/jdk: No such file or directory
> ```
> 
> I think it slipped testing here, because bootjdk was cached before.
> 
> @gdams, please see if you can fix it?

Looking into it...

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

PR Comment: https://git.openjdk.org/jdk/pull/17694#issuecomment-1932715172

From darcy at openjdk.org  Wed Feb  7 19:28:11 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 Feb 2024 19:28:11 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
 [v2]
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <jp74YWXh1wYnLIE5t-LxJvXUc6CNAs7O-EL_7gAPITw=.cd1f7fff-6c06-4a36-8b45-7277ff553e91@github.com>

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into JDK-8325189
 - JDK-8325189: Enable this-escape javac warning in java.base

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17692/files
  - new: https://git.openjdk.org/jdk/pull/17692/files/8a160a7c..e1d56388

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

  Stats: 5575 lines in 160 files changed: 3404 ins; 1290 del; 881 mod
  Patch: https://git.openjdk.org/jdk/pull/17692.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17692/head:pull/17692

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

From gdams at openjdk.org  Wed Feb  7 19:32:59 2024
From: gdams at openjdk.org (George Adams)
Date: Wed, 7 Feb 2024 19:32:59 GMT
Subject: RFR: 8325194: GHA: Add macOS M1 testing [v5]
In-Reply-To: <C5O8pLSu4H09fiZAnEMdYEiI0-ZIeNSt6T6dspndO9A=.ee8c71cf-6676-4c6b-a0a2-ba58939e54cf@github.com>
References: <AajUHnzAeT8VngtyariR_vfo-FTkoRbv5d1OJsbeuw4=.6eb2d4c3-0260-4d6c-9342-6587dacdc05b@github.com>
 <GrRXOT-hiuBaJWl2JU5_gZhLFvisGr1oZm09hK2zGVI=.28c43e47-50d6-46b7-a055-abc5db204c2d@github.com>
 <cOd_jAx0ZpWcj27MQPZyHma4KebQqiJpnLu-pVfz9Ew=.e994c305-070e-4b71-9e36-7baaf7702544@github.com>
 <C5O8pLSu4H09fiZAnEMdYEiI0-ZIeNSt6T6dspndO9A=.ee8c71cf-6676-4c6b-a0a2-ba58939e54cf@github.com>
Message-ID: <qcSm-CTtG7awZ13RdJWyEjz1xtSVlbBNzIf2Z5aN3mY=.8d9284e6-5b85-486b-b3df-d2fd12dfa6e2@github.com>

On Wed, 7 Feb 2024 19:21:24 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Okay, this one regressed GHA for new PRs: https://github.com/stefank/jdk/actions/runs/7817217154/job/21324582843
>> 
>> 
>> Run # Build JTReg and move files to the proper locations
>> realpath: bootjdk/jdk: No such file or directory
>> 
>> 
>> I think it slipped testing here, because bootjdk was cached before.
>> 
>> @gdams, please see if you can fix it?
>
>> Okay, this one regressed GHA for new PRs: https://github.com/stefank/jdk/actions/runs/7817217154/job/21324582843
>> 
>> ```
>> Run # Build JTReg and move files to the proper locations
>> realpath: bootjdk/jdk: No such file or directory
>> ```
>> 
>> I think it slipped testing here, because bootjdk was cached before.
>> 
>> @gdams, please see if you can fix it?
> 
> Looking into it...

Thanks @RealCLanger, let me know if you'd like me to raise a fix?

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

PR Comment: https://git.openjdk.org/jdk/pull/17694#issuecomment-1932725755

From clanger at openjdk.org  Wed Feb  7 19:33:00 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 7 Feb 2024 19:33:00 GMT
Subject: RFR: 8325194: GHA: Add macOS M1 testing [v5]
In-Reply-To: <GrRXOT-hiuBaJWl2JU5_gZhLFvisGr1oZm09hK2zGVI=.28c43e47-50d6-46b7-a055-abc5db204c2d@github.com>
References: <AajUHnzAeT8VngtyariR_vfo-FTkoRbv5d1OJsbeuw4=.6eb2d4c3-0260-4d6c-9342-6587dacdc05b@github.com>
 <GrRXOT-hiuBaJWl2JU5_gZhLFvisGr1oZm09hK2zGVI=.28c43e47-50d6-46b7-a055-abc5db204c2d@github.com>
Message-ID: <tevQ-DmJMtoYBEEnPeDxYsmL7MPtmDTFJBmNP4mdt9I=.7ab6acce-7017-4969-8d4a-d7f0bc9758ea@github.com>

On Sat, 3 Feb 2024 21:55:25 GMT, George Adams <gdams at openjdk.org> wrote:

>> Now that macOS M1 executors are [available in GitHub actions](https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/) it makes sense to move the build to run on M1 (rather than cross-compiled) and also enable testing on the platform.
>
> George Adams has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify jtreg

Opened [JDK-8325444](https://bugs.openjdk.org/browse/JDK-8325444) and trying a fix in https://github.com/RealCLanger/jdk/actions/runs/7820130826

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

PR Comment: https://git.openjdk.org/jdk/pull/17694#issuecomment-1932726771

From gdams at openjdk.org  Wed Feb  7 19:33:00 2024
From: gdams at openjdk.org (George Adams)
Date: Wed, 7 Feb 2024 19:33:00 GMT
Subject: RFR: 8325194: GHA: Add macOS M1 testing [v5]
In-Reply-To: <tevQ-DmJMtoYBEEnPeDxYsmL7MPtmDTFJBmNP4mdt9I=.7ab6acce-7017-4969-8d4a-d7f0bc9758ea@github.com>
References: <AajUHnzAeT8VngtyariR_vfo-FTkoRbv5d1OJsbeuw4=.6eb2d4c3-0260-4d6c-9342-6587dacdc05b@github.com>
 <GrRXOT-hiuBaJWl2JU5_gZhLFvisGr1oZm09hK2zGVI=.28c43e47-50d6-46b7-a055-abc5db204c2d@github.com>
 <tevQ-DmJMtoYBEEnPeDxYsmL7MPtmDTFJBmNP4mdt9I=.7ab6acce-7017-4969-8d4a-d7f0bc9758ea@github.com>
Message-ID: <_KBDtljvb-7T4xyF6xgA-aL18EU5jsbnMk36I1G3-zo=.c6326977-deed-4a7e-ae02-2c226045d8b2@github.com>

On Wed, 7 Feb 2024 19:29:02 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Opened [JDK-8325444](https://bugs.openjdk.org/browse/JDK-8325444) and trying a fix in https://github.com/RealCLanger/jdk/actions/runs/7820130826

I like your approach, it feels more robust

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

PR Comment: https://git.openjdk.org/jdk/pull/17694#issuecomment-1932728575

From gdams at openjdk.org  Wed Feb  7 19:58:05 2024
From: gdams at openjdk.org (George Adams)
Date: Wed, 7 Feb 2024 19:58:05 GMT
Subject: RFR: 8325444: GHA: JDK-8325194 causes a regression
In-Reply-To: <FMzkS9WftnB4e9fKBVsz669sBsudFpb1GYQRyYJC3bM=.70e69304-9d4b-44a6-a3dd-b7efa8dc3c1e@github.com>
References: <FMzkS9WftnB4e9fKBVsz669sBsudFpb1GYQRyYJC3bM=.70e69304-9d4b-44a6-a3dd-b7efa8dc3c1e@github.com>
Message-ID: <sVb-O561R1bikuw5GCgpAopKIocV5nRa-Css5sfkrBc=.37a6cbf2-a403-4438-8a80-bb3873b9fb16@github.com>

On Wed, 7 Feb 2024 19:50:51 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The [change](https://github.com/openjdk/jdk/commit/d1c82156ba6ede4b798ac15f935289cfcc99d1a0) for [JDK-8325194](https://bugs.openjdk.org/browse/JDK-8325194) broke get-jtreg because the macro to determine the build jdk was not correct.
> 
> I fix this by reverting to the originally proposed way to use `$JAVA_HOME_17_<arch>`. I tried to use the bootstrap JDK in first place with the correct wiring but it turned out that the build of JTReg fails with that version, see [here](https://github.com/RealCLanger/jdk/actions/runs/7820130826/job/21334120478).

Marked as reviewed by gdams (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/17756#pullrequestreview-1868656028

From clanger at openjdk.org  Wed Feb  7 19:58:58 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 7 Feb 2024 19:58:58 GMT
Subject: RFR: 8325194: GHA: Add macOS M1 testing [v5]
In-Reply-To: <_KBDtljvb-7T4xyF6xgA-aL18EU5jsbnMk36I1G3-zo=.c6326977-deed-4a7e-ae02-2c226045d8b2@github.com>
References: <AajUHnzAeT8VngtyariR_vfo-FTkoRbv5d1OJsbeuw4=.6eb2d4c3-0260-4d6c-9342-6587dacdc05b@github.com>
 <GrRXOT-hiuBaJWl2JU5_gZhLFvisGr1oZm09hK2zGVI=.28c43e47-50d6-46b7-a055-abc5db204c2d@github.com>
 <tevQ-DmJMtoYBEEnPeDxYsmL7MPtmDTFJBmNP4mdt9I=.7ab6acce-7017-4969-8d4a-d7f0bc9758ea@github.com>
 <_KBDtljvb-7T4xyF6xgA-aL18EU5jsbnMk36I1G3-zo=.c6326977-deed-4a7e-ae02-2c226045d8b2@github.com>
Message-ID: <dzTGibNMfUwxTVECnkUEVN0jJJUZkdYPY6dTu3Yzogg=.c11ced21-7afb-488d-963c-96e6cfa61c7a@github.com>

On Wed, 7 Feb 2024 19:30:17 GMT, George Adams <gdams at openjdk.org> wrote:

> > Opened [JDK-8325444](https://bugs.openjdk.org/browse/JDK-8325444) and trying a fix in https://github.com/RealCLanger/jdk/actions/runs/7820130826
> 
> I like your approach, it feels more robust

Yeah, but didn't work. Here's a PR with something working (your initial version ?): https://github.com/openjdk/jdk/pull/17756

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

PR Comment: https://git.openjdk.org/jdk/pull/17694#issuecomment-1932766071

From clanger at openjdk.org  Wed Feb  7 19:58:05 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 7 Feb 2024 19:58:05 GMT
Subject: RFR: 8325444: GHA: JDK-8325194 causes a regression
Message-ID: <FMzkS9WftnB4e9fKBVsz669sBsudFpb1GYQRyYJC3bM=.70e69304-9d4b-44a6-a3dd-b7efa8dc3c1e@github.com>

The [change](https://github.com/openjdk/jdk/commit/d1c82156ba6ede4b798ac15f935289cfcc99d1a0) for [JDK-8325194](https://bugs.openjdk.org/browse/JDK-8325194) broke get-jtreg because the macro to determine the build jdk was not correct.

I fix this by reverting to the originally proposed way to use `$JAVA_HOME_17_<arch>`. I tried to use the bootstrap JDK in first place with the correct wiring but it turned out that the build of JTReg fails with that version, see [here](https://github.com/RealCLanger/jdk/actions/runs/7820130826/job/21334120478).

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

Commit messages:
 - JDK-8325444

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

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

From darcy at openjdk.org  Wed Feb  7 20:08:19 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 Feb 2024 20:08:19 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
 [v2]
In-Reply-To: <jp74YWXh1wYnLIE5t-LxJvXUc6CNAs7O-EL_7gAPITw=.cd1f7fff-6c06-4a36-8b45-7277ff553e91@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
 <jp74YWXh1wYnLIE5t-LxJvXUc6CNAs7O-EL_7gAPITw=.cd1f7fff-6c06-4a36-8b45-7277ff553e91@github.com>
Message-ID: <FYWvDDXgiscOfzZp5HB6c8ynDIJsRaDOjkzxtgbaPjo=.fde686ba-c4aa-4857-8d70-d77e3fcbd25a@github.com>

On Wed, 7 Feb 2024 19:28:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8325189
>  - JDK-8325189: Enable this-escape javac warning in java.base

Thanks all for the reviews. Will integrate now after a sync with mainline and successful cross-platform build run.

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

PR Comment: https://git.openjdk.org/jdk/pull/17692#issuecomment-1932778005

From darcy at openjdk.org  Wed Feb  7 20:08:18 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 Feb 2024 20:08:18 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
 [v3]
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <L7nEoVs-6ael9bm5bVO8_DaOxMprSmoQGJSdqdPgs58=.f1307b51-c620-438d-bab7-894500bb991d@github.com>

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into JDK-8325189
 - Merge branch 'master' into JDK-8325189
 - JDK-8325189: Enable this-escape javac warning in java.base

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17692/files
  - new: https://git.openjdk.org/jdk/pull/17692/files/e1d56388..bc6cdfc8

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

  Stats: 1057 lines in 91 files changed: 598 ins; 167 del; 292 mod
  Patch: https://git.openjdk.org/jdk/pull/17692.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17692/head:pull/17692

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

From darcy at openjdk.org  Wed Feb  7 20:08:19 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 Feb 2024 20:08:19 GMT
Subject: Integrated: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
Message-ID: <LkBQc7hq4weFI6vUgKm3EZehMXS9-BzY-Gc9rhFAu-I=.84d1d82b-7522-484d-a48d-256f3c0ce5c2@github.com>

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

This pull request has now been integrated.

Changeset: fbd15b20
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fbd15b20878b276ccd41128116f73b91b6d4c159
Stats:     151 lines in 93 files changed: 149 ins; 0 del; 2 mod

8325189: Enable this-escape javac warning in java.base

Reviewed-by: alanb, erikj, naoto, smarks, ihse, joehw, lancea, weijun

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

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

From darcy at openjdk.org  Wed Feb  7 20:40:59 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 Feb 2024 20:40:59 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
 [v3]
In-Reply-To: <25rXR-RgzW2Qib1E4ngpo8oG3E6pGJYr42QEWLi1fJw=.75e7164c-04dd-4d73-a44d-85b3a9c50406@github.com>
References: <oUXj4VqjvBsayE0K1XWbQtNN3eesxNIvf69MfwIuYzA=.7dbbd2f4-a951-4fe0-9820-506e00a2202c@github.com>
 <25rXR-RgzW2Qib1E4ngpo8oG3E6pGJYr42QEWLi1fJw=.75e7164c-04dd-4d73-a44d-85b3a9c50406@github.com>
Message-ID: <WhC6zrDWuc-eTsDycVlO2KbUhPUjwWssLrAxlRlntSw=.5dc6d8e1-06b8-48ef-b2b1-c75a602ba6d7@github.com>

On Wed, 7 Feb 2024 19:06:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Security changes look fine. Although I don't know how to remove those annotations later. A lot of compatibility impact.

In case you didn't see it, the warning message are listed in an attachment on [JDK-8325263](https://bugs.openjdk.org/browse/JDK-8325263).

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

PR Comment: https://git.openjdk.org/jdk/pull/17692#issuecomment-1932829588

From duke at openjdk.org  Thu Feb  8 04:44:02 2024
From: duke at openjdk.org (Sam James)
Date: Thu, 8 Feb 2024 04:44:02 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
In-Reply-To: <U-SS1eldBMrY51y5s7bn7Ehh4vg4tZncIz3bbFZ_Uv4=.03d7aaa1-c25d-4d7a-a1c9-b5b5c139d960@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
 <Ve5i_GI5N-X0wSVaLavvfy62e6XL_jlN4Qs_CkbS3fs=.88f0d499-8edc-48c6-b92d-8d8f5d27c991@github.com>
 <160IUiEFfgHTenlTpN4C2yL2oMdZPpV1fsK0YysXcr8=.cf71797d-9e10-4713-804e-368b481efde0@github.com>
 <U-SS1eldBMrY51y5s7bn7Ehh4vg4tZncIz3bbFZ_Uv4=.03d7aaa1-c25d-4d7a-a1c9-b5b5c139d960@github.com>
Message-ID: <FAuF_ncQ0_VNTlREed1TeyHIsBX-ER6SVjbc30CLKiI=.b9ab548a-8840-4804-a674-a096297e4bdc@github.com>

On Fri, 2 Feb 2024 15:49:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I wrote earlier:
>> 
>>> There is one change that merit highlighting: In src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c, I kept the dlsym lookup for openat64, fstatat64 and fdopendir64, on non-BSD OSes (i.e. Linux and AIX), and on AIX, respectively. This seems to me to be the safest choice, as we do not need to know if a lookup of openat would yield a 32-bit or a 64-bit version. (I frankly don't know, but I'm guessing it would yield the 32-bit version.)
>
> Basically, my understanding is that a call to "openat" in the source file will be converted into a call to openat64 on 32-bit platforms. When we look up the function using dlsym, I assume we need to find the 64-bit version directly. 
> 
> Even if this is incorrect, it seems at least *safe* to do it this way.

The redirection is done via aliases in the headers, so you're right. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1482403071

From ihse at openjdk.org  Thu Feb  8 07:33:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 8 Feb 2024 07:33:52 GMT
Subject: RFR: 8325444: GHA: JDK-8325194 causes a regression
In-Reply-To: <FMzkS9WftnB4e9fKBVsz669sBsudFpb1GYQRyYJC3bM=.70e69304-9d4b-44a6-a3dd-b7efa8dc3c1e@github.com>
References: <FMzkS9WftnB4e9fKBVsz669sBsudFpb1GYQRyYJC3bM=.70e69304-9d4b-44a6-a3dd-b7efa8dc3c1e@github.com>
Message-ID: <PlGvrqdXOQLOSpdEzXthpLHwgWEfjMkisti6FjBnoOE=.c7995e09-7eab-468e-a5bd-c4b4d62908ad@github.com>

On Wed, 7 Feb 2024 19:50:51 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The [change](https://github.com/openjdk/jdk/commit/d1c82156ba6ede4b798ac15f935289cfcc99d1a0) for [JDK-8325194](https://bugs.openjdk.org/browse/JDK-8325194) broke get-jtreg because the way to determine the build jdk was not correct.
> 
> I then tried to use the bootstrap JDK with the correct wiring but it turned out that the build of JTReg fails with the current JDK, see [here](https://github.com/RealCLanger/jdk/actions/runs/7820130826/job/21334120478).
> 
> So I propose to fix it by going to the originally proposed solution using `$JAVA_HOME_17_<arch>`.

I don't like this approach. There must be better ways to achieve this, like inputting the correct value as input to the action, or setting it as a global gh variable. Where does even the `$JAVA_HOME_17_arm64` come from? Is it provided by GH? I don't recall setting variables with that weird case style in our GHA files.

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

PR Comment: https://git.openjdk.org/jdk/pull/17756#issuecomment-1933499696

From clanger at openjdk.org  Thu Feb  8 07:43:58 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 8 Feb 2024 07:43:58 GMT
Subject: RFR: 8325444: GHA: JDK-8325194 causes a regression
In-Reply-To: <PlGvrqdXOQLOSpdEzXthpLHwgWEfjMkisti6FjBnoOE=.c7995e09-7eab-468e-a5bd-c4b4d62908ad@github.com>
References: <FMzkS9WftnB4e9fKBVsz669sBsudFpb1GYQRyYJC3bM=.70e69304-9d4b-44a6-a3dd-b7efa8dc3c1e@github.com>
 <PlGvrqdXOQLOSpdEzXthpLHwgWEfjMkisti6FjBnoOE=.c7995e09-7eab-468e-a5bd-c4b4d62908ad@github.com>
Message-ID: <Gdjn_L5NyCWqkFjNnRdzsCRn0dXWvWFYn7XC-uhOwXs=.6230eaa6-c8eb-4717-b783-40b56d3ec7f2@github.com>

On Thu, 8 Feb 2024 07:31:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I don't like this approach. There must be better ways to achieve this, like inputting the correct value as input to the action, or setting it as a global gh variable. Where does even the `$JAVA_HOME_17_arm64` come from? Is it provided by GH? I don't recall setting variables with that weird case style in our GHA files.

I think (as @gdams told me) these are paths to the Java installation in the Github Runners which happen to be there.

I agree, to avoid the if statement, we could properly set it as input to get-jtreg.

We probably could also use the setup-java action here - however, this will then lead to downloading another JDK, not sure if this is a performance concern.

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

PR Comment: https://git.openjdk.org/jdk/pull/17756#issuecomment-1933513448

From ihse at openjdk.org  Thu Feb  8 07:44:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 8 Feb 2024 07:44:18 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10]
In-Reply-To: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
Message-ID: <pxn7GqRax1tb7sEK0Q1KnEalowEaZjSUp-O6h4khF78=.9a069feb-3598-4253-a0ac-f87480628802@github.com>

> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Once more, remove AIX dirent64 et al defines

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17538/files
  - new: https://git.openjdk.org/jdk/pull/17538/files/1fd34b10..8a71e3b6

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

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

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

From duke at openjdk.org  Thu Feb  8 07:44:18 2024
From: duke at openjdk.org (Sam James)
Date: Thu, 8 Feb 2024 07:44:18 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10]
In-Reply-To: <pxn7GqRax1tb7sEK0Q1KnEalowEaZjSUp-O6h4khF78=.9a069feb-3598-4253-a0ac-f87480628802@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <pxn7GqRax1tb7sEK0Q1KnEalowEaZjSUp-O6h4khF78=.9a069feb-3598-4253-a0ac-f87480628802@github.com>
Message-ID: <UBza7vF2ZUw0v3bvpOPzjZqT0jxoc12oP6CrrNI2TOE=.d7aada43-1298-4acd-9de3-a23fb4c4343a@github.com>

On Thu, 8 Feb 2024 07:41:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Once more, remove AIX dirent64 et al defines

Marked as reviewed by thesamesam at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/17538#pullrequestreview-1869449960

From ihse at openjdk.org  Thu Feb  8 07:44:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 8 Feb 2024 07:44:18 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
In-Reply-To: <XYZD6zO-3fdkLSnGf2WVRgIC1v0VmdKtl0da9h_Mofg=.58cf03dd-8e2c-4608-90f1-01992ba9cd4d@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
 <js04r6dJGMDL_c1dfpNEGvhDD53Y1H2JRCJxtJ7Xtjs=.d1b19610-206b-4809-a559-842c69f90f59@github.com>
 <tWCBjZIzUFDJxIec37zQeyB3LjUHXIy0NpFDMpTf5-Q=.71f4ada6-3dda-4f0d-8ecf-178c154eb1c3@github.com>
 <XYZD6zO-3fdkLSnGf2WVRgIC1v0VmdKtl0da9h_Mofg=.58cf03dd-8e2c-4608-90f1-01992ba9cd4d@github.com>
Message-ID: <JMYVVM_2taHSChuae0agMHo2Rhk62Xp8zm2WsyZsRtc=.8ce09477-adda-4e30-baaa-cf5063b10063@github.com>

On Tue, 6 Feb 2024 08:05:14 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>>> I hope finally the AIX part of this PR is done.
>> 
>> Thanks for the AIX related effort ; I put it again into our internal build/test queue.
>
>> 
>> Thanks for the AIX related effort ; I put it again into our internal build/test queue.
> 
> With the latest commit the build again fails on AIX with this error
> 
> /jdk/src/java.base/unix/native/libnio/ch/UnixFileDispatcherImpl.c:381:27: error: incompatible pointer types passing 'struct statvfs64 *' to parameter of type 'struct statvfs *' [-Werror,-Wincompatible-pointer-types]
>     result = fstatvfs(fd, &file_stat);
>                           ^~~~~~~~~~
> /usr/include/sys/statvfs.h:102:42: note: passing argument to parameter here
> extern int fstatvfs(int, struct statvfs *);

Well, well... The code at least looks cleaner without these AIX defines, so I really hope that this is the end of the AIX saga, at the `n+1`th time. @MBaesken Can you rerun AIX testing with the latest commit?

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1933513366

From duke at openjdk.org  Thu Feb  8 07:44:18 2024
From: duke at openjdk.org (Sam James)
Date: Thu, 8 Feb 2024 07:44:18 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10]
In-Reply-To: <Tk-oYD9tIeVq4hEwn3_vHmJrAErya7_lpIzKcotYdn0=.4090e8b8-0107-4662-b674-f49f92cfc499@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
 <Ve5i_GI5N-X0wSVaLavvfy62e6XL_jlN4Qs_CkbS3fs=.88f0d499-8edc-48c6-b92d-8d8f5d27c991@github.com>
 <Tk-oYD9tIeVq4hEwn3_vHmJrAErya7_lpIzKcotYdn0=.4090e8b8-0107-4662-b674-f49f92cfc499@github.com>
Message-ID: <7tII90EgHAAJH2eHwSx0CFV5smD9VXSUx5ffVtUtnWc=.c39a6845-2f40-4c57-bd0e-200cf77ccb28@github.com>

On Tue, 6 Feb 2024 16:10:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/modules/jdk.hotspot.agent/Lib.gmk line 31:
>> 
>>> 29: 
>>> 30: ifeq ($(call isTargetOs, linux), true)
>>> 31:   SA_CFLAGS := -D_FILE_OFFSET_BITS=64
>> 
>> We have two choices to feel a bit more comfortable:
>> 1) We unconditionally `static_assert` in a few places for large `off_t`, or
>> 2) We only do it for platforms we know definitely support F_O_B and aren't AIX (which we've handled separately).
>> 
>> Not sure that's strictly necessary though. Also, if something understands LARGEFILE*_SOURCE, then it probably understood F_O_B, or at least has some macro to control it. Just thinking aloud.
>
> @thesamesam Do you want a `static_assert`? As I said, please let me know where you want to put it. I don't think it provides much, but if it makes you feel more comfortable, I'm okay with adding it.

Sorry! I think I'm okay with it as-is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1482529665

From shade at openjdk.org  Thu Feb  8 08:27:54 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 8 Feb 2024 08:27:54 GMT
Subject: RFR: 8325444: GHA: JDK-8325194 causes a regression
In-Reply-To: <FMzkS9WftnB4e9fKBVsz669sBsudFpb1GYQRyYJC3bM=.70e69304-9d4b-44a6-a3dd-b7efa8dc3c1e@github.com>
References: <FMzkS9WftnB4e9fKBVsz669sBsudFpb1GYQRyYJC3bM=.70e69304-9d4b-44a6-a3dd-b7efa8dc3c1e@github.com>
Message-ID: <4Kx-pwiHCY2aiutQ5gaxgyT9nQ7gsRB6vJLW4MYJKN4=.8e8f913f-fe11-44f1-b530-9fd670d00ed8@github.com>

On Wed, 7 Feb 2024 19:50:51 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The [change](https://github.com/openjdk/jdk/commit/d1c82156ba6ede4b798ac15f935289cfcc99d1a0) for [JDK-8325194](https://bugs.openjdk.org/browse/JDK-8325194) broke get-jtreg because the way to determine the build jdk was not correct.
> 
> I then tried to use the bootstrap JDK with the correct wiring but it turned out that the build of JTReg fails with the current JDK, see [here](https://github.com/RealCLanger/jdk/actions/runs/7820130826/job/21334120478).
> 
> So I propose to fix it by going to the originally proposed solution using `$JAVA_HOME_17_<arch>`.

Looks good.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17756#pullrequestreview-1869529331

From clanger at openjdk.org  Thu Feb  8 08:55:55 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 8 Feb 2024 08:55:55 GMT
Subject: RFR: 8325444: GHA: JDK-8325194 causes a regression
In-Reply-To: <Gdjn_L5NyCWqkFjNnRdzsCRn0dXWvWFYn7XC-uhOwXs=.6230eaa6-c8eb-4717-b783-40b56d3ec7f2@github.com>
References: <FMzkS9WftnB4e9fKBVsz669sBsudFpb1GYQRyYJC3bM=.70e69304-9d4b-44a6-a3dd-b7efa8dc3c1e@github.com>
 <PlGvrqdXOQLOSpdEzXthpLHwgWEfjMkisti6FjBnoOE=.c7995e09-7eab-468e-a5bd-c4b4d62908ad@github.com>
 <Gdjn_L5NyCWqkFjNnRdzsCRn0dXWvWFYn7XC-uhOwXs=.6230eaa6-c8eb-4717-b783-40b56d3ec7f2@github.com>
Message-ID: <wJJ0nxx8jZK9Sstz3kDt6Y_x_w_ARr_EjTG3AHYFDwg=.91bd963b-d539-4656-ac07-8afe898d738c@github.com>

On Thu, 8 Feb 2024 07:40:50 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> > I don't like this approach. There must be better ways to achieve this, like inputting the correct value as input to the action, or setting it as a global gh variable. Where does even the `$JAVA_HOME_17_arm64` come from? Is it provided by GH? I don't recall setting variables with that weird case style in our GHA files.
> 
> I think (as @gdams told me) these are paths to the Java installation in the Github Runners which happen to be there.
> 
> I agree, to avoid the if statement, we could properly set it as input to get-jtreg.
> 
> We probably could also use the setup-java action here - however, this will then lead to downloading another JDK, not sure if this is a performance concern.

@magicus I looked a bit more into the alternatives. So, regarding using the correct value as input to the action, I actually don't see that it buys us anything. We'd have switch statements further up when invoking the actions and we'll likely have even more of them.

And as for setup-java, this also would only set up a `JAVA_HOME_{{ MAJOR_VERSION }}_{{ ARCHITECTURE }}` environment which we'd have to reference then. So no gain.

Unless you have some great other idea, I don't see how we could resolve this more elegantly.

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

PR Comment: https://git.openjdk.org/jdk/pull/17756#issuecomment-1933615018

From shade at openjdk.org  Thu Feb  8 09:02:53 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 8 Feb 2024 09:02:53 GMT
Subject: RFR: 8325444: GHA: JDK-8325194 causes a regression
In-Reply-To: <FMzkS9WftnB4e9fKBVsz669sBsudFpb1GYQRyYJC3bM=.70e69304-9d4b-44a6-a3dd-b7efa8dc3c1e@github.com>
References: <FMzkS9WftnB4e9fKBVsz669sBsudFpb1GYQRyYJC3bM=.70e69304-9d4b-44a6-a3dd-b7efa8dc3c1e@github.com>
Message-ID: <hTUgz0LFs__gul2yXAqCm3IsUBBzbZ57aI0a5W6qq7E=.26dbb551-d7da-4464-8c15-999e611cfb69@github.com>

On Wed, 7 Feb 2024 19:50:51 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The [change](https://github.com/openjdk/jdk/commit/d1c82156ba6ede4b798ac15f935289cfcc99d1a0) for [JDK-8325194](https://bugs.openjdk.org/browse/JDK-8325194) broke get-jtreg because the way to determine the build jdk was not correct.
> 
> I then tried to use the bootstrap JDK with the correct wiring but it turned out that the build of JTReg fails with the current JDK, see [here](https://github.com/RealCLanger/jdk/actions/runs/7820130826/job/21334120478).
> 
> So I propose to fix it by going to the originally proposed solution using `$JAVA_HOME_17_<arch>`.

I would prefer us to unbreak GHA for everyone first, and then look for the cleaner solutions to this problem. Current fix, while ugly, is essentially what we did before: using the runner image var. The `JAVA_HOME_17_arm64` is documented here for `macos-14` runner image: https://github.com/actions/runner-images/blob/main/images/macos/macos-14-arm64-Readme.md

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

PR Comment: https://git.openjdk.org/jdk/pull/17756#issuecomment-1933625985

From jkern at openjdk.org  Thu Feb  8 09:06:03 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 8 Feb 2024 09:06:03 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10]
In-Reply-To: <pxn7GqRax1tb7sEK0Q1KnEalowEaZjSUp-O6h4khF78=.9a069feb-3598-4253-a0ac-f87480628802@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <pxn7GqRax1tb7sEK0Q1KnEalowEaZjSUp-O6h4khF78=.9a069feb-3598-4253-a0ac-f87480628802@github.com>
Message-ID: <ran4RH4U4aZqbo5qhnTVflV7u6ZnxSgu1xetJDWQywE=.8009f47b-9355-4280-bfa6-9d67c7d4454b@github.com>

On Thu, 8 Feb 2024 07:44:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Once more, remove AIX dirent64 et al defines

And also `#define statvfs statvfs64` is not necessary with the same explanation as  for the `opendir` defines above -- sorry again.

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1933630674

From mbaesken at openjdk.org  Thu Feb  8 09:20:00 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 8 Feb 2024 09:20:00 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
In-Reply-To: <XYZD6zO-3fdkLSnGf2WVRgIC1v0VmdKtl0da9h_Mofg=.58cf03dd-8e2c-4608-90f1-01992ba9cd4d@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <bSF5QTGkmOZeHr7qQptaEf6oIepHPPZ4UK0tfrvdY34=.35ca8fc5-5803-488a-95df-bb3e76fb60a4@github.com>
 <js04r6dJGMDL_c1dfpNEGvhDD53Y1H2JRCJxtJ7Xtjs=.d1b19610-206b-4809-a559-842c69f90f59@github.com>
 <tWCBjZIzUFDJxIec37zQeyB3LjUHXIy0NpFDMpTf5-Q=.71f4ada6-3dda-4f0d-8ecf-178c154eb1c3@github.com>
 <XYZD6zO-3fdkLSnGf2WVRgIC1v0VmdKtl0da9h_Mofg=.58cf03dd-8e2c-4608-90f1-01992ba9cd4d@github.com>
Message-ID: <5GBUr8CF3X7ZZYPezmBQUzuWQZuk-pXRrdkS4PX6zeE=.28790345-6e6a-4b10-8767-1b3f8b44754b@github.com>

On Tue, 6 Feb 2024 08:05:14 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>>> I hope finally the AIX part of this PR is done.
>> 
>> Thanks for the AIX related effort ; I put it again into our internal build/test queue.
>
>> 
>> Thanks for the AIX related effort ; I put it again into our internal build/test queue.
> 
> With the latest commit the build again fails on AIX with this error
> 
> /jdk/src/java.base/unix/native/libnio/ch/UnixFileDispatcherImpl.c:381:27: error: incompatible pointer types passing 'struct statvfs64 *' to parameter of type 'struct statvfs *' [-Werror,-Wincompatible-pointer-types]
>     result = fstatvfs(fd, &file_stat);
>                           ^~~~~~~~~~
> /usr/include/sys/statvfs.h:102:42: note: passing argument to parameter here
> extern int fstatvfs(int, struct statvfs *);

> Well, well... The code at least looks cleaner without these AIX defines, so I really hope that this is the end of the AIX saga, at the `n+1`th time. @MBaesken Can you rerun AIX testing with the latest commit?

Latest commit looks still good on AIX.

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1933652124

From gdams at openjdk.org  Thu Feb  8 11:34:04 2024
From: gdams at openjdk.org (George Adams)
Date: Thu, 8 Feb 2024 11:34:04 GMT
Subject: RFR: 8325444: GHA: JDK-8325194 causes a regression
In-Reply-To: <FMzkS9WftnB4e9fKBVsz669sBsudFpb1GYQRyYJC3bM=.70e69304-9d4b-44a6-a3dd-b7efa8dc3c1e@github.com>
References: <FMzkS9WftnB4e9fKBVsz669sBsudFpb1GYQRyYJC3bM=.70e69304-9d4b-44a6-a3dd-b7efa8dc3c1e@github.com>
Message-ID: <Qcj6g9hCX52BgSTjpxlqdgFKrGo2bQV9ZCqCCJqijGg=.c2a9ab4d-8f86-4166-9181-d44d1dea0c15@github.com>

On Wed, 7 Feb 2024 19:50:51 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The [change](https://github.com/openjdk/jdk/commit/d1c82156ba6ede4b798ac15f935289cfcc99d1a0) for [JDK-8325194](https://bugs.openjdk.org/browse/JDK-8325194) broke get-jtreg because the way to determine the build jdk was not correct.
> 
> I then tried to use the bootstrap JDK with the correct wiring but it turned out that the build of JTReg fails with the current JDK, see [here](https://github.com/RealCLanger/jdk/actions/runs/7820130826/job/21334120478).
> 
> So I propose to fix it by going to the originally proposed solution using `$JAVA_HOME_17_<arch>`.

Noting the discussion here: https://github.com/actions/runner-images/discussions/9266

GitHub are considering removing the architecture prefix

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

PR Comment: https://git.openjdk.org/jdk/pull/17756#issuecomment-1933883736

From clanger at openjdk.org  Thu Feb  8 13:33:05 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 8 Feb 2024 13:33:05 GMT
Subject: RFR: 8325444: GHA: JDK-8325194 causes a regression
In-Reply-To: <PlGvrqdXOQLOSpdEzXthpLHwgWEfjMkisti6FjBnoOE=.c7995e09-7eab-468e-a5bd-c4b4d62908ad@github.com>
References: <FMzkS9WftnB4e9fKBVsz669sBsudFpb1GYQRyYJC3bM=.70e69304-9d4b-44a6-a3dd-b7efa8dc3c1e@github.com>
 <PlGvrqdXOQLOSpdEzXthpLHwgWEfjMkisti6FjBnoOE=.c7995e09-7eab-468e-a5bd-c4b4d62908ad@github.com>
Message-ID: <hp5kQiS2KLNYmFdhkJQJKMwZllsrK_bw_Q2sopfuDck=.eec55a5f-9326-4898-b3eb-d12e467440b9@github.com>

On Thu, 8 Feb 2024 07:31:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The [change](https://github.com/openjdk/jdk/commit/d1c82156ba6ede4b798ac15f935289cfcc99d1a0) for [JDK-8325194](https://bugs.openjdk.org/browse/JDK-8325194) broke get-jtreg because the way to determine the build jdk was not correct.
>> 
>> I then tried to use the bootstrap JDK with the correct wiring but it turned out that the build of JTReg fails with the current JDK, see [here](https://github.com/RealCLanger/jdk/actions/runs/7820130826/job/21334120478).
>> 
>> So I propose to fix it by going to the originally proposed solution using `$JAVA_HOME_17_<arch>`.
>
> I don't like this approach. There must be better ways to achieve this, like inputting the correct value as input to the action, or setting it as a global gh variable. Where does even the `$JAVA_HOME_17_arm64` come from? Is it provided by GH? I don't recall setting variables with that weird case style in our GHA files.

OK, I'm ready to integrate. Waiting for blessing from @magicus.

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

PR Comment: https://git.openjdk.org/jdk/pull/17756#issuecomment-1934128826

From ihse at openjdk.org  Thu Feb  8 13:42:07 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 8 Feb 2024 13:42:07 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10]
In-Reply-To: <ran4RH4U4aZqbo5qhnTVflV7u6ZnxSgu1xetJDWQywE=.8009f47b-9355-4280-bfa6-9d67c7d4454b@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <pxn7GqRax1tb7sEK0Q1KnEalowEaZjSUp-O6h4khF78=.9a069feb-3598-4253-a0ac-f87480628802@github.com>
 <ran4RH4U4aZqbo5qhnTVflV7u6ZnxSgu1xetJDWQywE=.8009f47b-9355-4280-bfa6-9d67c7d4454b@github.com>
Message-ID: <kuzR3C65ig8LM8fsxURLO0SCacaIJtXkhzTbNZVEpIk=.24e33332-348b-4429-856d-66851df8435b@github.com>

On Thu, 8 Feb 2024 09:03:10 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Once more, remove AIX dirent64 et al defines
>
> And also `#define statvfs statvfs64` is not necessary with the same explanation as  for the `opendir` defines above -- sorry again.
> The very only difference between statvfs and statvfs64 is that the filesystem ID field in statvfs has a width of 8 Bytes, while in statvfs64 it has a width of 16 Bytes.

@JoKern65 So what about `#define fstatvfs fstatvfs64`? Is that still needed? If so, I could not be bothered to make another change. Otherwise, we can get rid of *all* AIX 64-bit redefines, and then I'll (probably) do it.

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1934144258

From ihse at openjdk.org  Thu Feb  8 13:49:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 8 Feb 2024 13:49:03 GMT
Subject: RFR: 8325444: GHA: JDK-8325194 causes a regression
In-Reply-To: <FMzkS9WftnB4e9fKBVsz669sBsudFpb1GYQRyYJC3bM=.70e69304-9d4b-44a6-a3dd-b7efa8dc3c1e@github.com>
References: <FMzkS9WftnB4e9fKBVsz669sBsudFpb1GYQRyYJC3bM=.70e69304-9d4b-44a6-a3dd-b7efa8dc3c1e@github.com>
Message-ID: <efIud260eXvWqigh8hD4U9EGiiBrcqRdJnYYL4va8nY=.1ef9b284-3199-4a80-8f11-c6633cc6d014@github.com>

On Wed, 7 Feb 2024 19:50:51 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The [change](https://github.com/openjdk/jdk/commit/d1c82156ba6ede4b798ac15f935289cfcc99d1a0) for [JDK-8325194](https://bugs.openjdk.org/browse/JDK-8325194) broke get-jtreg because the way to determine the build jdk was not correct.
> 
> I then tried to use the bootstrap JDK with the correct wiring but it turned out that the build of JTReg fails with the current JDK, see [here](https://github.com/RealCLanger/jdk/actions/runs/7820130826/job/21334120478).
> 
> So I propose to fix it by going to the originally proposed solution using `$JAVA_HOME_17_<arch>`.

Okay, whatever.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17756#pullrequestreview-1870266919

From clanger at openjdk.org  Thu Feb  8 14:08:01 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 8 Feb 2024 14:08:01 GMT
Subject: Integrated: 8325444: GHA: JDK-8325194 causes a regression
In-Reply-To: <FMzkS9WftnB4e9fKBVsz669sBsudFpb1GYQRyYJC3bM=.70e69304-9d4b-44a6-a3dd-b7efa8dc3c1e@github.com>
References: <FMzkS9WftnB4e9fKBVsz669sBsudFpb1GYQRyYJC3bM=.70e69304-9d4b-44a6-a3dd-b7efa8dc3c1e@github.com>
Message-ID: <tCCSCrsjRJgMxypswWjWuQyFa39jOsLI1uF5pUe1BhE=.3facab44-20d2-48e1-b593-fbc8cfab3f8a@github.com>

On Wed, 7 Feb 2024 19:50:51 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The [change](https://github.com/openjdk/jdk/commit/d1c82156ba6ede4b798ac15f935289cfcc99d1a0) for [JDK-8325194](https://bugs.openjdk.org/browse/JDK-8325194) broke get-jtreg because the way to determine the build jdk was not correct.
> 
> I then tried to use the bootstrap JDK with the correct wiring but it turned out that the build of JTReg fails with the current JDK, see [here](https://github.com/RealCLanger/jdk/actions/runs/7820130826/job/21334120478).
> 
> So I propose to fix it by going to the originally proposed solution using `$JAVA_HOME_17_<arch>`.

This pull request has now been integrated.

Changeset: 3c91b59e
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3c91b59ef9c992718d73f2fc9fa50ad2ead78208
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

8325444: GHA: JDK-8325194 causes a regression

Reviewed-by: gdams, shade, ihse

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

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

From jkern at openjdk.org  Thu Feb  8 14:50:08 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 8 Feb 2024 14:50:08 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10]
In-Reply-To: <ran4RH4U4aZqbo5qhnTVflV7u6ZnxSgu1xetJDWQywE=.8009f47b-9355-4280-bfa6-9d67c7d4454b@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <pxn7GqRax1tb7sEK0Q1KnEalowEaZjSUp-O6h4khF78=.9a069feb-3598-4253-a0ac-f87480628802@github.com>
 <ran4RH4U4aZqbo5qhnTVflV7u6ZnxSgu1xetJDWQywE=.8009f47b-9355-4280-bfa6-9d67c7d4454b@github.com>
Message-ID: <XVYdfEqu9JnUHo2IIYd3mRN3czS1RvhdHmvgCSYrMKU=.1caabb1d-787b-4415-84c0-1ac3362d1dbf@github.com>

On Thu, 8 Feb 2024 09:03:10 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Once more, remove AIX dirent64 et al defines
>
> And also `#define statvfs statvfs64` is not necessary with the same explanation as  for the `opendir` defines above -- sorry again.
> The very only difference between statvfs and statvfs64 is that the filesystem ID field in statvfs has a width of 8 Bytes, while in statvfs64 it has a width of 16 Bytes.

> @JoKern65 So what about `#define fstatvfs fstatvfs64`? Is that still needed? If so, I could not be bothered to make another change. Otherwise, we can get rid of _all_ AIX 64-bit redefines, and then I'll (probably) do it.

Same as `statvfs`. Only the file system ID field is smaller.

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1934275624

From prappo at openjdk.org  Thu Feb  8 16:33:13 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Feb 2024 16:33:13 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v22]
In-Reply-To: <vrwe2U_b9K6EUSg760EHhm3x7sz2tp0D4thYIqknnGw=.e5c1c331-644a-4473-8a8b-d3c8f3128303@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <vrwe2U_b9K6EUSg760EHhm3x7sz2tp0D4thYIqknnGw=.e5c1c331-644a-4473-8a8b-d3c8f3128303@github.com>
Message-ID: <twtI7_ifT_3pTl3f8YtW1l-AX_H7EzZfj4EsXY1rFUA=.727894b4-c49f-4ccc-8eda-0f8ef82cdbfd@github.com>

On Wed, 7 Feb 2024 18:14:24 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3 # Please enter a commit message to explain why this merge is necessary, # especially if it
>    merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the commit.
>  - add test case contributed by @lahodaj
>  - initial fix for source offset problem
>  - remove unused imports
>  - First pass at remove DocCommentTransformer from the public API.
>    
>    It is still declared internally, and installed by default, using the service-provider mechanism.
>    If the standard impl is not available, an identity transformer is used.
>  - updates for "first sentence" issues and tests
>  - add info about provenance of `jdk.internal.md` module
>  - MarkdownTransformer: tweak doc comments
>  - MarkdownTransformer: change `Lower.replaceIter` to be `private final`
>  - MarkdownTransformer: use suggested text for using streams
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/18e24d06...63dd8bf4

Jon, here are a few reminders and misc comments.

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

PR Review: https://git.openjdk.org/jdk/pull/16388#pullrequestreview-1846272367

From prappo at openjdk.org  Thu Feb  8 16:33:14 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Feb 2024 16:33:14 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
Message-ID: <MDprROiV35Q1rjuL_TD_cFkhYEGkN2B-xuH3eRcz0e0=.878238df-e7fd-4054-918b-17f77a5a4ecd@github.com>

On Fri, 19 Jan 2024 18:37:48 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons 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 with upstream/master
>  - Merge with upstream/master
>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>  - Address review comments
>  - Fix whitespace
>  - Improve handling of embedded inline taglets
>  - Customize support for Markdown headings
>  - JDK-8298405: Support Markdown in Documentation Comments

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java line 329:

> 327:         if (doclint == null) {
> 328:             var trees = docEnv.getDocTrees();
> 329:             if (trees.getDocCommentTreeTransformer()== null) {

Suggestion:

            if (trees.getDocCommentTreeTransformer() == null) {

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/RawHtml.java line 145:

> 143:     }
> 144: 
> 145:     Pattern tag = Pattern.compile("<(?<tag>[A-Za-z0-9]+)(\\s|>)");

I'm not sure I grok this pattern; what's up with `\\s`?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/CommentUtils.java line 629:

> 627:     public DocCommentTree parse(URI uri, String text) {
> 628:         return trees.getDocCommentTree(new SimpleJavaFileObject(
> 629:                 uri, JavaFileObject.Kind.HTML) {

Was it a bug before?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Env.java line 139:

> 137:         this.types = types;
> 138: 
> 139:         if (this.trees.getDocCommentTreeTransformer()== null) {

Suggestion:

        if (this.trees.getDocCommentTreeTransformer() == null) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1467988621
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1467977203
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1467980609
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1467982493

From prappo at openjdk.org  Thu Feb  8 16:33:14 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Feb 2024 16:33:14 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v22]
In-Reply-To: <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
Message-ID: <vpCR8ztMJ6THwioLqFcmf_XaoBfgGU8hESSITzaZDgg=.e3ccf661-eff8-41e9-b203-a58d369ec710@github.com>

On Wed, 8 Nov 2023 17:17:46 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3 # Please enter a commit message to explain why this merge is necessary, # especially if it
>>    merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the commit.
>>  - add test case contributed by @lahodaj
>>  - initial fix for source offset problem
>>  - remove unused imports
>>  - First pass at remove DocCommentTransformer from the public API.
>>    
>>    It is still declared internally, and installed by default, using the service-provider mechanism.
>>    If the standard impl is not available, an identity transformer is used.
>>  - updates for "first sentence" issues and tests
>>  - add info about provenance of `jdk.internal.md` module
>>  - MarkdownTransformer: tweak doc comments
>>  - MarkdownTransformer: change `Lower.replaceIter` to be `private final`
>>  - MarkdownTransformer: use suggested text for using streams
>>  - ... and 18 more: https://git.openjdk.org/jdk/compare/18e24d06...63dd8bf4
>
> test/langtools/jdk/javadoc/tool/sampleapi/lib/sampleapi/generator/ModuleGenerator.java line 49:
> 
>> 47: import sampleapi.util.PoorDocCommentTable;
>> 48: 
>> 49: import static com.sun.tools.javac.parser.Tokens.Comment.CommentStyle.JAVADOC;
> 
> To clarify, the change to this file is that you removed two unused imports, right?

Ping. Maybe if it is not essential, we could remove that change, to keep PR more focused.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1483182361

From prappo at openjdk.org  Thu Feb  8 16:33:15 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Feb 2024 16:33:15 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v22]
In-Reply-To: <3N5guZn5SiRlcjZrWQt0JbqUMJr79EcQ999JpVtx8-k=.cf3f71c3-4fcb-4958-b673-76b6b9797cd5@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
 <3N5guZn5SiRlcjZrWQt0JbqUMJr79EcQ999JpVtx8-k=.cf3f71c3-4fcb-4958-b673-76b6b9797cd5@github.com>
Message-ID: <aRyFeUB0t9pLvRy-awz2Kr2gh1RDsiB0YGsuWTSItCQ=.b313e672-413f-46af-b95f-8d87707a8d70@github.com>

On Thu, 11 Jan 2024 15:07:33 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> test/langtools/tools/javac/classfiles/attributes/deprecated/DeprecatedTest.java line 26:
>> 
>>> 24: /*
>>> 25:  * @test
>>> 26:  * @bug 8042261 8298405
>> 
>> This comment is not for this line, but for two compiler tests for `@deprecated` javadoc tag. It seemed quite contextual place to put it.
>> 
>> Did I miss it, or you are planning to add a javadoc test that verifies that `@deprecated` appearing in a `///` comment has no [special meaning] it has in classic `/** */` comments?
>> 
>> [special meaning]: https://github.com/openjdk/jdk/blob/128363bf3b57dfa05b3807271b47851733c1afb9/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java#L1639-L1653
>
> Ping. I do believe that it's important to have such a test.

Ping.

>> test/langtools/tools/javac/doctree/DocCommentTester.java line 1012:
>> 
>>> 1010: //            }
>>> 1011: //            return null;
>>> 1012: //        }
>> 
>> Debugging leftover?
>
> If you want to leave it for debugging you can make it private and uncomment.

Ping.

>> test/langtools/tools/javac/doctree/MarkdownTest.java line 555:
>> 
>>> 553: //  block tags: empty
>>> 554: //]
>>> 555: //*/
>> 
>> Just to clarify: it is supposed to be commented out, right? If uncommented, this test fails with a slightly different error.
>
> Please update the DocComment printout in that commented out test: the actual content is different. It would be nice if the test were passing at least at the moment of its initial commit.
> 
> Here's what I see locally:
> 
> 
> Expect:
> DocComment[DOC_COMMENT, pos:0
>   firstSentence: 1
>     Summary[SUMMARY, pos:4
>       summary: 1
>         Erroneous[ERRONEOUS, pos:14, prefPos:37
>           code: compiler.err.dc.unterminated.inline.tag
>           body: abc_`|_def}|_rest_`more`
>         ]
>     ]
>   body: empty
>   block tags: empty
> ]
> 
> Found:
> DocComment[DOC_COMMENT, pos:0
>   firstSentence: 1
>     Summary[SUMMARY, pos:1
>       summary: 1
>         Erroneous[ERRONEOUS, pos:11, prefPos:32
>           code: compiler.err.dc.unterminated.inline.tag
>           body: abc_`|def}|rest_`more`
>         ]
>     ]
>   body: empty
>   block tags: empty
> ]

Ping.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1483179667
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1483179302
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1483178073

From ihse at openjdk.org  Thu Feb  8 18:20:16 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 8 Feb 2024 18:20:16 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10]
In-Reply-To: <pxn7GqRax1tb7sEK0Q1KnEalowEaZjSUp-O6h4khF78=.9a069feb-3598-4253-a0ac-f87480628802@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <pxn7GqRax1tb7sEK0Q1KnEalowEaZjSUp-O6h4khF78=.9a069feb-3598-4253-a0ac-f87480628802@github.com>
Message-ID: <hILubNwiJGkxOmTDJaPQqNABP1AQUgTa7DUtowaJ0Qo=.a23c01b4-0aa9-4cae-8ccb-4bc2e6bd372e@github.com>

On Thu, 8 Feb 2024 07:44:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Once more, remove AIX dirent64 et al defines

And the smaller file system ID is not a problem, I guess?

Do you want me to remove the redefines?

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1934691860

From jjg at openjdk.org  Thu Feb  8 18:56:05 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 8 Feb 2024 18:56:05 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <MDprROiV35Q1rjuL_TD_cFkhYEGkN2B-xuH3eRcz0e0=.878238df-e7fd-4054-918b-17f77a5a4ecd@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <MDprROiV35Q1rjuL_TD_cFkhYEGkN2B-xuH3eRcz0e0=.878238df-e7fd-4054-918b-17f77a5a4ecd@github.com>
Message-ID: <5-LBnp9pQaksnQQQIe1MPmqdKGD2-0-UZgNnhtY5294=.db5cb4ce-dd03-4d5e-8533-48fdf15d9371@github.com>

On Fri, 26 Jan 2024 18:10:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons 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 with upstream/master
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/RawHtml.java line 145:
> 
>> 143:     }
>> 144: 
>> 145:     Pattern tag = Pattern.compile("<(?<tag>[A-Za-z0-9]+)(\\s|>)");
> 
> I'm not sure I grok this pattern; what's up with `\\s`?

The match for a tag is one of
* `<` _tag-name_ `>`
* `<` _tag-name_ _whitespace_

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1483444658

From jjg at openjdk.org  Thu Feb  8 19:06:21 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 8 Feb 2024 19:06:21 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <MDprROiV35Q1rjuL_TD_cFkhYEGkN2B-xuH3eRcz0e0=.878238df-e7fd-4054-918b-17f77a5a4ecd@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <MDprROiV35Q1rjuL_TD_cFkhYEGkN2B-xuH3eRcz0e0=.878238df-e7fd-4054-918b-17f77a5a4ecd@github.com>
Message-ID: <UaIDVKbhQfqfrZJw_Eg7F0FM3pgdf6J21lwxVqJB1FM=.906f65d4-495b-4339-842c-fe57d4dca162@github.com>

On Fri, 26 Jan 2024 18:14:05 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons 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 with upstream/master
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/CommentUtils.java line 629:
> 
>> 627:     public DocCommentTree parse(URI uri, String text) {
>> 628:         return trees.getDocCommentTree(new SimpleJavaFileObject(
>> 629:                 uri, JavaFileObject.Kind.HTML) {
> 
> Was it a bug before?

I would describe it as having been a "latent bug, waiting to happen".

Previously, all file objects were regarded as containing HTML content, and so there was no need to use the parameter, although maybe it would have been good to check it.

Now, file objects can be HTML or Markdown, and so we do need to use the parameter.

In the case here, the method is used on strings specified in command-line options, which are specified to be in HTML format.   Yes, we might want to change that, but that would be a different RFE separate from the work in this PR.  In that future evolution, I would suggest adding a `JavaFileObject.Kind` parameter to parse and/or inferring the kind from the tail of the path in the `uri` parameter.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1483458107

From jjg at openjdk.org  Thu Feb  8 19:16:25 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 8 Feb 2024 19:16:25 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v23]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <eIvTG8kifeKKbTm0mHWsWuLOz1a8xvJs7S0Rt78X_nE=.af538f7c-c85f-41c4-af6c-cd47d1820395@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  clean up imports in ModuleGenerator test file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/63dd8bf4..92b5e7a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=21-22

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

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

From jjg at openjdk.org  Thu Feb  8 19:19:19 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 8 Feb 2024 19:19:19 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v24]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <LU8x_y5yqCo2qjx2nUoYpqXZcg0GLdBkLPGvuaxS5Tw=.84aa9c31-a962-4886-af71-a643fe4bec28@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  remove commented-out code from DocCommentTester

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/92b5e7a5..5fc415b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=22-23

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

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

From jjg at openjdk.org  Thu Feb  8 19:49:37 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 8 Feb 2024 19:49:37 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v25]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <ONBViDjGySnRgD67SvM1P1n2kmNKO01jkgMQZhuNPrA=.dd52e932-3fec-4367-a536-cbdf089d113c@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  improve comments on negative test case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/5fc415b6..c891fe9a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=23-24

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

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

From jjg at openjdk.org  Thu Feb  8 21:01:00 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 8 Feb 2024 21:01:00 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v25]
In-Reply-To: <aRyFeUB0t9pLvRy-awz2Kr2gh1RDsiB0YGsuWTSItCQ=.b313e672-413f-46af-b95f-8d87707a8d70@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
 <3N5guZn5SiRlcjZrWQt0JbqUMJr79EcQ999JpVtx8-k=.cf3f71c3-4fcb-4958-b673-76b6b9797cd5@github.com>
 <aRyFeUB0t9pLvRy-awz2Kr2gh1RDsiB0YGsuWTSItCQ=.b313e672-413f-46af-b95f-8d87707a8d70@github.com>
Message-ID: <hdNONc20yvv1FsDu66KDbyJ72OJrmz8hmJygq46wiAI=.8d8a4743-7f27-45da-9bbd-5cf9b44b888b@github.com>

On Thu, 8 Feb 2024 15:37:06 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Ping. I do believe that it's important to have such a test.
>
> Ping.

I believe this is substantially covered in line 226-227.  See the third call to `test` in the following group of lines:


for (String src : sources) {
                test(src);
                test(src.replaceAll("@Deprecated", "/** @deprecated */"));
                test(src.replaceAll("deprecated", "notDeprecated2") // change class name
                        .replaceAll("@Deprecated", "/// @deprecated\n"));
            }


* The first call, `test(src)`, runs all the test cases, using the `@Deprecated` annotation by default.  In these test cases, the name of the element encodes whether it is expected that the element is deprecated or not.

* The second call, `test(src.replaceAll("deprecated", "notDeprecated2")`, runs the test cases again, after changing the annotation to a traditional (`/** ...*/`) comment containing the `@deprecated` tag. This is a long-standing call, and tests the legacy behavior of `@deprecated` appearing in a traditional doc comment.  Effectively, it tests whether a `/** @deprecated */` comment has equivalent behavior to a `@Deprecated` comment.

* The third call is new to this PR and the functionality to support Markdown comments.  It makes two changes to the source for the test cases, before running them:
   1. as in the previous test, the annotations are replaced by a comment containing `@deprecated` -- except that this time, the comment is a new-style `/// ... ` comment instead of a traditional `/** ... */` comment, and ...
   2. because we do not expect `/// @deprecated` to indicate deprecation, we need to change the expected result for each test case, which we do by changing the element name for the test case.  The change is the first call to replace to avoid false positives after changing the doc comment. The change uses a new name, `notDeprecated2`, in which `notDeprecated` encodes the expected deprecation status, and the `2` is to differentiate the declarations from other declarations in the case case that already use the name `notDeprecated`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1483582480

From jjg at openjdk.org  Thu Feb  8 21:42:31 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 8 Feb 2024 21:42:31 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v26]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <5uofSBLPGv5G97bklFCq78DEJ4dYKlg2YwZQ1VEsuB8=.5ea3bbd4-8b31-43d5-b3a5-9ca9a4027a7d@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  amend comment in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/c891fe9a..cb070451

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=24-25

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

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

From jjg at openjdk.org  Thu Feb  8 21:49:07 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 8 Feb 2024 21:49:07 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v26]
In-Reply-To: <hdNONc20yvv1FsDu66KDbyJ72OJrmz8hmJygq46wiAI=.8d8a4743-7f27-45da-9bbd-5cf9b44b888b@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
 <3N5guZn5SiRlcjZrWQt0JbqUMJr79EcQ999JpVtx8-k=.cf3f71c3-4fcb-4958-b673-76b6b9797cd5@github.com>
 <aRyFeUB0t9pLvRy-awz2Kr2gh1RDsiB0YGsuWTSItCQ=.b313e672-413f-46af-b95f-8d87707a8d70@github.com>
 <hdNONc20yvv1FsDu66KDbyJ72OJrmz8hmJygq46wiAI=.8d8a4743-7f27-45da-9bbd-5cf9b44b888b@github.com>
Message-ID: <EzAfM-a1G_Im5dcX5GK1jCetaqZ7yPmdMvPBLlLsi2U=.9eb2b2be-4bf2-4ea3-8edd-315b88250f07@github.com>

On Thu, 8 Feb 2024 20:58:24 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Ping.
>
> I believe this is substantially covered in line 226-227.  See the third call to `test` in the following group of lines:
> 
> 
> for (String src : sources) {
>                 test(src);
>                 test(src.replaceAll("@Deprecated", "/** @deprecated */"));
>                 test(src.replaceAll("deprecated", "notDeprecated2") // change class name
>                         .replaceAll("@Deprecated", "/// @deprecated\n"));
>             }
> 
> 
> * The first call, `test(src)`, runs all the test cases, using the `@Deprecated` annotation by default.  In these test cases, the name of the element encodes whether it is expected that the element is deprecated or not.
> 
> * The second call, `test(src.replaceAll("deprecated", "notDeprecated2")`, runs the test cases again, after changing the annotation to a traditional (`/** ...*/`) comment containing the `@deprecated` tag. This is a long-standing call, and tests the legacy behavior of `@deprecated` appearing in a traditional doc comment.  Effectively, it tests whether a `/** @deprecated */` comment has equivalent behavior to a `@Deprecated` comment.
> 
> * The third call is new to this PR and the functionality to support Markdown comments.  It makes two changes to the source for the test cases, before running them:
>    1. as in the previous test, the annotations are replaced by a comment containing `@deprecated` -- except that this time, the comment is a new-style `/// ... ` comment instead of a traditional `/** ... */` comment, and ...
>    2. because we do not expect `/// @deprecated` to indicate deprecation, we need to change the expected result for each test case, which we do by changing the element name for the test case.  The change is the first call to replace to avoid false positives after changing the doc comment. The change uses a new name, `notDeprecated2`, in which `notDeprecated` encodes the expected deprecation status, and the `2` is to differentiate the declarations from other declarations in the case case that already use the name `notDeprecated`.

While the underlying mechanism in javac for indicating deprecation is the same for all, I accept this is primarily a test for generated class files. I can add a javadoc test for basic behavior of `@deprecated` in Markdown comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1483628179

From jjg at openjdk.org  Thu Feb  8 23:02:18 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 8 Feb 2024 23:02:18 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v27]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <9NF_Fppb1h1roiaG9ZGVOsbYAF2pmrZtJEnJVFFmYh4=.83fe633b-cee0-4306-be22-1fe4467c6407@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  added test case in TestMarkdown.java for handling of `@deprecated` tag

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/cb070451..3b1350b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=25-26

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

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

From jjg at openjdk.org  Thu Feb  8 23:57:09 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 8 Feb 2024 23:57:09 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v27]
In-Reply-To: <9NF_Fppb1h1roiaG9ZGVOsbYAF2pmrZtJEnJVFFmYh4=.83fe633b-cee0-4306-be22-1fe4467c6407@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <9NF_Fppb1h1roiaG9ZGVOsbYAF2pmrZtJEnJVFFmYh4=.83fe633b-cee0-4306-be22-1fe4467c6407@github.com>
Message-ID: <g4pw9-j5XHSsHCwv4R_HSglA8vl9fuBBtTy9lIFP3bc=.6479816c-ec6e-4ab5-8d33-5046173f8f71@github.com>

On Thu, 8 Feb 2024 23:02:18 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added test case in TestMarkdown.java for handling of `@deprecated` tag

Re: https://github.com/openjdk/jdk/pull/16388#discussion_r1483182361
See https://github.com/openjdk/jdk/pull/17782

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

PR Comment: https://git.openjdk.org/jdk/pull/16388#issuecomment-1935112305

From prr at openjdk.org  Fri Feb  9 03:27:05 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 9 Feb 2024 03:27:05 GMT
Subject: RFR: 8324243: Fix GCC 14 build [v3]
In-Reply-To: <HdMQd-rsi1Ry5jT7ffesgEm8kzjdD80VO3REUlzBQMs=.c52c56a1-b118-4833-afc9-08798afd6581@github.com>
References: <PmU0wltBwGECZ_1D3iQA3WCZE-evJ-Exf9f51-hXdBc=.353a8bb3-79e9-46e0-a85a-c53f62efa8aa@github.com>
 <HdMQd-rsi1Ry5jT7ffesgEm8kzjdD80VO3REUlzBQMs=.c52c56a1-b118-4833-afc9-08798afd6581@github.com>
Message-ID: <EzKnCrIs1rj_qCdh_9gAcIpeNpx9V7sgQ34dn3SriGY=.3e0d0416-ec7d-4f1d-8b9d-0ef23e3fcd81@github.com>

On Sat, 3 Feb 2024 10:07:26 GMT, Sam James <duke at openjdk.org> wrote:

>> This fixes building with GCC 14:
>> * ~Cherry-pick a fix from Harfbuzz upstream~
>> * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources
>> 
>> -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses
>> -Werror.
>> 
>> The calloc prototype is:
>> 
>> void *calloc(size_t nmemb, size_t size);
>> 
>> 
>> So, just swap the number of members and size arguments to match the prototype, as
>> we're initialising 1 struct of size `sizeof(struct ...)`. GCC then sees we're not
>> doing anything wrong.
>
> Sam James has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17506#pullrequestreview-1871602651

From alanb at openjdk.org  Fri Feb  9 11:41:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Feb 2024 11:41:06 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10]
In-Reply-To: <pxn7GqRax1tb7sEK0Q1KnEalowEaZjSUp-O6h4khF78=.9a069feb-3598-4253-a0ac-f87480628802@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <pxn7GqRax1tb7sEK0Q1KnEalowEaZjSUp-O6h4khF78=.9a069feb-3598-4253-a0ac-f87480628802@github.com>
Message-ID: <HGgq1bdtBMDK83eAApYc8vYUmR5jg-Mcunk4g7zIYL8=.1ba06e1a-04ad-4523-b515-fc50e11874f3@github.com>

On Thu, 8 Feb 2024 07:44:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Once more, remove AIX dirent64 et al defines

I can't comment on AIX but the changes look okay overall. I assume you'll bump the copyright header date on all the updated files before integrating.

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 257:

> 255: static int fstatat_wrapper(int dfd, const char *path,
> 256:                              struct stat *statbuf, int flag)
> 257: {

Minor nit - you can probably fix the align after the edit or collapse it into one line.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17538#pullrequestreview-1872182776
PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1484203284

From ihse at openjdk.org  Fri Feb  9 13:41:39 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 Feb 2024 13:41:39 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
Message-ID: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>

This is an attempt to finally implement the idea brought forward in JDK-8295729:  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 or leading tabs instead of spaces. 

With Skara jcheck, it is possible to increase the coverage of the whitespace checks.

However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

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

Commit messages:
 - 8325558: Add jcheck whitespace checking for properties files

Changes: https://git.openjdk.org/jdk/pull/17789/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17789&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325558
  Stats: 761 lines in 95 files changed: 0 ins; 5 del; 756 mod
  Patch: https://git.openjdk.org/jdk/pull/17789.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17789/head:pull/17789

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

From ihse at openjdk.org  Fri Feb  9 13:41:39 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 Feb 2024 13:41:39 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
Message-ID: <vjpYKJQJffU8Erjfn6uucPoPpWriBq1VQhvkztNZ5yg=.834ae963-240f-4bbf-8110-2278d7e17cec@github.com>

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  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 or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

I'll add some specific comments/reasoning to individual files, where I think a remark might be needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/17789#issuecomment-1935947566

From ihse at openjdk.org  Fri Feb  9 13:55:09 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 Feb 2024 13:55:09 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
Message-ID: <aiUe8udp6Qtknwo8Ha3jenZ_TP_SMD5baGxnNlNz7WI=.86e01229-6456-4e46-ad0c-1e74c84c7c63@github.com>

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  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 or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

src/java.base/unix/classes/sun/net/www/content-types.properties line 1:

> 1: #sun.net.www MIME content-types table

I have converted all leading tabs to 8 spaces.

src/java.base/windows/classes/sun/net/www/content-types.properties line 1:

> 1: #sun.net.www MIME content-types table

I have converted all leading tabs to 8 spaces.

src/java.desktop/share/classes/com/sun/imageio/plugins/common/iio-plugin.properties line 11:

> 9: ImageUtil0=The supplied Raster does not represent a binary data set.
> 10: ImageUtil1=The provided sample model is null.
> 11: ImageUtil2=The provided image cannot be encoded using: 

While it seems like this could have been significant, the code that uses it looks like this:

 throw new IIOException(I18N.getString("ImageUtil2")+" "+
                                   writer.getClass().getName());

so it will end up with a double space right now.

src/java.scripting/share/classes/com/sun/tools/script/shell/messages.properties line 1:

> 1: #

I have converted all leading tabs to 8 spaces.

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 73:

> 71: cachedrowsetimpl.numrows = Number of rows is less than zero or less than fetch size
> 72: cachedrowsetimpl.startpos = Start position cannot be negative
> 73: cachedrowsetimpl.nextpage = Populate data before calling 

This sounded like it could potentially be followed by a name, but this is not the case.

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 128:

> 126: crswriter.params1 = Value of params1 : {0} 
> 127: crswriter.params2 = Value of params2 : {0} 
> 128: crswriter.conflictsno =  conflicts while synchronizing 

This sounded like it could potentially be followed by a string, but this is not the case.

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 1:

> 1: #

The changes in this and the following files are just to align the file with the English master copy.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages.properties line 24:

> 22: 
> 23:         BadMessageKey = The error message corresponding to the message key can not be found.
> 24:         FormatFailed = An internal error occurred while formatting the following message:\n  

At first glance, it might look like something should follow the `:`, but note that there is a `\n` so if anything this will only make the next line improperly indented.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties line 1:

> 1: #

The changes in this and the following files are just to align the file with the English master copy.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_de.properties line 1:

> 1: #

The changes in this and the following files are just to align the file with the English master copy.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages.properties line 20:

> 18: # Messages for message reporting
> 19: BadMessageKey = The error message corresponding to the message key can not be found.
> 20: FormatFailed = An internal error occurred while formatting the following message:\n

At first glance, it might look like something should follow the :, but note that there is a \n so if anything this will only make the next line improperly indented.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties line 1:

> 1: #

The changes in this and the following files are just to align the file with the English master copy.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties line 27:

> 25: 
> 26:         BadMessageKey = The error message corresponding to the message key can not be found.
> 27:         FormatFailed = An internal error occurred while formatting the following message:\n

Same here with `:\n`...

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages.properties line 24:

> 22: # Messages for message reporting
> 23: BadMessageKey = The error message corresponding to the message key can not be found.
> 24: FormatFailed = An internal error occurred while formatting the following message:\n

Same here with `:\n`...

src/jdk.compiler/share/classes/sun/tools/serialver/resources/serialver.properties line 1:

> 1: #

I have converted all leading tabs to 8 spaces.

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 49:

> 47:         'u' flag requires manifest, 'e' flag or input files to be specified!
> 48: error.bad.eflag=\
> 49: 	'e' flag and manifest with the 'Main-Class' attribute cannot be specified \n\

Here were two lines that used tab instead of space; I converted them to 8 spaces.

test/jaxp/javax/xml/jaxp/unittest/common/config/files/catalog2.properties line 4:

> 2: #       XML Library (java.xml) Configuration File
> 3: #
> 4: # This file is in java.util.Properties format and typically located in the conf 

These spaces at the end of comment lines has crept in since I cleaned all such out in [JDK-8298047](https://bugs.openjdk.org/browse/JDK-8298047). It's a good example of why we need the jcheck verification to keep this from regressing once more.

test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/TableDemo.properties line 12:

> 10: 
> 11: TableDemo.noDataStatusLabel=No data loaded
> 12: TableDemo.loadingStatusLabel=Loading data:\u0020

According to https://github.com/openjdk/jdk/pull/11488/files#r1038605801 the latter two are actually needed as spaces, and the first might be; so keeping it as well seems to be the safe choice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484326435
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484326568
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484327614
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484327859
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484329632
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484329770
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484330650
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484332081
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484332649
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484334629
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484334259
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484335061
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484335669
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484337306
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484338418
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484339114
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484341847
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484345466

From dfuchs at openjdk.org  Fri Feb  9 14:10:57 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 Feb 2024 14:10:57 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
Message-ID: <MAPhOTYtvVaNcWCFKbDS-_1DUpWDjk7QPxjKCqRkcMU=.6138cf57-eec3-47fd-9932-3ab1d538e789@github.com>

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  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 or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

changes to sun/net content-types.properties look OK

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

PR Comment: https://git.openjdk.org/jdk/pull/17789#issuecomment-1935996382

From erikj at openjdk.org  Fri Feb  9 14:56:57 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 9 Feb 2024 14:56:57 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: <aiUe8udp6Qtknwo8Ha3jenZ_TP_SMD5baGxnNlNz7WI=.86e01229-6456-4e46-ad0c-1e74c84c7c63@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
 <aiUe8udp6Qtknwo8Ha3jenZ_TP_SMD5baGxnNlNz7WI=.86e01229-6456-4e46-ad0c-1e74c84c7c63@github.com>
Message-ID: <nhpBrqfBtPnWkJykz1_einfiy1GazMV7NLU1-ukdtiw=.c2e3123b-9bc5-418e-9785-62a078ab9466@github.com>

On Fri, 9 Feb 2024 13:42:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is an attempt to finally implement the idea brought forward in JDK-8295729:  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 or leading tabs instead of spaces. 
>> 
>> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
>> 
>> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.
>
> src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages.properties line 24:
> 
>> 22: 
>> 23:         BadMessageKey = The error message corresponding to the message key can not be found.
>> 24:         FormatFailed = An internal error occurred while formatting the following message:\n  
> 
> At first glance, it might look like something should follow the `:`, but note that there is a `\n` so if anything this will only make the next line improperly indented.

That could have been intentional though. Not sure if it was a good idea, but indenting something is a way of making something stand out as a quote. But looking at every use site, there is an extra space added anyway, so this seems fine. If we wanted to preserve the exact same behavior, all use sites should be updated to add 3 spaces.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484416962

From naoto at openjdk.org  Fri Feb  9 18:12:06 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 Feb 2024 18:12:06 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
Message-ID: <rB3HxteVgSXBiQnLDLdYgc2jXTL2fFPg5zdCQwxHt1g=.37699c1c-1dad-4451-b364-38d1b2170957@github.com>

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  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 or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

Skimmed through the changes and all look good to me. Good to have `jcheck` detect those unneeded trailing spaces.

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

PR Review: https://git.openjdk.org/jdk/pull/17789#pullrequestreview-1872951198

From jjg at openjdk.org  Fri Feb  9 18:12:09 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 9 Feb 2024 18:12:09 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
 <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
Message-ID: <UPoDGtqJzFdUQ2K_WMcSGAYIny01XZ3yYJmRdp7m0S0=.dba7e91e-92a3-4cea-8d82-4bc35557c7ea@github.com>

On Sat, 13 Jan 2024 21:55:06 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> 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 seven additional commits since the last revision:
>> 
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.compiler/share/classes/com/sun/source/doctree/DocTreeVisitor.java line 257:
> 
>> 255:      *
>> 256:      * @implSpec Visits the provided {@code RawTextTree} node
>> 257:      * by calling {@code visitOther(node, p)}.
> 
> Nit: for consistency with the rest of the file, reorder `@param`-`@return` block with the `@implSpec` tag:
> 
> Suggestion:
> 
>      *
>      * @implSpec Visits the provided {@code RawTextTree} node
>      * by calling {@code visitOther(node, p)}.
>      *
>      * @param node the node being visited
>      * @param p a parameter value
>      * @return a result value

Done

> src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java line 1080:
> 
>> 1078:             }
>> 1079: 
>> 1080:             private String info(FileObject fo) {
> 
> This does not seem to be used; is it for debugging? If so, add your `// DEBUG` comment.

It probably was used for debugging at some point.  The method can be `static`, meaning it is not specific to this class and could be elsewhere if we wanted to retain the functionality.   Code like this is easy enough to regenerate, so I will delete this copy for now.

> src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java line 1156:
> 
>> 1154: 
>> 1155:     /**
>> 1156:      * {@return the {@linkplain ParserFactory} parser factory}.
> 
> Suggestion:
> 
>      * {@return the {@linkplain ParserFactory} parser factory}

done

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java line 1065:
> 
>> 1063: 
>> 1064:                     if (accept('/')) { // (Spec. 3.7)
>> 1065:                         if (accept('/')) { // Markdown comment
> 
> I believe that some of the changes in `com/sun/tools/javac/parser` were contributed by @JimLaskey. If so, don't forget to add him as a co-author: `/contributor add jlaskey`.

did that

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1484652974
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1484650198
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1484651230
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1484651466

From jjg at openjdk.org  Fri Feb  9 18:31:14 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 9 Feb 2024 18:31:14 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
 <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
Message-ID: <WYXUTmwMTgMP4YjGJk4CIxXFqZ6LwAhhjHOgjDVkOU4=.7a797721-e94f-44a8-8cea-78f761187d0f@github.com>

On Mon, 15 Jan 2024 12:26:34 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> 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 seven additional commits since the last revision:
>> 
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 201:
> 
>> 199:                 }
>> 200:                 newline = true;
>> 201:             }
> 
> I can see clean LF and CRLF, but no FF; was the latter intentional?
> 
> In any case, we should double-check the generated test output to see if there's anything unexpected.

We've been here, with `\f` before, noting the different handling of `\f` in `javac` and `javadoc`.

My recollection is that it was intentional to drop support for `\f`, thus aligning `javac` and `javadoc` behavior, and to normalize handling of the newline sequences, translating them to `\n`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1484669301

From jjg at openjdk.org  Fri Feb  9 18:57:27 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 9 Feb 2024 18:57:27 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v28]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <dfbZPdbtDSkKlqE7LBPsOxmhd35_xUsA68XNr8OjDrk=.5e7c7f26-2ce5-4ade-9094-703b3de0e3f4@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  address review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/3b1350b2..91588bc3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=26-27

  Stats: 23 lines in 2 files changed: 4 ins; 18 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388

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

From prappo at openjdk.org  Fri Feb  9 19:05:09 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 9 Feb 2024 19:05:09 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <5BjUOMWcopR-ouu-BVzMiDNUU5uZTFBhS4E0orGR9H4=.cb1112d1-7832-428f-b485-c417798248ab@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
 <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
 <flR9QGfiaBhXqoK_j0z67KC8aSbVgmV15-ZGGU1Nfog=.a06bc2dc-7e1c-4586-af4a-80ddfa0cd753@github.com>
 <5BjUOMWcopR-ouu-BVzMiDNUU5uZTFBhS4E0orGR9H4=.cb1112d1-7832-428f-b485-c417798248ab@github.com>
Message-ID: <qD-aQf5OgdJVWsXGMnEZFUoITXMdtwr20UfURFTnsdQ=.0b86d1fa-1c5a-46b3-b543-80f1cd65a2b1@github.com>

On Tue, 30 Jan 2024 00:47:33 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> > Musing on this more.
> > Can/should we, without introducing probably unwelcome `Kind.MD` to `javax.tools.JavaFileObject.Kind`, teach javac to recognise `package.md` similarly to how it recognises legacy `package.html`? If we are aiming for Markdown to be a drop in replacement for traditional javadoc comments, we might want to go the extra mile.
> > I'm pleased to see that Markdown `-overview` files work just fine.
> 
> No. There are times to let go of legacy behavior, and even if this is not the time to remove support for `package.html`, there is no reason to go backwards and support `package.md`. The preferred replacement for `package.html` has long been `package-info.java` and you can put Markdown content in that file with no issues.
> 
> In similar fashion, remember the recent discussion as to whether we should support `@deprecated` in Markdown comments as marking the declaration as _deprecated_, even without the `@Deprecated` annotation. The general consensus was to not persist with that legacy behavior.

Okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1484693923

From prappo at openjdk.org  Fri Feb  9 19:05:09 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 9 Feb 2024 19:05:09 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <4Tqtmfv4DzkI4sbb6bLBY9Ll0xd34vm9KBUzthu3fd8=.2e94fa19-e555-4371-bd2e-8506938527e8@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
 <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
 <w8lQxY5brSRBfHvIQq-Qb12dg5HdAKbkfR_5tJIPjkY=.ae66d225-f916-4719-be19-03372eaf8b23@github.com>
 <4Tqtmfv4DzkI4sbb6bLBY9Ll0xd34vm9KBUzthu3fd8=.2e94fa19-e555-4371-bd2e-8506938527e8@github.com>
Message-ID: <z0-3fcMBCKOgPaEfSWe3NBOmXDHS-NDUiDVCIQBFUZQ=.95386f8d-e0cc-4cdf-96ba-307ccec06f27@github.com>

On Mon, 29 Jan 2024 23:50:25 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Probably, yes.
>
> New class comment added.

I can see it and it reads nicely; thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1484586216

From prappo at openjdk.org  Fri Feb  9 19:05:12 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 9 Feb 2024 19:05:12 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <_WLv7XFq2-900uOZFhRJ8rLQmjlFdTlHmC9wVfS6I-Y=.1ada9999-1a0e-4f88-aa67-5d4120585f35@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <_WLv7XFq2-900uOZFhRJ8rLQmjlFdTlHmC9wVfS6I-Y=.1ada9999-1a0e-4f88-aa67-5d4120585f35@github.com>
Message-ID: <qNT4gi2yF_GeQLZ8FE0_B_zvEoO5umtnBFX38QRG_dE=.56ab1794-a499-4759-a529-dcbd56cdb120@github.com>

On Tue, 23 Jan 2024 13:02:46 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons 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 with upstream/master
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1315:
> 
>> 1313:     }
>> 1314: 
>> 1315:     void skipLine() {
> 
> Like `peekLike()`, this method also does not seem to be consistent with `newline` in `nextChar()`.

It's okay. You explained my confusion here: https://github.com/openjdk/jdk/pull/16388#discussion_r1470367971

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1419:
> 
>> 1417:     LineKind peekLineKind() {
>> 1418:         switch (ch) {
>> 1419:             case '#', '=', '-', '+', '_', '`', '~' -> {
> 
> This change is to match that of `THEMATIC_BREAK`:
> Suggestion:
> 
>             case '#', '=', '-', '*', '_', '`', '~' -> {

While you seem to have forgotten to change it, no tests failed, which is sad.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1484619952
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1484617917

From prappo at openjdk.org  Fri Feb  9 19:05:12 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 9 Feb 2024 19:05:12 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <VIgOZy_4rC8rWkb-re-lYOmabLq6vwl9lpg9U1Lbz7U=.ac116c11-dd6c-4fe6-82d6-fbe92354702c@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <_WLv7XFq2-900uOZFhRJ8rLQmjlFdTlHmC9wVfS6I-Y=.1ada9999-1a0e-4f88-aa67-5d4120585f35@github.com>
 <VIgOZy_4rC8rWkb-re-lYOmabLq6vwl9lpg9U1Lbz7U=.ac116c11-dd6c-4fe6-82d6-fbe92354702c@github.com>
Message-ID: <fB3rnqUsK7o_0gHrF3deAM_k1LQLBbxd60EWJctq0SA=.3299c83c-1662-4aa9-be8e-7049857ea974@github.com>

On Tue, 30 Jan 2024 21:37:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java line 1065:
>> 
>>> 1063: 
>>> 1064:                     if (accept('/')) { // (Spec. 3.7)
>>> 1065:                         if (accept('/')) { // Markdown comment
>> 
>> Here and elsewhere in this file: do we need to mention Markdown?
>
> The "M" word appears 10 times in this file. I'll work to convert them to an alternate nomenclature, such as "line comment".

I can see that you've managed to remove all of those occurrences nicely; well done!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1484624573

From prappo at openjdk.org  Fri Feb  9 19:05:10 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 9 Feb 2024 19:05:10 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <uv0-wEcbk0cdgcF2V4G7SHPu3WoH6hfdjspkWJk31SA=.40a3fe04-523b-40bd-83f9-28708de46901@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
 <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
 <uv0-wEcbk0cdgcF2V4G7SHPu3WoH6hfdjspkWJk31SA=.40a3fe04-523b-40bd-83f9-28708de46901@github.com>
Message-ID: <imFMX3KSSPgzib_zMIjARkFIx9Mxk-yJ0neGRiZxzJE=.90f3887f-572b-4640-9d94-8285040ee6b1@github.com>

On Mon, 29 Jan 2024 23:34:24 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 215:
>> 
>>> 213:                  case '\n', '\r' -> {
>>> 214:                      return newString(bp, p);
>>> 215:                  }
>> 
>> Hm... this does not seem to be consistent with `newline` in `nextChar`; should it be consistent?
>
> I think it is OK, isn't it?
> 
> In both cases, a newline sequence can begin with `\r` or `\n`.
> 
> In this `peekLine` method, we only want the content up to but not including the newline, so there is no need to handle the possibility of `\r\n`.   In `nextChar`, we do want to detect `r` and `\r\n` and treat both as equivalent to `\n`.
> 
> Or am I missing something?

You don't seem to be missing anything; it's me who was confused.

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1295:
>> 
>>> 1293:             switch (ch) {
>>> 1294:                 case ' ' -> indent++;
>>> 1295:                 case '\t' -> indent = 4;
>> 
>> Shouldn't it be like this or it does not matter?
>>  ```suggestion
>>                  case '\t' -> indent += 4;
>
> I did mean `indent = 4`.
> It would not mean `indent +=4` because you would have to take preceding character count into account, to round up to a multiple of 4.
> But anyway, it's enough to know the indent is 4 or more, meaning the code is looking at an indented code block.
> https://spec.commonmark.org/0.30/#indented-code-blocks

I'm not sure I understood the _take preceding character count into account_ part, but if `indent = 4` is what you meant and having read that section of the spec, I'm okay with it. Thanks.

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1421:
>> 
>>> 1419:             case '#', '=', '-', '+', '_', '`', '~' -> {
>>> 1420:                 String line = peekLine();
>>> 1421:                 for (LineKind lk : LineKind.values()) {
>> 
>> Nothing wrong here, just noting that this is one more way one can depend on an enum constant order. Change it, and a peeked line kind might change too (e.g. `OTHER` matches everything.)
>
> Like it or not, JLS defines that enum members are ordered, and even has an example 8.9.3-1 of using the `values` method in an enhanced `for` loop. Any change to the order of the members of any enum has the potential to be a breaking change and should never be done lightly.  Curiously, JLS 13.4.26 does not say that reordering enum constants may break clients.
> 
> Anyway, I added comments to the LineKind enum declaration.

I think I'm still coming to terms with this feature of enum constants: being order-sensitive. https://docs.oracle.com/javase/specs/jls/se21/html/jls-13.html#jls-13.4.26 is concerned with "binary compatibility". What we are talking about here is more like "behavioural compatibilty" as defined in https://wiki.openjdk.org/display/csr/Kinds+of+Compatibility. But we digress.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1484581568
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1484593858
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1484607076

From prappo at openjdk.org  Fri Feb  9 19:05:13 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 9 Feb 2024 19:05:13 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v22]
In-Reply-To: <vrwe2U_b9K6EUSg760EHhm3x7sz2tp0D4thYIqknnGw=.e5c1c331-644a-4473-8a8b-d3c8f3128303@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <vrwe2U_b9K6EUSg760EHhm3x7sz2tp0D4thYIqknnGw=.e5c1c331-644a-4473-8a8b-d3c8f3128303@github.com>
Message-ID: <Fi4NuaFltjeOrEITZ6UI3osRWtQrnoDx566UsfCL0EE=.a042889e-e4f0-4ba7-b2f9-04b1d36c510d@github.com>

On Wed, 7 Feb 2024 18:14:24 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3 # Please enter a commit message to explain why this merge is necessary, # especially if it
>    merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the commit.
>  - add test case contributed by @lahodaj
>  - initial fix for source offset problem
>  - remove unused imports
>  - First pass at remove DocCommentTransformer from the public API.
>    
>    It is still declared internally, and installed by default, using the service-provider mechanism.
>    If the standard impl is not available, an identity transformer is used.
>  - updates for "first sentence" issues and tests
>  - add info about provenance of `jdk.internal.md` module
>  - MarkdownTransformer: tweak doc comments
>  - MarkdownTransformer: change `Lower.replaceIter` to be `private final`
>  - MarkdownTransformer: use suggested text for using streams
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/18e24d06...63dd8bf4

src/jdk.internal.md/share/classes/module-info.java line 41:

> 39: // * package and import statements are updated
> 40: // * characters outside the ASCII range are converted to Unicode escapes
> 41: // * @SuppressWarnings("fallthrough") is added to getSetextHeadingLevel

I wonder if it would be better to compile this module without (some) lint checks. Is it possible?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1483335356

From prappo at openjdk.org  Fri Feb  9 19:05:13 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 9 Feb 2024 19:05:13 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v28]
In-Reply-To: <vpCR8ztMJ6THwioLqFcmf_XaoBfgGU8hESSITzaZDgg=.e3ccf661-eff8-41e9-b203-a58d369ec710@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
 <vpCR8ztMJ6THwioLqFcmf_XaoBfgGU8hESSITzaZDgg=.e3ccf661-eff8-41e9-b203-a58d369ec710@github.com>
Message-ID: <p-5OpfgEIx2PZY2AiORJ1snS434p54SzB_HxJPZzxFM=.62a91526-0281-4ad7-ad89-a3b3c8a05b86@github.com>

On Thu, 8 Feb 2024 15:38:26 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> test/langtools/jdk/javadoc/tool/sampleapi/lib/sampleapi/generator/ModuleGenerator.java line 49:
>> 
>>> 47: import sampleapi.util.PoorDocCommentTable;
>>> 48: 
>>> 49: import static com.sun.tools.javac.parser.Tokens.Comment.CommentStyle.JAVADOC;
>> 
>> To clarify, the change to this file is that you removed two unused imports, right?
>
> Ping. Maybe if it is not essential, we could remove that change, to keep PR more focused.

Okay I can see that you tried to revert the change to that file and published a [PR] to optimise imports separately. Sadly, the "revert" introduced even more churn. Here's my proposal, which might not be elegant but does the job:


git checkout 8298405.doclet-markdown-v3
git diff -R head --not upstream/master -- test/langtools/jdk/javadoc/tool/sampleapi/lib/sampleapi/generator/ModuleGenerator.java | git apply
git commit -am "Revert all changes to ModuleGenerator.java"


If you have any issues with that snippet, ping me out of band; I hope the intent of the snippet is clear though.

[PR]: https://github.com/openjdk/jdk/pull/17782

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1484477033

From prappo at openjdk.org  Fri Feb  9 19:05:13 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 9 Feb 2024 19:05:13 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v28]
In-Reply-To: <Zwe6y0vUwzwB1fCJM_FiKalBTvej10e5oxQIjX-xNJk=.ab043e54-14a4-4f9c-9687-7957354d460d@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
 <Zwe6y0vUwzwB1fCJM_FiKalBTvej10e5oxQIjX-xNJk=.ab043e54-14a4-4f9c-9687-7957354d460d@github.com>
Message-ID: <osiK1d46PggEwfKnkRcnwwgXRVsbRhD23JzayeLNzEo=.d035ba2a-90b1-46c0-ad4f-19b0cb97852e@github.com>

On Wed, 15 Nov 2023 00:37:06 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> test/langtools/jdk/javadoc/tool/testTransformer/TestTransformer.java line 96:
>> 
>>> 94:         var sl = ServiceLoader.load(DocTrees.DocCommentTreeTransformer.class);
>>> 95:         return StreamSupport.stream(sl.spliterator(), false)
>>> 96:                 .filter(p -> p.name().equals(name))
>> 
>> ServiceLoader specification suggests another way of streaming:
>> Suggestion:
>> 
>>         return sl.stream()
>>                 .map(ServiceLoader.Provider::get)
>>                 .filter(t -> t.name().equals(name))
>> 
>> Would it be the same and more readable?
>
> Hmm. It's longer, but arguably simpler to comprehend than using a spliterator. I've changed the code.

There's now a leftover `import java.util.stream.StreamSupport;` in that file.

>> test/langtools/tools/javac/doctree/MDPrinter.java line 67:
>> 
>>> 65:  * Conceptually based on javac's {@code DPrinter}.
>>> 66:  */
>>> 67: public class MDPrinter {
>> 
>> While DPrinter is used, MDPrinter isn't. (At least, I could't find any usages of it.) If you feel like MDPrinter is important, we should at least add a compile test for it, to protect it from bitrot.
>
> ?

MDPrinter.java is now a test that compiles itself; thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1484541756
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1484196535

From prappo at openjdk.org  Fri Feb  9 19:05:13 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 9 Feb 2024 19:05:13 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v28]
In-Reply-To: <EzAfM-a1G_Im5dcX5GK1jCetaqZ7yPmdMvPBLlLsi2U=.9eb2b2be-4bf2-4ea3-8edd-315b88250f07@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
 <3N5guZn5SiRlcjZrWQt0JbqUMJr79EcQ999JpVtx8-k=.cf3f71c3-4fcb-4958-b673-76b6b9797cd5@github.com>
 <aRyFeUB0t9pLvRy-awz2Kr2gh1RDsiB0YGsuWTSItCQ=.b313e672-413f-46af-b95f-8d87707a8d70@github.com>
 <hdNONc20yvv1FsDu66KDbyJ72OJrmz8hmJygq46wiAI=.8d8a4743-7f27-45da-9bbd-5cf9b44b888b@github.com>
 <EzAfM-a1G_Im5dcX5GK1jCetaqZ7yPmdMvPBLlLsi2U=.9eb2b2be-4bf2-4ea3-8edd-315b88250f07@github.com>
Message-ID: <yc8uyiXGmd-ymdwUPFnGBe6md0vh5EyQgLSvIesmY00=.81eb3acd-3b20-47eb-b3f4-4552b3412744@github.com>

On Thu, 8 Feb 2024 21:46:34 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> I believe this is substantially covered in line 226-227.  See the third call to `test` in the following group of lines:
>> 
>> 
>> for (String src : sources) {
>>                 test(src);
>>                 test(src.replaceAll("@Deprecated", "/** @deprecated */"));
>>                 test(src.replaceAll("deprecated", "notDeprecated2") // change class name
>>                         .replaceAll("@Deprecated", "/// @deprecated\n"));
>>             }
>> 
>> 
>> * The first call, `test(src)`, runs all the test cases, using the `@Deprecated` annotation by default.  In these test cases, the name of the element encodes whether it is expected that the element is deprecated or not.
>> 
>> * The second call, `test(src.replaceAll("deprecated", "notDeprecated2")`, runs the test cases again, after changing the annotation to a traditional (`/** ...*/`) comment containing the `@deprecated` tag. This is a long-standing call, and tests the legacy behavior of `@deprecated` appearing in a traditional doc comment.  Effectively, it tests whether a `/** @deprecated */` comment has equivalent behavior to a `@Deprecated` comment.
>> 
>> * The third call is new to this PR and the functionality to support Markdown comments.  It makes two changes to the source for the test cases, before running them:
>>    1. as in the previous test, the annotations are replaced by a comment containing `@deprecated` -- except that this time, the comment is a new-style `/// ... ` comment instead of a traditional `/** ... */` comment, and ...
>>    2. because we do not expect `/// @deprecated` to indicate deprecation, we need to change the expected result for each test case, which we do by changing the element name for the test case.  The change is the first call to replace to avoid false positives after changing the doc comment. The change uses a new name, `notDeprecated2`, in which `notDeprecated` encodes the expected deprecation status, and the `2` is to differentiate the declarations from other declarations in the case case that already use the name `notDeprecated`.
>
> While the underlying mechanism in javac for indicating deprecation is the same for all, I accept this is primarily a test for generated class files. I can add a javadoc test for basic behavior of `@deprecated` in Markdown comments.

Thanks for confirming that there's a test to check that `/// @deprecated` is a no-op and for patiently explaining how that test works.

I confirm that test/langtools/tools/javac/classfiles/attributes/deprecated/DeprecatedTest.java starts failing if I introduce the following change:


--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java
@@ -1638,7 +1638,7 @@ protected void scanDocComment() {
                             ? trimJavadocLineComment(line, indent)
                             : trimJavadocComment(line);
 
-                    if (cs == CommentStyle.JAVADOC_BLOCK) {
+//                    if (cs == CommentStyle.JAVADOC_BLOCK) {
                         // If standalone @deprecated tag
                         int pos = line.position();
                         line.skipWhitespace();
@@ -1652,7 +1652,7 @@ protected void scanDocComment() {
                         }
 
                         line.reset(pos);
-                    }
+//                    }
 
                     putLine(line);
                 }


I can also see that you have introduced a dedicated test/langtools/jdk/javadoc/doclet/testMarkdown/TestMarkdown.java#testDeprecated which also starts failing with that change of mine.

Please update the copyright year in test/langtools/jdk/javadoc/doclet/testMarkdown/TestMarkdown.java.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1484410402

From prappo at openjdk.org  Fri Feb  9 19:05:13 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 9 Feb 2024 19:05:13 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v28]
In-Reply-To: <aRyFeUB0t9pLvRy-awz2Kr2gh1RDsiB0YGsuWTSItCQ=.b313e672-413f-46af-b95f-8d87707a8d70@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <bZq6pPTdtcJayLOFPeVpL2lth3zrxQFh7MVhw_RnD8Q=.13043746-8c61-474d-93b5-44743733441d@github.com>
 <3N5guZn5SiRlcjZrWQt0JbqUMJr79EcQ999JpVtx8-k=.cf3f71c3-4fcb-4958-b673-76b6b9797cd5@github.com>
 <aRyFeUB0t9pLvRy-awz2Kr2gh1RDsiB0YGsuWTSItCQ=.b313e672-413f-46af-b95f-8d87707a8d70@github.com>
Message-ID: <ss_jUjkp9czFGbMUUQ2nUdTrvJrFMmDv3zGUXtGTblw=.30fb6106-7606-41ee-8ecd-edc445286258@github.com>

On Thu, 8 Feb 2024 15:35:58 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please update the DocComment printout in that commented out test: the actual content is different. It would be nice if the test were passing at least at the moment of its initial commit.
>> 
>> Here's what I see locally:
>> 
>> 
>> Expect:
>> DocComment[DOC_COMMENT, pos:0
>>   firstSentence: 1
>>     Summary[SUMMARY, pos:4
>>       summary: 1
>>         Erroneous[ERRONEOUS, pos:14, prefPos:37
>>           code: compiler.err.dc.unterminated.inline.tag
>>           body: abc_`|_def}|_rest_`more`
>>         ]
>>     ]
>>   body: empty
>>   block tags: empty
>> ]
>> 
>> Found:
>> DocComment[DOC_COMMENT, pos:0
>>   firstSentence: 1
>>     Summary[SUMMARY, pos:1
>>       summary: 1
>>         Erroneous[ERRONEOUS, pos:11, prefPos:32
>>           code: compiler.err.dc.unterminated.inline.tag
>>           body: abc_`|def}|rest_`more`
>>         ]
>>     ]
>>   body: empty
>>   block tags: empty
>> ]
>
> Ping.

Thanks for fixing the test and clarifying its comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1484174598

From mikael at openjdk.org  Fri Feb  9 19:07:24 2024
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Fri, 9 Feb 2024 19:07:24 GMT
Subject: RFR: 8325570: Update to Graphviz 9.0.0
Message-ID: <mqFYVDlCBjSvwrZzi7r7bUl8dFXqbQYp8XZoK1Fwgog=.80ace7f5-6b7c-4f56-9b40-145914fd38d8@github.com>

Graphviz (aka. dotty/dot) is used when building "full" docs, and in particular for creating various module graph images (.svg). This change upgrades the Graphviz version used to 9.0.0 (latest).

In particular, the change:

* Updates the createGraphvizBundle.sh script (currently broken) to build graphviz from source
* Updates doc/building.{md,html} to reflect the role of Graphviz and Pandoc in the build
* The version of of the graphviz dependency used when building at Oracle (in jib-profiles.js)

Since, in addition to the changes in this PR itself, the exact version of Graphviz has an effect on the generated images, I have uploaded the docs generated by graphviz 9.0.0 here: https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/. For baseline the latest jdk23 docs, which uses graphviz 2.38.0, should do the trick: https://download.java.net/java/early_access/jdk23/docs/api/.

For example, picking a random .svg file:

baseline (graphviz 2.38.0): https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
new (graphviz 9.0.0): https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg


Testing: tier1, manual inspection of a few of the generated .svg files

As far as I can tell there are only very minor differences between the old (2.38.0) and new (9.0.0) .svg files. In particular, it seems like the new graphs are ever so slightly (5-10% or so) larger, but otherwise appear to be identical.

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

Commit messages:
 - 8325570: Update to Graphviz 9.0.0

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

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

From liach at openjdk.org  Fri Feb  9 19:23:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 Feb 2024 19:23:05 GMT
Subject: RFR: 8325570: Update to Graphviz 9.0.0
In-Reply-To: <mqFYVDlCBjSvwrZzi7r7bUl8dFXqbQYp8XZoK1Fwgog=.80ace7f5-6b7c-4f56-9b40-145914fd38d8@github.com>
References: <mqFYVDlCBjSvwrZzi7r7bUl8dFXqbQYp8XZoK1Fwgog=.80ace7f5-6b7c-4f56-9b40-145914fd38d8@github.com>
Message-ID: <R8WcIdsUIm-rBU8yq5zCHUV-Wh_UirPvC5SzDAHw3eI=.fb8d52ab-2329-4e84-b7d8-ad163b246d30@github.com>

On Fri, 9 Feb 2024 19:02:13 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Graphviz (aka. dotty/dot) is used when building "full" docs, and in particular for creating various module graph images (.svg). This change upgrades the Graphviz version used to 9.0.0 (latest).
> 
> In particular, the change:
> 
> * Updates the createGraphvizBundle.sh script (currently broken) to build graphviz from source
> * Updates doc/building.{md,html} to reflect the role of Graphviz and Pandoc in the build
> * The version of of the graphviz dependency used when building at Oracle (in jib-profiles.js)
> 
> Since, in addition to the changes in this PR itself, the exact version of Graphviz has an effect on the generated images, I have uploaded the docs generated by graphviz 9.0.0 here: https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/. For baseline the latest jdk23 docs, which uses graphviz 2.38.0, should do the trick: https://download.java.net/java/early_access/jdk23/docs/api/.
> 
> For example, picking a random .svg file:
> 
> baseline (graphviz 2.38.0): https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> new (graphviz 9.0.0): https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> 
> 
> Testing: tier1, manual inspection of a few of the generated .svg files
> 
> As far as I can tell there are only very minor differences between the old (2.38.0) and new (9.0.0) .svg files. In particular, it seems like the new graphs are ever so slightly (5-10% or so) larger, but otherwise appear to be identical.

Quick question, since configure scans for dot, will platform-specific pandoc (like Windows pandoc) lead to different image outputs?

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

PR Comment: https://git.openjdk.org/jdk/pull/17794#issuecomment-1936475303

From erikj at openjdk.org  Fri Feb  9 19:29:02 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 9 Feb 2024 19:29:02 GMT
Subject: RFR: 8325570: Update to Graphviz 9.0.0
In-Reply-To: <mqFYVDlCBjSvwrZzi7r7bUl8dFXqbQYp8XZoK1Fwgog=.80ace7f5-6b7c-4f56-9b40-145914fd38d8@github.com>
References: <mqFYVDlCBjSvwrZzi7r7bUl8dFXqbQYp8XZoK1Fwgog=.80ace7f5-6b7c-4f56-9b40-145914fd38d8@github.com>
Message-ID: <ctR1uGxHb_ZSeEbil3esg2pTjsuFG25HUyTg5-bMmic=.7c3e7b36-d2cf-4885-8470-d9afc01fa923@github.com>

On Fri, 9 Feb 2024 19:02:13 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Graphviz (aka. dotty/dot) is used when building "full" docs, and in particular for creating various module graph images (.svg). This change upgrades the Graphviz version used to 9.0.0 (latest).
> 
> In particular, the change:
> 
> * Updates the createGraphvizBundle.sh script (currently broken) to build graphviz from source
> * Updates doc/building.{md,html} to reflect the role of Graphviz and Pandoc in the build
> * The version of of the graphviz dependency used when building at Oracle (in jib-profiles.js)
> 
> Since, in addition to the changes in this PR itself, the exact version of Graphviz has an effect on the generated images, I have uploaded the docs generated by graphviz 9.0.0 here: https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/. For baseline the latest jdk23 docs, which uses graphviz 2.38.0, should do the trick: https://download.java.net/java/early_access/jdk23/docs/api/.
> 
> For example, picking a random .svg file:
> 
> baseline (graphviz 2.38.0): https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> new (graphviz 9.0.0): https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> 
> 
> Testing: tier1, manual inspection of a few of the generated .svg files
> 
> As far as I can tell there are only very minor differences between the old (2.38.0) and new (9.0.0) .svg files. In particular, it seems like the new graphs are ever so slightly (5-10% or so) larger, but otherwise appear to be identical.

Build changes and generator script look good to me. I don't want to be the judge of the difference in svg output.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17794#pullrequestreview-1873062975

From mikael at openjdk.org  Fri Feb  9 19:35:01 2024
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Fri, 9 Feb 2024 19:35:01 GMT
Subject: RFR: 8325570: Update to Graphviz 9.0.0
In-Reply-To: <KXCkLUe87o9wDii12PjKt947KwerPzLnUVyN0zDcBc4=.64b3a95f-e246-4397-86ce-acafcc72f986@github.com>
References: <mqFYVDlCBjSvwrZzi7r7bUl8dFXqbQYp8XZoK1Fwgog=.80ace7f5-6b7c-4f56-9b40-145914fd38d8@github.com>
 <R8WcIdsUIm-rBU8yq5zCHUV-Wh_UirPvC5SzDAHw3eI=.fb8d52ab-2329-4e84-b7d8-ad163b246d30@github.com>
 <KXCkLUe87o9wDii12PjKt947KwerPzLnUVyN0zDcBc4=.64b3a95f-e246-4397-86ce-acafcc72f986@github.com>
Message-ID: <bOnVTOwR0j9By4sJJsRchVJ1Rxb32xNLwCaJUPTfSzU=.a5fa930f-895d-4fa3-86b8-c9a9c6074254@github.com>

On Fri, 9 Feb 2024 19:32:01 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Quick question, since configure scans for dot, will platform-specific pandoc (like Windows pandoc) lead to different image outputs?

AFAIU pandoc is not involved in the generation of the .svg images. The .dot files are generated by the taglet build tool (https://github.com/openjdk/jdk/tree/master/make/jdk/src/classes/build/tools/taglet) and graphviz (dot) is used to convert the .dot files to .svg images.

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

PR Comment: https://git.openjdk.org/jdk/pull/17794#issuecomment-1936491417

From erikj at openjdk.org  Fri Feb  9 19:35:01 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 9 Feb 2024 19:35:01 GMT
Subject: RFR: 8325570: Update to Graphviz 9.0.0
In-Reply-To: <R8WcIdsUIm-rBU8yq5zCHUV-Wh_UirPvC5SzDAHw3eI=.fb8d52ab-2329-4e84-b7d8-ad163b246d30@github.com>
References: <mqFYVDlCBjSvwrZzi7r7bUl8dFXqbQYp8XZoK1Fwgog=.80ace7f5-6b7c-4f56-9b40-145914fd38d8@github.com>
 <R8WcIdsUIm-rBU8yq5zCHUV-Wh_UirPvC5SzDAHw3eI=.fb8d52ab-2329-4e84-b7d8-ad163b246d30@github.com>
Message-ID: <KXCkLUe87o9wDii12PjKt947KwerPzLnUVyN0zDcBc4=.64b3a95f-e246-4397-86ce-acafcc72f986@github.com>

On Fri, 9 Feb 2024 19:20:22 GMT, Chen Liang <liach at openjdk.org> wrote:

> Quick question, since configure scans for dot, will platform-specific pandoc (like Windows pandoc) lead to different image outputs?

The build should work with a locally installed Graphviz (`dot`) picked up from the environment, but as has been shown here, the output from different versions of Graphviz can vary. So yes, the build output can vary depending on the versions of tools used in the build.

To guarantee that builds from Oracle have a consistent output, we use defined versions of various tools, such as Graphviz, and for transparency we provide the scripts used to create those tool bundles in the make/devkit dir in the source tree, so that anyone who wants to know what we use can easily find out and replicate if desired.

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

PR Comment: https://git.openjdk.org/jdk/pull/17794#issuecomment-1936490191

From jjg at openjdk.org  Fri Feb  9 19:48:15 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 9 Feb 2024 19:48:15 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
 <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
Message-ID: <azswcdZYNHX6p00wKlN4P6z1EkXio2WNRdsXWWeDA_A=.be0d0648-f530-4262-aa7a-27bceea7e5df@github.com>

On Mon, 15 Jan 2024 12:20:57 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> 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 seven additional commits since the last revision:
>> 
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 130:
> 
>> 128: 
>> 129:     /**
>> 130:      * Create a parser for a documentation comment.
> 
> Suggestion:
> 
>      * Creates a parser for a documentation comment.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1484737196

From jjg at openjdk.org  Fri Feb  9 21:04:14 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 9 Feb 2024 21:04:14 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
 <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
Message-ID: <Pj1tkRMx-qPl7LG9T0ALXZyMtirj4CA-QB3hQ0TNxA4=.d18c10bf-fcde-40fa-b914-a197b2dd395f@github.com>

On Mon, 15 Jan 2024 11:48:23 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> 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 seven additional commits since the last revision:
>> 
>>  - Merge with upstream/master
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Address review comments
>>  - Fix whitespace
>>  - Improve handling of embedded inline taglets
>>  - Customize support for Markdown headings
>>  - JDK-8298405: Support Markdown in Documentation Comments
>
> src/jdk.compiler/share/classes/com/sun/source/util/DocTreeFactory.java line 299:
> 
>> 297:      * @param code the code
>> 298:      * @return a {@code RawTextTree} object
>> 299:      * @throws IllegalArgumentException if the kind is not a recognized kind for raw text
> 
> This method's implementation also throws `NullPointerException` if kind is null, which is unusual for these methods. You can either add `@throws`, or workaround it by using `String.valueOf(kind)` instead of `kind.toString()` down in the implementation.

It took me a while to understand this comment.
For here and now, I will use `String.valueOf(kind)`
Long term, it would be good to better document `null` behavior in this API. 
[JDK-8325577](https://bugs.openjdk.org/browse/JDK-8325577)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1484798682

From jjg at openjdk.org  Fri Feb  9 21:20:08 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 9 Feb 2024 21:20:08 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
In-Reply-To: <WYXUTmwMTgMP4YjGJk4CIxXFqZ6LwAhhjHOgjDVkOU4=.7a797721-e94f-44a8-8cea-78f761187d0f@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0mlIFIZ2ec8oE2zlmKxoMwp59dBgOdUQs-vzTLnU7hI=.15fa2827-8c87-415b-ab74-0e42b45a5cf7@github.com>
 <6df9dQzBK0M7SlHDpNO4T_bhE7i6WqwLP64cs6Df9A8=.e08f76a3-8753-4bad-9325-b0ab042645a4@github.com>
 <WYXUTmwMTgMP4YjGJk4CIxXFqZ6LwAhhjHOgjDVkOU4=.7a797721-e94f-44a8-8cea-78f761187d0f@github.com>
Message-ID: <PiqEAJdFc4w3Ub9drdvdE5s33UBmL1Q03c0EDvlb2P8=.bdf13154-75a0-45bf-848f-3ce4855c4ac7@github.com>

On Fri, 9 Feb 2024 18:27:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 201:
>> 
>>> 199:                 }
>>> 200:                 newline = true;
>>> 201:             }
>> 
>> I can see clean LF and CRLF, but no FF; was the latter intentional?
>> 
>> In any case, we should double-check the generated test output to see if there's anything unexpected.
>
> We've been here, with `\f` before, noting the different handling of `\f` in `javac` and `javadoc`.
> 
> My recollection is that it was intentional to drop support for `\f`, thus aligning `javac` and `javadoc` behavior, and to normalize handling of the newline sequences, translating them to `\n`.

> In any case, we should double-check the generated test output to see if there's anything unexpected.

verified tests pass and no change in generated JDK API docs

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1484812046

From jjg at openjdk.org  Fri Feb  9 21:24:25 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 9 Feb 2024 21:24:25 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v29]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <034sIbO5WNQTE779M9KSaGfIefM0m50Hsle5KBc_QH8=.1703bc55-c733-4702-b064-54bd65173cff@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  address review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/91588bc3..d22668da

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=27-28

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

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

From jjg at openjdk.org  Fri Feb  9 22:17:43 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 9 Feb 2024 22:17:43 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v30]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <jyz30BnzzLWkefI92p092QSHqOafHMQSP4819QxpS_8=.c548e7cc-33c2-4c26-9d89-65de18397cfe@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  refactor recent new test case in TestMarkdown.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/d22668da..3f8aa6b5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=28-29

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

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

From tanksherman27 at gmail.com  Sun Feb 11 11:14:00 2024
From: tanksherman27 at gmail.com (Julian Waters)
Date: Sun, 11 Feb 2024 19:14:00 +0800
Subject: Which JDK in the build directory is the one that is shipped?
In-Reply-To: <c4130dd2-7d47-4c2b-9755-1e0e91466dd3@oracle.com>
References: <CAP2b4GMnq=PHt=SzFttM1rTL7st5RnW3VK+huuNUpFP+A7ZSDQ@mail.gmail.com>
 <c4130dd2-7d47-4c2b-9755-1e0e91466dd3@oracle.com>
Message-ID: <CAP2b4GM8OrWfJUoC3TGjOCg65DAQyxMo68DSzARTyVGTD162nA@mail.gmail.com>

Hi Erik,

Thanks for the clarification! How then does Oracle compile the JDK, such
that the versioning numbers appear in the following manner?

C:\Users\vertig0>java --version
java 21 2023-09-19 LTS
Java(TM) SE Runtime Environment (build 21+35-LTS-2513)
Java HotSpot(TM) 64-Bit Server VM (build 21+35-LTS-2513, mixed mode,
sharing)

(My system doesn't have OpenJDK as its main JDK, and uses the Oracle JDK
instead. The "Java" strings should rightfully be "OpenJDK", so pay no mind
to that. Last I remember, the printed OpenJDK version is the same as above
except for "Java(TM)" being "OpenJDK" instead)

The MSYS2 Project would prefer to have its MinGW JDKs versioned as such (Eg
build 21+35-LTS-2513 or whatever), rather than something like
"23-internal-adhoc.mingwci.jdk", and we'd prefer to mimic how Oracle
compiles both OpenJDK and Oracle JDK as closely as possible.

I believe Oracle probably does it by specifying different parts of the
version string on configure, something like

bash configure <Whatever the option string and other compile options are>
make product-bundles

but I'd like to know the exact flags used, especially for Windows binaries,
if possible

best regards,
Julian

On Thu, Feb 1, 2024 at 9:52?PM <erik.joelsson at oracle.com> wrote:

> On 2/1/24 04:47, Julian Waters wrote:
> > Hi all,
> >
> > Quick question: Which JDK in the build directory is the one that is
> > officially shipped by Oracle? Is it the one in "jdk" that is directly
> > in the build directory, or the one in "images/jdk"?
>
> The one in images/jdk is the one we base the distribution on, but it's
> not actually exactly that. For historic reasons the image generated in
> images/jdk contains external debug symbols, which we do not ship. To get
> exactly what is shipped, run `make product-bundles` and check the
> zip/tar.gz in "bundles/".
>
> The one directly in jdk, the "exploded image", just exists because it's
> faster to build, especially incrementally, so in some developer
> workflows it's preferred. Since the class files are all laid out on disk
> and not jlinked together, it has quite different performance
> characteristics.
>
> /Erik
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240211/3ebde6b4/attachment.htm>

From ihse at openjdk.org  Mon Feb 12 08:01:23 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 12 Feb 2024 08:01:23 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v11]
In-Reply-To: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
Message-ID: <qWgtofRO90npZio78zqiZ-JRFAInJnzEd3M4vTS5Sw4=.2f55945e-3c80-4551-8ae1-91643f750489@github.com>

> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge branch 'master' into jdk-FOB64
 - Fix indentation
 - Once more, remove AIX dirent64 et al defines
 - Also fix fstatvfs on AIX
 - Redefine statvfs as statvfs64 on AIX
 - Add kludge to BufferedRenderPipe.c for AIX
 - Merge branch 'master' into jdk-FOB64
 - Remove all system includes from debug_util.h
 - Merge branch 'master' into jdk-FOB64
 - Move #include <stdlib/io.h> out of debug_util.h
 - ... and 5 more: https://git.openjdk.org/jdk/compare/efa071dd...caccbf9b

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

Changes: https://git.openjdk.org/jdk/pull/17538/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=10
  Stats: 284 lines in 29 files changed: 23 ins; 144 del; 117 mod
  Patch: https://git.openjdk.org/jdk/pull/17538.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538

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

From ihse at openjdk.org  Mon Feb 12 08:09:34 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 12 Feb 2024 08:09:34 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v12]
In-Reply-To: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
Message-ID: <XgE0rWiUyRPX33RDpnEMAN0QHkN-mKslzdbUBDqlRm4=.c30dcb89-9b0a-476d-b5c4-b7f84b0ac295@github.com>

> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17538/files
  - new: https://git.openjdk.org/jdk/pull/17538/files/caccbf9b..7f673ef6

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

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

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

From ihse at openjdk.org  Mon Feb 12 08:09:34 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 12 Feb 2024 08:09:34 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10]
In-Reply-To: <XVYdfEqu9JnUHo2IIYd3mRN3czS1RvhdHmvgCSYrMKU=.1caabb1d-787b-4415-84c0-1ac3362d1dbf@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <pxn7GqRax1tb7sEK0Q1KnEalowEaZjSUp-O6h4khF78=.9a069feb-3598-4253-a0ac-f87480628802@github.com>
 <ran4RH4U4aZqbo5qhnTVflV7u6ZnxSgu1xetJDWQywE=.8009f47b-9355-4280-bfa6-9d67c7d4454b@github.com>
 <XVYdfEqu9JnUHo2IIYd3mRN3czS1RvhdHmvgCSYrMKU=.1caabb1d-787b-4415-84c0-1ac3362d1dbf@github.com>
Message-ID: <mAHZLLjPhCxXrsikL9lTKw6qZW3Jvtu9bMiz8BqkXzY=.bd4c37a5-f700-4ad8-bf13-4a4ac3e2c747@github.com>

On Thu, 8 Feb 2024 14:47:26 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> And also `#define statvfs statvfs64` is not necessary with the same explanation as  for the `opendir` defines above -- sorry again.
>> The very only difference between statvfs and statvfs64 is that the filesystem ID field in statvfs has a width of 8 Bytes, while in statvfs64 it has a width of 16 Bytes.
>
>> @JoKern65 So what about `#define fstatvfs fstatvfs64`? Is that still needed? If so, I could not be bothered to make another change. Otherwise, we can get rid of _all_ AIX 64-bit redefines, and then I'll (probably) do it.
> 
> Same as `statvfs`. Only the file system ID field is smaller.

@JoKern65 @MBaesken I did not receive any reply about what to do with `fstatvfs`, so I decided to keep the last verified change for AIX. If you want to clean this up, then please do so, but at that time it will be an AIX-only patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1938201250

From duke at openjdk.org  Mon Feb 12 08:09:36 2024
From: duke at openjdk.org (Sam James)
Date: Mon, 12 Feb 2024 08:09:36 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v11]
In-Reply-To: <qWgtofRO90npZio78zqiZ-JRFAInJnzEd3M4vTS5Sw4=.2f55945e-3c80-4551-8ae1-91643f750489@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <qWgtofRO90npZio78zqiZ-JRFAInJnzEd3M4vTS5Sw4=.2f55945e-3c80-4551-8ae1-91643f750489@github.com>
Message-ID: <dE2aTbLBiwus6fRcwRSCSss6GL4ibefbmgTbeq1A-Fw=.c182b77d-6f38-4fb8-9aeb-da47eb8cdf24@github.com>

On Mon, 12 Feb 2024 08:01:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge branch 'master' into jdk-FOB64
>  - Fix indentation
>  - Once more, remove AIX dirent64 et al defines
>  - Also fix fstatvfs on AIX
>  - Redefine statvfs as statvfs64 on AIX
>  - Add kludge to BufferedRenderPipe.c for AIX
>  - Merge branch 'master' into jdk-FOB64
>  - Remove all system includes from debug_util.h
>  - Merge branch 'master' into jdk-FOB64
>  - Move #include <stdlib/io.h> out of debug_util.h
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/efa071dd...caccbf9b

Thank you again for this!

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1938202537

From ihse at openjdk.org  Mon Feb 12 08:09:36 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 12 Feb 2024 08:09:36 GMT
Subject: Integrated: 8324539: Do not use LFS64 symbols in JDK libs
In-Reply-To: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
Message-ID: <hwIZoTTvMohV73pgmnY9XsTT3lVw5yOSE1hv-3xX5iE=.f4bf6905-f2f0-49cf-8fd9-a27abd5169ac@github.com>

On Tue, 23 Jan 2024 15:42:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.

This pull request has now been integrated.

Changeset: e5cb78cc
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e5cb78cc88761cd27964e9fe77fc9c6f9073e888
Stats:     310 lines in 29 files changed: 23 ins; 144 del; 143 mod

8324539: Do not use LFS64 symbols in JDK libs

Reviewed-by: jwaters, erikj, mbaesken, alanb

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

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

From ihse at openjdk.org  Mon Feb 12 08:11:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 12 Feb 2024 08:11:03 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: <rB3HxteVgSXBiQnLDLdYgc2jXTL2fFPg5zdCQwxHt1g=.37699c1c-1dad-4451-b364-38d1b2170957@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
 <rB3HxteVgSXBiQnLDLdYgc2jXTL2fFPg5zdCQwxHt1g=.37699c1c-1dad-4451-b364-38d1b2170957@github.com>
Message-ID: <8BLLuuu7gTj4P8bDZ40PWRJDT7668CSSqMiywzlPrIs=.1f188e66-2327-43e3-b30e-16798937eefe@github.com>

On Fri, 9 Feb 2024 18:09:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is an attempt to finally implement the idea brought forward in JDK-8295729:  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 or leading tabs instead of spaces. 
>> 
>> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
>> 
>> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.
>
> Skimmed through the changes and all look good to me. Good to have `jcheck` detect those unneeded trailing spaces.

@naotoj Thanks! Would you care to also submit a review?

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

PR Comment: https://git.openjdk.org/jdk/pull/17789#issuecomment-1938204446

From aph-open at littlepinkcloud.com  Mon Feb 12 08:42:02 2024
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Mon, 12 Feb 2024 08:42:02 +0000
Subject: Which JDK in the build directory is the one that is shipped?
In-Reply-To: <CAP2b4GM8OrWfJUoC3TGjOCg65DAQyxMo68DSzARTyVGTD162nA@mail.gmail.com>
References: <CAP2b4GMnq=PHt=SzFttM1rTL7st5RnW3VK+huuNUpFP+A7ZSDQ@mail.gmail.com>
 <c4130dd2-7d47-4c2b-9755-1e0e91466dd3@oracle.com>
 <CAP2b4GM8OrWfJUoC3TGjOCg65DAQyxMo68DSzARTyVGTD162nA@mail.gmail.com>
Message-ID: <ba98e0bb-82da-4d0e-9901-f299f7a9298f@littlepinkcloud.com>

On 2/11/24 11:14, Julian Waters wrote:
> Hi Erik,
> 
> Thanks for the clarification! How then does Oracle compile the JDK, such that the versioning numbers appear in the following manner?
> 
> C:\Users\vertig0>java --version
> java 21 2023-09-19 LTS
> Java(TM) SE Runtime Environment (build 21+35-LTS-2513)
> Java HotSpot(TM) 64-Bit Server VM (build 21+35-LTS-2513, mixed mode, sharing)
> 
> (My system doesn't have OpenJDK as its main JDK, and uses the Oracle JDK instead. The "Java" strings should rightfully be "OpenJDK", so pay no mind to that. Last I remember, the printed OpenJDK version is the same as above except for "Java(TM)" being "OpenJDK" instead)
> 
> The MSYS2 Project would prefer to have its MinGW JDKs versioned as such (Eg build 21+35-LTS-2513 or whatever), rather than something like "23-internal-adhoc.mingwci.jdk", and we'd prefer to mimic how Oracle compiles both OpenJDK and Oracle JDK as closely as possible.
> 
> I sh ./configure --helpbelieve Oracle probably does it by specifying different parts of the version string on configure, something like
> 
> bash configure <Whatever the option string and other compile options are>

"sh ./configure --help" and look for the --with-version options.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From pminborg at openjdk.org  Mon Feb 12 09:04:52 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 12 Feb 2024 09:04:52 GMT
Subject: RFR: 8325570: Update to Graphviz 9.0.0
In-Reply-To: <mqFYVDlCBjSvwrZzi7r7bUl8dFXqbQYp8XZoK1Fwgog=.80ace7f5-6b7c-4f56-9b40-145914fd38d8@github.com>
References: <mqFYVDlCBjSvwrZzi7r7bUl8dFXqbQYp8XZoK1Fwgog=.80ace7f5-6b7c-4f56-9b40-145914fd38d8@github.com>
Message-ID: <8cRByF_RgK7PtIE7t5gUkw-0WyQIk81O84nCf7icwiw=.af414775-7e52-4903-afe0-6af5b4bff4dd@github.com>

On Fri, 9 Feb 2024 19:02:13 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Graphviz (aka. dotty/dot) is used when building "full" docs, and in particular for creating various module graph images (.svg). This change upgrades the Graphviz version used to 9.0.0 (latest).
> 
> In particular, the change:
> 
> * Updates the createGraphvizBundle.sh script (currently broken) to build graphviz from source
> * Updates doc/building.{md,html} to reflect the role of Graphviz and Pandoc in the build
> * The version of of the graphviz dependency used when building at Oracle (in jib-profiles.js)
> 
> Since, in addition to the changes in this PR itself, the exact version of Graphviz has an effect on the generated images, I have uploaded the docs generated by graphviz 9.0.0 here: https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/. For baseline the latest jdk23 docs, which uses graphviz 2.38.0, should do the trick: https://download.java.net/java/early_access/jdk23/docs/api/.
> 
> For example, picking a random .svg file:
> 
> baseline (graphviz 2.38.0): https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> new (graphviz 9.0.0): https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> 
> 
> Testing: tier1, manual inspection of a few of the generated .svg files
> 
> As far as I can tell there are only very minor differences between the old (2.38.0) and new (9.0.0) .svg files. In particular, it seems like the new graphs are ever so slightly (5-10% or so) larger, but otherwise appear to be identical.

I have reviewed the image output for some classes (e.g. MemoryLayout) and there is a small scale difference and some minor changes in the appearance of rendered objects. As the rendering is not strictly defined, the effect of the proposed changes looks good to me.

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

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17794#pullrequestreview-1874769735

From jkern at openjdk.org  Mon Feb 12 09:26:14 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 12 Feb 2024 09:26:14 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10]
In-Reply-To: <XVYdfEqu9JnUHo2IIYd3mRN3czS1RvhdHmvgCSYrMKU=.1caabb1d-787b-4415-84c0-1ac3362d1dbf@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <pxn7GqRax1tb7sEK0Q1KnEalowEaZjSUp-O6h4khF78=.9a069feb-3598-4253-a0ac-f87480628802@github.com>
 <ran4RH4U4aZqbo5qhnTVflV7u6ZnxSgu1xetJDWQywE=.8009f47b-9355-4280-bfa6-9d67c7d4454b@github.com>
 <XVYdfEqu9JnUHo2IIYd3mRN3czS1RvhdHmvgCSYrMKU=.1caabb1d-787b-4415-84c0-1ac3362d1dbf@github.com>
Message-ID: <eskJafo8EX8h4OQ_EbvplsWV3ivNrFHjbqAhHv5BMW8=.0a88009e-453b-456a-afed-93289f773a52@github.com>

On Thu, 8 Feb 2024 14:47:26 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> And also `#define statvfs statvfs64` is not necessary with the same explanation as  for the `opendir` defines above -- sorry again.
>> The very only difference between statvfs and statvfs64 is that the filesystem ID field in statvfs has a width of 8 Bytes, while in statvfs64 it has a width of 16 Bytes.
>
>> @JoKern65 So what about `#define fstatvfs fstatvfs64`? Is that still needed? If so, I could not be bothered to make another change. Otherwise, we can get rid of _all_ AIX 64-bit redefines, and then I'll (probably) do it.
> 
> Same as `statvfs`. Only the file system ID field is smaller.

> @JoKern65 @MBaesken I did not receive any reply about what to do with `fstatvfs`, so I decided to keep the last verified change for AIX. If you want to clean this up, then please do so, but at that time it will be an AIX-only patch.

@magicus I have to reach out to IBM asking if the different size of the 'filesystem ID' field in statvfs makes an important difference. If not, I will remove the defines in an AIX-only patch.
Thanks a lot for your effort.

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1938300228

From ihse at openjdk.org  Mon Feb 12 11:49:13 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 12 Feb 2024 11:49:13 GMT
Subject: RFR: 8325626: Allow selection of non-matching configurations using
 CONF=!string
Message-ID: <QG3leQN-ylFbwPAR2M0YWNf15XEj0FY6zjzfQl4IGck=.803ec8a5-2264-4df5-8d72-2722c2c8f4a3@github.com>

A common scenario is for a developer to have two configurations, a product and a debug version, e.g. `linux-x64`and `linux-x64-debug`. To select the latter using `CONF` is just a matter of using `CONF=debug`, but to select the former, the complete name needs to be supplied: `CONF=linux-x64`.

Instead, this patch introduces the use of `!` as a negation character, so `CONF=!debug` would select all configurations that do not match `debug`. 

I also took the time to clarify and correct the documentation on how to use `CONF`.

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

Commit messages:
 - 8325626: Allow selection of non-matching configurations using CONF=!string

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

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

From ihse at openjdk.org  Mon Feb 12 12:57:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 12 Feb 2024 12:57:03 GMT
Subject: RFR: 8325570: Update to Graphviz 9.0.0
In-Reply-To: <mqFYVDlCBjSvwrZzi7r7bUl8dFXqbQYp8XZoK1Fwgog=.80ace7f5-6b7c-4f56-9b40-145914fd38d8@github.com>
References: <mqFYVDlCBjSvwrZzi7r7bUl8dFXqbQYp8XZoK1Fwgog=.80ace7f5-6b7c-4f56-9b40-145914fd38d8@github.com>
Message-ID: <a2WtRXdeDbCVicnuRF81jNmNBimorp6vHch4Pq3ijCA=.43ab3a2d-8fb0-42fd-be18-fc984e6ad057@github.com>

On Fri, 9 Feb 2024 19:02:13 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Graphviz (aka. dotty/dot) is used when building "full" docs, and in particular for creating various module graph images (.svg). This change upgrades the Graphviz version used to 9.0.0 (latest).
> 
> In particular, the change:
> 
> * Updates the createGraphvizBundle.sh script (currently broken) to build graphviz from source
> * Updates doc/building.{md,html} to reflect the role of Graphviz and Pandoc in the build
> * The version of of the graphviz dependency used when building at Oracle (in jib-profiles.js)
> 
> Since, in addition to the changes in this PR itself, the exact version of Graphviz has an effect on the generated images, I have uploaded the docs generated by graphviz 9.0.0 here: https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/. For baseline the latest jdk23 docs, which uses graphviz 2.38.0, should do the trick: https://download.java.net/java/early_access/jdk23/docs/api/.
> 
> For example, picking a random .svg file:
> 
> baseline (graphviz 2.38.0): https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> new (graphviz 9.0.0): https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> 
> 
> Testing: tier1, manual inspection of a few of the generated .svg files
> 
> As far as I can tell there are only very minor differences between the old (2.38.0) and new (9.0.0) .svg files. In particular, it seems like the new graphs are ever so slightly (5-10% or so) larger, but otherwise appear to be identical.

LGTM. Thanks for updating the build documentation!

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17794#pullrequestreview-1875177939

From ihse at openjdk.org  Mon Feb 12 14:01:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 12 Feb 2024 14:01:03 GMT
Subject: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX
 [v7]
In-Reply-To: <Im5Io8I0KFrq0VMnTh04FN1lF_lJ894Ol6UHbzoLALA=.b9fa2522-eb47-4b62-9ad4-45c10319cf5a@github.com>
References: <ICO286ZvQYqYXv9c73UlduKVcNF19k9Eln1po4znpxc=.2fbc366d-3095-47ca-a49d-ec35509f30ba@github.com>
 <Im5Io8I0KFrq0VMnTh04FN1lF_lJ894Ol6UHbzoLALA=.b9fa2522-eb47-4b62-9ad4-45c10319cf5a@github.com>
Message-ID: <FjwOWTp46HEile71IYJ40CmBL__QUuq0tvJ9uczyE6A=.a2617816-a833-4e82-b661-d08c17c10ede@github.com>

On Thu, 18 Jan 2024 16:21:46 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted autoconf flags being added to the command line, and solves the issue by filtering out the added flags by force. This is not optimal however, as doing so leaves the autoconf message that the flags were added still displaying during the configure process, which is confusing. Instead, setting a couple of fields to disable the autoconf internals responsible for the unwanted flag is a cleaner solution
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement custom AC_PROG_CC and AC_PROG_CXX in util.m4

I have verified that this works fine in the Oracle internal CI.

Erik's point still stands:
> I still think it would be prudent to verify this patch with all the currently accepted versions of autoconf (2.69, 2.70, 2.71, 2.72).

I think the easiest way to achieve this is to checkout the autoconf at these versions, and build it yourself. Iirc it was quite easy to build autoconf (anything else would be a shame and very bad PR for the project! :-o).

I'm hoping you are willing to do this, since I believe this is a superior solution and I'd like to see it in mainline. (Otherwise, let me know and I'll try to squeeze in doing it.)

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

PR Comment: https://git.openjdk.org/jdk/pull/17401#issuecomment-1938730535

From jwaters at openjdk.org  Mon Feb 12 14:13:05 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 12 Feb 2024 14:13:05 GMT
Subject: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX
 [v7]
In-Reply-To: <FjwOWTp46HEile71IYJ40CmBL__QUuq0tvJ9uczyE6A=.a2617816-a833-4e82-b661-d08c17c10ede@github.com>
References: <ICO286ZvQYqYXv9c73UlduKVcNF19k9Eln1po4znpxc=.2fbc366d-3095-47ca-a49d-ec35509f30ba@github.com>
 <Im5Io8I0KFrq0VMnTh04FN1lF_lJ894Ol6UHbzoLALA=.b9fa2522-eb47-4b62-9ad4-45c10319cf5a@github.com>
 <FjwOWTp46HEile71IYJ40CmBL__QUuq0tvJ9uczyE6A=.a2617816-a833-4e82-b661-d08c17c10ede@github.com>
Message-ID: <JgM0v3RHPzFTPzIt1HpNR1nZUegjx-j5KN7NQ3RaCFc=.6e142ef5-e6c2-4e0a-a5dd-d3b3bc178234@github.com>

On Mon, 12 Feb 2024 13:57:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I have verified that this works fine in the Oracle internal CI.
> 
> Erik's point still stands:
> 
> > I still think it would be prudent to verify this patch with all the currently accepted versions of autoconf (2.69, 2.70, 2.71, 2.72).
> 
> I think the easiest way to achieve this is to checkout the autoconf at these versions, and build it yourself. Iirc it was quite easy to build autoconf (anything else would be a shame and very bad PR for the project! :-o).
> 
> I'm hoping you are willing to do this, since I believe this is a superior solution and I'd like to see it in mainline. (Otherwise, let me know and I'll try to squeeze in doing it.)

It's actually even easier to do on Windows than it might appear, since MinGW's pacman system has caches that contain past package versions. I wouldn't have to build it at all in fact, all I'd have to do is downgrade my autoconf to past versions (I think I'm currently on 2.71). I know you're probably very busy right now, so I'll spare you the chore of having to do that by testing it on my end. That said, should I test autoconf on all platforms too? That aside, I'm still a little unhappy that there is no formal way to unregister an AC_DEFUN macro though :(

By the way, I've left you something in the mail. Hope you have some time to check it out!

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

PR Comment: https://git.openjdk.org/jdk/pull/17401#issuecomment-1938751180

From erik.joelsson at oracle.com  Mon Feb 12 14:16:15 2024
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Mon, 12 Feb 2024 06:16:15 -0800
Subject: [External] : Re: Which JDK in the build directory is the one that
 is shipped?
In-Reply-To: <CAP2b4GM8OrWfJUoC3TGjOCg65DAQyxMo68DSzARTyVGTD162nA@mail.gmail.com>
References: <CAP2b4GMnq=PHt=SzFttM1rTL7st5RnW3VK+huuNUpFP+A7ZSDQ@mail.gmail.com>
 <c4130dd2-7d47-4c2b-9755-1e0e91466dd3@oracle.com>
 <CAP2b4GM8OrWfJUoC3TGjOCg65DAQyxMo68DSzARTyVGTD162nA@mail.gmail.com>
Message-ID: <3fc0aca8-6d61-4685-9126-ad9309ba0887@oracle.com>


On 2/11/24 03:14, Julian Waters wrote:
> Hi Erik,
>
> Thanks for the clarification! How then does Oracle compile the JDK, 
> such that the versioning numbers appear in the following manner?
>
> C:\Users\vertig0>java --version
> java 21 2023-09-19 LTS
> Java(TM) SE Runtime Environment (build 21+35-LTS-2513)
> Java HotSpot(TM) 64-Bit Server VM (build 21+35-LTS-2513, mixed mode, 
> sharing)
>
> (My system doesn't have OpenJDK as its main JDK, and uses the Oracle 
> JDK instead. The "Java" strings should rightfully be "OpenJDK", so pay 
> no mind to that. Last I remember, the printed OpenJDK version is the 
> same as above except for "Java(TM)" being "OpenJDK" instead)
>
> The MSYS2 Project would prefer to have its MinGW JDKs versioned as 
> such (Eg build 21+35-LTS-2513 or whatever), rather than something like 
> "23-internal-adhoc.mingwci.jdk", and we'd prefer to mimic how Oracle 
> compiles both OpenJDK and Oracle JDK as closely as possible.
>
> I believe Oracle probably does it by specifying different parts of the 
> version string on configure, something like
>
> bash configure <Whatever the option string and other compile options are>
> make product-bundles
>
> but I'd like to know the exact flags used, especially for Windows 
> binaries, if possible
>
These are the relevant arguments we used for that particular build:

 ?--with-version-build=35 --with-version-pre= --with-version-opt=LTS-2513

/Erik

> best regards,
> Julian
>
> On Thu, Feb 1, 2024 at 9:52?PM <erik.joelsson at oracle.com> wrote:
>
>     On 2/1/24 04:47, Julian Waters wrote:
>     > Hi all,
>     >
>     > Quick question: Which JDK in the build directory is the one that is
>     > officially shipped by Oracle? Is it the one in "jdk" that is
>     directly
>     > in the build directory, or the one in "images/jdk"?
>
>     The one in images/jdk is the one we base the distribution on, but
>     it's
>     not actually exactly that. For historic reasons the image
>     generated in
>     images/jdk contains external debug symbols, which we do not ship.
>     To get
>     exactly what is shipped, run `make product-bundles` and check the
>     zip/tar.gz in "bundles/".
>
>     The one directly in jdk, the "exploded image", just exists because
>     it's
>     faster to build, especially incrementally, so in some developer
>     workflows it's preferred. Since the class files are all laid out
>     on disk
>     and not jlinked together, it has quite different performance
>     characteristics.
>
>     /Erik
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240212/d640c04a/attachment-0001.htm>

From erikj at openjdk.org  Mon Feb 12 14:23:04 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 12 Feb 2024 14:23:04 GMT
Subject: RFR: 8325626: Allow selection of non-matching configurations using
 CONF=!string
In-Reply-To: <QG3leQN-ylFbwPAR2M0YWNf15XEj0FY6zjzfQl4IGck=.803ec8a5-2264-4df5-8d72-2722c2c8f4a3@github.com>
References: <QG3leQN-ylFbwPAR2M0YWNf15XEj0FY6zjzfQl4IGck=.803ec8a5-2264-4df5-8d72-2722c2c8f4a3@github.com>
Message-ID: <c626zK0w5eXqALLjif1AQEtrgcWzvCUoItDBa0dykqo=.2c964030-00a0-45b0-b7b5-f3fbbaaed50a@github.com>

On Mon, 12 Feb 2024 11:44:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A common scenario is for a developer to have two configurations, a product and a debug version, e.g. `linux-x64`and `linux-x64-debug`. To select the latter using `CONF` is just a matter of using `CONF=debug`, but to select the former, the complete name needs to be supplied: `CONF=linux-x64`.
> 
> Instead, this patch introduces the use of `!` as a negation character, so `CONF=!debug` would select all configurations that do not match `debug`. 
> 
> I also took the time to clarify and correct the documentation on how to use `CONF`.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17804#pullrequestreview-1875350996

From ihse at openjdk.org  Mon Feb 12 14:31:04 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 12 Feb 2024 14:31:04 GMT
Subject: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX
 [v7]
In-Reply-To: <JgM0v3RHPzFTPzIt1HpNR1nZUegjx-j5KN7NQ3RaCFc=.6e142ef5-e6c2-4e0a-a5dd-d3b3bc178234@github.com>
References: <ICO286ZvQYqYXv9c73UlduKVcNF19k9Eln1po4znpxc=.2fbc366d-3095-47ca-a49d-ec35509f30ba@github.com>
 <Im5Io8I0KFrq0VMnTh04FN1lF_lJ894Ol6UHbzoLALA=.b9fa2522-eb47-4b62-9ad4-45c10319cf5a@github.com>
 <FjwOWTp46HEile71IYJ40CmBL__QUuq0tvJ9uczyE6A=.a2617816-a833-4e82-b661-d08c17c10ede@github.com>
 <JgM0v3RHPzFTPzIt1HpNR1nZUegjx-j5KN7NQ3RaCFc=.6e142ef5-e6c2-4e0a-a5dd-d3b3bc178234@github.com>
Message-ID: <X9RKvu5oV8TEx98Mr4-j0m8RoiLQIP183tgqtLr93CA=.9f0f8551-89c9-45db-aad6-5fc7cdc5f638@github.com>

On Mon, 12 Feb 2024 14:09:49 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> That said, should I test autoconf on all platforms too?

No, that seems over the top. For this purpose, we must assume that all autoconf on all platforms behave the same.

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

PR Comment: https://git.openjdk.org/jdk/pull/17401#issuecomment-1938783176

From prappo at openjdk.org  Mon Feb 12 15:30:10 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 12 Feb 2024 15:30:10 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <e0aoGsEBu6BxJgwRLe8EWXsZuRzJYC8POqB22FVVWhE=.c15250b4-1680-48d7-82de-bb512e0f3afd@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <HZQiJKB0i4jqcVhsKgdzF3_q0vXLC2IIEi6JeZpdq5w=.5cc0180c-8db2-4768-ad38-95aa3ec85403@github.com>
 <e0aoGsEBu6BxJgwRLe8EWXsZuRzJYC8POqB22FVVWhE=.c15250b4-1680-48d7-82de-bb512e0f3afd@github.com>
Message-ID: <wicEi4HomuO7CTYRviD8GDZWm0FcNgauHW-2Nd3mJxc=.ea6da35a-ec2b-434e-909d-0a7119739829@github.com>

On Tue, 30 Jan 2024 23:15:32 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java line 790:
>> 
>>> 788: 
>>> 789:         // end of paragraph is newline, followed by a blank line or the beginning of the next block
>>> 790:         private static final Pattern endPara = Pattern.compile("\n(([ \t]*\n)|( {0,3}[-+*#=]))");
>> 
>> So DocTreeMaker now also knows about Markdown. I wonder if we can avoid that. Also, I assume you mean this (`+` is not a part of "thematic break"):
>> Suggestion:
>> 
>>         private static final Pattern endPara = Pattern.compile("\n(([ \t]*\n)|( {0,3}[-_*#=]))");
>
> The code is doing its best to model the non-Markdown behavior, which is to detect paragraph breaks, which terminate the first sentence in the absence of any period.
> 
> `+` is in the pattern as a list marker; I added `_` for thematic break, and added more comments.

I can see that you have fixed it to recognise lists `+` and thematic breaks `_`; good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1486343596

From prappo at openjdk.org  Mon Feb 12 15:47:08 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 12 Feb 2024 15:47:08 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <HfTVo2rOdZeEXe3qGclLIHgptXeQ568_eWNRU66dOWU=.94fa57b9-1e4d-4151-a7f7-0cbd66598f50@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <zrqu3x52AXuB6DBs1kg66rC0arBB3MUFFokkL8CIF_k=.7935ef71-4d3c-4246-bf5c-afe5fd5fb625@github.com>
 <82KgOfWLlL77CZkJUnSaiWxaSuu4C1uLkzr6BHnCUd4=.aeeb8842-7c6c-4db3-bf70-690e0008f74c@github.com>
 <HfTVo2rOdZeEXe3qGclLIHgptXeQ568_eWNRU66dOWU=.94fa57b9-1e4d-4151-a7f7-0cbd66598f50@github.com>
Message-ID: <gqNWtYhM4nv9c-cGDwvZJgu1AvfCoBDaGbhns5kdgQ0=.14b7c2ac-aed4-4e0e-906d-1204f73404e1@github.com>

On Wed, 31 Jan 2024 22:15:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> I guess I don't see this as being as big a deal as you seem to think it is. What is it that you are so concerned about?
>> 
>> I also think it is a potential feature to document and use reference links with `code:` URLs, using the reference link syntax to avoid having long method signatures in narrative text.
>> 
>> For example, 
>> 
>>    One of the methods on [List] has [lots of args][List.of10].
>>    
>>    [List.of10]code:List.of(E,E,E,E,E,E,E,E,E,E)
>
> I've changed the prefix to be dynamically generated. It's now called `autorefScheme` and is passed around as needed. It contains a hex hashcode, so is reasonably unguessable.
> 
> I'm still sort-of sad to lose the ability to use `code:` URLs directly, so I've left a comment in the code hinting that that is a possibility.

Thanks for accepting this; we could revert it later if the fixed, known scheme is deemed more useful.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1486364459

From prappo at openjdk.org  Mon Feb 12 15:47:08 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 12 Feb 2024 15:47:08 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <xdbBz5jNKMyTzPYYjGZ993AJ53U6DQm-LZHahZLLKfc=.0de14de4-08fe-435b-a173-6d7c5518d21b@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <zrqu3x52AXuB6DBs1kg66rC0arBB3MUFFokkL8CIF_k=.7935ef71-4d3c-4246-bf5c-afe5fd5fb625@github.com>
 <UbOd3C2ZrB35hFrkossEp7LIUWFk9dpBZh6v8IS0HeA=.84a2e253-8eb2-40fc-8256-c38a8a4e4399@github.com>
 <t12_cx8L88XOIB668UOHrnt7TPsyJiVC48ic7BribrI=.4b9996e0-a930-48cb-a8f4-6f2f7e0d717a@github.com>
 <9udnoUCtCVEEO3rIQypPb3f14bMp6wVRRO4x0yNKZpw=.b1245fbf-e2eb-44c1-9b44-76ccbefe200f@github.com>
 <xdbBz5jNKMyTzPYYjGZ993AJ53U6DQm-LZHahZLLKfc=.0de14de4-08fe-435b-a173-6d7c5518d21b@github.com>
Message-ID: <TiPSARTKDJ4VWiM_lCretvQrNBUbUhKUS98BnHF49h8=.b1a6fe08-5b70-46e9-a586-bf4f085fd5f0@github.com>

On Thu, 1 Feb 2024 00:19:42 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> I'll add a test case.
>
> Done

Thank you. I double-checked: if that `replace` is removed, jdk/javadoc/doclet/testMarkdown/TestMarkdown.java fails.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1486361794

From prappo at openjdk.org  Mon Feb 12 15:47:09 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 12 Feb 2024 15:47:09 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <82KgOfWLlL77CZkJUnSaiWxaSuu4C1uLkzr6BHnCUd4=.aeeb8842-7c6c-4db3-bf70-690e0008f74c@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <zrqu3x52AXuB6DBs1kg66rC0arBB3MUFFokkL8CIF_k=.7935ef71-4d3c-4246-bf5c-afe5fd5fb625@github.com>
 <82KgOfWLlL77CZkJUnSaiWxaSuu4C1uLkzr6BHnCUd4=.aeeb8842-7c6c-4db3-bf70-690e0008f74c@github.com>
Message-ID: <WsEs4rMgpP1bgJihQA4Cn137iqTAf4DzI4LL0HC2Rvk=.bc95846d-55d9-47f8-9552-0e84087832ea@github.com>

On Tue, 30 Jan 2024 23:47:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 771:
>> 
>>> 769:                 copyTo(getStartPos(link));
>>> 770:                 // push temporary value for {@code trees} while handling the content of the node
>>> 771:                 var saveTrees = trees;
>> 
>> "saveTrees": I see what you did there :-)
>
> ?? Not sure I understand this comment.

It's just a funny word play evoking the famous eco slogan, is all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1486368352

From jwaters at openjdk.org  Mon Feb 12 15:51:52 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 12 Feb 2024 15:51:52 GMT
Subject: RFR: 8325626: Allow selection of non-matching configurations using
 CONF=!string
In-Reply-To: <QG3leQN-ylFbwPAR2M0YWNf15XEj0FY6zjzfQl4IGck=.803ec8a5-2264-4df5-8d72-2722c2c8f4a3@github.com>
References: <QG3leQN-ylFbwPAR2M0YWNf15XEj0FY6zjzfQl4IGck=.803ec8a5-2264-4df5-8d72-2722c2c8f4a3@github.com>
Message-ID: <pvehWAOYsPSiksXBou520CjCSqmm2r_AXXn1OO3v4c4=.da157e06-bf76-4b6c-8468-f7c72c96b674@github.com>

On Mon, 12 Feb 2024 11:44:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A common scenario is for a developer to have two configurations, a product and a debug version, e.g. `linux-x64`and `linux-x64-debug`. To select the latter using `CONF` is just a matter of using `CONF=debug`, but to select the former, the complete name needs to be supplied: `CONF=linux-x64`.
> 
> Instead, this patch introduces the use of `!` as a negation character, so `CONF=!debug` would select all configurations that do not match `debug`. 
> 
> I also took the time to clarify and correct the documentation on how to use `CONF`.

Marked as reviewed by jwaters (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/17804#pullrequestreview-1875552891

From prappo at openjdk.org  Mon Feb 12 15:57:09 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 12 Feb 2024 15:57:09 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
In-Reply-To: <5-LBnp9pQaksnQQQIe1MPmqdKGD2-0-UZgNnhtY5294=.db5cb4ce-dd03-4d5e-8533-48fdf15d9371@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <0pRMUgBnvCfb7DTm_pDnIlmuYdXH8URKFAIk5cT082Y=.f4c324b6-ef98-41b3-9b06-9cb82e03b08f@github.com>
 <MDprROiV35Q1rjuL_TD_cFkhYEGkN2B-xuH3eRcz0e0=.878238df-e7fd-4054-918b-17f77a5a4ecd@github.com>
 <5-LBnp9pQaksnQQQIe1MPmqdKGD2-0-UZgNnhtY5294=.db5cb4ce-dd03-4d5e-8533-48fdf15d9371@github.com>
Message-ID: <XAE5labHBGRVMR4FpGRSlq9RLdRhn1ynU2ObVOx8UJ4=.d41b9dcc-4f9a-493c-9a0e-41d34879a73b@github.com>

On Thu, 8 Feb 2024 18:52:54 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/RawHtml.java line 145:
>> 
>>> 143:     }
>>> 144: 
>>> 145:     Pattern tag = Pattern.compile("<(?<tag>[A-Za-z0-9]+)(\\s|>)");
>> 
>> I'm not sure I grok this pattern; what's up with `\\s`?
>
> The code is looking for HTML tag names, The match for a tag name is one of
> * `<` _tag-name_ `>`
> * `<` _tag-name_ _whitespace_

I see, thanks.
Suggestion:

    private final Pattern tag = Pattern.compile("<(?<tag>[A-Za-z0-9]+)(\\s|>)");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1486384478

From jjg at openjdk.org  Mon Feb 12 16:34:10 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 12 Feb 2024 16:34:10 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v22]
In-Reply-To: <Fi4NuaFltjeOrEITZ6UI3osRWtQrnoDx566UsfCL0EE=.a042889e-e4f0-4ba7-b2f9-04b1d36c510d@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <vrwe2U_b9K6EUSg760EHhm3x7sz2tp0D4thYIqknnGw=.e5c1c331-644a-4473-8a8b-d3c8f3128303@github.com>
 <Fi4NuaFltjeOrEITZ6UI3osRWtQrnoDx566UsfCL0EE=.a042889e-e4f0-4ba7-b2f9-04b1d36c510d@github.com>
Message-ID: <I_HQtpxnIvC3m3U8px26lJifLB5vUuw_PjQMUjn2nus=.c02f3cb7-5786-4095-bb87-7f7b7bfa42f0@github.com>

On Thu, 8 Feb 2024 17:20:23 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3 # Please enter a commit message to explain why this merge is necessary, # especially if it
>>    merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the commit.
>>  - add test case contributed by @lahodaj
>>  - initial fix for source offset problem
>>  - remove unused imports
>>  - First pass at remove DocCommentTransformer from the public API.
>>    
>>    It is still declared internally, and installed by default, using the service-provider mechanism.
>>    If the standard impl is not available, an identity transformer is used.
>>  - updates for "first sentence" issues and tests
>>  - add info about provenance of `jdk.internal.md` module
>>  - MarkdownTransformer: tweak doc comments
>>  - MarkdownTransformer: change `Lower.replaceIter` to be `private final`
>>  - MarkdownTransformer: use suggested text for using streams
>>  - ... and 18 more: https://git.openjdk.org/jdk/compare/18e24d06...63dd8bf4
>
> src/jdk.internal.md/share/classes/module-info.java line 41:
> 
>> 39: // * package and import statements are updated
>> 40: // * characters outside the ASCII range are converted to Unicode escapes
>> 41: // * @SuppressWarnings("fallthrough") is added to getSetextHeadingLevel
> 
> I wonder if it would be better to compile this module without (some) lint checks. Is it possible?

It's possible, but that would be a more global setting, whereas this is a very targeted modification.

I guess it depends how much we want to import the code as-is, without knowing any lint-warts.

FWIW, any module can be compiled with module-specific lint settings, if we choose to do so.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1486450189

From prappo at openjdk.org  Mon Feb 12 17:27:14 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 12 Feb 2024 17:27:14 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v22]
In-Reply-To: <I_HQtpxnIvC3m3U8px26lJifLB5vUuw_PjQMUjn2nus=.c02f3cb7-5786-4095-bb87-7f7b7bfa42f0@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <vrwe2U_b9K6EUSg760EHhm3x7sz2tp0D4thYIqknnGw=.e5c1c331-644a-4473-8a8b-d3c8f3128303@github.com>
 <Fi4NuaFltjeOrEITZ6UI3osRWtQrnoDx566UsfCL0EE=.a042889e-e4f0-4ba7-b2f9-04b1d36c510d@github.com>
 <I_HQtpxnIvC3m3U8px26lJifLB5vUuw_PjQMUjn2nus=.c02f3cb7-5786-4095-bb87-7f7b7bfa42f0@github.com>
Message-ID: <qQg5KGUPY08AUSD7dN2bubu21q8r79NPgcuqZBXgefg=.f2d7f31f-8266-4b0b-9ae9-2df72e720a41@github.com>

On Mon, 12 Feb 2024 16:29:19 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> I guess it depends how much we want to import the code as-is, without knowing any lint-warts.

I think it would be nice not to have to modify code beyond superficial edits: addition of headers, renaming of packages, and converting of non-ASCII symbols.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1486526603

From jjg at openjdk.org  Mon Feb 12 17:30:09 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 12 Feb 2024 17:30:09 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v22]
In-Reply-To: <qQg5KGUPY08AUSD7dN2bubu21q8r79NPgcuqZBXgefg=.f2d7f31f-8266-4b0b-9ae9-2df72e720a41@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <vrwe2U_b9K6EUSg760EHhm3x7sz2tp0D4thYIqknnGw=.e5c1c331-644a-4473-8a8b-d3c8f3128303@github.com>
 <Fi4NuaFltjeOrEITZ6UI3osRWtQrnoDx566UsfCL0EE=.a042889e-e4f0-4ba7-b2f9-04b1d36c510d@github.com>
 <I_HQtpxnIvC3m3U8px26lJifLB5vUuw_PjQMUjn2nus=.c02f3cb7-5786-4095-bb87-7f7b7bfa42f0@github.com>
 <qQg5KGUPY08AUSD7dN2bubu21q8r79NPgcuqZBXgefg=.f2d7f31f-8266-4b0b-9ae9-2df72e720a41@github.com>
Message-ID: <2ASC_hZEZa6tXgQaHWm690WnGxWOQOzDzMkgCi1I8Ug=.3884f658-b1f5-4016-9195-6784dc5b407e@github.com>

On Mon, 12 Feb 2024 17:23:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> It's possible, but that would be a more global setting, whereas this is a very targeted modification.
>> 
>> I guess it depends how much we want to import the code as-is, without knowing any lint-warts.
>> 
>> FWIW, any module can be compiled with module-specific lint settings, if we choose to do so.
>
>> I guess it depends how much we want to import the code as-is, without knowing any lint-warts.
> 
> I think it would be nice not to have to modify code beyond superficial edits: addition of headers, renaming of packages, and converting of non-ASCII symbols.

I think adding `@SuppressWarnings` is a superficial edit, but I see the writing on the wall.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1486531142

From naoto at openjdk.org  Mon Feb 12 17:37:56 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 12 Feb 2024 17:37:56 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
Message-ID: <NscNVRE66ok6SSHmMGQaeVZSxYEnWS_WzhLMve54xbU=.5ecae045-37aa-45aa-86c3-926bfb04599e@github.com>

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  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 or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

> @naotoj Thanks! Would you care to also submit a review?

My bad. I thought I approved this PR.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17789#pullrequestreview-1875811619

From dfuchs at openjdk.org  Mon Feb 12 17:42:06 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 Feb 2024 17:42:06 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
Message-ID: <aP9GcIjHZudg8GUlGYhOK4kUlFo5m6aWU4_adCeIIU8=.8634bdeb-198c-4827-b90f-bdee1a94e0f4@github.com>

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  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 or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

Approving the sun.net changes.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17789#pullrequestreview-1875818676

From prappo at openjdk.org  Mon Feb 12 17:48:09 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 12 Feb 2024 17:48:09 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v30]
In-Reply-To: <jyz30BnzzLWkefI92p092QSHqOafHMQSP4819QxpS_8=.c548e7cc-33c2-4c26-9d89-65de18397cfe@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <jyz30BnzzLWkefI92p092QSHqOafHMQSP4819QxpS_8=.c548e7cc-33c2-4c26-9d89-65de18397cfe@github.com>
Message-ID: <CW0r0SR17XtCUmH695N_7pNv1sgAMEHEuIXVGXUTGsU=.ed41f8a4-795c-4a51-a9d9-4867ced745f7@github.com>

On Fri, 9 Feb 2024 22:17:43 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refactor recent new test case in TestMarkdown.java

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1465:

> 1463:                         markdownInput.append('\n');
> 1464:                     }
> 1465:                     markdownInput.append(PLACEHOLDER_BLOCK);

There's quite a lot of overlap with the recently simplified https://github.com/openjdk/jdk/blob/7c6316886d1ae86a663d996dae373c42281622fd/src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java#L220-L238

If it's impractical to factor out the common bits, maybe we could at least make the respective parts of HtmlDocletWriter as close as possible to those of MarkdownTransformer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1486548869

From jjg at openjdk.org  Mon Feb 12 18:39:10 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 12 Feb 2024 18:39:10 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v30]
In-Reply-To: <CW0r0SR17XtCUmH695N_7pNv1sgAMEHEuIXVGXUTGsU=.ed41f8a4-795c-4a51-a9d9-4867ced745f7@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <jyz30BnzzLWkefI92p092QSHqOafHMQSP4819QxpS_8=.c548e7cc-33c2-4c26-9d89-65de18397cfe@github.com>
 <CW0r0SR17XtCUmH695N_7pNv1sgAMEHEuIXVGXUTGsU=.ed41f8a4-795c-4a51-a9d9-4867ced745f7@github.com>
Message-ID: <zkV7ZHVcTqBE2r4AFZGaaAF7KBQT6-roaka9NJ3eI4c=.3c0be81f-6c5a-4a03-a56d-280dcb731dce@github.com>

On Mon, 12 Feb 2024 17:44:29 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refactor recent new test case in TestMarkdown.java
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1465:
> 
>> 1463:                         markdownInput.append('\n');
>> 1464:                     }
>> 1465:                     markdownInput.append(PLACEHOLDER_BLOCK);
> 
> There's quite a lot of overlap with the recently simplified https://github.com/openjdk/jdk/blob/7c6316886d1ae86a663d996dae373c42281622fd/src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java#L220-L238
> 
> If it's impractical to factor out the common bits, maybe we could at least make the respective parts of HtmlDocletWriter as close as possible to those of MarkdownTransformer.

I think it is impractical to factor out the common bits, but I will look at the possibility of making the code more similar -- but no promises.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1486609585

From mchung at openjdk.org  Mon Feb 12 18:43:05 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 12 Feb 2024 18:43:05 GMT
Subject: RFR: 8325570: Update to Graphviz 9.0.0
In-Reply-To: <mqFYVDlCBjSvwrZzi7r7bUl8dFXqbQYp8XZoK1Fwgog=.80ace7f5-6b7c-4f56-9b40-145914fd38d8@github.com>
References: <mqFYVDlCBjSvwrZzi7r7bUl8dFXqbQYp8XZoK1Fwgog=.80ace7f5-6b7c-4f56-9b40-145914fd38d8@github.com>
Message-ID: <IpEjFpdQSsjTBZFN48asSOyDSe6vkrPZD0nRPmAAFgc=.92185bb6-ed32-4ada-89ed-56d3db60391b@github.com>

On Fri, 9 Feb 2024 19:02:13 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Graphviz (aka. dotty/dot) is used when building "full" docs, and in particular for creating various module graph images (.svg). This change upgrades the Graphviz version used to 9.0.0 (latest).
> 
> In particular, the change:
> 
> * Updates the createGraphvizBundle.sh script (currently broken) to build graphviz from source
> * Updates doc/building.{md,html} to reflect the role of Graphviz and Pandoc in the build
> * The version of of the graphviz dependency used when building at Oracle (in jib-profiles.js)
> 
> Since, in addition to the changes in this PR itself, the exact version of Graphviz has an effect on the generated images, I have uploaded the docs generated by graphviz 9.0.0 here: https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/. For baseline the latest jdk23 docs, which uses graphviz 2.38.0, should do the trick: https://download.java.net/java/early_access/jdk23/docs/api/.
> 
> For example, picking a random .svg file:
> 
> baseline (graphviz 2.38.0): https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> new (graphviz 9.0.0): https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> 
> 
> Testing: tier1, manual inspection of a few of the generated .svg files
> 
> As far as I can tell there are only very minor differences between the old (2.38.0) and new (9.0.0) .svg files. In particular, it seems like the new graphs are ever so slightly (5-10% or so) larger, but otherwise appear to be identical.

Marked as reviewed by mchung (Reviewer).

I reviewed the module graph image output.  They look fine with this Graphviz update.

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

PR Review: https://git.openjdk.org/jdk/pull/17794#pullrequestreview-1875936929
PR Comment: https://git.openjdk.org/jdk/pull/17794#issuecomment-1939320718

From iris at openjdk.org  Mon Feb 12 19:02:07 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 12 Feb 2024 19:02:07 GMT
Subject: RFR: 8325570: Update to Graphviz 9.0.0
In-Reply-To: <mqFYVDlCBjSvwrZzi7r7bUl8dFXqbQYp8XZoK1Fwgog=.80ace7f5-6b7c-4f56-9b40-145914fd38d8@github.com>
References: <mqFYVDlCBjSvwrZzi7r7bUl8dFXqbQYp8XZoK1Fwgog=.80ace7f5-6b7c-4f56-9b40-145914fd38d8@github.com>
Message-ID: <53e61OY23u-rO4jO0hG_yQmByo7K-WSGc-VEp4jy7Lo=.2cd572d5-14fd-4632-b4cc-6b3b74c8f2f0@github.com>

On Fri, 9 Feb 2024 19:02:13 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Graphviz (aka. dotty/dot) is used when building "full" docs, and in particular for creating various module graph images (.svg). This change upgrades the Graphviz version used to 9.0.0 (latest).
> 
> In particular, the change:
> 
> * Updates the createGraphvizBundle.sh script (currently broken) to build graphviz from source
> * Updates doc/building.{md,html} to reflect the role of Graphviz and Pandoc in the build
> * The version of of the graphviz dependency used when building at Oracle (in jib-profiles.js)
> 
> Since, in addition to the changes in this PR itself, the exact version of Graphviz has an effect on the generated images, I have uploaded the docs generated by graphviz 9.0.0 here: https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/. For baseline the latest jdk23 docs, which uses graphviz 2.38.0, should do the trick: https://download.java.net/java/early_access/jdk23/docs/api/.
> 
> For example, picking a random .svg file:
> 
> baseline (graphviz 2.38.0): https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> new (graphviz 9.0.0): https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> 
> 
> Testing: tier1, manual inspection of a few of the generated .svg files
> 
> As far as I can tell there are only very minor differences between the old (2.38.0) and new (9.0.0) .svg files. In particular, it seems like the new graphs are ever so slightly (5-10% or so) larger, but otherwise appear to be identical.

This is the java.se module graph generated by the previous version of Graphviz

[https://cr.openjdk.org/~iris/se/22/latestSpec/images/java.se-graph.svg](https://cr.openjdk.org/~iris/se/22/latestSpec/images/java.se-graph.svg)

and the new version:

[https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/java.se/module-graph.svg](https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/java.se/module-graph.svg).

They appear to be topologically identical.  The only differences I see is a slight increase in size, as noted by @vidmik in his original PR comment and a few crossed edges on the lower right side (e.g. java.net.http -> java.base, java.prefs -> java.base).

I think it's a minor price to pay for moving to the more recent version.

Thanks for moving to the newer version!

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17794#pullrequestreview-1875970167

From jjg at openjdk.org  Mon Feb 12 19:39:06 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 12 Feb 2024 19:39:06 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v22]
In-Reply-To: <2ASC_hZEZa6tXgQaHWm690WnGxWOQOzDzMkgCi1I8Ug=.3884f658-b1f5-4016-9195-6784dc5b407e@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <vrwe2U_b9K6EUSg760EHhm3x7sz2tp0D4thYIqknnGw=.e5c1c331-644a-4473-8a8b-d3c8f3128303@github.com>
 <Fi4NuaFltjeOrEITZ6UI3osRWtQrnoDx566UsfCL0EE=.a042889e-e4f0-4ba7-b2f9-04b1d36c510d@github.com>
 <I_HQtpxnIvC3m3U8px26lJifLB5vUuw_PjQMUjn2nus=.c02f3cb7-5786-4095-bb87-7f7b7bfa42f0@github.com>
 <qQg5KGUPY08AUSD7dN2bubu21q8r79NPgcuqZBXgefg=.f2d7f31f-8266-4b0b-9ae9-2df72e720a41@github.com>
 <2ASC_hZEZa6tXgQaHWm690WnGxWOQOzDzMkgCi1I8Ug=.3884f658-b1f5-4016-9195-6784dc5b407e@github.com>
Message-ID: <a6Kn7uMmbMnqUknoiHshT_JDcZyMGcWW9oyH22VZTQ0=.5ce739b4-9401-4d12-a725-d8045ccac564@github.com>

On Mon, 12 Feb 2024 17:27:42 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>>> I guess it depends how much we want to import the code as-is, without knowing any lint-warts.
>> 
>> I think it would be nice not to have to modify code beyond superficial edits: addition of headers, renaming of packages, and converting of non-ASCII symbols.
>
> I think adding `@SuppressWarnings` is a superficial edit, but I see the writing on the wall.

Based on additional private conversations, and because the annotation is added automatically by the same utility used to address other issues in the imported code (package declarations, import statements, non-ASCII characters, etc), I will leave the annotation in at this time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1486674245

From joehw at openjdk.org  Mon Feb 12 20:26:00 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 12 Feb 2024 20:26:00 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: <aiUe8udp6Qtknwo8Ha3jenZ_TP_SMD5baGxnNlNz7WI=.86e01229-6456-4e46-ad0c-1e74c84c7c63@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
 <aiUe8udp6Qtknwo8Ha3jenZ_TP_SMD5baGxnNlNz7WI=.86e01229-6456-4e46-ad0c-1e74c84c7c63@github.com>
Message-ID: <xLIVBeMz0nzp8xjs9ukxIJ1CAe4Aflvz0mtCgDL3RU4=.61371bf6-7719-4bc5-9537-df645d3fa640@github.com>

On Fri, 9 Feb 2024 13:46:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is an attempt to finally implement the idea brought forward in JDK-8295729:  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 or leading tabs instead of spaces. 
>> 
>> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
>> 
>> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.
>
> src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages.properties line 24:
> 
>> 22: # Messages for message reporting
>> 23: BadMessageKey = The error message corresponding to the message key can not be found.
>> 24: FormatFailed = An internal error occurred while formatting the following message:\n
> 
> Same here with `:\n`...

It's done with the code (that is, a key is appended with the code). In fact, the whole Xerces stack was implemented this way. I'd leave it as is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1486731927

From joehw at openjdk.org  Mon Feb 12 20:25:59 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 12 Feb 2024 20:25:59 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
Message-ID: <o8ZfKM3dvC-eD-ryNHYogkK94Ha8ArlUiw1qb9Bw51U=.bc0a293b-0dff-43d9-98d0-a798b2ba2dc7@github.com>

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  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 or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

java.xml changes look fine to me.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17789#pullrequestreview-1876181019

From mikael at openjdk.org  Mon Feb 12 20:29:05 2024
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Mon, 12 Feb 2024 20:29:05 GMT
Subject: RFR: 8325570: Update to Graphviz 9.0.0
In-Reply-To: <mqFYVDlCBjSvwrZzi7r7bUl8dFXqbQYp8XZoK1Fwgog=.80ace7f5-6b7c-4f56-9b40-145914fd38d8@github.com>
References: <mqFYVDlCBjSvwrZzi7r7bUl8dFXqbQYp8XZoK1Fwgog=.80ace7f5-6b7c-4f56-9b40-145914fd38d8@github.com>
Message-ID: <r8QSbw4sfhlg-v_AZ1vEaQHVK9qkcdR4xSwGjb-XW00=.b66a4eea-decb-4dcc-93ec-28f8e3bd243d@github.com>

On Fri, 9 Feb 2024 19:02:13 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Graphviz (aka. dotty/dot) is used when building "full" docs, and in particular for creating various module graph images (.svg). This change upgrades the Graphviz version used to 9.0.0 (latest).
> 
> In particular, the change:
> 
> * Updates the createGraphvizBundle.sh script (currently broken) to build graphviz from source
> * Updates doc/building.{md,html} to reflect the role of Graphviz and Pandoc in the build
> * The version of of the graphviz dependency used when building at Oracle (in jib-profiles.js)
> 
> Since, in addition to the changes in this PR itself, the exact version of Graphviz has an effect on the generated images, I have uploaded the docs generated by graphviz 9.0.0 here: https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/. For baseline the latest jdk23 docs, which uses graphviz 2.38.0, should do the trick: https://download.java.net/java/early_access/jdk23/docs/api/.
> 
> For example, picking a random .svg file:
> 
> baseline (graphviz 2.38.0): https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> new (graphviz 9.0.0): https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> 
> 
> Testing: tier1, manual inspection of a few of the generated .svg files
> 
> As far as I can tell there are only very minor differences between the old (2.38.0) and new (9.0.0) .svg files. In particular, it seems like the new graphs are ever so slightly (5-10% or so) larger, but otherwise appear to be identical.

Thank you for all the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/17794#issuecomment-1939516107

From mikael at openjdk.org  Mon Feb 12 20:29:05 2024
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Mon, 12 Feb 2024 20:29:05 GMT
Subject: Integrated: 8325570: Update to Graphviz 9.0.0
In-Reply-To: <mqFYVDlCBjSvwrZzi7r7bUl8dFXqbQYp8XZoK1Fwgog=.80ace7f5-6b7c-4f56-9b40-145914fd38d8@github.com>
References: <mqFYVDlCBjSvwrZzi7r7bUl8dFXqbQYp8XZoK1Fwgog=.80ace7f5-6b7c-4f56-9b40-145914fd38d8@github.com>
Message-ID: <5EUpr2ZdmICypn2uPSAPeVtpcWDJ_X-qi9CPmmPeHeQ=.fecd51a4-7595-4062-ac6b-9792b6d769db@github.com>

On Fri, 9 Feb 2024 19:02:13 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Graphviz (aka. dotty/dot) is used when building "full" docs, and in particular for creating various module graph images (.svg). This change upgrades the Graphviz version used to 9.0.0 (latest).
> 
> In particular, the change:
> 
> * Updates the createGraphvizBundle.sh script (currently broken) to build graphviz from source
> * Updates doc/building.{md,html} to reflect the role of Graphviz and Pandoc in the build
> * The version of of the graphviz dependency used when building at Oracle (in jib-profiles.js)
> 
> Since, in addition to the changes in this PR itself, the exact version of Graphviz has an effect on the generated images, I have uploaded the docs generated by graphviz 9.0.0 here: https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/. For baseline the latest jdk23 docs, which uses graphviz 2.38.0, should do the trick: https://download.java.net/java/early_access/jdk23/docs/api/.
> 
> For example, picking a random .svg file:
> 
> baseline (graphviz 2.38.0): https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> new (graphviz 9.0.0): https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> 
> 
> Testing: tier1, manual inspection of a few of the generated .svg files
> 
> As far as I can tell there are only very minor differences between the old (2.38.0) and new (9.0.0) .svg files. In particular, it seems like the new graphs are ever so slightly (5-10% or so) larger, but otherwise appear to be identical.

This pull request has now been integrated.

Changeset: 7c697123
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7c6971239dd9af2a62aefb1163328c66c4507ef1
Stats:     123 lines in 4 files changed: 86 ins; 1 del; 36 mod

8325570: Update to Graphviz 9.0.0

Reviewed-by: erikj, pminborg, ihse, mchung, iris

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

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

From jjg at openjdk.org  Mon Feb 12 23:52:35 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 12 Feb 2024 23:52:35 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v31]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <Imc_x0a26ALH3KO5jdgjvvwqZ8SL7eC-cotk7AphhRI=.8fcfe332-53cd-4aa9-8ff7-fc2082b23ece@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits:

 - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
 - improve support for DocCommentParser.LineKind
 - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3 # Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the
   commit.
 - update copyright year on test
 - refactor recent new test case in TestMarkdown.java
 - address review feedback
 - address review feedback
 - added test case in TestMarkdown.java for handling of `@deprecated` tag
 - amend comment in test
 - improve comments on negative test case
 - ... and 30 more: https://git.openjdk.org/jdk/compare/2ed889b7...1c64a6e0

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

Changes: https://git.openjdk.org/jdk/pull/16388/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=30
  Stats: 22058 lines in 194 files changed: 21390 ins; 271 del; 397 mod
  Patch: https://git.openjdk.org/jdk/pull/16388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388

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

From ihse at openjdk.org  Tue Feb 13 09:54:05 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 13 Feb 2024 09:54:05 GMT
Subject: Integrated: 8325626: Allow selection of non-matching configurations
 using CONF=!string
In-Reply-To: <QG3leQN-ylFbwPAR2M0YWNf15XEj0FY6zjzfQl4IGck=.803ec8a5-2264-4df5-8d72-2722c2c8f4a3@github.com>
References: <QG3leQN-ylFbwPAR2M0YWNf15XEj0FY6zjzfQl4IGck=.803ec8a5-2264-4df5-8d72-2722c2c8f4a3@github.com>
Message-ID: <yUWv8_Bm77K6N_gAiCMFJ0V6_PTL2lPPGpGFCVa5JDA=.de4a1a77-952f-4149-8510-cb3aa4017bbe@github.com>

On Mon, 12 Feb 2024 11:44:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A common scenario is for a developer to have two configurations, a product and a debug version, e.g. `linux-x64`and `linux-x64-debug`. To select the latter using `CONF` is just a matter of using `CONF=debug`, but to select the former, the complete name needs to be supplied: `CONF=linux-x64`.
> 
> Instead, this patch introduces the use of `!` as a negation character, so `CONF=!debug` would select all configurations that do not match `debug`. 
> 
> I also took the time to clarify and correct the documentation on how to use `CONF`.

This pull request has now been integrated.

Changeset: ec20b0aa
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec20b0aa2ed711daeea5d0a09102093b3a2a49ec
Stats:     51 lines in 4 files changed: 30 ins; 1 del; 20 mod

8325626: Allow selection of non-matching configurations using CONF=!string

Reviewed-by: erikj, jwaters

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

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

From ihse at openjdk.org  Tue Feb 13 10:03:08 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 13 Feb 2024 10:03:08 GMT
Subject: Integrated: 8325558: Add jcheck whitespace checking for properties
 files
In-Reply-To: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
References: <Uwmj8L0as9HbHd362qpSAArpgCzYvkAyI6OOSq5J9Dk=.670c5220-c7df-40cc-817d-f0cf55fbb955@github.com>
Message-ID: <1_5f_JhU7k2LuEKn7w-rn3FkkBpaBDiz3o_uBy-uKiw=.7ed5bef7-6484-435f-8d87-12dadc4d9e9d@github.com>

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  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 or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

This pull request has now been integrated.

Changeset: c266800a
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c266800a3a7dd44416b0b4df3bdd78410241d74b
Stats:     761 lines in 95 files changed: 0 ins; 5 del; 756 mod

8325558: Add jcheck whitespace checking for properties files

Reviewed-by: naoto, dfuchs, joehw

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

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

From jbechberger at openjdk.org  Tue Feb 13 11:40:14 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 13 Feb 2024 11:40:14 GMT
Subject: RFR: 8325731: Installation instructions for Debian/Ubuntu don't
 mention autoconf
Message-ID: <qnXzhJjfLt-GeFvT-CQdMU9iBEYUcf797FKR5l0UzdU=.54c1ea29-1493-486c-bba3-fd3920bd9db6@github.com>

So I added autoconf besides build-essential. With both packages, `bash configure` is runnable.

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

Commit messages:
 - 8325731: Installation instructions for Debian/Ubuntu don't mention autoconf

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

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

From ihse at openjdk.org  Tue Feb 13 12:27:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 13 Feb 2024 12:27:03 GMT
Subject: RFR: 8325731: Installation instructions for Debian/Ubuntu don't
 mention autoconf
In-Reply-To: <qnXzhJjfLt-GeFvT-CQdMU9iBEYUcf797FKR5l0UzdU=.54c1ea29-1493-486c-bba3-fd3920bd9db6@github.com>
References: <qnXzhJjfLt-GeFvT-CQdMU9iBEYUcf797FKR5l0UzdU=.54c1ea29-1493-486c-bba3-fd3920bd9db6@github.com>
Message-ID: <h1_Xr2CI3AmyXEIjTNKXYNMP5YUZFyu26XUDHFkUQhM=.0a3dd3d1-5301-4382-8f6c-76f3d15eb79e@github.com>

On Tue, 13 Feb 2024 11:35:32 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> So I added autoconf besides build-essential. With both packages, `bash configure` is runnable.

Thanks for fixing!

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17826#pullrequestreview-1877809447

From jbechberger at openjdk.org  Tue Feb 13 12:34:08 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 13 Feb 2024 12:34:08 GMT
Subject: Integrated: 8325731: Installation instructions for Debian/Ubuntu don't
 mention autoconf
In-Reply-To: <qnXzhJjfLt-GeFvT-CQdMU9iBEYUcf797FKR5l0UzdU=.54c1ea29-1493-486c-bba3-fd3920bd9db6@github.com>
References: <qnXzhJjfLt-GeFvT-CQdMU9iBEYUcf797FKR5l0UzdU=.54c1ea29-1493-486c-bba3-fd3920bd9db6@github.com>
Message-ID: <EGKvoQE636gPAWvNocS1H_LyVl6I7n2zTxrHRWjk33o=.780a2cac-4ffa-4867-a301-367f5e2dee5b@github.com>

On Tue, 13 Feb 2024 11:35:32 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> So I added autoconf besides build-essential. With both packages, `bash configure` is runnable.

This pull request has now been integrated.

Changeset: c3c1cdd1
Author:    Johannes Bechberger <jbechberger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c3c1cdd1b017654469f214c62457cde248474f2f
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8325731: Installation instructions for Debian/Ubuntu don't mention autoconf

Reviewed-by: ihse

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

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

From prappo at openjdk.org  Tue Feb 13 18:18:10 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 13 Feb 2024 18:18:10 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v31]
In-Reply-To: <Imc_x0a26ALH3KO5jdgjvvwqZ8SL7eC-cotk7AphhRI=.8fcfe332-53cd-4aa9-8ff7-fc2082b23ece@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <Imc_x0a26ALH3KO5jdgjvvwqZ8SL7eC-cotk7AphhRI=.8fcfe332-53cd-4aa9-8ff7-fc2082b23ece@github.com>
Message-ID: <revTaYUgM40q0U5bHloqsO56zzKGpaMVRdj_LLyHQrs=.047fe7ff-2f0e-4fad-b4b8-10bdee6b639c@github.com>

On Mon, 12 Feb 2024 23:52:35 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>  - improve support for DocCommentParser.LineKind
>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3 # Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the
>    commit.
>  - update copyright year on test
>  - refactor recent new test case in TestMarkdown.java
>  - address review feedback
>  - address review feedback
>  - added test case in TestMarkdown.java for handling of `@deprecated` tag
>  - amend comment in test
>  - improve comments on negative test case
>  - ... and 30 more: https://git.openjdk.org/jdk/compare/2ed889b7...1c64a6e0

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 563:

> 561: 
> 562:     /**
> 563:      * {@returns the plain-text content of a named HTML element in a list of content}

Suggestion:

     * {@return the plain-text content of a named HTML element in a list of content}

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 1021:

> 1019:                     .findFirst();
> 1020:             if (first.isEmpty() || first.get() != tree) {
> 1021:                 dct.getFirstSentence().forEach(t -> System.err.println(t.getKind() + ": >>|" + t + "|<<"));

Is it leftover debug output?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java line 571:

> 569:         // of a doclet to be specified instead of the name of the
> 570:         // doclet class and optional doclet path.
> 571:         // See https://bugs.openjdk.org/browse/JDK-8263219

It's hard to understand this:

> to permit an instance of an appropriately configured instance of a doclet

Also: how is that piece of code used? When I commented it out, no test/langtools:langtools_javadoc tests failed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1487629102
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1487659843
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1487642764

From mikael at openjdk.org  Tue Feb 13 20:51:11 2024
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 13 Feb 2024 20:51:11 GMT
Subject: RFR: 8325800: Drop unused cups declaration from Oracle build
 configuration
Message-ID: <CTa6YLIPNfFxfd5YSNcIzpCcY87RxCKCYcGPzOCDEgw=.1983ce5a-dda9-448f-8856-04ad7b0f215b@github.com>

The cups dependency was used for Solaris builds, and has been unused since [JDK-8244224](https://bugs.openjdk.org/browse/JDK-8244224).

Testing: tier1

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

Commit messages:
 - 8325800: Drop unused cups declaration from Oracle build configuration

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

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

From erikj at openjdk.org  Tue Feb 13 21:21:02 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 13 Feb 2024 21:21:02 GMT
Subject: RFR: 8325800: Drop unused cups declaration from Oracle build
 configuration
In-Reply-To: <CTa6YLIPNfFxfd5YSNcIzpCcY87RxCKCYcGPzOCDEgw=.1983ce5a-dda9-448f-8856-04ad7b0f215b@github.com>
References: <CTa6YLIPNfFxfd5YSNcIzpCcY87RxCKCYcGPzOCDEgw=.1983ce5a-dda9-448f-8856-04ad7b0f215b@github.com>
Message-ID: <NqTiFgdeg2yivwB4J1o1N3wubjjjjriYZNfmV8DCnus=.cb767cb1-f1cd-46ff-8c81-7436448bec0a@github.com>

On Tue, 13 Feb 2024 20:47:01 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> The cups dependency was used for Solaris builds, and has been unused since [JDK-8244224](https://bugs.openjdk.org/browse/JDK-8244224).
> 
> Testing: tier1

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17837#pullrequestreview-1878936683

From mikael at openjdk.org  Tue Feb 13 21:26:10 2024
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 13 Feb 2024 21:26:10 GMT
Subject: RFR: 8325800: Drop unused cups declaration from Oracle build
 configuration
In-Reply-To: <CTa6YLIPNfFxfd5YSNcIzpCcY87RxCKCYcGPzOCDEgw=.1983ce5a-dda9-448f-8856-04ad7b0f215b@github.com>
References: <CTa6YLIPNfFxfd5YSNcIzpCcY87RxCKCYcGPzOCDEgw=.1983ce5a-dda9-448f-8856-04ad7b0f215b@github.com>
Message-ID: <I89E_LqSTkNy_-cY26ojG9F7eMSlLtsKxgsGIVqsRFU=.bfa663eb-e1e3-4c8f-b8a8-ce83ec6602c4@github.com>

On Tue, 13 Feb 2024 20:47:01 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> The cups dependency was used for Solaris builds, and has been unused since [JDK-8244224](https://bugs.openjdk.org/browse/JDK-8244224).
> 
> Testing: tier1

Thank you for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/17837#issuecomment-1942580652

From mikael at openjdk.org  Tue Feb 13 21:26:10 2024
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 13 Feb 2024 21:26:10 GMT
Subject: Integrated: 8325800: Drop unused cups declaration from Oracle build
 configuration
In-Reply-To: <CTa6YLIPNfFxfd5YSNcIzpCcY87RxCKCYcGPzOCDEgw=.1983ce5a-dda9-448f-8856-04ad7b0f215b@github.com>
References: <CTa6YLIPNfFxfd5YSNcIzpCcY87RxCKCYcGPzOCDEgw=.1983ce5a-dda9-448f-8856-04ad7b0f215b@github.com>
Message-ID: <uogk4EUP6I4Ory10Jg2JO_D5vj7uZLiA0VWyjFc1Syk=.711d9802-e1d7-4ed3-8616-e651f08ccb8b@github.com>

On Tue, 13 Feb 2024 20:47:01 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> The cups dependency was used for Solaris builds, and has been unused since [JDK-8244224](https://bugs.openjdk.org/browse/JDK-8244224).
> 
> Testing: tier1

This pull request has now been integrated.

Changeset: 8765b176
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8765b176f97dbf334836f0aa6acd921d114304a9
Stats:     7 lines in 1 file changed: 0 ins; 6 del; 1 mod

8325800: Drop unused cups declaration from Oracle build configuration

Reviewed-by: erikj

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

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

From magnus.ihse.bursie at oracle.com  Wed Feb 14 09:00:27 2024
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 14 Feb 2024 10:00:27 +0100
Subject: Questions about the Hermetic Java project
Message-ID: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com>

First some background for build-dev: I have spent some time looking at 
the build implications of the Hermetic Java effort, which is part of 
Project Leyden. A high-level overview is available here: 
https://cr.openjdk.org/~jiangli/hermetic_java.pdf and the current source 
code is here: https://github.com/openjdk/leyden/tree/hermetic-java-runtime.

Hermetic Java faces several challenges, but the part that is relevant 
for the build system is the ability to create static libraries. We've 
had this functionality (in three different ways...) for some time, but 
it is rather badly implemented.

As a result of my investigations, I have a bunch of questions. :-) I 
have gotten some answers in private discussion, but for the sake of 
transparency I will repeat them here, to foster an open dialogue.

1. Am I correct in understanding that the ultimate goal of this exercise 
is to be able to have jmods which include static libraries (*.a) of the 
native code which the module uses, and that the user can then run a 
special jlink command to have this linked into a single executable 
binary (which also bundles the *.class files and any additional 
resources needed)?

2. If so, is the idea to create special kinds of static jmods, like 
java.base-static.jmod, that contains *.a files instead of lib*.so files? 
Or is the idea that the normal jmod should contain both?

3. Linking .o and .a files into an executable is a formidable task. Is 
the intention to have jlink call a system-provided ld, or to bundle ld 
with jlink, or to reimplement this functionality in Java?

4. Is the intention is to allow users to create their own jmods with 
static libraries, and have these linked in as well? This seems to be the 
case. If that is so, then there will always be the risk for name 
collisions, and we can only minimize the risk by making sure any global 
names are as unique as possible.

5. The original implementation of static builds in the JDK, created for 
the Mobile project, used a configure flag, --enable-static-builds, to 
change the entire behavior of the build system to only produce *.a files 
instead of lib*.so. In contrast, the current system is using a special 
target instead. In my eyes, this is a much worse solution. Apart from 
the conceptual principle (if the build should generate static or dynamic 
libraries is definitely a property of what a "configuration" means), 
this makes it much harder to implement efficiently, since we cannot make 
changes in NativeCompilation.gmk, where they are needed.

That was not as much a question as a statement. ? But here is the 
question: Do you think it would be reasonable to restore the old 
behavior but with the new methods, so that we don't use special targets, 
but instead tells configure to generate static libraries? I'm thinking 
we should have a flag like "--with-library-type=" that can have values 
"dynamic" (which is default), "static" or "both". I am not sure if 
"both" are needed, but if we want to bundle both lib*.so and *.a files 
into a single jmod file (see question 2 above), then it definitely is. 
In general, the cost of producing two kinds of libraries are quite 
small, compared to the cost of compiling the source code to object files.

Finally, I have looked at how to manipulate symbol visibility. There 
seems many ways forward, so I feel confident that we can find a good 
solution.

One way forward is to use objcopy to manipulate symbol status 
(global/local). There is an option --localize-symbol in objcopy, that 
has been available in objcopy since at least 2.15, which was released 
2004, so it should be safe to use. But ideally we should avoid using 
objcopy and do this as part of the linking process. This should be 
possible to do, given that we make changes in NativeCompilation.gmk -- 
see question 5 above.

As a fallback, it is also possible to rename symbols, either piecewise 
or wholesale, using objcopy. There are many ways to do this, using 
--prefix-symbols, --redefine-sym or --redefine-syms (note the -s, this 
takes a file with a list of symbols). Thus we can always introduce a 
"post factum namespace" by renaming symbols.

So in the end, I think it will be fully possible to produce .a files 
that only has global symbols for the functions that are part of the API 
exposed by that library, and have all other symbols local, and make this 
is in a way that is consistent with the rest of the build system.

Finally, a note on Hotspot. Due to debugging reasons, we export 
basically all symbols in hotspot as global. This is not reasonable to do 
for a static build. The effect of not exporting those symbols will be 
that SA will not function to 100%. On the other hand, I have no idea if 
SA works at all with a static build. Have you tested this? Is this part 
of the plan to support, or will it be officially dropped for Hermetic Java?

/Magnus


From ihse at openjdk.org  Wed Feb 14 09:05:07 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 Feb 2024 09:05:07 GMT
Subject: RFR: 8325800: Drop unused cups declaration from Oracle build
 configuration
In-Reply-To: <CTa6YLIPNfFxfd5YSNcIzpCcY87RxCKCYcGPzOCDEgw=.1983ce5a-dda9-448f-8856-04ad7b0f215b@github.com>
References: <CTa6YLIPNfFxfd5YSNcIzpCcY87RxCKCYcGPzOCDEgw=.1983ce5a-dda9-448f-8856-04ad7b0f215b@github.com>
Message-ID: <3tZSlUNLIT223a08pRX7_jnrSQVXFkRUAvQIy7A11Mk=.6dd8c7d1-e9c9-4c44-a4e3-b3f48b3731a8@github.com>

On Tue, 13 Feb 2024 20:47:01 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> The cups dependency was used for Solaris builds, and has been unused since [JDK-8244224](https://bugs.openjdk.org/browse/JDK-8244224).
> 
> Testing: tier1

Just checking, we are still using cups on other platforms (linux, macosx), right? It's just that we assume it is installed by the system and need no special separate dependency?

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

PR Comment: https://git.openjdk.org/jdk/pull/17837#issuecomment-1943335351

From magnus.ihse.bursie at oracle.com  Wed Feb 14 10:06:00 2024
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 14 Feb 2024 11:06:00 +0100
Subject: Hotspot symbol visibility
Message-ID: <645132e0-687e-4f04-9e49-f90131294367@oracle.com>

I am currently pursuing improved build functionality for static 
libraries. One of the issues with static libraries are name collisions, 
which led me back to an old discussion about which symbols are exported 
from Hotspot, and how this is achieved. A long discussion is available 
in JDK-8017234 [1], which was created in 2013 and has been on the back 
burner ever since, coming back to life every now and then.

There are basically two different problems here. They are both distinct 
and interrelated, and we likely need to solve both in tandem.

The first problem is how Hotspot should say which symbols (functions) 
that should be exported from libjvm.so. The historical, and still used, 
system is to have a mapfile. In the "new" (not so new anymore) build 
system, this was simplified to a list of function names in 
make/data/hotspot-symbols, from which a mapfile is built.

This is in contrast with how all other libraries in the JDK are built, 
and also with modern best practices. A better approach would be to 
annotate the functions that should be exported in the source code. In 
fact, such annotation already exists, even in Hotspot, as JNIEXPORT, but 
this is currently not used in the compilation of Hotspot.

The second problem is that in addition to these explicitly exported 
functions, we also export basically all other functions as well in 
Hotspot. (So currently we could basically just forgo this complicated 
machinery and just export everything by default...)

The reason for this seem somewhat unclear. The specifics are probably 
forever lost in the mists of time past, but the essential point is that 
these symbols are needed for SA to do it's job.

So what we do is that we list all symbols in hotspot after compiling 
(but before linking), and selects some (most, I think) of them using 
regexp patterns, and add these to the mapfile.

As long as we're doing this, we cannot stop using a mapfile, and we're 
stuck from progressing on point 1.

My takeaway from the discussions is that we are most likely exporting a 
way too broad set of symbols to SA. It seems likely that this set can be 
drastically cut down. Actually getting an understanding of exactly which 
symbols SA need seem like a very good first step.

So, is this a journey anyone would be interested in embarkering on? I 
will help as much as I can from a build PoV, but I have no clue 
whatsoever about what SA needs.

/Magnus

[1] https://bugs.openjdk.org/browse/JDK-8017234


From erikj at openjdk.org  Wed Feb 14 14:48:58 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 14 Feb 2024 14:48:58 GMT
Subject: RFR: 8325800: Drop unused cups declaration from Oracle build
 configuration
In-Reply-To: <3tZSlUNLIT223a08pRX7_jnrSQVXFkRUAvQIy7A11Mk=.6dd8c7d1-e9c9-4c44-a4e3-b3f48b3731a8@github.com>
References: <CTa6YLIPNfFxfd5YSNcIzpCcY87RxCKCYcGPzOCDEgw=.1983ce5a-dda9-448f-8856-04ad7b0f215b@github.com>
 <3tZSlUNLIT223a08pRX7_jnrSQVXFkRUAvQIy7A11Mk=.6dd8c7d1-e9c9-4c44-a4e3-b3f48b3731a8@github.com>
Message-ID: <9y5WIrVVQpgKT-vVGzjTbwcflVQ0RoioZT3EyO7d0vk=.0f0409c9-482b-4cd1-b57c-5e4c3af89085@github.com>

On Wed, 14 Feb 2024 09:02:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Just checking, we are still using cups on other platforms (linux, macosx), right? It's just that we assume it is installed by the system and need no special separate dependency?

I believe that's true yes. We only ever needed to supply it for Solaris and certain embedded Linux configurations where the toolchain/devkit didn't contain cups.

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

PR Comment: https://git.openjdk.org/jdk/pull/17837#issuecomment-1943952640

From ihse at openjdk.org  Wed Feb 14 15:39:29 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 Feb 2024 15:39:29 GMT
Subject: RFR: 8325877: Split up NativeCompilation.gmk
Message-ID: <Y3QhATUmfQcr1D1geIUqzWhkGfxpXJAY1HzV9Kc1hvs=.1f862280-3618-40f4-99e3-0e8a7de57c61@github.com>

The file NativeCompilation.gmk is a beast. It is one of the largest in the build system, and it is not very well organized. This makes it hard to read, understand, debug, edit and modify, especially since IDEs have a hard time helping out with makefiles, so you get very little overview or navigation support.

This patch will split up the file into several parts. The splits are somewhat arbitrary, but tries to keep things sort of logically connected, and make the chunks somewhat approximate equal size.

I've gone to great pains to make sure I do not accidentally change anything. The order for the code in each of these files are the same as in the original NativeCompilation.gmk. I have not rearranged any code (with a few trivially exceptions, moving some assignments to allow better grouping), and instead preferred to split up functionality in several parts (as in SetupBasicVariables1-3).

Since I include the files in alphabetic order, some code will inevitable switch places, but this should either be just defines (which are trivially safe to move around), or it should be code that are independent of each other.

My intention is to follow up this shuffling with more intrusive fixes, that can e.g. reorder stuff to make for more logical grouping. But I want to do that separately.

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

Commit messages:
 - 8325877: Split up NativeCompilation.gmk

Changes: https://git.openjdk.org/jdk/pull/17849/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17849&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325877
  Stats: 2547 lines in 7 files changed: 1420 ins; 1103 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/17849.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17849/head:pull/17849

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

From ihse at openjdk.org  Wed Feb 14 15:44:27 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 Feb 2024 15:44:27 GMT
Subject: RFR: 8325877: Split up NativeCompilation.gmk [v2]
In-Reply-To: <Y3QhATUmfQcr1D1geIUqzWhkGfxpXJAY1HzV9Kc1hvs=.1f862280-3618-40f4-99e3-0e8a7de57c61@github.com>
References: <Y3QhATUmfQcr1D1geIUqzWhkGfxpXJAY1HzV9Kc1hvs=.1f862280-3618-40f4-99e3-0e8a7de57c61@github.com>
Message-ID: <IHnW95znJoo2_ujDQckNZ8UvRe_J6xr_oCTUOJi1vm4=.47fee067-c6f0-4fa6-8200-cd339d2256b6@github.com>

> The file NativeCompilation.gmk is a beast. It is one of the largest in the build system, and it is not very well organized. This makes it hard to read, understand, debug, edit and modify, especially since IDEs have a hard time helping out with makefiles, so you get very little overview or navigation support.
> 
> This patch will split up the file into several parts. The splits are somewhat arbitrary, but tries to keep things sort of logically connected, and make the chunks somewhat approximate equal size.
> 
> I've gone to great pains to make sure I do not accidentally change anything. The order for the code in each of these files are the same as in the original NativeCompilation.gmk. I have not rearranged any code (with a few trivially exceptions, moving some assignments to allow better grouping), and instead preferred to split up functionality in several parts (as in SetupBasicVariables1-3).
> 
> Since I include the files in alphabetic order, some code will inevitable switch places, but this should either be just defines (which are trivially safe to move around), or it should be code that are independent of each other.
> 
> My intention is to follow up this shuffling with more intrusive fixes, that can e.g. reorder stuff to make for more logical grouping. But I want to do that separately.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Remove debug code (and fix one more space)
 - Restore mistakenly deleted space

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17849/files
  - new: https://git.openjdk.org/jdk/pull/17849/files/9124f2a3..439ebf20

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

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

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

From kbarrett at openjdk.org  Wed Feb 14 16:03:08 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 14 Feb 2024 16:03:08 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <bhrcRriVPrMI3BZd4M7MBIeFeF4vKhBbLVxbe0vfKPc=.c089032b-7420-4224-8186-d7d6e721856b@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
 <bhrcRriVPrMI3BZd4M7MBIeFeF4vKhBbLVxbe0vfKPc=.c089032b-7420-4224-8186-d7d6e721856b@github.com>
Message-ID: <Kf3TPcBiwoF4IKXQSdVu8fPrmy_AUe6japArSVzHHGw=.ac49ae36-aa56-4590-ba46-e195b03445d1@github.com>

On Fri, 19 Jan 2024 14:04:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Well, the only additional thing this PR does except raise the compiler version is to change the `--std` flag. It is a bit unclear what that means. For the JDK libraries, there are already code present that relies on C++17. For hotspot, what C++ constructions to use is strictly limited by the code standard document. As long as it does not mention any C++17 constructs, it does not really matter what the `--std` flag says. But, otoh, to be able to say something about C++17, we need first have proper support from all compilers.
> 
> So I'd say just chill a bit, give folks some time to respond. My understanding of the situation is as follows:
> 
>     * Raising clang to 13.0 is uncontroversial
> 
>     * Raising xlc to 17.1.1.4 seems acceptable by the folks using it (I hope I got that right)
> 
>     * Raising gcc to 10.0 met some resistance. We could stop at gcc 9.0 for this PR (which is enough for C++17), and then continue discussing going to gcc 10.0 in a separate PR, or we can wait a bit more to see if @shipilev feels compelled by the arguments given in the discussion to accept going to 10.

I'd like to separate the version update discussions from C++17 specifics, so
we can have focused discussions on the version choices. Of course, that's
going to be informed by the possibility of C++17, but that's not the only
factor. That way this issue can be just about turning on C++17, when, and why.

In order to do that, I've filed the following issues about version updates:
https://bugs.openjdk.org/browse/JDK-8325881
Require minimum gcc version 10

https://bugs.openjdk.org/browse/JDK-8325878
Require minimum clang version 13

https://bugs.openjdk.org/browse/JDK-8325880
Require minimum OpenXL C/C++ version 17.1.1

PRs will follow shortly.

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1944126546

From kbarrett at openjdk.org  Wed Feb 14 23:08:24 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 14 Feb 2024 23:08:24 GMT
Subject: RFR: 8325880: Require minimum Open XL C/C++ version 17.1.1
Message-ID: <mYhkdea6XL09IsDZzeSMKCw5k2nWmB0bbVZfAA2bmIE=.b4d15383-e5e9-4e06-aef3-57cf104fc9bb@github.com>

Please review this change that updates the minimum supported version of IBM
Open XL C/C++.  SAP dropped support for older versions in JDK 22, only
supporting the version specified in this change.

I need someone from the aix-ppc porters to test and review the change.

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

Commit messages:
 - update XLC version

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

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

From erikj at openjdk.org  Wed Feb 14 23:59:54 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 14 Feb 2024 23:59:54 GMT
Subject: RFR: 8325877: Split up NativeCompilation.gmk [v2]
In-Reply-To: <IHnW95znJoo2_ujDQckNZ8UvRe_J6xr_oCTUOJi1vm4=.47fee067-c6f0-4fa6-8200-cd339d2256b6@github.com>
References: <Y3QhATUmfQcr1D1geIUqzWhkGfxpXJAY1HzV9Kc1hvs=.1f862280-3618-40f4-99e3-0e8a7de57c61@github.com>
 <IHnW95znJoo2_ujDQckNZ8UvRe_J6xr_oCTUOJi1vm4=.47fee067-c6f0-4fa6-8200-cd339d2256b6@github.com>
Message-ID: <c4wKijdOffhBeKMTuNWenhYrddi20naDH93x1It3dbw=.af7b11f6-0f04-4413-8cfb-75465cd36d55@github.com>

On Wed, 14 Feb 2024 15:44:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The file NativeCompilation.gmk is a beast. It is one of the largest in the build system, and it is not very well organized. This makes it hard to read, understand, debug, edit and modify, especially since IDEs have a hard time helping out with makefiles, so you get very little overview or navigation support.
>> 
>> This patch will split up the file into several parts. The splits are somewhat arbitrary, but tries to keep things sort of logically connected, and make the chunks somewhat approximate equal size.
>> 
>> I've gone to great pains to make sure I do not accidentally change anything. The order for the code in each of these files are the same as in the original NativeCompilation.gmk. I have not rearranged any code (with a few trivially exceptions, moving some assignments to allow better grouping), and instead preferred to split up functionality in several parts (as in SetupBasicVariables1-3).
>> 
>> Since I include the files in alphabetic order, some code will inevitable switch places, but this should either be just defines (which are trivially safe to move around), or it should be code that are independent of each other.
>> 
>> My intention is to follow up this shuffling with more intrusive fixes, that can e.g. reorder stuff to make for more logical grouping. But I want to do that separately.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove debug code (and fix one more space)
>  - Restore mistakenly deleted space

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17849#pullrequestreview-1881521221

From jjg at openjdk.org  Thu Feb 15 00:30:25 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 15 Feb 2024 00:30:25 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v32]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <5f-y-x2KRcAGr501XkShj08p51vAl8wxD8l8PYFcQmI=.08ee889e-8abb-47e2-b3ba-49bb09ae600d@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits:

 - fill in `visitRawText` in `CommentHelper.getTags` visitor
 - fixes for the "New API" page
 - change "standard" to "traditional" when referring to a comment
 - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
 - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
 - improve support for DocCommentParser.LineKind
 - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3 # Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the
   commit.
 - update copyright year on test
 - refactor recent new test case in TestMarkdown.java
 - address review feedback
 - ... and 34 more: https://git.openjdk.org/jdk/compare/8765b176...2801c2e1

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

Changes: https://git.openjdk.org/jdk/pull/16388/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=31
  Stats: 22094 lines in 197 files changed: 21411 ins; 286 del; 397 mod
  Patch: https://git.openjdk.org/jdk/pull/16388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388

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

From jianglizhou at google.com  Thu Feb 15 01:07:25 2024
From: jianglizhou at google.com (Jiangli Zhou)
Date: Wed, 14 Feb 2024 17:07:25 -0800
Subject: Questions about the Hermetic Java project
In-Reply-To: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com>
References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com>
Message-ID: <CALrW1jzdU4QD0mHc4-vTTL46VNzXLbmASdnmoY5qfa7wS8=s7Q@mail.gmail.com>

Hi Magnus,

Thanks for looking into this from the build perspective.

On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> wrote:
>
> First some background for build-dev: I have spent some time looking at
> the build implications of the Hermetic Java effort, which is part of
> Project Leyden. A high-level overview is available here:
> https://cr.openjdk.org/~jiangli/hermetic_java.pdf and the current source
> code is here: https://github.com/openjdk/leyden/tree/hermetic-java-runtime.

Some additional hermetic Java related references that are also useful:

- https://bugs.openjdk.org/browse/JDK-8303796 is an umbrella bug that
links to the issues for resolving static linking issues so far
- https://github.com/openjdk/jdk21/pull/26 is the enhancement for
building the complete set of static libraries in JDK/VM, particularly
including libjvm.a

>
> Hermetic Java faces several challenges, but the part that is relevant
> for the build system is the ability to create static libraries. We've
> had this functionality (in three different ways...) for some time, but
> it is rather badly implemented.
>
> As a result of my investigations, I have a bunch of questions. :-) I
> have gotten some answers in private discussion, but for the sake of
> transparency I will repeat them here, to foster an open dialogue.
>
> 1. Am I correct in understanding that the ultimate goal of this exercise
> is to be able to have jmods which include static libraries (*.a) of the
> native code which the module uses, and that the user can then run a
> special jlink command to have this linked into a single executable
> binary (which also bundles the *.class files and any additional
> resources needed)?
>
> 2. If so, is the idea to create special kinds of static jmods, like
> java.base-static.jmod, that contains *.a files instead of lib*.so files?
> Or is the idea that the normal jmod should contain both?
>
> 3. Linking .o and .a files into an executable is a formidable task. Is
> the intention to have jlink call a system-provided ld, or to bundle ld
> with jlink, or to reimplement this functionality in Java?

I have a similar view as Alan responded in your other email thread.
Things are still in the early stage for the general solution.

In the https://github.com/openjdk/leyden/tree/hermetic-java-runtime
branch, when configuring JDK with --with-static-java=yes, the JDK
binary contains the following extra artifacts:

- static-libs/*.a: The complete set of JDK/VM static libraries
- jdk/bin/javastatic: A demo Java launcher fully statically linked
with the selected JDK .a libraries (e.g. it currently statically link
with the headless) and libjvm.a. It's the standard Java launcher
without additional work for hermetic Java.

In our prototype for hermetic Java, we build the hermetic executable
image (a single image) from the following input (see description on
singlejar packaging tool in
https://cr.openjdk.org/~jiangli/hermetic_java.pdf):

- A customized launcher (with additional work for hermetic) executable
fully statically linked with JDK/VM static libraries (.a files),
application natives and dependencies (e.g. in .a static libraries)
- JDK lib/modules, JDK resource files
- Application classes and resource files

Including a JDK library .a into the corresponding .jmod would require
extracting the .a for linking with the executable. In some systems
that may cause memory overhead due to the extracted copy of the .a
files. I think we should consider the memory overhead issue.

One possibility (as Alan described in his response) is for jlink to
invoke the ld on the build system. jlink could pass the needed JDK
static libraries and libjvm.a (provided as part of the JDK binary) to
ld based on the modules required for the application.

>
> 4. Is the intention is to allow users to create their own jmods with
> static libraries, and have these linked in as well? This seems to be the
> case.

An alternative with less memory overhead could be using application
modular JAR and separate .a as the input for jlink.

> If that is so, then there will always be the risk for name
> collisions, and we can only minimize the risk by making sure any global
> names are as unique as possible.

Part of the current effort includes resolving the discovered symbol
collision issues with static linking. Will respond to your other email
on the symbol issue separately later.

>
> 5. The original implementation of static builds in the JDK, created for
> the Mobile project, used a configure flag, --enable-static-builds, to
> change the entire behavior of the build system to only produce *.a files
> instead of lib*.so. In contrast, the current system is using a special
> target instead.

I think we would need both configure flag and special target for the
static builds.

> In my eyes, this is a much worse solution. Apart from
> the conceptual principle (if the build should generate static or dynamic
> libraries is definitely a property of what a "configuration" means),
> this makes it much harder to implement efficiently, since we cannot make
> changes in NativeCompilation.gmk, where they are needed.

For the potential objcopy work to resolve symbol issues, we can add
that conditionally in NativeCompilation.gmk if STATIC_LIBS is true. We
have an internal prototype (not included in
https://github.com/openjdk/leyden/tree/hermetic-java-runtime yet) done
by one of colleagues for localizing symbols in libfreetype using
objcopy.

>
> That was not as much a question as a statement. ? But here is the
> question: Do you think it would be reasonable to restore the old
> behavior but with the new methods, so that we don't use special targets,
> but instead tells configure to generate static libraries? I'm thinking
> we should have a flag like "--with-library-type=" that can have values
> "dynamic" (which is default), "static" or "both".

If we want to also build a fully statically linked launcher, maybe
--with-static-java? Being able to configure either dynamic, static or
both as you suggested also seems to be a good idea.

> I am not sure if "both" are needed, but if we want to bundle both lib*.so and *.a files
> into a single jmod file (see question 2 above), then it definitely is.
> In general, the cost of producing two kinds of libraries are quite
> small, compared to the cost of compiling the source code to object files.

Completely agree. It would be good to avoid recompiling the .o file
for static and dynamic builds. As proposed in
https://bugs.openjdk.org/browse/JDK-8303796:

It's beneficial to be able to build both .so and .a from the same set
of .o files. That would involve some changes to handle the dynamic JDK
and static JDK difference at runtime, instead of relying on the
STATIC_BUILD macro.

>
> Finally, I have looked at how to manipulate symbol visibility. There
> seems many ways forward, so I feel confident that we can find a good
> solution.
>
> One way forward is to use objcopy to manipulate symbol status
> (global/local). There is an option --localize-symbol in objcopy, that
> has been available in objcopy since at least 2.15, which was released
> 2004, so it should be safe to use. But ideally we should avoid using
> objcopy and do this as part of the linking process. This should be
> possible to do, given that we make changes in NativeCompilation.gmk --
> see question 5 above.
>
> As a fallback, it is also possible to rename symbols, either piecewise
> or wholesale, using objcopy. There are many ways to do this, using
> --prefix-symbols, --redefine-sym or --redefine-syms (note the -s, this
> takes a file with a list of symbols). Thus we can always introduce a
> "post factum namespace" by renaming symbols.

Renaming or redefining the symbol at build time could cause confusions
with debugging. That's a concern raised in
https://github.com/openjdk/jdk/pull/17456 discussions.

Additionally, redefining symbols using tools like objcopy may not
handle member names referenced in string literals. For example, in
https://github.com/openjdk/jdk/pull/17456 additional changes are
needed in assembling and SA to reflect the symbol change.

>
> So in the end, I think it will be fully possible to produce .a files
> that only has global symbols for the functions that are part of the API
> exposed by that library, and have all other symbols local, and make this
> is in a way that is consistent with the rest of the build system.
>
> Finally, a note on Hotspot. Due to debugging reasons, we export
> basically all symbols in hotspot as global. This is not reasonable to do
> for a static build. The effect of not exporting those symbols will be
> that SA will not function to 100%. On the other hand, I have no idea if
> SA works at all with a static build. Have you tested this? Is this part
> of the plan to support, or will it be officially dropped for Hermetic Java?

We have done some testing with jtreg SA related tests for the fully
statically linked `javastatic`.

If we use objcopy to localize symbols in hotspot, it's not yet clear
what's the impact on SA. We could do some tests. The other question
that I raised is the supported gcc versions (for partial linking)
related to the solution.

Best,
Jiangli

>
> /Magnus
>

From kbarrett at openjdk.org  Thu Feb 15 05:25:13 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 15 Feb 2024 05:25:13 GMT
Subject: RFR: 8325878: Require minimum Clang version 13
Message-ID: <zSj7alqhcE-_CnzPzWSc9bIKCZtTew_WaSTIkx5qHhQ=.ca1dc065-38d1-4b33-9ae5-e1a86d47c53a@github.com>

Please review this change that updates the minimum supported version of Clang
to be used for building OpenJDK from 3.5 to 13.

This permits enabling C++17 (JDK-8314488), though Clang 5 might suffice for
that. A minimum of Clang 13 also obtains a critical bug fix for the [[noreturn]]
attribute (see JDK-8303805).

Testing: mach5 tier1, which includes building with a recent version of Xcode/clang.

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

Commit messages:
 - update minimum clang version

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

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

From jwaters at openjdk.org  Thu Feb 15 08:37:54 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 15 Feb 2024 08:37:54 GMT
Subject: RFR: 8325878: Require minimum Clang version 13
In-Reply-To: <zSj7alqhcE-_CnzPzWSc9bIKCZtTew_WaSTIkx5qHhQ=.ca1dc065-38d1-4b33-9ae5-e1a86d47c53a@github.com>
References: <zSj7alqhcE-_CnzPzWSc9bIKCZtTew_WaSTIkx5qHhQ=.ca1dc065-38d1-4b33-9ae5-e1a86d47c53a@github.com>
Message-ID: <Ljsiqg9O4T7Dwd4ohjDLNIEXfmXSo5RzfGOsAn_4K5I=.76777f8e-b652-4ea7-af68-c3f4f9b838e4@github.com>

On Thu, 15 Feb 2024 05:19:45 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that updates the minimum supported version of Clang
> to be used for building OpenJDK from 3.5 to 13.
> 
> This permits enabling C++17 (JDK-8314488), though Clang 5 might suffice for
> that. A minimum of Clang 13 also obtains a critical bug fix for the [[noreturn]]
> attribute (see JDK-8303805).
> 
> Testing: mach5 tier1, which includes building with a recent version of Xcode/clang.

Marked as reviewed by jwaters (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/17862#pullrequestreview-1882097398

From mdoerr at openjdk.org  Thu Feb 15 08:47:02 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 15 Feb 2024 08:47:02 GMT
Subject: RFR: 8325880: Require minimum Open XL C/C++ version 17.1.1
In-Reply-To: <mYhkdea6XL09IsDZzeSMKCw5k2nWmB0bbVZfAA2bmIE=.b4d15383-e5e9-4e06-aef3-57cf104fc9bb@github.com>
References: <mYhkdea6XL09IsDZzeSMKCw5k2nWmB0bbVZfAA2bmIE=.b4d15383-e5e9-4e06-aef3-57cf104fc9bb@github.com>
Message-ID: <MtcyyPyKfQHYdX119f7_RvLBI4gWC3Pcd-TBQVURyRk=.cb37d6e9-35f0-4a79-b04b-89842ae9dd74@github.com>

On Wed, 14 Feb 2024 22:43:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that updates the minimum supported version of IBM
> Open XL C/C++.  SAP dropped support for older versions in JDK 22, only
> supporting the version specified in this change.
> 
> I need someone from the aix-ppc porters to test and review the change.

LGTM and works for us.
@JoKern65: We should probably remove the old build pipeline after this is integrated.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17857#pullrequestreview-1882123803

From jkern at openjdk.org  Thu Feb 15 08:56:03 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 15 Feb 2024 08:56:03 GMT
Subject: RFR: 8325880: Require minimum Open XL C/C++ version 17.1.1
In-Reply-To: <mYhkdea6XL09IsDZzeSMKCw5k2nWmB0bbVZfAA2bmIE=.b4d15383-e5e9-4e06-aef3-57cf104fc9bb@github.com>
References: <mYhkdea6XL09IsDZzeSMKCw5k2nWmB0bbVZfAA2bmIE=.b4d15383-e5e9-4e06-aef3-57cf104fc9bb@github.com>
Message-ID: <jLkYXRGtceEm6ogTWU8SCvhRSSCdietyl1WNW91aUV0=.22ab1491-0c18-4fe4-b7dd-a8d1d4dfb855@github.com>

On Wed, 14 Feb 2024 22:43:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that updates the minimum supported version of IBM
> Open XL C/C++.  SAP dropped support for older versions in JDK 22, only
> supporting the version specified in this change.
> 
> I need someone from the aix-ppc porters to test and review the change.

make/autoconf/toolchain.m4 line 56:

> 54: TOOLCHAIN_MINIMUM_VERSION_gcc="6.0"
> 55: TOOLCHAIN_MINIMUM_VERSION_microsoft="19.28.0.0" # VS2019 16.8, aka MSVC 14.28
> 56: TOOLCHAIN_MINIMUM_VERSION_xlc="17.1.1.4"

We do not build AIX with the xlc toolchain any more but the clang one. So this line only stops a build if someone is trying to build with xlc 16 against toolchain xlc.
I have to agree to @TheRealMDoerr, that the correct change would be to remove the xlc toolchain in jdk23 at all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17857#discussion_r1490650675

From jwaters at openjdk.org  Thu Feb 15 08:56:05 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 15 Feb 2024 08:56:05 GMT
Subject: RFR: 8325877: Split up NativeCompilation.gmk [v2]
In-Reply-To: <IHnW95znJoo2_ujDQckNZ8UvRe_J6xr_oCTUOJi1vm4=.47fee067-c6f0-4fa6-8200-cd339d2256b6@github.com>
References: <Y3QhATUmfQcr1D1geIUqzWhkGfxpXJAY1HzV9Kc1hvs=.1f862280-3618-40f4-99e3-0e8a7de57c61@github.com>
 <IHnW95znJoo2_ujDQckNZ8UvRe_J6xr_oCTUOJi1vm4=.47fee067-c6f0-4fa6-8200-cd339d2256b6@github.com>
Message-ID: <gq7PX3-HJe4ObxFrJCFmvcxvIWdoyQBEfuvs8cmJI7Y=.60dc1027-4cb8-4eea-bd60-7fb03b2219cc@github.com>

On Wed, 14 Feb 2024 15:44:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The file NativeCompilation.gmk is a beast. It is one of the largest in the build system, and it is not very well organized. This makes it hard to read, understand, debug, edit and modify, especially since IDEs have a hard time helping out with makefiles, so you get very little overview or navigation support.
>> 
>> This patch will split up the file into several parts. The splits are somewhat arbitrary, but tries to keep things sort of logically connected, and make the chunks somewhat approximate equal size.
>> 
>> I've gone to great pains to make sure I do not accidentally change anything. The order for the code in each of these files are the same as in the original NativeCompilation.gmk. I have not rearranged any code (with a few trivially exceptions, moving some assignments to allow better grouping), and instead preferred to split up functionality in several parts (as in SetupBasicVariables1-3).
>> 
>> Since I include the files in alphabetic order, some code will inevitable switch places, but this should either be just defines (which are trivially safe to move around), or it should be code that are independent of each other.
>> 
>> My intention is to follow up this shuffling with more intrusive fixes, that can e.g. reorder stuff to make for more logical grouping. But I want to do that separately.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove debug code (and fix one more space)
>  - Restore mistakenly deleted space

This is not going to be fun to rebase on top on in my port :(

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17849#pullrequestreview-1882142178

From jwaters at openjdk.org  Thu Feb 15 09:20:03 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 15 Feb 2024 09:20:03 GMT
Subject: RFR: 8325880: Require minimum Open XL C/C++ version 17.1.1
In-Reply-To: <mYhkdea6XL09IsDZzeSMKCw5k2nWmB0bbVZfAA2bmIE=.b4d15383-e5e9-4e06-aef3-57cf104fc9bb@github.com>
References: <mYhkdea6XL09IsDZzeSMKCw5k2nWmB0bbVZfAA2bmIE=.b4d15383-e5e9-4e06-aef3-57cf104fc9bb@github.com>
Message-ID: <jee-nYUtW_EOsAh10a1_8b4_fsd4eAXz3NqvSwg--Xc=.ed7c5f2c-516b-47fe-a95f-6c950fe30505@github.com>

On Wed, 14 Feb 2024 22:43:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that updates the minimum supported version of IBM
> Open XL C/C++.  SAP dropped support for older versions in JDK 22, only
> supporting the version specified in this change.
> 
> I need someone from the aix-ppc porters to test and review the change.

Marked as reviewed by jwaters (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/17857#pullrequestreview-1882190279

From ihse at openjdk.org  Thu Feb 15 10:41:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Feb 2024 10:41:01 GMT
Subject: RFR: 8325877: Split up NativeCompilation.gmk [v2]
In-Reply-To: <gq7PX3-HJe4ObxFrJCFmvcxvIWdoyQBEfuvs8cmJI7Y=.60dc1027-4cb8-4eea-bd60-7fb03b2219cc@github.com>
References: <Y3QhATUmfQcr1D1geIUqzWhkGfxpXJAY1HzV9Kc1hvs=.1f862280-3618-40f4-99e3-0e8a7de57c61@github.com>
 <IHnW95znJoo2_ujDQckNZ8UvRe_J6xr_oCTUOJi1vm4=.47fee067-c6f0-4fa6-8200-cd339d2256b6@github.com>
 <gq7PX3-HJe4ObxFrJCFmvcxvIWdoyQBEfuvs8cmJI7Y=.60dc1027-4cb8-4eea-bd60-7fb03b2219cc@github.com>
Message-ID: <fFWZ8T_AG5Rh4O2ZMjAH-I_wo7IhZ3GHpqy6498_KHg=.6ec05a2a-55ca-472a-9883-287eb9e43c3d@github.com>

On Thu, 15 Feb 2024 08:53:35 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> This is not going to be fun to rebase on top on in my port :(

Apologies. :( But I think it might not be that hard either, if you do it correctly. That was one of my goals by keeping the order so strict, to facilitate this kind of merges. 

Basically, you can consider each of the new files as a copy of the original NativeCompilation.gmk. So take your version of NativeCompilation.gmk, and copy it once for each of the new files. And then if you use a good diff tool (personally, I prefer Meld), it will show the "deleted" parts, and you can just delete them, and any changes you have done to individual lines will be kept in the "saved" parts. This assumes that you have only made a bit of change here and there; if you have reordered stuff or whatever, then you're in trouble. I hope you understand what I mean; ask if I did not express myself clearly enough.

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

PR Comment: https://git.openjdk.org/jdk/pull/17849#issuecomment-1945800763

From ihse at openjdk.org  Thu Feb 15 10:41:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Feb 2024 10:41:03 GMT
Subject: Integrated: 8325877: Split up NativeCompilation.gmk
In-Reply-To: <Y3QhATUmfQcr1D1geIUqzWhkGfxpXJAY1HzV9Kc1hvs=.1f862280-3618-40f4-99e3-0e8a7de57c61@github.com>
References: <Y3QhATUmfQcr1D1geIUqzWhkGfxpXJAY1HzV9Kc1hvs=.1f862280-3618-40f4-99e3-0e8a7de57c61@github.com>
Message-ID: <Uev4TLVXcgi26uWQC5oQ_8a0AZq5aayEjCkqKGamodI=.21e23559-82fe-4280-a844-951a31cf8d2e@github.com>

On Wed, 14 Feb 2024 15:33:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The file NativeCompilation.gmk is a beast. It is one of the largest in the build system, and it is not very well organized. This makes it hard to read, understand, debug, edit and modify, especially since IDEs have a hard time helping out with makefiles, so you get very little overview or navigation support.
> 
> This patch will split up the file into several parts. The splits are somewhat arbitrary, but tries to keep things sort of logically connected, and make the chunks somewhat approximate equal size.
> 
> I've gone to great pains to make sure I do not accidentally change anything. The order for the code in each of these files are the same as in the original NativeCompilation.gmk. I have not rearranged any code (with a few trivially exceptions, moving some assignments to allow better grouping), and instead preferred to split up functionality in several parts (as in SetupBasicVariables1-3).
> 
> Since I include the files in alphabetic order, some code will inevitable switch places, but this should either be just defines (which are trivially safe to move around), or it should be code that are independent of each other.
> 
> My intention is to follow up this shuffling with more intrusive fixes, that can e.g. reorder stuff to make for more logical grouping. But I want to do that separately.

This pull request has now been integrated.

Changeset: 0d51b769
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0d51b76947324643166cdaf9ca703431bd83bc0e
Stats:     2541 lines in 7 files changed: 1418 ins; 1101 del; 22 mod

8325877: Split up NativeCompilation.gmk

Reviewed-by: erikj, jwaters

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

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

From ihse at openjdk.org  Thu Feb 15 10:44:06 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Feb 2024 10:44:06 GMT
Subject: RFR: 8325880: Require minimum Open XL C/C++ version 17.1.1
In-Reply-To: <mYhkdea6XL09IsDZzeSMKCw5k2nWmB0bbVZfAA2bmIE=.b4d15383-e5e9-4e06-aef3-57cf104fc9bb@github.com>
References: <mYhkdea6XL09IsDZzeSMKCw5k2nWmB0bbVZfAA2bmIE=.b4d15383-e5e9-4e06-aef3-57cf104fc9bb@github.com>
Message-ID: <b9_qJOzEltyO-xkvbPrbWwHLk7t40YyFjQg1YwYeSbU=.0503a6f5-3829-4ce7-87ee-505756777389@github.com>

On Wed, 14 Feb 2024 22:43:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that updates the minimum supported version of IBM
> Open XL C/C++.  SAP dropped support for older versions in JDK 22, only
> supporting the version specified in this change.
> 
> I need someone from the aix-ppc porters to test and review the change.

Change look fine from a build perspective.

What does this mean? That you are not using xlc at all? Or is it clang but still with an xlc frontend, so all xlc flags etc need to stay?

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17857#pullrequestreview-1882416313
PR Comment: https://git.openjdk.org/jdk/pull/17857#issuecomment-1945809787

From ihse at openjdk.org  Thu Feb 15 10:44:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Feb 2024 10:44:53 GMT
Subject: RFR: 8325878: Require minimum Clang version 13
In-Reply-To: <zSj7alqhcE-_CnzPzWSc9bIKCZtTew_WaSTIkx5qHhQ=.ca1dc065-38d1-4b33-9ae5-e1a86d47c53a@github.com>
References: <zSj7alqhcE-_CnzPzWSc9bIKCZtTew_WaSTIkx5qHhQ=.ca1dc065-38d1-4b33-9ae5-e1a86d47c53a@github.com>
Message-ID: <UZFStQEEDZ4FxhFdRTEDfW2LrKjlLw9b6qPya2vy3M4=.7c981e96-8ff3-42ca-bb39-eade34254e1d@github.com>

On Thu, 15 Feb 2024 05:19:45 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that updates the minimum supported version of Clang
> to be used for building OpenJDK from 3.5 to 13.
> 
> This permits enabling C++17 (JDK-8314488), though Clang 5 might suffice for
> that. A minimum of Clang 13 also obtains a critical bug fix for the [[noreturn]]
> attribute (see JDK-8303805).
> 
> Testing: mach5 tier1, which includes building with a recent version of Xcode/clang.

Change looks fine from a build perspective.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17862#pullrequestreview-1882418401

From jkern at openjdk.org  Thu Feb 15 11:12:55 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 15 Feb 2024 11:12:55 GMT
Subject: RFR: 8325880: Require minimum Open XL C/C++ version 17.1.1
In-Reply-To: <b9_qJOzEltyO-xkvbPrbWwHLk7t40YyFjQg1YwYeSbU=.0503a6f5-3829-4ce7-87ee-505756777389@github.com>
References: <mYhkdea6XL09IsDZzeSMKCw5k2nWmB0bbVZfAA2bmIE=.b4d15383-e5e9-4e06-aef3-57cf104fc9bb@github.com>
 <b9_qJOzEltyO-xkvbPrbWwHLk7t40YyFjQg1YwYeSbU=.0503a6f5-3829-4ce7-87ee-505756777389@github.com>
Message-ID: <ONhNJiUAWHP3QlZ6--xQrk1cqFoYpY-DPQ3BNxnD9T8=.8a6f62fb-7ed0-481a-8273-9686e77e5e15@github.com>

On Thu, 15 Feb 2024 10:40:53 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> What does this mean? That you are not using xlc at all? Or is it clang but still with an xlc frontend, so all xlc flags etc need to stay?


The `xlc` toolchain is for the compiler versions up to 16 (xlclang++); the `clang` toolchain is for the compiler versions 17 (ibm-clang++_r) and higher. For the 17 Compiler the frontend is `clang`-ish and we are using the `clang` flags instead of the `xlc` flags.
`toolchain.m4` decides on the basis of the found compiler which toolchain to use as default.

# On AIX the default toolchain depends on the installed (found) compiler
  #   xlclang++     -> xlc toolchain
  #   ibm-clang++_r -> clang toolchain
  # The compiler is searched on the PATH and TOOLCHAIN_PATH
  # xlclang++ has precedence over ibm-clang++_r if both are installed

So, if we set the minimum compiler level for AIX to 17, we can remove the xlc toolchain at all. 
We cannot remove every reference to xlc, because at least some headers we still use the xlc version (globalDefinitions_xlc.hpp)

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

PR Comment: https://git.openjdk.org/jdk/pull/17857#issuecomment-1945873440

From ihse at openjdk.org  Thu Feb 15 11:43:04 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Feb 2024 11:43:04 GMT
Subject: RFR: 8325880: Require minimum Open XL C/C++ version 17.1.1
In-Reply-To: <ONhNJiUAWHP3QlZ6--xQrk1cqFoYpY-DPQ3BNxnD9T8=.8a6f62fb-7ed0-481a-8273-9686e77e5e15@github.com>
References: <mYhkdea6XL09IsDZzeSMKCw5k2nWmB0bbVZfAA2bmIE=.b4d15383-e5e9-4e06-aef3-57cf104fc9bb@github.com>
 <b9_qJOzEltyO-xkvbPrbWwHLk7t40YyFjQg1YwYeSbU=.0503a6f5-3829-4ce7-87ee-505756777389@github.com>
 <ONhNJiUAWHP3QlZ6--xQrk1cqFoYpY-DPQ3BNxnD9T8=.8a6f62fb-7ed0-481a-8273-9686e77e5e15@github.com>
Message-ID: <zi5Mu9jv0c_j-_Z8lso4m7IajlEJC2H2wgPtL1b53NU=.79de9835-55bf-4a4f-ae1d-f9d9d3bfbb45@github.com>

On Thu, 15 Feb 2024 11:10:32 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> What does this mean? That you are not using xlc at all? Or is it clang but still with an xlc frontend, so all xlc flags etc need to stay?
>
>> What does this mean? That you are not using xlc at all? Or is it clang but still with an xlc frontend, so all xlc flags etc need to stay?
> 
> 
> The `xlc` toolchain is for the compiler versions up to 16 (xlclang++); the `clang` toolchain is for the compiler versions 17 (ibm-clang++_r) and higher. For the 17 Compiler the frontend is `clang`-ish and we are using the `clang` flags instead of the `xlc` flags.
> `toolchain.m4` decides on the basis of the found compiler which toolchain to use as default.
> 
> # On AIX the default toolchain depends on the installed (found) compiler
>   #   xlclang++     -> xlc toolchain
>   #   ibm-clang++_r -> clang toolchain
>   # The compiler is searched on the PATH and TOOLCHAIN_PATH
>   # xlclang++ has precedence over ibm-clang++_r if both are installed
> 
> So, if we set the minimum compiler level for AIX to 17, we can remove the xlc toolchain at all. 
> We cannot remove every reference to xlc, because at least some headers we still use the xlc version (globalDefinitions_xlc.hpp)

@JoKern65 Thanks for the explanation! It would be nice to clear out the xlc stuff. Let's open a separate issue for that once this is integrated.

I also believe that the selection of `globalDefinitions_xlc.hpp` is done by #ifdefs in Hotspot source code, and has no relation to the build systems concept of toolchains.

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

PR Comment: https://git.openjdk.org/jdk/pull/17857#issuecomment-1945927380

From jwaters at openjdk.org  Thu Feb 15 12:26:04 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 15 Feb 2024 12:26:04 GMT
Subject: RFR: 8325880: Require minimum Open XL C/C++ version 17.1.1
In-Reply-To: <ONhNJiUAWHP3QlZ6--xQrk1cqFoYpY-DPQ3BNxnD9T8=.8a6f62fb-7ed0-481a-8273-9686e77e5e15@github.com>
References: <mYhkdea6XL09IsDZzeSMKCw5k2nWmB0bbVZfAA2bmIE=.b4d15383-e5e9-4e06-aef3-57cf104fc9bb@github.com>
 <b9_qJOzEltyO-xkvbPrbWwHLk7t40YyFjQg1YwYeSbU=.0503a6f5-3829-4ce7-87ee-505756777389@github.com>
 <ONhNJiUAWHP3QlZ6--xQrk1cqFoYpY-DPQ3BNxnD9T8=.8a6f62fb-7ed0-481a-8273-9686e77e5e15@github.com>
Message-ID: <GiNwZvtecvzFOuvGUCW5p6-AlWU3edjVg-ygMPOXNos=.10b9817c-ba33-4c0e-804e-f1dc151bef19@github.com>

On Thu, 15 Feb 2024 11:10:32 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> What does this mean? That you are not using xlc at all? Or is it clang but still with an xlc frontend, so all xlc flags etc need to stay?
>
>> What does this mean? That you are not using xlc at all? Or is it clang but still with an xlc frontend, so all xlc flags etc need to stay?
> 
> 
> The `xlc` toolchain is for the compiler versions up to 16 (xlclang++); the `clang` toolchain is for the compiler versions 17 (ibm-clang++_r) and higher. For the 17 Compiler the frontend is `clang`-ish and we are using the `clang` flags instead of the `xlc` flags.
> `toolchain.m4` decides on the basis of the found compiler which toolchain to use as default.
> 
> # On AIX the default toolchain depends on the installed (found) compiler
>   #   xlclang++     -> xlc toolchain
>   #   ibm-clang++_r -> clang toolchain
>   # The compiler is searched on the PATH and TOOLCHAIN_PATH
>   # xlclang++ has precedence over ibm-clang++_r if both are installed
> 
> So, if we set the minimum compiler level for AIX to 17, we can remove the xlc toolchain at all. 
> We cannot remove every reference to xlc, because at least some headers we still use the xlc version (globalDefinitions_xlc.hpp)

> @JoKern65 Thanks for the explanation! It would be nice to clear out the xlc stuff. Let's open a separate issue for that once this is integrated.
> 
> I also believe that the selection of `globalDefinitions_xlc.hpp` is done by #ifdefs in Hotspot source code, and has no relation to the build systems concept of toolchains.

There is one spot in the build system where clang is forcefully labelled as xlc, in the place where the HotSpot toolchain type is set
https://github.com/openjdk/jdk/blob/a0e5e16afbd19f6396f0af2cba954225a357eca8/make/autoconf/toolchain.m4#L1015

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

PR Comment: https://git.openjdk.org/jdk/pull/17857#issuecomment-1945992143

From ihse at openjdk.org  Thu Feb 15 12:29:23 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Feb 2024 12:29:23 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
Message-ID: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>

Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).

I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

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

Commit messages:
 - 8325950: Make sure all files in the JDK pass jcheck

Changes: https://git.openjdk.org/jdk/pull/17871/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17871&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325950
  Stats: 113 lines in 38 files changed: 0 ins; 10 del; 103 mod
  Patch: https://git.openjdk.org/jdk/pull/17871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17871/head:pull/17871

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

From ihse at openjdk.org  Thu Feb 15 12:29:24 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Feb 2024 12:29:24 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
Message-ID: <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>

On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
> 
> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

Some general remarks: The problems in .m4 files where not properly detected and fixed when I added .m4 to the list of checked files. The properties files were recently checked by me, so these suprrised me. It turned out I had misunderstood the jcheck criteria: I thought only leading tabs were disallowed, but it is actually tabs anywhere in the file that are banned.

In general, I have replaced tab characters with spaces aligning to tab stops at 8 characters distance. 

I'll leave some remarks for individual files.

src/java.naming/share/classes/com/sun/jndi/ldap/jndiprovider.properties line 10:

> 8: java.naming.factory.object=com.sun.jndi.ldap.obj.AttrsToCorba:com.sun.jndi.ldap.obj.MarshalledToObject
> 9: 
> 10: # RemoteToAttrs: Turn RMI/JRMP and RMI/IIOP object into javaMarshalledObject or

I adjusted this tab stop (with one space) so it aligned properly with the line above; I think that was the intention.

src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdkinternals.properties line 41:

> 39: jdk.internal.ref.Cleaner=Use java.lang.ref.PhantomReference @since 1.2 or java.lang.ref.Cleaner @since 9
> 40: sun.awt.CausedFocusEvent=Use java.awt.event.FocusEvent::getCause @since 9
> 41: sun.font.FontUtilities=See java.awt.Font.textRequiresLayout	@since 9

This tab just looked out of place, so I replaced it with a space. (Rhyming not intentional...)

test/hotspot/jtreg/containers/docker/JfrReporter.java line 52:

> 50:             }
> 51:         }
> 52:     }

I'm not sure how a Java file ever got into the code base with trailing spaces, but a guess is that there have been a bug in jcheck that did not properly check for trailing whitespace at the end of the file, or something like that.

test/jdk/java/util/Currency/currency.properties line 18:

> 16: SB=EUR,111,2, 2099-01-01T00:00:00
> 17: US=euR,978,2,2001-01-01T00:00:00
> 18: ZZ	=	ZZZ	,	999	,	3

This looks weird, but so did the original code. I assume this is to clearly indicate this as a end of list marker.

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

PR Comment: https://git.openjdk.org/jdk/pull/17871#issuecomment-1945992837
PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1490931378
PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1490931979
PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1490933432
PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1490934063

From ihse at openjdk.org  Thu Feb 15 12:33:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Feb 2024 12:33:03 GMT
Subject: RFR: 8325880: Require minimum Open XL C/C++ version 17.1.1
In-Reply-To: <mYhkdea6XL09IsDZzeSMKCw5k2nWmB0bbVZfAA2bmIE=.b4d15383-e5e9-4e06-aef3-57cf104fc9bb@github.com>
References: <mYhkdea6XL09IsDZzeSMKCw5k2nWmB0bbVZfAA2bmIE=.b4d15383-e5e9-4e06-aef3-57cf104fc9bb@github.com>
Message-ID: <xXpGBX6jplD8U9aDw5QsH0s8__aLCjWzY-17cBN3vaY=.4d6000eb-26ab-4825-af3f-549433b1e9e3@github.com>

On Wed, 14 Feb 2024 22:43:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that updates the minimum supported version of IBM
> Open XL C/C++.  SAP dropped support for older versions in JDK 22, only
> supporting the version specified in this change.
> 
> I need someone from the aix-ppc porters to test and review the change.

I see. I believe I wrote that piece of code, but I'd clearly forgotten that. ?  Thanks! :)

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

PR Comment: https://git.openjdk.org/jdk/pull/17857#issuecomment-1946004231

From jkern at openjdk.org  Thu Feb 15 12:39:53 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 15 Feb 2024 12:39:53 GMT
Subject: RFR: 8325880: Require minimum Open XL C/C++ version 17.1.1
In-Reply-To: <xXpGBX6jplD8U9aDw5QsH0s8__aLCjWzY-17cBN3vaY=.4d6000eb-26ab-4825-af3f-549433b1e9e3@github.com>
References: <mYhkdea6XL09IsDZzeSMKCw5k2nWmB0bbVZfAA2bmIE=.b4d15383-e5e9-4e06-aef3-57cf104fc9bb@github.com>
 <xXpGBX6jplD8U9aDw5QsH0s8__aLCjWzY-17cBN3vaY=.4d6000eb-26ab-4825-af3f-549433b1e9e3@github.com>
Message-ID: <j8m-VyuCWiKBoTsYqTbcBRUqANS1ZGHeDv69wisONto=.f45608e4-cff1-410e-8967-5b16acd7de89@github.com>

On Thu, 15 Feb 2024 12:29:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I see. I believe I wrote that piece of code, but I'd clearly forgotten that. ? Thanks! :)

No, this was added by me, because this was the root point to still resolve to globalDefinitions_xlc.hpp even with toolchain clang

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

PR Comment: https://git.openjdk.org/jdk/pull/17857#issuecomment-1946015507

From stuefe at openjdk.org  Thu Feb 15 12:48:03 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 15 Feb 2024 12:48:03 GMT
Subject: RFR: 8325878: Require minimum Clang version 13
In-Reply-To: <zSj7alqhcE-_CnzPzWSc9bIKCZtTew_WaSTIkx5qHhQ=.ca1dc065-38d1-4b33-9ae5-e1a86d47c53a@github.com>
References: <zSj7alqhcE-_CnzPzWSc9bIKCZtTew_WaSTIkx5qHhQ=.ca1dc065-38d1-4b33-9ae5-e1a86d47c53a@github.com>
Message-ID: <-yAR2iW4MtSKz0hO93nAa4YJWurcpIe0zLctEf-01a4=.ffe8876b-5692-47da-afdf-32170818945b@github.com>

On Thu, 15 Feb 2024 05:19:45 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that updates the minimum supported version of Clang
> to be used for building OpenJDK from 3.5 to 13.
> 
> This permits enabling C++17 (JDK-8314488), though Clang 5 might suffice for
> that. A minimum of Clang 13 also obtains a critical bug fix for the [[noreturn]]
> attribute (see JDK-8303805).
> 
> Testing: mach5 tier1, which includes building with a recent version of Xcode/clang.

Unfortunately this will break my workflow on Linux - I use clang to build on Ubuntu 20.04, which is not that old, but it ships with clang 12. This is not a deal breaker, just annoying.

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

PR Comment: https://git.openjdk.org/jdk/pull/17862#issuecomment-1946030283

From jwaters at openjdk.org  Thu Feb 15 12:51:53 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 15 Feb 2024 12:51:53 GMT
Subject: RFR: 8325880: Require minimum Open XL C/C++ version 17.1.1
In-Reply-To: <j8m-VyuCWiKBoTsYqTbcBRUqANS1ZGHeDv69wisONto=.f45608e4-cff1-410e-8967-5b16acd7de89@github.com>
References: <mYhkdea6XL09IsDZzeSMKCw5k2nWmB0bbVZfAA2bmIE=.b4d15383-e5e9-4e06-aef3-57cf104fc9bb@github.com>
 <xXpGBX6jplD8U9aDw5QsH0s8__aLCjWzY-17cBN3vaY=.4d6000eb-26ab-4825-af3f-549433b1e9e3@github.com>
 <j8m-VyuCWiKBoTsYqTbcBRUqANS1ZGHeDv69wisONto=.f45608e4-cff1-410e-8967-5b16acd7de89@github.com>
Message-ID: <-E8pd_e1fNLaTVWvrzBMWKK-NBf_anagYZs9hNqZXNI=.4871b67f-cd2f-4b64-9ca4-a9719659a854@github.com>

On Thu, 15 Feb 2024 12:36:25 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> > I see. I believe I wrote that piece of code, but I'd clearly forgotten that. ? Thanks! :)
> 
> No, this was added by me, because this was the root point to still resolve to globalDefinitions_xlc.hpp even with toolchain clang

Shame that we can't fully swap to clang in some areas for AIX, but oh well

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

PR Comment: https://git.openjdk.org/jdk/pull/17857#issuecomment-1946036007

From stuefe at openjdk.org  Thu Feb 15 13:04:07 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 15 Feb 2024 13:04:07 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
Message-ID: <Wx3S6B4fUk9k1Rez__mXIHAGYuNjPw8FqqoLxyzlK2Y=.f0a77d7e-6544-4601-a7ed-61556cb4c312@github.com>

On Thu, 11 Jan 2024 13:23:45 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Compile the JDK as C++17, enabling the use of all C++17 language features
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Require clang 13 in toolchain.m4

Just on a general note:

I would like it if toolchain version bumps were discussed somewhere else first, not in a PR. (And apologies if it was and I missed that discussion). Because PRs are usually followed only by active developers, but toolchain versions affect a broader part of the community. As we have seen in this PR, there are conflicting interests.

We have things like CSRs and JEPs. Both are not ideal - a JEP is way too massive, and a CSR is about the compatibility of the product, not about build-time. Still, maybe something like a CSR would make sense here.

I understand that with toolchain support, there will always be opposing parties, and I can see arguments on both sides. We don't want to end up like FreeBSD - stuck in time because of opinion stalemates. I just keep thinking that a PR is maybe not the perfect forum for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1946053820

From jkern at openjdk.org  Thu Feb 15 13:24:03 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 15 Feb 2024 13:24:03 GMT
Subject: RFR: 8325880: Require minimum Open XL C/C++ version 17.1.1
In-Reply-To: <-E8pd_e1fNLaTVWvrzBMWKK-NBf_anagYZs9hNqZXNI=.4871b67f-cd2f-4b64-9ca4-a9719659a854@github.com>
References: <mYhkdea6XL09IsDZzeSMKCw5k2nWmB0bbVZfAA2bmIE=.b4d15383-e5e9-4e06-aef3-57cf104fc9bb@github.com>
 <xXpGBX6jplD8U9aDw5QsH0s8__aLCjWzY-17cBN3vaY=.4d6000eb-26ab-4825-af3f-549433b1e9e3@github.com>
 <j8m-VyuCWiKBoTsYqTbcBRUqANS1ZGHeDv69wisONto=.f45608e4-cff1-410e-8967-5b16acd7de89@github.com>
 <-E8pd_e1fNLaTVWvrzBMWKK-NBf_anagYZs9hNqZXNI=.4871b67f-cd2f-4b64-9ca4-a9719659a854@github.com>
Message-ID: <rm25nLpMuDs0F-859bymUewalKWLZ4R9kb1Hz5XBMFs=.ad85cac0-921c-4567-8717-58685f8d9417@github.com>

On Thu, 15 Feb 2024 12:49:26 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> > > I see. I believe I wrote that piece of code, but I'd clearly forgotten that. ? Thanks! :)
> > 
> > 
> > No, this was added by me, because this was the root point to still resolve to globalDefinitions_xlc.hpp even with toolchain clang
> 
> Shame that we can't fully swap to clang in some areas for AIX, but oh well

Although the compiler is now clang, the headers are still the old IBM ones and globalDefinitions_xlc.hpp is not consumable by other clang implementations. So if we change this we still have to differentiate between AIX clang and  other clangs.

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

PR Comment: https://git.openjdk.org/jdk/pull/17857#issuecomment-1946086792

From erikj at openjdk.org  Thu Feb 15 14:05:12 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 15 Feb 2024 14:05:12 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
Message-ID: <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>

On Thu, 15 Feb 2024 12:26:11 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
>> 
>> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.
>
> test/jdk/java/util/Currency/currency.properties line 18:
> 
>> 16: SB=EUR,111,2, 2099-01-01T00:00:00
>> 17: US=euR,978,2,2001-01-01T00:00:00
>> 18: ZZ	=	ZZZ	,	999	,	3
> 
> This looks weird, but so did the original code. I assume this is to clearly indicate this as a end of list marker.

This looks weird indeed. Luckily it's just test code. Did you run the test after this change?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491056108

From ihse at openjdk.org  Thu Feb 15 15:13:14 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Feb 2024 15:13:14 GMT
Subject: RFR: 8325972: Add -x to bash for building with LOG=debug
Message-ID: <UIGPgQR2VRlTTSVoNqyaA1TGdWs2FSB_1aYRb07sXZE=.3bbc1bb2-4542-4b2c-aeff-920f0693ec62@github.com>

I don't understand why I have never thought of this before. If we add `-x` to the set of bash arguments when running with LOG=debug, we get output of *all* shell commands that make is running, even those for $(shell).

This makes it soooo much easier to understand what is actually happening in the makefile! (To the point where we could actually consider moving other stuff away from the debug level.)

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

Commit messages:
 - 8325972: Add -x to bash for building with LOG=debug

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

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

From ihse at openjdk.org  Thu Feb 15 15:50:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Feb 2024 15:50:57 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
 <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>
Message-ID: <osmSAGyuE-qyC6sjVT_UjfRd2CfUQHuKFjlvmDOW-3Y=.b8a009f9-e995-42e7-afed-af83a016ff2b@github.com>

On Thu, 15 Feb 2024 14:01:46 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> test/jdk/java/util/Currency/currency.properties line 18:
>> 
>>> 16: SB=EUR,111,2, 2099-01-01T00:00:00
>>> 17: US=euR,978,2,2001-01-01T00:00:00
>>> 18: ZZ	=	ZZZ	,	999	,	3
>> 
>> This looks weird, but so did the original code. I assume this is to clearly indicate this as a end of list marker.
>
> This looks weird indeed. Luckily it's just test code. Did you run the test after this change?

All the java/util/Currency tests pass. I also searched the code for "ZZ" but could not find any references in the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491227492

From ihse at openjdk.org  Thu Feb 15 15:52:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Feb 2024 15:52:53 GMT
Subject: RFR: 8325880: Require minimum Open XL C/C++ version 17.1.1
In-Reply-To: <mYhkdea6XL09IsDZzeSMKCw5k2nWmB0bbVZfAA2bmIE=.b4d15383-e5e9-4e06-aef3-57cf104fc9bb@github.com>
References: <mYhkdea6XL09IsDZzeSMKCw5k2nWmB0bbVZfAA2bmIE=.b4d15383-e5e9-4e06-aef3-57cf104fc9bb@github.com>
Message-ID: <AMbFFka3hKd3QXxrTGnVYozWpZMTe5jm9l-GNVZSMQQ=.3bdcd9c8-07cc-44b5-995a-11e2d5d3dc02@github.com>

On Wed, 14 Feb 2024 22:43:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that updates the minimum supported version of IBM
> Open XL C/C++.  SAP dropped support for older versions in JDK 22, only
> supporting the version specified in this change.
> 
> I need someone from the aix-ppc porters to test and review the change.

Sounds like it really should be `globalDefinitions_aix.hpp` then...

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

PR Comment: https://git.openjdk.org/jdk/pull/17857#issuecomment-1946379438

From ihse at openjdk.org  Thu Feb 15 15:57:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Feb 2024 15:57:57 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <Wx3S6B4fUk9k1Rez__mXIHAGYuNjPw8FqqoLxyzlK2Y=.f0a77d7e-6544-4601-a7ed-61556cb4c312@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
 <Wx3S6B4fUk9k1Rez__mXIHAGYuNjPw8FqqoLxyzlK2Y=.f0a77d7e-6544-4601-a7ed-61556cb4c312@github.com>
Message-ID: <UJpm6tMqM1HHSg7Za-n0sHCZdMl5u6r3anC7Cty6VAQ=.000fac5d-00d6-4c71-846b-4c1aeedf4c70@github.com>

On Thu, 15 Feb 2024 13:00:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I would like it if toolchain version bumps were discussed somewhere else first, not in a PR. (And apologies if it was and I missed that discussion). 

Yes, it definitely was. I posted a separate [mail to build-dev](https://mail.openjdk.org/pipermail/build-dev/2024-January/042802.html) with subject "Raising the minimum version of gcc, clang and xlc". I don't think we can make it more clear than that.

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1946388775

From stuefe at openjdk.org  Thu Feb 15 16:01:57 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 15 Feb 2024 16:01:57 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <UJpm6tMqM1HHSg7Za-n0sHCZdMl5u6r3anC7Cty6VAQ=.000fac5d-00d6-4c71-846b-4c1aeedf4c70@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
 <Wx3S6B4fUk9k1Rez__mXIHAGYuNjPw8FqqoLxyzlK2Y=.f0a77d7e-6544-4601-a7ed-61556cb4c312@github.com>
 <UJpm6tMqM1HHSg7Za-n0sHCZdMl5u6r3anC7Cty6VAQ=.000fac5d-00d6-4c71-846b-4c1aeedf4c70@github.com>
Message-ID: <AXQxJs2SIwoi3xltheTzOwumeoCjvrcOc62WMOD9lnk=.7ba32dd8-680e-4cc0-8665-5ff90350eed9@github.com>

On Thu, 15 Feb 2024 15:54:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > I would like it if toolchain version bumps were discussed somewhere else first, not in a PR. (And apologies if it was and I missed that discussion).
> 
> Yes, it definitely was. I posted a separate [mail to build-dev](https://mail.openjdk.org/pipermail/build-dev/2024-January/042802.html) with subject "Raising the minimum version of gcc, clang and xlc". I don't think we can make it more clear than that.

Okay, thank you for that clarification. I clearly missed it then.

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1946396577

From naoto at openjdk.org  Thu Feb 15 17:12:55 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Feb 2024 17:12:55 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <osmSAGyuE-qyC6sjVT_UjfRd2CfUQHuKFjlvmDOW-3Y=.b8a009f9-e995-42e7-afed-af83a016ff2b@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
 <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>
 <osmSAGyuE-qyC6sjVT_UjfRd2CfUQHuKFjlvmDOW-3Y=.b8a009f9-e995-42e7-afed-af83a016ff2b@github.com>
Message-ID: <oX6tKgqTMzsDdSFj-X-EXtJS-20BsyiMYBacmxBTzTk=.b6eb0e9d-9940-479e-b70b-75a446e43e1c@github.com>

On Thu, 15 Feb 2024 15:48:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This looks weird indeed. Luckily it's just test code. Did you run the test after this change?
>
> All the java/util/Currency tests pass. I also searched the code for "ZZ" but could not find any references in the test.

Please do not replace those tabs with spaces as they are intentional for testing the runtime to safely ignore them. I suggest replacing them with Unicode escapes (`\u000b`)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491352359

From stuefe at openjdk.org  Thu Feb 15 17:15:57 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 15 Feb 2024 17:15:57 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <yq-FT47x7QF7L78fMxw3VvYAo_osUWzeUzxb5iJU3hE=.1899b72a-41f7-44b7-946f-84ca1339f1f8@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
 <i3bo22m6I5cYhAMfktX-W_4-rrtyK6EPyK57QUi6Tco=.a18ddecb-440b-4c70-95ec-4b21fd1b3144@github.com>
 <KCC78U2X_if2XTRu1qNkeVXSQ672EyZFHbkl-OtP3U8=.9695b185-dc76-4d26-ae32-ceb254f5f275@github.com>
 <yq-FT47x7QF7L78fMxw3VvYAo_osUWzeUzxb5iJU3hE=.1899b72a-41f7-44b7-946f-84ca1339f1f8@github.com>
Message-ID: <F7MGxuI0CLaL28Y7s7KhRW_NmgsCOnJLs5wnUlXjGk8=.f44adba9-e08c-4093-a13e-dd2851e94e97@github.com>

On Mon, 5 Feb 2024 09:44:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > Sure, you can always install a newer GCC than the system one, but it's another thing that makes it harder for people to build OpenJDK. Having said that, C++17 is nice to have.
> 
> @theRealAph I am still just hearing hand-waving "perhaps someone somewhere will have a somewhat harder time building the JDK". Yes, perhaps that is so. But that is very uncertain, and I have still not heard a single concrete example of where this would apply. In contrast, going to gcc 10 will clearly bring a benefit to all other platforms, since it allows us to synchronize the code base at C++17.
> 
> In light of this, I think we need to hear some really compelling evidence of problems that would ensue if we raise the minimum to gcc 10. If nobody can produce such evidence, then to me it is a sign that this fear is not well-grounded, and we should proceed with this PR.

@magicus You put the onus of proving that problems could ensue strictly to the objectors. That is a bit one-sided. I do not see much effort - any, really - put into detailing the motivation for this move, neither in the PR description nor in the JBS issue text. I just read through the whole PR discussion and really the only helpful comment I found was from Kim ( https://github.com/openjdk/jdk/pull/14988#issuecomment-1858136247 ).

I think important decisions like enforcing C++17 would benefit from a more careful preparation.

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1946628523

From prappo at openjdk.org  Thu Feb 15 17:21:07 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 15 Feb 2024 17:21:07 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v32]
In-Reply-To: <5f-y-x2KRcAGr501XkShj08p51vAl8wxD8l8PYFcQmI=.08ee889e-8abb-47e2-b3ba-49bb09ae600d@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <5f-y-x2KRcAGr501XkShj08p51vAl8wxD8l8PYFcQmI=.08ee889e-8abb-47e2-b3ba-49bb09ae600d@github.com>
Message-ID: <7hjkEusPyjQpzUGNArF4qKR_tSVyi3ekgkyX7gZ2LZw=.ad6b2cd6-f29b-4fca-b246-73572689180b@github.com>

On Thu, 15 Feb 2024 00:30:25 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits:
> 
>  - fill in `visitRawText` in `CommentHelper.getTags` visitor
>  - fixes for the "New API" page
>  - change "standard" to "traditional" when referring to a comment
>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>  - improve support for DocCommentParser.LineKind
>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3 # Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the
>    commit.
>  - update copyright year on test
>  - refactor recent new test case in TestMarkdown.java
>  - address review feedback
>  - ... and 34 more: https://git.openjdk.org/jdk/compare/8765b176...2801c2e1

I'm again looking `LineKind`. This time because of 9eaf84e5dd6.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 422:

> 420:                             defaultContentCharacter();
> 421:                         }
> 422:                     }

Is it to pass `` through to Markdown, to allow it to deal with Markdown escapes?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1401:

> 1399:      */
> 1400:     enum LineKind {
> 1401:         BLANK(Pattern.compile("[ \t]*")),

`BLANK` is a pseudo kind, because it is set manually, but never returned from `peekLine()`. I wonder if we can change it somehow.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1433:

> 1431:          * @see <a href="https://spec.commonmark.org/0.30/#list-items">List items</a>
> 1432:          */
> 1433:         BULLETED_LIST_ITEM(Pattern.compile("[-+*] .*")),

This comment is about `BULLETED_LIST_ITEM` and `ORDERED_LIST_ITEM` constants. I know that we don't need to be very precise, but perhaps in this case we should. While the CommonMark spec is a vague on that, from my experiments with [dingus](https://spec.commonmark.org/dingus/), it appears that a list marker can be preceded and followed by some number of whitespace characters.

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

PR Review: https://git.openjdk.org/jdk/pull/16388#pullrequestreview-1883374712
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1491362821
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1491344667
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1491354450

From angorya at openjdk.org  Thu Feb 15 17:31:56 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 15 Feb 2024 17:31:56 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <oX6tKgqTMzsDdSFj-X-EXtJS-20BsyiMYBacmxBTzTk=.b6eb0e9d-9940-479e-b70b-75a446e43e1c@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
 <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>
 <osmSAGyuE-qyC6sjVT_UjfRd2CfUQHuKFjlvmDOW-3Y=.b8a009f9-e995-42e7-afed-af83a016ff2b@github.com>
 <oX6tKgqTMzsDdSFj-X-EXtJS-20BsyiMYBacmxBTzTk=.b6eb0e9d-9940-479e-b70b-75a446e43e1c@github.com>
Message-ID: <Si89vBx8-kmdHyp9_XHJyFMD5oVir2mKhgwOcO281CE=.c387b74a-b09c-4213-8561-8e111f08f855@github.com>

On Thu, 15 Feb 2024 17:09:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> All the java/util/Currency tests pass. I also searched the code for "ZZ" but could not find any references in the test.
>
> Please do not replace those tabs with spaces as they are intentional for testing the runtime to safely ignore them. I suggest replacing them with Unicode escapes (`\u000b`)

`\u000b` is VT   (vertical tab)  
`\u0009` or `\t` perhaps?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491375928

From naoto at openjdk.org  Thu Feb 15 17:55:58 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Feb 2024 17:55:58 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <Si89vBx8-kmdHyp9_XHJyFMD5oVir2mKhgwOcO281CE=.c387b74a-b09c-4213-8561-8e111f08f855@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
 <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>
 <osmSAGyuE-qyC6sjVT_UjfRd2CfUQHuKFjlvmDOW-3Y=.b8a009f9-e995-42e7-afed-af83a016ff2b@github.com>
 <oX6tKgqTMzsDdSFj-X-EXtJS-20BsyiMYBacmxBTzTk=.b6eb0e9d-9940-479e-b70b-75a446e43e1c@github.com>
 <Si89vBx8-kmdHyp9_XHJyFMD5oVir2mKhgwOcO281CE=.c387b74a-b09c-4213-8561-8e111f08f855@github.com>
Message-ID: <RtDj7nYzLQTAHvuthfA12JIjqYTM7LkXy92QXXib4jY=.62dbc402-ade5-48be-9e7a-1ca1091899d4@github.com>

On Thu, 15 Feb 2024 17:28:52 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Please do not replace those tabs with spaces as they are intentional for testing the runtime to safely ignore them. I suggest replacing them with Unicode escapes (`\u000b`)
>
> `\u000b` is VT   (vertical tab)  
> `\u0009` or `\t` perhaps?

Right. `\t` is better to avoid such a mistake.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491403426

From erikj at openjdk.org  Thu Feb 15 18:02:53 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 15 Feb 2024 18:02:53 GMT
Subject: RFR: 8325972: Add -x to bash for building with LOG=debug
In-Reply-To: <UIGPgQR2VRlTTSVoNqyaA1TGdWs2FSB_1aYRb07sXZE=.3bbc1bb2-4542-4b2c-aeff-920f0693ec62@github.com>
References: <UIGPgQR2VRlTTSVoNqyaA1TGdWs2FSB_1aYRb07sXZE=.3bbc1bb2-4542-4b2c-aeff-920f0693ec62@github.com>
Message-ID: <HGiotFygbrmLLxFQUYhjtTLa-QHzuObnpgXQnpMxVDs=.d5137c7c-165f-4a58-bba6-27ac0c22e446@github.com>

On Thu, 15 Feb 2024 15:07:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I don't understand why I have never thought of this before. If we add `-x` to the set of bash arguments when running with LOG=debug, we get output of *all* shell commands that make is running, even those for $(shell).
> 
> This makes it soooo much easier to understand what is actually happening in the makefile! (To the point where we could actually consider moving other stuff away from the debug level.)

Should we also disable the built in make command printing option for `debug` to avoid duplicate output?

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

PR Review: https://git.openjdk.org/jdk/pull/17875#pullrequestreview-1883482256

From jjg at openjdk.org  Thu Feb 15 19:04:18 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 15 Feb 2024 19:04:18 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v33]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <ZWiDa55stEIAQtlU6oL0XUfqTEZlPe2UcWjBC9E_2js=.e2d42833-7e4a-40d4-aebc-718a94909f14@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  fix compilation and whitespace issues

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/2801c2e1..f6d08db9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=31-32

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

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

From jjg at openjdk.org  Thu Feb 15 19:20:06 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 15 Feb 2024 19:20:06 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v31]
In-Reply-To: <revTaYUgM40q0U5bHloqsO56zzKGpaMVRdj_LLyHQrs=.047fe7ff-2f0e-4fad-b4b8-10bdee6b639c@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <Imc_x0a26ALH3KO5jdgjvvwqZ8SL7eC-cotk7AphhRI=.8fcfe332-53cd-4aa9-8ff7-fc2082b23ece@github.com>
 <revTaYUgM40q0U5bHloqsO56zzKGpaMVRdj_LLyHQrs=.047fe7ff-2f0e-4fad-b4b8-10bdee6b639c@github.com>
Message-ID: <g82TmBi3DkRmU2UGOnXqtNsUSowqEHZOWGZv7171xOE=.695378bb-1a9e-4931-9db0-a7d43395e8cd@github.com>

On Tue, 13 Feb 2024 11:15:55 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - improve support for DocCommentParser.LineKind
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3 # Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the
>>    commit.
>>  - update copyright year on test
>>  - refactor recent new test case in TestMarkdown.java
>>  - address review feedback
>>  - address review feedback
>>  - added test case in TestMarkdown.java for handling of `@deprecated` tag
>>  - amend comment in test
>>  - improve comments on negative test case
>>  - ... and 30 more: https://git.openjdk.org/jdk/compare/2ed889b7...1c64a6e0
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 1021:
> 
>> 1019:                     .findFirst();
>> 1020:             if (first.isEmpty() || first.get() != tree) {
>> 1021:                 dct.getFirstSentence().forEach(t -> System.err.println(t.getKind() + ": >>|" + t + "|<<"));
> 
> Is it leftover debug output?

Oops, yes.  Thanks.

> src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java line 571:
> 
>> 569:         // of a doclet to be specified instead of the name of the
>> 570:         // doclet class and optional doclet path.
>> 571:         // See https://bugs.openjdk.org/browse/JDK-8263219
> 
> It's hard to understand this:
> 
>> to permit an instance of an appropriately configured instance of a doclet
> 
> Also: how is that piece of code used? When I commented it out, no test/langtools:langtools_javadoc tests failed.

1.  Since forever, and still true, the way to specify a doclet is by its name, and the tool will create the instance for you.  This goes back to the original old days before any API, when the only entry point was the command line.
This implies that (a) the doclet has a no-args constructor and (b) that all doclet config is done through command line options.  A better solution would be to add new functionality to the various javadoc tool API (some or all of `Main`/`Start`/`DocumentationTool`) so that a client can initialize an instance of a doclet and pass that instance into the API.

2. If I understand the question correctly, the code is invoked by using the command-line option `-XDaccessInternalAPI` which is a preexisting hidden feature already supported by `javac`.  It is used in `TestTransformer.java` on line 161.

        javadoc("-d", base.resolve("api").toString(),
                "-Xdoclint:none",
                "-XDaccessInternalAPI", // required to access JavacTrees
                "-doclet", "TestTransformer$MyDoclet",
                "-docletpath", System.getProperty("test.classes"),
                "-sourcepath", src.toString(),
                "p");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1491504223
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1491502389

From jjg at openjdk.org  Thu Feb 15 19:25:05 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 15 Feb 2024 19:25:05 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v32]
In-Reply-To: <7hjkEusPyjQpzUGNArF4qKR_tSVyi3ekgkyX7gZ2LZw=.ad6b2cd6-f29b-4fca-b246-73572689180b@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <5f-y-x2KRcAGr501XkShj08p51vAl8wxD8l8PYFcQmI=.08ee889e-8abb-47e2-b3ba-49bb09ae600d@github.com>
 <7hjkEusPyjQpzUGNArF4qKR_tSVyi3ekgkyX7gZ2LZw=.ad6b2cd6-f29b-4fca-b246-73572689180b@github.com>
Message-ID: <2S7ZUtfa7Dnc0ttfGUEG4F0hZbj78o5U6h3Spi-qzR0=.53d767bc-faec-4bd8-a916-9364efcf5d28@github.com>

On Thu, 15 Feb 2024 17:03:09 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits:
>> 
>>  - fill in `visitRawText` in `CommentHelper.getTags` visitor
>>  - fixes for the "New API" page
>>  - change "standard" to "traditional" when referring to a comment
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - improve support for DocCommentParser.LineKind
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3 # Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the
>>    commit.
>>  - update copyright year on test
>>  - refactor recent new test case in TestMarkdown.java
>>  - address review feedback
>>  - ... and 34 more: https://git.openjdk.org/jdk/compare/8765b176...2801c2e1
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1401:
> 
>> 1399:      */
>> 1400:     enum LineKind {
>> 1401:         BLANK(Pattern.compile("[ \t]*")),
> 
> `BLANK` is a pseudo kind, because it is set manually, but never returned from `peekLine()`. I wonder if we can change it somehow.

Even if it is set manually, it is still appropriate to have it as a member in the `LineKind` enum class.

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1433:
> 
>> 1431:          * @see <a href="https://spec.commonmark.org/0.30/#list-items">List items</a>
>> 1432:          */
>> 1433:         BULLETED_LIST_ITEM(Pattern.compile("[-+*] .*")),
> 
> This comment is about `BULLETED_LIST_ITEM` and `ORDERED_LIST_ITEM` constants. I know that we don't need to be very precise, but perhaps in this case we should. While the CommonMark spec is a vague on that, from my experiments with [dingus](https://spec.commonmark.org/dingus/), it appears that a list marker can be preceded and followed by some number of whitespace characters.

whitespace is handled separately, on line 280 (`readIndent`) and285 (`: (indent <= 3) ? peekLineKind()`)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1491508303
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1491512611

From jjg at openjdk.org  Thu Feb 15 19:30:06 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 15 Feb 2024 19:30:06 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v32]
In-Reply-To: <7hjkEusPyjQpzUGNArF4qKR_tSVyi3ekgkyX7gZ2LZw=.ad6b2cd6-f29b-4fca-b246-73572689180b@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <5f-y-x2KRcAGr501XkShj08p51vAl8wxD8l8PYFcQmI=.08ee889e-8abb-47e2-b3ba-49bb09ae600d@github.com>
 <7hjkEusPyjQpzUGNArF4qKR_tSVyi3ekgkyX7gZ2LZw=.ad6b2cd6-f29b-4fca-b246-73572689180b@github.com>
Message-ID: <fWIF6Cid8DdR7xC7A7-CCs21YTSwt6LDII5XZ0mxfnM=.fa08a84e-24fe-4441-95ae-1568ec27ce5e@github.com>

On Thu, 15 Feb 2024 17:17:46 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits:
>> 
>>  - fill in `visitRawText` in `CommentHelper.getTags` visitor
>>  - fixes for the "New API" page
>>  - change "standard" to "traditional" when referring to a comment
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
>>  - improve support for DocCommentParser.LineKind
>>  - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3 # Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the
>>    commit.
>>  - update copyright year on test
>>  - refactor recent new test case in TestMarkdown.java
>>  - address review feedback
>>  - ... and 34 more: https://git.openjdk.org/jdk/compare/8765b176...2801c2e1
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 422:
> 
>> 420:                             defaultContentCharacter();
>> 421:                         }
>> 422:                     }
> 
> Is it to pass `` through to Markdown, to allow it to deal with Markdown escapes?

It is more about supporting the sequence `` ` `` so that the backtick is treated as a literal character and not the beginning of a code span.   This is the "backstop" preferred way to ensure that a single backtick is treated literally, without relying on detected that it is unbalanced when the end of the current block is reached.  The alternative workaround would be a single backtick enclosed in multiple backticks, such as this ``` `` ` `` ```. (I leave you to figure out what I actually typed there!!!)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1491519707

From jjg at openjdk.org  Thu Feb 15 19:35:44 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 15 Feb 2024 19:35:44 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v34]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <camkOJUbRfPCbUliYwMRzmXdrE4DAYIls3IpEl9FlEM=.6174333a-7172-41bd-a7c8-b6dd7c96f302@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with two additional commits since the last revision:

 - fix return tag name
 - remove debug print

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/f6d08db9..393d3a9c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=32-33

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

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

From jjg at openjdk.org  Thu Feb 15 19:35:44 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 15 Feb 2024 19:35:44 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v32]
In-Reply-To: <fWIF6Cid8DdR7xC7A7-CCs21YTSwt6LDII5XZ0mxfnM=.fa08a84e-24fe-4441-95ae-1568ec27ce5e@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <5f-y-x2KRcAGr501XkShj08p51vAl8wxD8l8PYFcQmI=.08ee889e-8abb-47e2-b3ba-49bb09ae600d@github.com>
 <7hjkEusPyjQpzUGNArF4qKR_tSVyi3ekgkyX7gZ2LZw=.ad6b2cd6-f29b-4fca-b246-73572689180b@github.com>
 <fWIF6Cid8DdR7xC7A7-CCs21YTSwt6LDII5XZ0mxfnM=.fa08a84e-24fe-4441-95ae-1568ec27ce5e@github.com>
Message-ID: <hWgzrX0mXRaqaRQl2drISdRMChmLivSG6jqW6kNlAAc=.3ddd7191-7386-4164-b14f-e6da398ac2fd@github.com>

On Thu, 15 Feb 2024 19:27:12 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 422:
>> 
>>> 420:                             defaultContentCharacter();
>>> 421:                         }
>>> 422:                     }
>> 
>> Is it to pass `` through to Markdown, to allow it to deal with Markdown escapes?
>
> It is more about supporting the sequence `` ` `` so that the backtick is treated as a literal character and not the beginning of a code span.   This is the "backstop" preferred way to ensure that a single backtick is treated literally, without relying on detected that it is unbalanced when the end of the current block is reached.  The alternative workaround would be a single backtick enclosed in multiple backticks, such as this ``` `` ` `` ```. (I leave you to figure out what I actually typed there!!!)

You might also need to use `` ` `` when there are two literal backticks in a sentence.

After the first backtick (`), another backtick (`) can be used to delimit a code span.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1491528153

From jjg at openjdk.org  Thu Feb 15 19:39:06 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 15 Feb 2024 19:39:06 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v31]
In-Reply-To: <g82TmBi3DkRmU2UGOnXqtNsUSowqEHZOWGZv7171xOE=.695378bb-1a9e-4931-9db0-a7d43395e8cd@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <Imc_x0a26ALH3KO5jdgjvvwqZ8SL7eC-cotk7AphhRI=.8fcfe332-53cd-4aa9-8ff7-fc2082b23ece@github.com>
 <revTaYUgM40q0U5bHloqsO56zzKGpaMVRdj_LLyHQrs=.047fe7ff-2f0e-4fad-b4b8-10bdee6b639c@github.com>
 <g82TmBi3DkRmU2UGOnXqtNsUSowqEHZOWGZv7171xOE=.695378bb-1a9e-4931-9db0-a7d43395e8cd@github.com>
Message-ID: <m-Qoz5S_VxMK8gRc8aqiyeEjFdwfABqK793vhq42BTU=.c1e136d4-1f27-488d-ab35-f0c65a31d81f@github.com>

On Thu, 15 Feb 2024 19:15:25 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java line 571:
>> 
>>> 569:         // of a doclet to be specified instead of the name of the
>>> 570:         // doclet class and optional doclet path.
>>> 571:         // See https://bugs.openjdk.org/browse/JDK-8263219
>> 
>> It's hard to understand this:
>> 
>>> to permit an instance of an appropriately configured instance of a doclet
>> 
>> Also: how is that piece of code used? When I commented it out, no test/langtools:langtools_javadoc tests failed.
>
> 1.  Since forever, and still true, the way to specify a doclet is by its name, and the tool will create the instance for you.  This goes back to the original old days before any API, when the only entry point was the command line.
> This implies that (a) the doclet has a no-args constructor and (b) that all doclet config is done through command line options.  A better solution would be to add new functionality to the various javadoc tool API (some or all of `Main`/`Start`/`DocumentationTool`) so that a client can initialize an instance of a doclet and pass that instance into the API.
> 
> 2. If I understand the question correctly, the code is invoked by using the command-line option `-XDaccessInternalAPI` which is a preexisting hidden feature already supported by `javac`.  It is used in `TestTransformer.java` on line 161.
> 
>         javadoc("-d", base.resolve("api").toString(),
>                 "-Xdoclint:none",
>                 "-XDaccessInternalAPI", // required to access JavacTrees
>                 "-doclet", "TestTransformer$MyDoclet",
>                 "-docletpath", System.getProperty("test.classes"),
>                 "-sourcepath", src.toString(),
>                 "p");

I confirm that `TestTransformer.java` fails as expected with an `IllegalAccessError` if the option is not used.

java.lang.IllegalAccessError: class TestTransformer$MyDoclet (in unnamed module @0x355de863) cannot access class com.sun.tools.javac.api.JavacTrees (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.api to unnamed module @0x355de863
        at TestTransformer$MyDoclet.run(TestTransformer.java:139)
        at jdk.javadoc/jdk.javadoc.internal.tool.Start.parseAndExecute(Start.java:589)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1491538120

From prappo at openjdk.org  Thu Feb 15 19:46:06 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 15 Feb 2024 19:46:06 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v32]
In-Reply-To: <2S7ZUtfa7Dnc0ttfGUEG4F0hZbj78o5U6h3Spi-qzR0=.53d767bc-faec-4bd8-a916-9364efcf5d28@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <5f-y-x2KRcAGr501XkShj08p51vAl8wxD8l8PYFcQmI=.08ee889e-8abb-47e2-b3ba-49bb09ae600d@github.com>
 <7hjkEusPyjQpzUGNArF4qKR_tSVyi3ekgkyX7gZ2LZw=.ad6b2cd6-f29b-4fca-b246-73572689180b@github.com>
 <2S7ZUtfa7Dnc0ttfGUEG4F0hZbj78o5U6h3Spi-qzR0=.53d767bc-faec-4bd8-a916-9364efcf5d28@github.com>
Message-ID: <72nE2l_N_wo2zHtS3wZSDyIYZJU2MqopYv422LDio74=.6c267f6f-0856-40b5-aff0-1288749ccd78@github.com>

On Thu, 15 Feb 2024 19:20:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1401:
>> 
>>> 1399:      */
>>> 1400:     enum LineKind {
>>> 1401:         BLANK(Pattern.compile("[ \t]*")),
>> 
>> `BLANK` is a pseudo kind, because it is set manually, but never returned from `peekLine()`. I wonder if we can change it somehow.
>
> Even if it is set manually, it is still appropriate to have it as a member in the `LineKind` enum class.

Not that it invalidates your reply; clarification: I meant `peekLineKind()`, not `peekLine()`.

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1433:
>> 
>>> 1431:          * @see <a href="https://spec.commonmark.org/0.30/#list-items">List items</a>
>>> 1432:          */
>>> 1433:         BULLETED_LIST_ITEM(Pattern.compile("[-+*] .*")),
>> 
>> This comment is about `BULLETED_LIST_ITEM` and `ORDERED_LIST_ITEM` constants. I know that we don't need to be very precise, but perhaps in this case we should. While the CommonMark spec is a vague on that, from my experiments with [dingus](https://spec.commonmark.org/dingus/), it appears that a list marker can be preceded and followed by some number of whitespace characters.
>
> whitespace is handled separately, on line 280 (`readIndent`) and285 (`: (indent <= 3) ? peekLineKind()`)

Correct, but I believe the ordered list marker should be like this:

    ORDERED_LIST_ITEM(Pattern.compile("[0-9]{1,9}[.)] .*"))
                                                     ^

Note extra whitespace character. I think we should really add this to our tests, since lists are foundational Markdown structures, probably right after italics and bold.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1491550784
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1491545609

From jjg at openjdk.org  Thu Feb 15 19:46:07 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 15 Feb 2024 19:46:07 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v32]
In-Reply-To: <72nE2l_N_wo2zHtS3wZSDyIYZJU2MqopYv422LDio74=.6c267f6f-0856-40b5-aff0-1288749ccd78@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <5f-y-x2KRcAGr501XkShj08p51vAl8wxD8l8PYFcQmI=.08ee889e-8abb-47e2-b3ba-49bb09ae600d@github.com>
 <7hjkEusPyjQpzUGNArF4qKR_tSVyi3ekgkyX7gZ2LZw=.ad6b2cd6-f29b-4fca-b246-73572689180b@github.com>
 <2S7ZUtfa7Dnc0ttfGUEG4F0hZbj78o5U6h3Spi-qzR0=.53d767bc-faec-4bd8-a916-9364efcf5d28@github.com>
 <72nE2l_N_wo2zHtS3wZSDyIYZJU2MqopYv422LDio74=.6c267f6f-0856-40b5-aff0-1288749ccd78@github.com>
Message-ID: <uuj70xG0D9dO9cq_NI_mjEthLOwDvp2VuuiBm5dBNrc=.3064c029-c577-4aa3-ad05-bcdbd9c93f98@github.com>

On Thu, 15 Feb 2024 19:39:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> whitespace is handled separately, on line 280 (`readIndent`) and285 (`: (indent <= 3) ? peekLineKind()`)
>
> Correct, but I believe the ordered list marker should be like this:
> 
>     ORDERED_LIST_ITEM(Pattern.compile("[0-9]{1,9}[.)] .*"))
>                                                      ^
> 
> Note extra whitespace character. I think we should really add this to our tests, since lists are foundational Markdown structures, probably right after italics and bold.

My recollection is that the space is required.   I will double check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1491552312

From jjg at openjdk.org  Thu Feb 15 19:46:07 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 15 Feb 2024 19:46:07 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v31]
In-Reply-To: <m-Qoz5S_VxMK8gRc8aqiyeEjFdwfABqK793vhq42BTU=.c1e136d4-1f27-488d-ab35-f0c65a31d81f@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <Imc_x0a26ALH3KO5jdgjvvwqZ8SL7eC-cotk7AphhRI=.8fcfe332-53cd-4aa9-8ff7-fc2082b23ece@github.com>
 <revTaYUgM40q0U5bHloqsO56zzKGpaMVRdj_LLyHQrs=.047fe7ff-2f0e-4fad-b4b8-10bdee6b639c@github.com>
 <g82TmBi3DkRmU2UGOnXqtNsUSowqEHZOWGZv7171xOE=.695378bb-1a9e-4931-9db0-a7d43395e8cd@github.com>
 <m-Qoz5S_VxMK8gRc8aqiyeEjFdwfABqK793vhq42BTU=.c1e136d4-1f27-488d-ab35-f0c65a31d81f@github.com>
Message-ID: <Zj9a1owB2ySz0xwJYGhBw1BMHww1lc7movAdCG2p360=.fbdd3315-063a-41a6-9369-28df1139eb13@github.com>

On Thu, 15 Feb 2024 19:36:36 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> 1.  Since forever, and still true, the way to specify a doclet is by its name, and the tool will create the instance for you.  This goes back to the original old days before any API, when the only entry point was the command line.
>> This implies that (a) the doclet has a no-args constructor and (b) that all doclet config is done through command line options.  A better solution would be to add new functionality to the various javadoc tool API (some or all of `Main`/`Start`/`DocumentationTool`) so that a client can initialize an instance of a doclet and pass that instance into the API.
>> 
>> 2. If I understand the question correctly, the code is invoked by using the command-line option `-XDaccessInternalAPI` which is a preexisting hidden feature already supported by `javac`.  It is used in `TestTransformer.java` on line 161.
>> 
>>         javadoc("-d", base.resolve("api").toString(),
>>                 "-Xdoclint:none",
>>                 "-XDaccessInternalAPI", // required to access JavacTrees
>>                 "-doclet", "TestTransformer$MyDoclet",
>>                 "-docletpath", System.getProperty("test.classes"),
>>                 "-sourcepath", src.toString(),
>>                 "p");
>
> I confirm that `TestTransformer.java` fails as expected with an `IllegalAccessError` if the option is not used.
> 
> java.lang.IllegalAccessError: class TestTransformer$MyDoclet (in unnamed module @0x355de863) cannot access class com.sun.tools.javac.api.JavacTrees (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.api to unnamed module @0x355de863
>         at TestTransformer$MyDoclet.run(TestTransformer.java:139)
>         at jdk.javadoc/jdk.javadoc.internal.tool.Start.parseAndExecute(Start.java:589)

Generally, the error occurs because the `MyDoclet` class is run in a different class loader than that used for the test.  The class loader for the test already has the necessary access permissions given, from the lines in `@modules` in the `jtreg` test description.  Ideally, we could call `new MyDoclet()` in the main test code, and pas the instance in to the `javadoc` call and from there to the javadoc `Start` method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1491547571

From prappo at openjdk.org  Thu Feb 15 19:55:06 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 15 Feb 2024 19:55:06 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v32]
In-Reply-To: <72nE2l_N_wo2zHtS3wZSDyIYZJU2MqopYv422LDio74=.6c267f6f-0856-40b5-aff0-1288749ccd78@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <5f-y-x2KRcAGr501XkShj08p51vAl8wxD8l8PYFcQmI=.08ee889e-8abb-47e2-b3ba-49bb09ae600d@github.com>
 <7hjkEusPyjQpzUGNArF4qKR_tSVyi3ekgkyX7gZ2LZw=.ad6b2cd6-f29b-4fca-b246-73572689180b@github.com>
 <2S7ZUtfa7Dnc0ttfGUEG4F0hZbj78o5U6h3Spi-qzR0=.53d767bc-faec-4bd8-a916-9364efcf5d28@github.com>
 <72nE2l_N_wo2zHtS3wZSDyIYZJU2MqopYv422LDio74=.6c267f6f-0856-40b5-aff0-1288749ccd78@github.com>
Message-ID: <Dg6jpPfJIfk5w2u2OvsE_HjJ5CQJO3helJS3g7svLuQ=.c3547e7d-34c7-4f92-ba86-ef1207364fc6@github.com>

On Thu, 15 Feb 2024 19:39:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> whitespace is handled separately, on line 280 (`readIndent`) and285 (`: (indent <= 3) ? peekLineKind()`)
>
> Correct, but I believe the ordered list marker should be like this:
> 
>     ORDERED_LIST_ITEM(Pattern.compile("[0-9]{1,9}[.)] .*"))
>                                                      ^
> 
> Note extra whitespace character. I think we should really add this to our tests, since lists are foundational Markdown structures, probably right after italics and bold.

Then we should add `[ \t]` to both constants, right:

    BULLETED_LIST_ITEM(Pattern.compile("[-+*][ \t].*"))
    ORDERED_LIST_ITEM(Pattern.compile("[0-9]{1,9}[.)][ \t].*"))

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1491564839

From jianglizhou at google.com  Thu Feb 15 20:01:00 2024
From: jianglizhou at google.com (Jiangli Zhou)
Date: Thu, 15 Feb 2024 12:01:00 -0800
Subject: Questions about the Hermetic Java project
In-Reply-To: <CALrW1jzdU4QD0mHc4-vTTL46VNzXLbmASdnmoY5qfa7wS8=s7Q@mail.gmail.com>
References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com>
 <CALrW1jzdU4QD0mHc4-vTTL46VNzXLbmASdnmoY5qfa7wS8=s7Q@mail.gmail.com>
Message-ID: <CALrW1jwoT-uDwcoYhmE5QY5w_a9EcsqpRr==q4AEFxJiR7QXBQ@mail.gmail.com>

On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou <jianglizhou at google.com> wrote:
>
> Hi Magnus,
>
> Thanks for looking into this from the build perspective.
>
> On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com> wrote:
> >
> > First some background for build-dev: I have spent some time looking at
> > the build implications of the Hermetic Java effort, which is part of
> > Project Leyden. A high-level overview is available here:
> > https://cr.openjdk.org/~jiangli/hermetic_java.pdf and the current source
> > code is here: https://github.com/openjdk/leyden/tree/hermetic-java-runtime.
>
> Some additional hermetic Java related references that are also useful:
>
> - https://bugs.openjdk.org/browse/JDK-8303796 is an umbrella bug that
> links to the issues for resolving static linking issues so far
> - https://github.com/openjdk/jdk21/pull/26 is the enhancement for
> building the complete set of static libraries in JDK/VM, particularly
> including libjvm.a
>
> >
> > Hermetic Java faces several challenges, but the part that is relevant
> > for the build system is the ability to create static libraries. We've
> > had this functionality (in three different ways...) for some time, but
> > it is rather badly implemented.
> >
> > As a result of my investigations, I have a bunch of questions. :-) I
> > have gotten some answers in private discussion, but for the sake of
> > transparency I will repeat them here, to foster an open dialogue.
> >
> > 1. Am I correct in understanding that the ultimate goal of this exercise
> > is to be able to have jmods which include static libraries (*.a) of the
> > native code which the module uses, and that the user can then run a
> > special jlink command to have this linked into a single executable
> > binary (which also bundles the *.class files and any additional
> > resources needed)?
> >
> > 2. If so, is the idea to create special kinds of static jmods, like
> > java.base-static.jmod, that contains *.a files instead of lib*.so files?
> > Or is the idea that the normal jmod should contain both?
> >
> > 3. Linking .o and .a files into an executable is a formidable task. Is
> > the intention to have jlink call a system-provided ld, or to bundle ld
> > with jlink, or to reimplement this functionality in Java?
>
> I have a similar view as Alan responded in your other email thread.
> Things are still in the early stage for the general solution.
>
> In the https://github.com/openjdk/leyden/tree/hermetic-java-runtime
> branch, when configuring JDK with --with-static-java=yes, the JDK
> binary contains the following extra artifacts:
>
> - static-libs/*.a: The complete set of JDK/VM static libraries
> - jdk/bin/javastatic: A demo Java launcher fully statically linked
> with the selected JDK .a libraries (e.g. it currently statically link
> with the headless) and libjvm.a. It's the standard Java launcher
> without additional work for hermetic Java.
>
> In our prototype for hermetic Java, we build the hermetic executable
> image (a single image) from the following input (see description on
> singlejar packaging tool in
> https://cr.openjdk.org/~jiangli/hermetic_java.pdf):
>
> - A customized launcher (with additional work for hermetic) executable
> fully statically linked with JDK/VM static libraries (.a files),
> application natives and dependencies (e.g. in .a static libraries)
> - JDK lib/modules, JDK resource files
> - Application classes and resource files
>
> Including a JDK library .a into the corresponding .jmod would require
> extracting the .a for linking with the executable. In some systems
> that may cause memory overhead due to the extracted copy of the .a
> files. I think we should consider the memory overhead issue.
>
> One possibility (as Alan described in his response) is for jlink to
> invoke the ld on the build system. jlink could pass the needed JDK
> static libraries and libjvm.a (provided as part of the JDK binary) to
> ld based on the modules required for the application.
>

I gave a bit more thoughts on this one. For jlink to trigger ld, it
would need to know the complete linker options and inputs. Those
include options and inputs related to the application part as well. In
some usages, it might be easier to handle native linking separately
and pass the linker output, the executable to jlink directly. Maybe we
could consider supporting different modes for various usages
requirements, from static libraries and native linking point of view:

Mode #1
Support .jmod packaged natives static libraries, for both JDK/VM .a
and application natives and dependencies. If the inputs to jlink
include .jmods, jlink can extract the .a libraries and pass the
information to ld to link the executable.

Mode #2
Support separate .a as jlink input. Jlink could pass the path
information to the .a libraries and other linker options to ld to
create the executable.

For both mode #1 and #2, jlink would then use the linker output
executable to create the final hermetic image.

Mode #3
Support a fully linked executable as a jlink input. When a linked
executable is given to jlink, it can process it directly with other
JDK data/files to create the final image, without native linking step.

Any other thoughts and considerations?

Best,
Jiangli

> >
> > 4. Is the intention is to allow users to create their own jmods with
> > static libraries, and have these linked in as well? This seems to be the
> > case.
>
> An alternative with less memory overhead could be using application
> modular JAR and separate .a as the input for jlink.
>
> > If that is so, then there will always be the risk for name
> > collisions, and we can only minimize the risk by making sure any global
> > names are as unique as possible.
>
> Part of the current effort includes resolving the discovered symbol
> collision issues with static linking. Will respond to your other email
> on the symbol issue separately later.
>
> >
> > 5. The original implementation of static builds in the JDK, created for
> > the Mobile project, used a configure flag, --enable-static-builds, to
> > change the entire behavior of the build system to only produce *.a files
> > instead of lib*.so. In contrast, the current system is using a special
> > target instead.
>
> I think we would need both configure flag and special target for the
> static builds.
>
> > In my eyes, this is a much worse solution. Apart from
> > the conceptual principle (if the build should generate static or dynamic
> > libraries is definitely a property of what a "configuration" means),
> > this makes it much harder to implement efficiently, since we cannot make
> > changes in NativeCompilation.gmk, where they are needed.
>
> For the potential objcopy work to resolve symbol issues, we can add
> that conditionally in NativeCompilation.gmk if STATIC_LIBS is true. We
> have an internal prototype (not included in
> https://github.com/openjdk/leyden/tree/hermetic-java-runtime yet) done
> by one of colleagues for localizing symbols in libfreetype using
> objcopy.
>
> >
> > That was not as much a question as a statement. ? But here is the
> > question: Do you think it would be reasonable to restore the old
> > behavior but with the new methods, so that we don't use special targets,
> > but instead tells configure to generate static libraries? I'm thinking
> > we should have a flag like "--with-library-type=" that can have values
> > "dynamic" (which is default), "static" or "both".
>
> If we want to also build a fully statically linked launcher, maybe
> --with-static-java? Being able to configure either dynamic, static or
> both as you suggested also seems to be a good idea.
>
> > I am not sure if "both" are needed, but if we want to bundle both lib*.so and *.a files
> > into a single jmod file (see question 2 above), then it definitely is.
> > In general, the cost of producing two kinds of libraries are quite
> > small, compared to the cost of compiling the source code to object files.
>
> Completely agree. It would be good to avoid recompiling the .o file
> for static and dynamic builds. As proposed in
> https://bugs.openjdk.org/browse/JDK-8303796:
>
> It's beneficial to be able to build both .so and .a from the same set
> of .o files. That would involve some changes to handle the dynamic JDK
> and static JDK difference at runtime, instead of relying on the
> STATIC_BUILD macro.
>
> >
> > Finally, I have looked at how to manipulate symbol visibility. There
> > seems many ways forward, so I feel confident that we can find a good
> > solution.
> >
> > One way forward is to use objcopy to manipulate symbol status
> > (global/local). There is an option --localize-symbol in objcopy, that
> > has been available in objcopy since at least 2.15, which was released
> > 2004, so it should be safe to use. But ideally we should avoid using
> > objcopy and do this as part of the linking process. This should be
> > possible to do, given that we make changes in NativeCompilation.gmk --
> > see question 5 above.
> >
> > As a fallback, it is also possible to rename symbols, either piecewise
> > or wholesale, using objcopy. There are many ways to do this, using
> > --prefix-symbols, --redefine-sym or --redefine-syms (note the -s, this
> > takes a file with a list of symbols). Thus we can always introduce a
> > "post factum namespace" by renaming symbols.
>
> Renaming or redefining the symbol at build time could cause confusions
> with debugging. That's a concern raised in
> https://github.com/openjdk/jdk/pull/17456 discussions.
>
> Additionally, redefining symbols using tools like objcopy may not
> handle member names referenced in string literals. For example, in
> https://github.com/openjdk/jdk/pull/17456 additional changes are
> needed in assembling and SA to reflect the symbol change.
>
> >
> > So in the end, I think it will be fully possible to produce .a files
> > that only has global symbols for the functions that are part of the API
> > exposed by that library, and have all other symbols local, and make this
> > is in a way that is consistent with the rest of the build system.
> >
> > Finally, a note on Hotspot. Due to debugging reasons, we export
> > basically all symbols in hotspot as global. This is not reasonable to do
> > for a static build. The effect of not exporting those symbols will be
> > that SA will not function to 100%. On the other hand, I have no idea if
> > SA works at all with a static build. Have you tested this? Is this part
> > of the plan to support, or will it be officially dropped for Hermetic Java?
>
> We have done some testing with jtreg SA related tests for the fully
> statically linked `javastatic`.
>
> If we use objcopy to localize symbols in hotspot, it's not yet clear
> what's the impact on SA. We could do some tests. The other question
> that I raised is the supported gcc versions (for partial linking)
> related to the solution.
>
> Best,
> Jiangli
>
> >
> > /Magnus
> >

From jjg at openjdk.org  Thu Feb 15 21:20:21 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 15 Feb 2024 21:20:21 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v35]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <5a4XLWHSLG_xQeQDr0Ibz4Rl31m8phZCZl5UAdhukF8=.0a0d8cdd-2a13-4b27-8f4b-3cbcab241899@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with three additional commits since the last revision:

 - fix handling of `@' in a Markdown comment
 - improve comments for some LineKind members
 - update LineKind members and test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/393d3a9c..da8752c8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=33-34

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

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

From prr at openjdk.org  Thu Feb 15 22:40:56 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 15 Feb 2024 22:40:56 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
Message-ID: <lmqQHpQrlQkG9kFB3GhPa0530wpWgAWXrVjKeKLrezM=.8050c3cd-2143-439e-ad8d-c3b27e82e59a@github.com>

On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
> 
> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

desktop changes look fine to me.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17871#pullrequestreview-1884009342

From jianglizhou at google.com  Fri Feb 16 00:37:48 2024
From: jianglizhou at google.com (Jiangli Zhou)
Date: Thu, 15 Feb 2024 16:37:48 -0800
Subject: Hotspot symbol visibility
In-Reply-To: <645132e0-687e-4f04-9e49-f90131294367@oracle.com>
References: <645132e0-687e-4f04-9e49-f90131294367@oracle.com>
Message-ID: <CALrW1jzhh1ENV+nOno-d73Qj3xVCb6=B5WDN-6AH29rraA0V5g@mail.gmail.com>

Hi Magnus,

For hotspot symbols that need to be exported, when statically linking
the launcher executable using libjvm.a, we use lld's
`-Wl,--export-dynamic-symbol-list=` option. Those exported symbols can
be used outside the VM code, e.g. in agent. Our friend(s) in c++
compiler/toolchain added the support for --export-dynamic-symbol-list,
https://reviews.llvm.org/D107317. -Wl,--dynamic-list with gcc provides
similar support.

Best,
Jiangli

On Wed, Feb 14, 2024 at 2:06?AM Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> wrote:
>
> I am currently pursuing improved build functionality for static
> libraries. One of the issues with static libraries are name collisions,
> which led me back to an old discussion about which symbols are exported
> from Hotspot, and how this is achieved. A long discussion is available
> in JDK-8017234 [1], which was created in 2013 and has been on the back
> burner ever since, coming back to life every now and then.
>
> There are basically two different problems here. They are both distinct
> and interrelated, and we likely need to solve both in tandem.
>
> The first problem is how Hotspot should say which symbols (functions)
> that should be exported from libjvm.so. The historical, and still used,
> system is to have a mapfile. In the "new" (not so new anymore) build
> system, this was simplified to a list of function names in
> make/data/hotspot-symbols, from which a mapfile is built.
>
> This is in contrast with how all other libraries in the JDK are built,
> and also with modern best practices. A better approach would be to
> annotate the functions that should be exported in the source code. In
> fact, such annotation already exists, even in Hotspot, as JNIEXPORT, but
> this is currently not used in the compilation of Hotspot.
>
> The second problem is that in addition to these explicitly exported
> functions, we also export basically all other functions as well in
> Hotspot. (So currently we could basically just forgo this complicated
> machinery and just export everything by default...)
>
> The reason for this seem somewhat unclear. The specifics are probably
> forever lost in the mists of time past, but the essential point is that
> these symbols are needed for SA to do it's job.
>
> So what we do is that we list all symbols in hotspot after compiling
> (but before linking), and selects some (most, I think) of them using
> regexp patterns, and add these to the mapfile.
>
> As long as we're doing this, we cannot stop using a mapfile, and we're
> stuck from progressing on point 1.
>
> My takeaway from the discussions is that we are most likely exporting a
> way too broad set of symbols to SA. It seems likely that this set can be
> drastically cut down. Actually getting an understanding of exactly which
> symbols SA need seem like a very good first step.
>
> So, is this a journey anyone would be interested in embarkering on? I
> will help as much as I can from a build PoV, but I have no clue
> whatsoever about what SA needs.
>
> /Magnus
>
> [1] https://bugs.openjdk.org/browse/JDK-8017234
>

From jjg at openjdk.org  Fri Feb 16 00:46:34 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 16 Feb 2024 00:46:34 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v36]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <u2J4zt4oo-GbgV2u6DYkdV3IlyeO-NxpbIzy6bGcX14=.c0bd758d-66f7-40cd-b046-4ef496cc9118@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with two additional commits since the last revision:

 - Support for Table Of Contents in Markdown headings
 - fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/da8752c8..53afd804

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=35
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=34-35

  Stats: 102 lines in 2 files changed: 99 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388

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

From wetmore at openjdk.org  Fri Feb 16 01:44:57 2024
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 16 Feb 2024 01:44:57 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
Message-ID: <AG07BfABTTmZaZhAd9jHgMMgcaGRtP_31MVSJg8LUYo=.e9355b50-d5d1-4551-a161-15712bf6b1e8@github.com>

On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
> 
> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

security properties looks ok.

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

Marked as reviewed by wetmore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17871#pullrequestreview-1884183930

From kbarrett at openjdk.org  Fri Feb 16 04:48:52 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 16 Feb 2024 04:48:52 GMT
Subject: RFR: 8325878: Require minimum Clang version 13
In-Reply-To: <-yAR2iW4MtSKz0hO93nAa4YJWurcpIe0zLctEf-01a4=.ffe8876b-5692-47da-afdf-32170818945b@github.com>
References: <zSj7alqhcE-_CnzPzWSc9bIKCZtTew_WaSTIkx5qHhQ=.ca1dc065-38d1-4b33-9ae5-e1a86d47c53a@github.com>
 <-yAR2iW4MtSKz0hO93nAa4YJWurcpIe0zLctEf-01a4=.ffe8876b-5692-47da-afdf-32170818945b@github.com>
Message-ID: <bsoXq0-hVAF8S8GUg39e87DxVPSB3ZX083MVUU4hLBg=.62ced729-0620-466a-a6e4-547ddf6ac6d4@github.com>

On Thu, 15 Feb 2024 12:45:45 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Unfortunately this will break my workflow on Linux - I use clang to build on Ubuntu 20.04, which is not that old, but it ships with clang 12. This is not a deal breaker, just annoying.

That's unfortunate, but I think the [[noreturn]] issue is very important.  Until we have that fix, we can't rely on that
attribute to silence certain warnings.  This requires us to continue to insert dead returns or apply other workarounds.
And forgetting to do so (because someone makes a change that works fine with later versions or on other platforms)
will lead to build-breakage JBS issues/PRs just to continue to support older versions of clang.  We've already had
several of those.

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

PR Comment: https://git.openjdk.org/jdk/pull/17862#issuecomment-1947750667

From stuefe at openjdk.org  Fri Feb 16 05:23:54 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 16 Feb 2024 05:23:54 GMT
Subject: RFR: 8325878: Require minimum Clang version 13
In-Reply-To: <bsoXq0-hVAF8S8GUg39e87DxVPSB3ZX083MVUU4hLBg=.62ced729-0620-466a-a6e4-547ddf6ac6d4@github.com>
References: <zSj7alqhcE-_CnzPzWSc9bIKCZtTew_WaSTIkx5qHhQ=.ca1dc065-38d1-4b33-9ae5-e1a86d47c53a@github.com>
 <-yAR2iW4MtSKz0hO93nAa4YJWurcpIe0zLctEf-01a4=.ffe8876b-5692-47da-afdf-32170818945b@github.com>
 <bsoXq0-hVAF8S8GUg39e87DxVPSB3ZX083MVUU4hLBg=.62ced729-0620-466a-a6e4-547ddf6ac6d4@github.com>
Message-ID: <SOwLSPstPKgyujBv7qK5GmdCGmVJG6xIggSjzb_PDOg=.483887f1-555c-4ce0-b8b0-06f5da453cf3@github.com>

On Fri, 16 Feb 2024 04:46:24 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > Unfortunately this will break my workflow on Linux - I use clang to build on Ubuntu 20.04, which is not that old, but it ships with clang 12. This is not a deal breaker, just annoying.
> 
> That's unfortunate, but I think the [[noreturn]] issue is very important. Until we have that fix, we can't rely on that attribute to silence certain warnings. This requires us to continue to insert dead returns or apply other workarounds. And forgetting to do so (because someone makes a change that works fine with later versions or on other platforms) will lead to build-breakage JBS issues/PRs just to continue to support older versions of clang. We've already had several of those.

Thank you for explaining the motivation. @forax also mentioned that our workaround produces false warnings in IDEs (just checked in CDT). I'm fine with it - I will find another solution for my Linux box.

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

PR Comment: https://git.openjdk.org/jdk/pull/17862#issuecomment-1947776707

From hannesw at openjdk.org  Fri Feb 16 07:45:06 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 16 Feb 2024 07:45:06 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v36]
In-Reply-To: <u2J4zt4oo-GbgV2u6DYkdV3IlyeO-NxpbIzy6bGcX14=.c0bd758d-66f7-40cd-b046-4ef496cc9118@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <u2J4zt4oo-GbgV2u6DYkdV3IlyeO-NxpbIzy6bGcX14=.c0bd758d-66f7-40cd-b046-4ef496cc9118@github.com>
Message-ID: <1hRkg0waT73IaCbhd7h-0bEgG5JirfxttEMjcY9EYM0=.827a07c5-d256-4b8e-9a3a-266506725f26@github.com>

On Fri, 16 Feb 2024 00:46:34 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Support for Table Of Contents in Markdown headings
>  - fix typo

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 286:

> 284:                         lineKind = (ch == '\n' || ch == '\r') ? LineKind.BLANK
> 285:                                 : (indent <= 3) ? peekLineKind()
> 286:                                 : lineKind != LineKind.OTHER ? LineKind.INDENTED_CODE_BLOCK

Doesn't this cause false positives for indented code blocks? In my understanding, indented lines in a list context and directly following a blockquote are not interpreted as code blocks, but as part of the list or blockquote. So my guess would be that `not OTHER` should be something like `BLANK or INDENTED_CODE_BLOCK or HEADER`, and that still leaves the problem of a [blank line in a list context](https://spec.commonmark.org/0.30/#example-108).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1492065799

From aph at openjdk.org  Fri Feb 16 08:37:58 2024
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 16 Feb 2024 08:37:58 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <F7MGxuI0CLaL28Y7s7KhRW_NmgsCOnJLs5wnUlXjGk8=.f44adba9-e08c-4093-a13e-dd2851e94e97@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
 <i3bo22m6I5cYhAMfktX-W_4-rrtyK6EPyK57QUi6Tco=.a18ddecb-440b-4c70-95ec-4b21fd1b3144@github.com>
 <KCC78U2X_if2XTRu1qNkeVXSQ672EyZFHbkl-OtP3U8=.9695b185-dc76-4d26-ae32-ceb254f5f275@github.com>
 <yq-FT47x7QF7L78fMxw3VvYAo_osUWzeUzxb5iJU3hE=.1899b72a-41f7-44b7-946f-84ca1339f1f8@github.com>
 <F7MGxuI0CLaL28Y7s7KhRW_NmgsCOnJLs5wnUlXjGk8=.f44adba9-e08c-4093-a13e-dd2851e94e97@github.com>
Message-ID: <NGRHe9BoTv7UWiYiu-kOQXbkFH7DbcS24syQFhhS3ag=.064ffdb5-10a6-4302-8b4a-e94c98bed0a3@github.com>

On Thu, 15 Feb 2024 17:11:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > Sure, you can always install a newer GCC than the system one, but it's another thing that makes it harder for people to build OpenJDK. Having said that, C++17 is nice to have.
> 
> @theRealAph I am still just hearing hand-waving "perhaps someone somewhere will have a somewhat harder time building the JDK". 

I'm going to ignore that rather insulting language.

> Yes, perhaps that is so. But that is very uncertain, and I have still not heard a single concrete example of where this would apply. In contrast, going to gcc 10 will clearly bring a benefit to all other platforms, since it allows us to synchronize the code base at C++17.

Well, hold on. You're implying that going to C++17 allows us to synchronize the code base at C++17. Sure, it does, but it's important also to discuss the pitfalls. And one of those pitfalls is that the system I'm typing this message on ? still in support ? won't be able to build the JDK without my first finding or building gcc 10 for it.

> In light of this, I think we need to hear some really compelling evidence of problems that would ensue if we raise the minimum to gcc 10. If nobody can produce such evidence, then to me it is a sign that this fear is not well-grounded, and we should proceed with this PR.

As the proposer of this change, the onus is on you to show the benefit. Certainly there are C++17 advantages, such as hex float constants. better templates, and so on. I guess the discussion of such advantages must have taken place elsewhere because it's not on the https://bugs.openjdk.org/browse/JDK-8314488 either.

To be clear: I do not object to this PR. I would like to use C++17.

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1947960141

From thomas.stuefe at gmail.com  Fri Feb 16 08:49:15 2024
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 16 Feb 2024 09:49:15 +0100
Subject: Hotspot symbol visibility
In-Reply-To: <645132e0-687e-4f04-9e49-f90131294367@oracle.com>
References: <645132e0-687e-4f04-9e49-f90131294367@oracle.com>
Message-ID: <CAA-vtUy-VjCXmtUN6evZic9wRV7VHXzS-M6U+Jjqsy4zJkqx+A@mail.gmail.com>

I cannot contribute much to the discussion, but I think this is a valuable
effort. These broad exports from hotspot have always bemused me.

It is probably safe to hide C++ mangled symbols since those decorations are
compiler-specific anyway, no? So they cannot have worked in a reliable
fashion?

On Wed, Feb 14, 2024 at 11:06?AM Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> I am currently pursuing improved build functionality for static
> libraries. One of the issues with static libraries are name collisions,
> which led me back to an old discussion about which symbols are exported
> from Hotspot, and how this is achieved. A long discussion is available
> in JDK-8017234 [1], which was created in 2013 and has been on the back
> burner ever since, coming back to life every now and then.
>
> There are basically two different problems here. They are both distinct
> and interrelated, and we likely need to solve both in tandem.
>
> The first problem is how Hotspot should say which symbols (functions)
> that should be exported from libjvm.so. The historical, and still used,
> system is to have a mapfile. In the "new" (not so new anymore) build
> system, this was simplified to a list of function names in
> make/data/hotspot-symbols, from which a mapfile is built.
>
> This is in contrast with how all other libraries in the JDK are built,
> and also with modern best practices. A better approach would be to
> annotate the functions that should be exported in the source code. In
> fact, such annotation already exists, even in Hotspot, as JNIEXPORT, but
> this is currently not used in the compilation of Hotspot.
>
> The second problem is that in addition to these explicitly exported
> functions, we also export basically all other functions as well in
> Hotspot. (So currently we could basically just forgo this complicated
> machinery and just export everything by default...)
>
> The reason for this seem somewhat unclear. The specifics are probably
> forever lost in the mists of time past, but the essential point is that
> these symbols are needed for SA to do it's job.
>
> So what we do is that we list all symbols in hotspot after compiling
> (but before linking), and selects some (most, I think) of them using
> regexp patterns, and add these to the mapfile.
>
> As long as we're doing this, we cannot stop using a mapfile, and we're
> stuck from progressing on point 1.
>
> My takeaway from the discussions is that we are most likely exporting a
> way too broad set of symbols to SA. It seems likely that this set can be
> drastically cut down. Actually getting an understanding of exactly which
> symbols SA need seem like a very good first step.
>
> So, is this a journey anyone would be interested in embarkering on? I
> will help as much as I can from a build PoV, but I have no clue
> whatsoever about what SA needs.
>
> /Magnus
>
> [1] https://bugs.openjdk.org/browse/JDK-8017234
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240216/6dd7e581/attachment.htm>

From aph at openjdk.org  Fri Feb 16 08:55:57 2024
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 16 Feb 2024 08:55:57 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <NGRHe9BoTv7UWiYiu-kOQXbkFH7DbcS24syQFhhS3ag=.064ffdb5-10a6-4302-8b4a-e94c98bed0a3@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
 <i3bo22m6I5cYhAMfktX-W_4-rrtyK6EPyK57QUi6Tco=.a18ddecb-440b-4c70-95ec-4b21fd1b3144@github.com>
 <KCC78U2X_if2XTRu1qNkeVXSQ672EyZFHbkl-OtP3U8=.9695b185-dc76-4d26-ae32-ceb254f5f275@github.com>
 <yq-FT47x7QF7L78fMxw3VvYAo_osUWzeUzxb5iJU3hE=.1899b72a-41f7-44b7-946f-84ca1339f1f8@github.com>
 <F7MGxuI0CLaL28Y7s7KhRW_NmgsCOnJLs5wnUlXjGk8=.f44adba9-e08c-4093-a13e-dd2851e94e97@github.com>
 <NGRHe9BoTv7UWiYiu-kOQXbkFH7DbcS24syQFhhS3ag=.064ffdb5-10a6-4302-8b4a-e94c98bed0a3@github.com>
Message-ID: <8W894WyNpek1tnlmVtRrGC8ZU3DXKzrPaDS24sQRwVM=.6dc95a73-6e0c-4cbd-b754-06d6ef3c1b34@github.com>

On Fri, 16 Feb 2024 08:35:29 GMT, Andrew Haley <aph at openjdk.org> wrote:

> 
> To be clear: I do not object to this PR. I would like to use C++17.

Maybe the advantages of C++17 have been discussed elsewhere, in which case all we need is a link to that discussion on the Bug page. Maybe it's just that we like to stay current, in which case all we need to do is say so on the Bug page.

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1947984619

From aph-open at littlepinkcloud.com  Fri Feb 16 09:06:39 2024
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Fri, 16 Feb 2024 09:06:39 +0000
Subject: Hotspot symbol visibility
In-Reply-To: <CAA-vtUy-VjCXmtUN6evZic9wRV7VHXzS-M6U+Jjqsy4zJkqx+A@mail.gmail.com>
References: <645132e0-687e-4f04-9e49-f90131294367@oracle.com>
 <CAA-vtUy-VjCXmtUN6evZic9wRV7VHXzS-M6U+Jjqsy4zJkqx+A@mail.gmail.com>
Message-ID: <05054cf8-7430-43aa-b101-cbf8725304a7@littlepinkcloud.com>

On 2/16/24 08:49, Thomas St?fe wrote:
> It is probably safe to hide C++ mangled symbols since those decorations are compiler-specific anyway, no? So they cannot have worked in a reliable fashion
They're not entirely compiler specific, but part of the ABI. See
https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling. But
that the extensive use of inlining in compiler headers means that
even a minor change affects binary compatibility.


From thomas.stuefe at gmail.com  Fri Feb 16 09:13:15 2024
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 16 Feb 2024 10:13:15 +0100
Subject: Hotspot symbol visibility
In-Reply-To: <05054cf8-7430-43aa-b101-cbf8725304a7@littlepinkcloud.com>
References: <645132e0-687e-4f04-9e49-f90131294367@oracle.com>
 <CAA-vtUy-VjCXmtUN6evZic9wRV7VHXzS-M6U+Jjqsy4zJkqx+A@mail.gmail.com>
 <05054cf8-7430-43aa-b101-cbf8725304a7@littlepinkcloud.com>
Message-ID: <CAA-vtUxuzpfePjDqkW-iH+0vbh25a2O0-0=uVqhb=Q_nvaMjuw@mail.gmail.com>

On Fri, Feb 16, 2024 at 10:06?AM Andrew Haley <aph-open at littlepinkcloud.com>
wrote:

> On 2/16/24 08:49, Thomas St?fe wrote:
> > It is probably safe to hide C++ mangled symbols since those decorations
> are compiler-specific anyway, no? So they cannot have worked in a reliable
> fashion
> They're not entirely compiler specific, but part of the ABI. See
> https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling.
>

Ah, thanks for the correction. That explains why we have different mangling
between Windows and the rest.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240216/ecbbb0aa/attachment.htm>

From ihse at openjdk.org  Fri Feb 16 12:35:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 16 Feb 2024 12:35:53 GMT
Subject: RFR: 8325972: Add -x to bash for building with LOG=debug
In-Reply-To: <UIGPgQR2VRlTTSVoNqyaA1TGdWs2FSB_1aYRb07sXZE=.3bbc1bb2-4542-4b2c-aeff-920f0693ec62@github.com>
References: <UIGPgQR2VRlTTSVoNqyaA1TGdWs2FSB_1aYRb07sXZE=.3bbc1bb2-4542-4b2c-aeff-920f0693ec62@github.com>
Message-ID: <p69KQB-gtCmILACgLpELtHY4zxVqRpNdfKfigWNCcXg=.e011afbd-61dc-4a41-a6b1-9e2bcca29ef4@github.com>

On Thu, 15 Feb 2024 15:07:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I don't understand why I have never thought of this before. If we add `-x` to the set of bash arguments when running with LOG=debug, we get output of *all* shell commands that make is running, even those for $(shell).
> 
> This makes it soooo much easier to understand what is actually happening in the makefile! (To the point where we could actually consider moving other stuff away from the debug level.)

I'm not sure, but I don't think so. Even if we get duplicate output, this way we can understand where things are coming from. I also think there is a difference in e.g. how variables are expanded.

At least, lets start here, and then we might go over the entire debug logging and see what we can cut out.

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

PR Comment: https://git.openjdk.org/jdk/pull/17875#issuecomment-1948308937

From ihse at openjdk.org  Fri Feb 16 12:43:25 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 16 Feb 2024 12:43:25 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck [v2]
In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
Message-ID: <ccnGBDgKifqtHAXAlfcdzACsqJG68fY7-TjtsAnN_p8=.afd45aec-c57f-4911-88d2-7988768ccad9@github.com>

> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
> 
> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Replace spaces with \t in test properties file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17871/files
  - new: https://git.openjdk.org/jdk/pull/17871/files/3faa912e..e1c9c0f0

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

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

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

From ihse at openjdk.org  Fri Feb 16 12:43:25 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 16 Feb 2024 12:43:25 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck [v2]
In-Reply-To: <RtDj7nYzLQTAHvuthfA12JIjqYTM7LkXy92QXXib4jY=.62dbc402-ade5-48be-9e7a-1ca1091899d4@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
 <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>
 <osmSAGyuE-qyC6sjVT_UjfRd2CfUQHuKFjlvmDOW-3Y=.b8a009f9-e995-42e7-afed-af83a016ff2b@github.com>
 <oX6tKgqTMzsDdSFj-X-EXtJS-20BsyiMYBacmxBTzTk=.b6eb0e9d-9940-479e-b70b-75a446e43e1c@github.com>
 <Si89vBx8-kmdHyp9_XHJyFMD5oVir2mKhgwOcO281CE=.c387b74a-b09c-4213-8561-8e111f08f855@github.com>
 <RtDj7nYzLQTAHvuthfA12JIjqYTM7LkXy92QXXib4jY=.62dbc402-ade5-48be-9e7a-1ca1091899d4@github.com>
Message-ID: <gQYN5tDVDEdGZVHhgOHMz2IvGZn4iam8xh4Xx3jKPFk=.55c92a6d-68dd-4838-a2f8-840b4a66e4c2@github.com>

On Thu, 15 Feb 2024 17:53:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `\u000b` is VT   (vertical tab)  
>> `\u0009` or `\t` perhaps?
>
> Right. `\t` is better to avoid such a mistake.

Ok, fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1492403403

From ihse at openjdk.org  Fri Feb 16 12:45:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 16 Feb 2024 12:45:59 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
Message-ID: <thctbcato1Bz1XDUBDRZagYtDn4ycbwHLSEiD8p04vA=.1b758366-f4ef-430f-a7c2-0598f1161593@github.com>

On Thu, 11 Jan 2024 13:23:45 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Compile the JDK as C++17, enabling the use of all C++17 language features
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Require clang 13 in toolchain.m4

I think Kim's approach here -- to separate compiler upgrades from C++17 usage -- is the right way. Then we can discuss each part separately -- what version is suitable for each compiler, and then -- if or when we end up with all compilers supporting C++17 -- we can come back to the discussion of whether that is a good idea.

To be clear: my goal here was not as much the C++17 as getting a compiler bump, especially for getting rid of old buggy ones. I kind of piggybacked that discussion here, but once again, it is better to take that separately.

I also apologize for my hash expressions. :( I did not mean to insult anyone.

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1948323482

From prappo at openjdk.org  Fri Feb 16 13:09:09 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 16 Feb 2024 13:09:09 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v36]
In-Reply-To: <1hRkg0waT73IaCbhd7h-0bEgG5JirfxttEMjcY9EYM0=.827a07c5-d256-4b8e-9a3a-266506725f26@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <u2J4zt4oo-GbgV2u6DYkdV3IlyeO-NxpbIzy6bGcX14=.c0bd758d-66f7-40cd-b046-4ef496cc9118@github.com>
 <1hRkg0waT73IaCbhd7h-0bEgG5JirfxttEMjcY9EYM0=.827a07c5-d256-4b8e-9a3a-266506725f26@github.com>
Message-ID: <WaymeBVWCFIWWt3eIKBTitH7EPgWTEvBuwhqRdJId-w=.aad1b61a-2828-4585-b227-ed967dee377e@github.com>

On Fri, 16 Feb 2024 07:42:47 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Support for Table Of Contents in Markdown headings
>>  - fix typo
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 286:
> 
>> 284:                         lineKind = (ch == '\n' || ch == '\r') ? LineKind.BLANK
>> 285:                                 : (indent <= 3) ? peekLineKind()
>> 286:                                 : lineKind != LineKind.OTHER ? LineKind.INDENTED_CODE_BLOCK
> 
> Doesn't this cause false positives for indented code blocks? In my understanding, indented lines [in a list context](https://spec.commonmark.org/0.30/#example-258) and [directly following a blockquote](https://spec.commonmark.org/dingus/?text=%3E%20%20%20%20foo%0A%20%20%20%20%20bar%0A) are not interpreted as code blocks, but as part of the list or blockquote. So my guess would be that `not OTHER` should be something like `BLANK or INDENTED_CODE_BLOCK or HEADER`, and that still leaves the problem of a [blank line in a list context](https://spec.commonmark.org/0.30/#example-108).

Sigh. I remember when we all hoped that we wouldn't need to go in the weeds of Markdown parsing, but here we are. Hannes is right. Here are a coupe of problematic examples:

 -     /// List
       ///
       ///   - item
       ///
       ///     @param

 -     /// > Quote
       /// >
       /// >     {@link java.lang.Object}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1492430822

From erikj at openjdk.org  Fri Feb 16 13:38:52 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 16 Feb 2024 13:38:52 GMT
Subject: RFR: 8325972: Add -x to bash for building with LOG=debug
In-Reply-To: <UIGPgQR2VRlTTSVoNqyaA1TGdWs2FSB_1aYRb07sXZE=.3bbc1bb2-4542-4b2c-aeff-920f0693ec62@github.com>
References: <UIGPgQR2VRlTTSVoNqyaA1TGdWs2FSB_1aYRb07sXZE=.3bbc1bb2-4542-4b2c-aeff-920f0693ec62@github.com>
Message-ID: <7S3XwxDNRaDtGUe4jHR2xInCAKgdfBNfEHRHQpSaHHM=.2c841dba-5e63-4769-b922-2087fb6661cd@github.com>

On Thu, 15 Feb 2024 15:07:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I don't understand why I have never thought of this before. If we add `-x` to the set of bash arguments when running with LOG=debug, we get output of *all* shell commands that make is running, even those for $(shell).
> 
> This makes it soooo much easier to understand what is actually happening in the makefile! (To the point where we could actually consider moving other stuff away from the debug level.)

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17875#pullrequestreview-1885176231

From erikj at openjdk.org  Fri Feb 16 13:39:56 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 16 Feb 2024 13:39:56 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck [v2]
In-Reply-To: <ccnGBDgKifqtHAXAlfcdzACsqJG68fY7-TjtsAnN_p8=.afd45aec-c57f-4911-88d2-7988768ccad9@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <ccnGBDgKifqtHAXAlfcdzACsqJG68fY7-TjtsAnN_p8=.afd45aec-c57f-4911-88d2-7988768ccad9@github.com>
Message-ID: <EG72V-Kg8FWuzTzqCGrfpb3fX_WIq4oybS3sljVlPGY=.400d3c9f-a361-4515-8c6f-6a465b89adc0@github.com>

On Fri, 16 Feb 2024 12:43:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
>> 
>> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace spaces with \t in test properties file

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17871#pullrequestreview-1885177994

From naoto at openjdk.org  Fri Feb 16 16:55:57 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Feb 2024 16:55:57 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck [v2]
In-Reply-To: <ccnGBDgKifqtHAXAlfcdzACsqJG68fY7-TjtsAnN_p8=.afd45aec-c57f-4911-88d2-7988768ccad9@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <ccnGBDgKifqtHAXAlfcdzACsqJG68fY7-TjtsAnN_p8=.afd45aec-c57f-4911-88d2-7988768ccad9@github.com>
Message-ID: <fV_QpLFoKMrAxR1VvhztN6ha6WJBO8iNcPzNbP-fgAo=.25e82e1c-ed8d-4b7f-9f76-a9ed2a08e62d@github.com>

On Fri, 16 Feb 2024 12:43:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
>> 
>> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace spaces with \t in test properties file

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17871#pullrequestreview-1885586969

From aph at openjdk.org  Fri Feb 16 16:59:00 2024
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 16 Feb 2024 16:59:00 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <thctbcato1Bz1XDUBDRZagYtDn4ycbwHLSEiD8p04vA=.1b758366-f4ef-430f-a7c2-0598f1161593@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
 <thctbcato1Bz1XDUBDRZagYtDn4ycbwHLSEiD8p04vA=.1b758366-f4ef-430f-a7c2-0598f1161593@github.com>
Message-ID: <OjQDJCvSf10R34TusB7UUcMRSt06qeTdCvJMWT1fwTc=.0411535d-db35-496b-9ec1-4b35170257ee@github.com>

On Fri, 16 Feb 2024 12:43:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I think Kim's approach here -- to separate compiler upgrades from C++17 usage -- is the right way. Then we can discuss each part separately -- what version is suitable for each compiler, and then -- if or when we end up with all compilers supporting C++17 -- we can come back to the discussion of whether that is a good idea.

I agree with all that. I don't even object to upgrading to a recent(ish) GCC, but I do think we ought to at least get a mention of the downsides on the record, and sometimes that job falls to me. So I think I agree it's the right thing to do going forward, even though it might be a bit bumpy for those of us trying to build the JDK on a range of elderly long-term-support Linux systems.

> I also apologize for my hash expressions. :( I did not mean to insult anyone.

No problem. We're good.

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1948879029

From kbarrett at openjdk.org  Fri Feb 16 17:01:01 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 16 Feb 2024 17:01:01 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang [v2]
In-Reply-To: <56uYGhLCcDFBfuEV2TpDDYcOzLjBtKKerH03q-L_wlk=.37ca1c75-45e9-42ad-af40-7cfb34c77725@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <qja7u1WGpMGYvymUwKDAfovke8Kplizcby_j0hNN-r4=.9a3603e4-1446-4b57-9059-7553d21c64a1@github.com>
 <56uYGhLCcDFBfuEV2TpDDYcOzLjBtKKerH03q-L_wlk=.37ca1c75-45e9-42ad-af40-7cfb34c77725@github.com>
Message-ID: <mnFeIhXnSVYxCCslAvxFNIXLo0Lya8Nfqk1FWA6T21o=.8aa2f1c0-b2fb-4d2b-97c1-7effc3f6c52d@github.com>

On Mon, 5 Feb 2024 21:39:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Here is the full list: https://clang.llvm.org/docs/DiagnosticsReference.html#wpedantic

I know about that list, and that's not what I was asking for. I want to
understand the impact on *our* code. What warnings are arising from *our*
code, how difficult are the fixes, and how beneficial are the fixes.

Looking through the list of warnings it can generate, I don't see much that
looks useful. I'm inclined to agree with Andrew Haley's comment in (draft)
https://github.com/openjdk/jdk/pull/17727#issuecomment-1929178213. It might be
that there are some specific warning options that are part of it that might be
worth turning on (or working toward), but it's mostly uncompelling.

The two that had bazillions of occurrences when I tried with gcc were (1) a
gcc bug (incorrect warning about extra semis), and (2) a completely non-useful
requirement that "%p" format spec only accepts exactly void*, with no implicit
conversions from other pointer types. Clang presumably doesn't have the
former, and I don't know about the latter.

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1948881656

From jjg at openjdk.org  Fri Feb 16 17:03:25 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 16 Feb 2024 17:03:25 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v37]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <28i4g6IynoB72EH0TiCPLtRASiHamLlXOzyKlpHzrI4=.c01d8c67-86ca-4282-8382-099bc98f6061@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  remove obsolete comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/53afd804..25921fd0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=35-36

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

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

From acobbs at openjdk.org  Fri Feb 16 17:14:09 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 16 Feb 2024 17:14:09 GMT
Subject: RFR: 8317376: Minor improvements to the 'this' escape analyzer
 [v3]
In-Reply-To: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
References: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
Message-ID: <QvX6vQp-aXt2jCvUMCVhwrna3Gr8m8NVesUmexUdMcI=.4f5e5118-97b6-4484-a838-808800bfbec8@github.com>

> Please review several fixes and improvements to the `this-escape` lint warning analyzer.
> 
> The goal here is to apply some relatively simple logical fixes that improve the precision and accuracy of the analyzer, and capture the remaining low-hanging fruit so we can consider the analyzer relatively complete with respect to what's feasible with its current design.
> 
> Although the changes are small from a logical point of view, they generate a fairly large patch due to impact of refactoring (sorry!). Most of the patch derives from the first two changes listed below.
> 
> The changes are summarized here:
> 
> #### 1. Generalize how we categorize references
> 
> The `Ref` class hierarchy models the various ways in which, at any point during the execution of a constructor or some other method/constructor that it invokes, there can be live references to the original object under construction lying around. We then look for places where one of these `Ref`'s might be passed to a subclass method. In other words, the analyzer keeps track of these references and watches what happens to them as the code executes so it can catch them trying to "escape".
> 
> Previously the `Ref` categories were:
> * `ThisRef` - The current instance of the (non-static) method or constructor being analyzed
> * `OuterRef` - The current outer instance of the (non-static) method or constructor being analyzed
> * `VarRef` - A local variable or method parameter currently in scope
> * `ExprRef` - An object reference sitting on top of the Java execution stack
> * `YieldRef` - The current switch expression's yield value(s)
> * `ReturnRef` - The current method's return value(s)
> 
> For each of those types, we further classified the "indirection" of the reference, i.e., whether the reference was direct (from the thing itself) or indirect (from something the thing referenced).
> 
> The problem with that hierarchy is that we could only track outer instance references that happened to be associated with the current instance. So we might know that `this` had an outer instance reference, but if we said `var x = this` we wouldn't know that `x` had an outer instance reference.
> 
> In other words, we should be treating "via an outer instance" as just another flavor of indirection along with "direct" and "indirect".
> 
> As a result, with this patch the `OuterRef` class goes away and a new `Indirection` enum has been created, with values `DIRECT`, `INDIRECT`, and `OUTER`.
> 
> #### 2. Track the types of all references
> 
> By keeping track of the actual type of...

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'master' into JDK-8317376
 - Merge branch 'master' into JDK-8317376
 - Merge branch 'master' into JDK-8317376
 - Merge branch 'master' into JDK-8317376
 - Javadoc++
 - Merge branch 'master' into JDK-8317376
 - Several improvements to the 'this' escape analyzer.
   
   - Track direct, indirect, and outer references for all Ref types.
   - Keep type information about all references to improve tracking precision.
   - Track enhanced for() invocations of iterator(), hasNext(), and next().
   - Don't report an escape of a non-public outer instances as a leak.
   - Fix omitted tracking of references from newly instantiated instances.
   - Fix omitted tracking of leaks via lambda return values.
   - Remove unneccesary suppressions of this-escape lint warning.

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

Changes: https://git.openjdk.org/jdk/pull/16208/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16208&range=02
  Stats: 869 lines in 19 files changed: 513 ins; 146 del; 210 mod
  Patch: https://git.openjdk.org/jdk/pull/16208.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16208/head:pull/16208

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

From prr at openjdk.org  Fri Feb 16 22:25:55 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 Feb 2024 22:25:55 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang [v2]
In-Reply-To: <qja7u1WGpMGYvymUwKDAfovke8Kplizcby_j0hNN-r4=.9a3603e4-1446-4b57-9059-7553d21c64a1@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <qja7u1WGpMGYvymUwKDAfovke8Kplizcby_j0hNN-r4=.9a3603e4-1446-4b57-9059-7553d21c64a1@github.com>
Message-ID: <diI68eQ6OxPru5Zvxq3GqauGgFlb9_Yx9itHl9X_KsI=.bad0dae6-f291-4a59-80bc-d600be2cf321@github.com>

On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
>> 
>> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
>> 
>> 
>> #define DEBUG_ONLY(code) code;
>> 
>> DEBUG_ONLY(foo());
>> 
>> 
>> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   FIx dtrace build

OK, although it would have been nice if you could have summarised what -pedantic and vla-extension are, so I didn't have to go and do research.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17687#pullrequestreview-1886164910

From kbarrett at openjdk.org  Sat Feb 17 08:33:04 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 17 Feb 2024 08:33:04 GMT
Subject: RFR: 8325881: Require minimum gcc version 10
Message-ID: <M0am_3VbHFaY6j5Ci1-DGeqfU7KOrTJeaymKvQ_EXyc=.c102258b-c728-4718-8061-1346e37e0276@github.com>

Please review this change that updates the minimum supported version of gcc
to be used for building OpenJDK from 6.0 to 10.0.

This permits enabling C++17 (JDK-8314488), though gcc 9.0 might suffice for
that. A minimum of gcc 10 also obtains the primitives needed to support a
work-alick for std::is_constant_evaluated (added in C++20). There are a bunch
of improvements that would be enabled by that. Having it would also allow the
elimination of a bit of a mess in the HotSpot assert macros that was needed to
work around the lack of that feature (JDK-8303805). Either current or proposed
minimum versions of other supported compilers also provide the needed
primitives.

Testing: mach5 tier1 (uses gcc13.2 on gcc-based platforms)
Locally (linux-x64) built and ran tier1 with gcc10.3.

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

Commit messages:
 - minimum gcc10

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

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

From kbarrett at openjdk.org  Sat Feb 17 08:37:57 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 17 Feb 2024 08:37:57 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <Kf3TPcBiwoF4IKXQSdVu8fPrmy_AUe6japArSVzHHGw=.ac49ae36-aa56-4590-ba46-e195b03445d1@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
 <bhrcRriVPrMI3BZd4M7MBIeFeF4vKhBbLVxbe0vfKPc=.c089032b-7420-4224-8186-d7d6e721856b@github.com>
 <Kf3TPcBiwoF4IKXQSdVu8fPrmy_AUe6japArSVzHHGw=.ac49ae36-aa56-4590-ba46-e195b03445d1@github.com>
Message-ID: <qvKzbx8UQHWBvn-Bjgzo3Es2SOjB2uKtjdKNElxJOIk=.e40e0553-eb0e-4f0e-bbd9-3b0cc3bcba85@github.com>

On Wed, 14 Feb 2024 15:59:50 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> I'd like to separate the version update discussions from C++17 specifics, so we can have focused discussions on the version choices. Of course, that's going to be informed by the possibility of C++17, but that's not the only factor. That way this issue can be just about turning on C++17, when, and why.
> 
> In order to do that, I've filed the following issues about version updates: https://bugs.openjdk.org/browse/JDK-8325881 Require minimum gcc version 10
> 
> https://bugs.openjdk.org/browse/JDK-8325878 Require minimum clang version 13
> 
> https://bugs.openjdk.org/browse/JDK-8325880 Require minimum OpenXL C/C++ version 17.1.1
> 
> PRs will follow shortly.

And here are the promised PRs:

8325881: Require minimum gcc version 10 
https://github.com/openjdk/jdk/pull/17899

8325878: Require minimum Clang version 13
https://github.com/openjdk/jdk/pull/17862

8325880: Require minimum Open XL C/C++ version 17.1.1
https://github.com/openjdk/jdk/pull/17857

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1949900566

From ihse at openjdk.org  Mon Feb 19 10:18:23 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 19 Feb 2024 10:18:23 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v50]
In-Reply-To: <oMTWDHUD8wvoaxiISrGY1ijZecfyRw2GoMN_lIENT6U=.69c833b2-1210-41ad-b08b-4775ab662243@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <oMTWDHUD8wvoaxiISrGY1ijZecfyRw2GoMN_lIENT6U=.69c833b2-1210-41ad-b08b-4775ab662243@github.com>
Message-ID: <PyvAxuIlx5l2C-34VCwfScQ4aB_RIRsgvf9LiHnIcOQ=.11ce8b3b-b0dd-4f7d-8904-035d32479b4c@github.com>

On Sun, 21 Jan 2024 07:58:11 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 84 commits:
> 
>  - Merge branch 'openjdk:master' into patch-10
>  - awt_Window.cpp
>  - awt_Frame.cpp
>  - awt_Component.cpp
>  - awt_Canvas.cpp
>  - Merge branch 'openjdk:master' into patch-10
>  - Merge branch 'openjdk:master' into patch-10
>  - Fix awt_Window.cpp
>  - Fix awt_PrintJob.cpp
>  - -Zc:stringStrings no longer needed with -permissive- flags-cflags.m4
>  - ... and 74 more: https://git.openjdk.org/jdk/compare/a474b372...0f34608b

bot-keep-alive

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

PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1952121717

From ihse at openjdk.org  Mon Feb 19 12:11:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 19 Feb 2024 12:11:00 GMT
Subject: RFR: 8325963: Clean up NativeCompilation.gmk and its newly created
 parts
Message-ID: <Urd9k-uHcIG6vau9ryCuZhGBRB6TJsiB0W7Egn9CeNI=.0cc3c88d-c80d-4b7a-bed8-387832147f90@github.com>

This is a follow-up to [JDK-8325877](https://bugs.openjdk.org/browse/JDK-8325877). I was careful in that bug not to change order of any lines, only split up the original file into parts.

In this PR, I use the new structure to improve the design. I collect the functionality into three clearly separate phases, preparation, compilation and linking. I use consistent naming to reveal whether a function just sets up variables, or create output. I simplify and split up a few extra hard to read functions. I move some code around so it is placed more logically.

It can be hard to convince yourself that the changes are correct if you just look at the end result. I have tried to make small and clear changes in each separate commit, and to explain in the commit title what I am doing. I recommend reviewing this PR [commit by commit](https://github.com/openjdk/jdk/pull/17873/commits).

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

Commit messages:
 - Inline SetupDebugSymbols into SetupCompilerFlags
 - Fix indentation in the new functions
 - Extract CreateStaticLibrary and CreateDynamicLibraryOrExecutable
 - Move GetEntitlement setup to SetupLinking. Inline GetSymbols (for static builds).
 - Simplify SetupCompileFileFlags by passing in $$($1_BASE) as $2
 - Clearly separate the steps into preparation, compilation and linking.
 - Be consistent (and explicit) about the use of Setup vs Create. Collect all Setup functions at the start.
 - Combine the linking preparations
 - Combine the three SetupBasicVariables functions

Changes: https://git.openjdk.org/jdk/pull/17873/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17873&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325963
  Stats: 385 lines in 6 files changed: 132 ins; 130 del; 123 mod
  Patch: https://git.openjdk.org/jdk/pull/17873.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17873/head:pull/17873

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

From ihse at openjdk.org  Mon Feb 19 12:11:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 19 Feb 2024 12:11:00 GMT
Subject: RFR: 8325963: Clean up NativeCompilation.gmk and its newly created
 parts
In-Reply-To: <Urd9k-uHcIG6vau9ryCuZhGBRB6TJsiB0W7Egn9CeNI=.0cc3c88d-c80d-4b7a-bed8-387832147f90@github.com>
References: <Urd9k-uHcIG6vau9ryCuZhGBRB6TJsiB0W7Egn9CeNI=.0cc3c88d-c80d-4b7a-bed8-387832147f90@github.com>
Message-ID: <VukatSv577sCheiOOnPbUrUdQ40iWzhR03mKlHrSf5E=.9ab9c2a0-f8e0-463d-a0b1-21abab6f57ac@github.com>

On Thu, 15 Feb 2024 14:13:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up to [JDK-8325877](https://bugs.openjdk.org/browse/JDK-8325877). I was careful in that bug not to change order of any lines, only split up the original file into parts.
> 
> In this PR, I use the new structure to improve the design. I collect the functionality into three clearly separate phases, preparation, compilation and linking. I use consistent naming to reveal whether a function just sets up variables, or create output. I simplify and split up a few extra hard to read functions. I move some code around so it is placed more logically.
> 
> It can be hard to convince yourself that the changes are correct if you just look at the end result. I have tried to make small and clear changes in each separate commit, and to explain in the commit title what I am doing. I recommend reviewing this PR [commit by commit](https://github.com/openjdk/jdk/pull/17873/commits).

I have fully verified using COMPARE_BUILD that the resulting native code is byte-by-byte identical on Linux, macOS and Windows, so that should confirm the correctness of this refactoring.

And @TheShermanTanker, I apologize, but this one is probably going to be much harder for you to integrate into your port. :-(

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

PR Comment: https://git.openjdk.org/jdk/pull/17873#issuecomment-1952314727
PR Comment: https://git.openjdk.org/jdk/pull/17873#issuecomment-1952316464

From jwaters at openjdk.org  Mon Feb 19 12:24:55 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 19 Feb 2024 12:24:55 GMT
Subject: RFR: 8325963: Clean up NativeCompilation.gmk and its newly created
 parts
In-Reply-To: <Urd9k-uHcIG6vau9ryCuZhGBRB6TJsiB0W7Egn9CeNI=.0cc3c88d-c80d-4b7a-bed8-387832147f90@github.com>
References: <Urd9k-uHcIG6vau9ryCuZhGBRB6TJsiB0W7Egn9CeNI=.0cc3c88d-c80d-4b7a-bed8-387832147f90@github.com>
Message-ID: <FXEJEXCAiRCFHbj0fctjh-aw83X2XJvRt9l6eKQOnAE=.eef144be-4158-4c59-a956-409845fb17e3@github.com>

On Thu, 15 Feb 2024 14:13:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up to [JDK-8325877](https://bugs.openjdk.org/browse/JDK-8325877). I was careful in that bug not to change order of any lines, only split up the original file into parts.
> 
> In this PR, I use the new structure to improve the design. I collect the functionality into three clearly separate phases, preparation, compilation and linking. I use consistent naming to reveal whether a function just sets up variables, or create output. I simplify and split up a few extra hard to read functions. I move some code around so it is placed more logically.
> 
> It can be hard to convince yourself that the changes are correct if you just look at the end result. I have tried to make small and clear changes in each separate commit, and to explain in the commit title what I am doing. I recommend reviewing this PR [commit by commit](https://github.com/openjdk/jdk/pull/17873/commits).

Oh boy, this isn't going to be fun, but no worries, I'll find a way :)
I've actually avoided pulling in the previous change into the gcc port since MinGW is packaging a version of Java that predates it, I'll probably pull it in once a new tag that includes that changeset is released

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

PR Comment: https://git.openjdk.org/jdk/pull/17873#issuecomment-1952338357

From jwaters at openjdk.org  Mon Feb 19 12:34:53 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 19 Feb 2024 12:34:53 GMT
Subject: RFR: 8325963: Clean up NativeCompilation.gmk and its newly created
 parts
In-Reply-To: <Urd9k-uHcIG6vau9ryCuZhGBRB6TJsiB0W7Egn9CeNI=.0cc3c88d-c80d-4b7a-bed8-387832147f90@github.com>
References: <Urd9k-uHcIG6vau9ryCuZhGBRB6TJsiB0W7Egn9CeNI=.0cc3c88d-c80d-4b7a-bed8-387832147f90@github.com>
Message-ID: <UyR5rhaYKV-z1uqDGWE8YaDDBkWZcxk5-fLFafwM-Xc=.2f2a529f-31bf-4350-be6e-2cab11795d08@github.com>

On Thu, 15 Feb 2024 14:13:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up to [JDK-8325877](https://bugs.openjdk.org/browse/JDK-8325877). I was careful in that bug not to change order of any lines, only split up the original file into parts.
> 
> In this PR, I use the new structure to improve the design. I collect the functionality into three clearly separate phases, preparation, compilation and linking. I use consistent naming to reveal whether a function just sets up variables, or create output. I simplify and split up a few extra hard to read functions. I move some code around so it is placed more logically.
> 
> It can be hard to convince yourself that the changes are correct if you just look at the end result. I have tried to make small and clear changes in each separate commit, and to explain in the commit title what I am doing. I recommend reviewing this PR [commit by commit](https://github.com/openjdk/jdk/pull/17873/commits).

Marked as reviewed by jwaters (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/17873#pullrequestreview-1888308883

From magnus.ihse.bursie at oracle.com  Mon Feb 19 14:25:06 2024
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 19 Feb 2024 15:25:06 +0100
Subject: Hotspot symbol visibility - surprising news!
In-Reply-To: <645132e0-687e-4f04-9e49-f90131294367@oracle.com>
References: <645132e0-687e-4f04-9e49-f90131294367@oracle.com>
Message-ID: <ba822e64-2a9c-447f-b545-b7fda01c47ef@oracle.com>

On 2024-02-14 11:06, Magnus Ihse Bursie wrote:

> I am currently pursuing improved build functionality for static 
> libraries. One of the issues with static libraries are name 
> collisions, which led me back to an old discussion about which symbols 
> are exported from Hotspot, and how this is achieved. A long discussion 
> is available in JDK-8017234 [1], which was created in 2013 and has 
> been on the back burner ever since, coming back to life every now and 
> then.
>
> There are basically two different problems here. They are both 
> distinct and interrelated, and we likely need to solve both in tandem.
>
> The first problem is how Hotspot should say which symbols (functions) 
> that should be exported from libjvm.so. The historical, and still 
> used, system is to have a mapfile. In the "new" (not so new anymore) 
> build system, this was simplified to a list of function names in 
> make/data/hotspot-symbols, from which a mapfile is built.
>
> This is in contrast with how all other libraries in the JDK are built, 
> and also with modern best practices. A better approach would be to 
> annotate the functions that should be exported in the source code. In 
> fact, such annotation already exists, even in Hotspot, as JNIEXPORT, 
> but this is currently not used in the compilation of Hotspot.
>
> The second problem is that in addition to these explicitly exported 
> functions, we also export basically all other functions as well in 
> Hotspot. (So currently we could basically just forgo this complicated 
> machinery and just export everything by default...)
>
> The reason for this seem somewhat unclear. The specifics are probably 
> forever lost in the mists of time past, but the essential point is 
> that these symbols are needed for SA to do it's job.
>
> So what we do is that we list all symbols in hotspot after compiling 
> (but before linking), and selects some (most, I think) of them using 
> regexp patterns, and add these to the mapfile.

Actually, we are not doing what I thought we're doing, and what I assume 
whoever wrote the original code thought we were doing. Seems no-one has 
ever bothered to check the effect of this massive generated mapfile. :-/ 
At least not on linux/gcc (which is the only platform I've looked at so 
far).

It turns out that the gcc linker never removes the "hidden" visibility 
from symbols. Even if you list them in a mapfile under "global:", if 
they were compiled with visibility "hidden", they will still be hidden. 
The only thing you can ever hope to achieve with a mapfile is to make 
symbols with "default" visibility be "hidden", by placing them under the 
"local:" header. In hotspot, only functions marked JNIEXPORT have the 
"default" visibility.

The upshot of all this is that the mapfile has very little impact on the 
resulting symbols in Hotspot, and a lot of the difference it makes seems 
to be incorrect. :-/

In other words, all the mapfile can ever do is hide stuff that would 
otherwise have been visible. So what symbols are then made hidden by the 
mapfile? In effect, symbols that are marked JNIEXPORT but are not listed 
in make/data/hotspot-symbols, and symbols that arise from outside 
hotspot source code. I have divided these symbols into four categories:

1) All symbols from debug.cpp that are marked JNIEXPORT (most of them).

2) All symbols from jvmciCompilerToVM.cpp and that are marked JNIEXPORT 
(most of them), and data from vmStructs_jvmci.cpp that are marked JNIEXPORT.

3) Assembly functions such as _Copy_arrayof_conjoint_bytes that are 
marked .globl

4) Symbols not present in hotspot source code, but which originates with 
the compiler or standard libraries, e.g. __bss_start, __cxa_begin_catch, 
_ZTIN10__cxxabiv117__class_type_infoE, 
_ZTSN9__gnu_cxx20recursive_init_errorE, etc.

My interpretation of this is:

a) It is actually an error not to export functions marked JNIEXPORT, so 
1 and 2 are actually more correct this way.

b) The assembly functions are incorrectly marked .globl. This should 
just be removed.

c) As for the symbols from compiler and standard libraries; I don't 
know. I assume these are exported by default by normal libs, so it 
should probably be fine to do the same with Hotspot. Possibly there are 
other ways to make these local, if we really want that (linker flags, or 
something like that?).

The most important observation, however, is that generating a long list 
of symbols from the object file to make them "available" to SA seems to 
be a complete misunderstanding of what is happening. No hidden symbols 
can ever be made visible in this manner.

/Magnus



From ihse at openjdk.org  Mon Feb 19 16:12:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 19 Feb 2024 16:12:55 GMT
Subject: RFR: 8325881: Require minimum gcc version 10
In-Reply-To: <M0am_3VbHFaY6j5Ci1-DGeqfU7KOrTJeaymKvQ_EXyc=.c102258b-c728-4718-8061-1346e37e0276@github.com>
References: <M0am_3VbHFaY6j5Ci1-DGeqfU7KOrTJeaymKvQ_EXyc=.c102258b-c728-4718-8061-1346e37e0276@github.com>
Message-ID: <zwLsZorxs-0jHwk_6FsJpEm2AwyU_F_fzrTO5AK0aMA=.9756c018-a5ce-4422-8e72-3cd29d55038a@github.com>

On Sat, 17 Feb 2024 08:28:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that updates the minimum supported version of gcc
> to be used for building OpenJDK from 6.0 to 10.0.
> 
> This permits enabling C++17 (JDK-8314488), though gcc 9.0 might suffice for
> that. A minimum of gcc 10 also obtains the primitives needed to support a
> work-alick for std::is_constant_evaluated (added in C++20). There are a bunch
> of improvements that would be enabled by that. Having it would also allow the
> elimination of a bit of a mess in the HotSpot assert macros that was needed to
> work around the lack of that feature (JDK-8303805). Either current or proposed
> minimum versions of other supported compilers also provide the needed
> primitives.
> 
> Testing: mach5 tier1 (uses gcc13.2 on gcc-based platforms)
> Locally (linux-x64) built and ran tier1 with gcc10.3.

Looks good from a build perspective.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17899#pullrequestreview-1888786735

From ihse at openjdk.org  Mon Feb 19 16:14:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 19 Feb 2024 16:14:57 GMT
Subject: Integrated: 8325972: Add -x to bash for building with LOG=debug
In-Reply-To: <UIGPgQR2VRlTTSVoNqyaA1TGdWs2FSB_1aYRb07sXZE=.3bbc1bb2-4542-4b2c-aeff-920f0693ec62@github.com>
References: <UIGPgQR2VRlTTSVoNqyaA1TGdWs2FSB_1aYRb07sXZE=.3bbc1bb2-4542-4b2c-aeff-920f0693ec62@github.com>
Message-ID: <wT5jC9LWBNZ0utZVFLTW-UJRR-5dFbc8AazfWdiTkeY=.e22a88eb-6c50-43d5-8cb9-86f62aac2405@github.com>

On Thu, 15 Feb 2024 15:07:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I don't understand why I have never thought of this before. If we add `-x` to the set of bash arguments when running with LOG=debug, we get output of *all* shell commands that make is running, even those for $(shell).
> 
> This makes it soooo much easier to understand what is actually happening in the makefile! (To the point where we could actually consider moving other stuff away from the debug level.)

This pull request has now been integrated.

Changeset: 8668198c
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8668198c26bdac412f0a9d1255ca74da860761c5
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8325972: Add -x to bash for building with LOG=debug

Reviewed-by: erikj

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

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

From ihse at openjdk.org  Mon Feb 19 16:16:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 19 Feb 2024 16:16:00 GMT
Subject: Integrated: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
Message-ID: <8lQWgT0JhzAP5uuraMs8UjJXJcyTacHziySbnLN9XaQ=.16d4233d-1815-4cf8-8761-368fe425a131@github.com>

On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
> 
> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

This pull request has now been integrated.

Changeset: 5c5a282f
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5c5a282f91dd28b306673ca2bcc30dec451e7a7d
Stats:     113 lines in 38 files changed: 0 ins; 10 del; 103 mod

8325950: Make sure all files in the JDK pass jcheck

Reviewed-by: prr, wetmore, erikj, naoto

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

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

From djelinski1 at gmail.com  Mon Feb 19 16:43:48 2024
From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=)
Date: Mon, 19 Feb 2024 17:43:48 +0100
Subject: Hotspot symbol visibility - surprising news!
In-Reply-To: <ba822e64-2a9c-447f-b545-b7fda01c47ef@oracle.com>
References: <645132e0-687e-4f04-9e49-f90131294367@oracle.com>
 <ba822e64-2a9c-447f-b545-b7fda01c47ef@oracle.com>
Message-ID: <CAMrH03K+fB1p5cEyEwo-QL3BfEC6iuugdd9P=nDkHy8FCRAr0Q@mail.gmail.com>

Hi Magnus,

The "massive generated mapfile" is used on Windows. As you noticed, on
Linux symbols are exported if they are both JNIEXPORT and listed in
the mapfile. On Windows, the symbols are exported if they are either
JNIEXPORT or listed in the mapfile. The Windows symbolicator needs to
see the vftables to tell apart different object types, and these
tables are only made available in the produced binaries through the
mapfile. The Windows mapfile exports the vftables of every virtual
class in libjvm, which is much more than the symbolicator actually
needs, but that's probably a separate topic.

The symbolicator on Linux does not need the mapfile.

The assembly functions are correctly labelled with .globl; if we
remove these declarations or change them to local, the code won't
link. The right solution here is to also label them as .hidden, for
example using this script:

     sed -i -n 'p;s/\.globa\?l/.hidden/p' src/hotspot/os_cpu/*/*.S

The symbols from the standard libraries are not exported by any of our
binaries. Libjvm removes them via the use of mapfile, and all other
libraries are linked with  -Wl,--exclude-libs,ALL; if you choose to
remove the mapfile from libjvm, you'll need to add that parameter.

Regards,
Daniel

From jjg at openjdk.org  Mon Feb 19 18:23:05 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 19 Feb 2024 18:23:05 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v36]
In-Reply-To: <1hRkg0waT73IaCbhd7h-0bEgG5JirfxttEMjcY9EYM0=.827a07c5-d256-4b8e-9a3a-266506725f26@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <u2J4zt4oo-GbgV2u6DYkdV3IlyeO-NxpbIzy6bGcX14=.c0bd758d-66f7-40cd-b046-4ef496cc9118@github.com>
 <1hRkg0waT73IaCbhd7h-0bEgG5JirfxttEMjcY9EYM0=.827a07c5-d256-4b8e-9a3a-266506725f26@github.com>
Message-ID: <dpksm8jrXyvld3ATgbHzPVJGqClj1iMjwADcZdP3Pg0=.f69e1822-1294-43f4-9119-4344cf4154d6@github.com>

On Fri, 16 Feb 2024 07:42:47 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Support for Table Of Contents in Markdown headings
>>  - fix typo
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 286:
> 
>> 284:                         lineKind = (ch == '\n' || ch == '\r') ? LineKind.BLANK
>> 285:                                 : (indent <= 3) ? peekLineKind()
>> 286:                                 : lineKind != LineKind.OTHER ? LineKind.INDENTED_CODE_BLOCK
> 
> Doesn't this cause false positives for indented code blocks? In my understanding, indented lines [in a list context](https://spec.commonmark.org/0.30/#example-258) and [directly following a blockquote](https://spec.commonmark.org/dingus/?text=%3E%20%20%20%20foo%0A%20%20%20%20%20bar%0A) are not interpreted as code blocks (always in the case of blockquote, and depending on the offset of text after the list marker in list items). 
> 
> Note: edited because my initial suggestion was incorrect.

@hns @pavelrappo noted; working on it ...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1494909524

From erikj at openjdk.org  Tue Feb 20 18:05:55 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 20 Feb 2024 18:05:55 GMT
Subject: RFR: 8325963: Clean up NativeCompilation.gmk and its newly created
 parts
In-Reply-To: <Urd9k-uHcIG6vau9ryCuZhGBRB6TJsiB0W7Egn9CeNI=.0cc3c88d-c80d-4b7a-bed8-387832147f90@github.com>
References: <Urd9k-uHcIG6vau9ryCuZhGBRB6TJsiB0W7Egn9CeNI=.0cc3c88d-c80d-4b7a-bed8-387832147f90@github.com>
Message-ID: <c6dpKC5N6gEcDfY7q091CXnb99_sWNf_DzF1GOMrpwY=.22b7a62b-c1c5-47c1-bb71-7e79dc8942fb@github.com>

On Thu, 15 Feb 2024 14:13:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up to [JDK-8325877](https://bugs.openjdk.org/browse/JDK-8325877). I was careful in that bug not to change order of any lines, only split up the original file into parts.
> 
> In this PR, I use the new structure to improve the design. I collect the functionality into three clearly separate phases, preparation, compilation and linking. I use consistent naming to reveal whether a function just sets up variables, or create output. I simplify and split up a few extra hard to read functions. I move some code around so it is placed more logically.
> 
> It can be hard to convince yourself that the changes are correct if you just look at the end result. I have tried to make small and clear changes in each separate commit, and to explain in the commit title what I am doing. I recommend reviewing this PR [commit by commit](https://github.com/openjdk/jdk/pull/17873/commits).

Overall this looks good.

make/common/NativeCompilation.gmk line 132:

> 130: SetupNativeCompilation = $(NamedParamsMacroTemplate)
> 131: define SetupNativeCompilationBody
> 132:   # In this functions, helpers named Setup<Foo> are just setting variables.

Suggestion:

  # In this function, helpers named Setup<Foo> are just setting variables.

I think have tried to use the word "macro" rather than "function" in makefiles as that's what they technically are.

make/common/native/Paths.gmk line 195:

> 193: 
> 194: ################################################################################
> 195: define RemoveSuperfluousOutputFiles

This macro doesn't fit in either of the two categories mentioned at the top. Perhaps worth clarifying that it's different here. It performs direct actions on output files but also doesn't do it through a recipe.

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

PR Review: https://git.openjdk.org/jdk/pull/17873#pullrequestreview-1891021386
PR Review Comment: https://git.openjdk.org/jdk/pull/17873#discussion_r1496197461
PR Review Comment: https://git.openjdk.org/jdk/pull/17873#discussion_r1496208627

From ihse at openjdk.org  Tue Feb 20 18:34:04 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 20 Feb 2024 18:34:04 GMT
Subject: RFR: 8325963: Clean up NativeCompilation.gmk and its newly created
 parts [v2]
In-Reply-To: <Urd9k-uHcIG6vau9ryCuZhGBRB6TJsiB0W7Egn9CeNI=.0cc3c88d-c80d-4b7a-bed8-387832147f90@github.com>
References: <Urd9k-uHcIG6vau9ryCuZhGBRB6TJsiB0W7Egn9CeNI=.0cc3c88d-c80d-4b7a-bed8-387832147f90@github.com>
Message-ID: <a40pSGE2TLQ7zBTvQAg5reHImtqLsfDpBqteM9vbAh0=.8ce02c5f-9a6b-44b7-b12c-e67c1fc0ba2e@github.com>

> This is a follow-up to [JDK-8325877](https://bugs.openjdk.org/browse/JDK-8325877). I was careful in that bug not to change order of any lines, only split up the original file into parts.
> 
> In this PR, I use the new structure to improve the design. I collect the functionality into three clearly separate phases, preparation, compilation and linking. I use consistent naming to reveal whether a function just sets up variables, or create output. I simplify and split up a few extra hard to read functions. I move some code around so it is placed more logically.
> 
> It can be hard to convince yourself that the changes are correct if you just look at the end result. I have tried to make small and clear changes in each separate commit, and to explain in the commit title what I am doing. I recommend reviewing this PR [commit by commit](https://github.com/openjdk/jdk/pull/17873/commits).

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Clarify comment based on review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17873/files
  - new: https://git.openjdk.org/jdk/pull/17873/files/c77b88c2..449cbae2

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

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

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

From ihse at openjdk.org  Tue Feb 20 18:34:04 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 20 Feb 2024 18:34:04 GMT
Subject: RFR: 8325963: Clean up NativeCompilation.gmk and its newly created
 parts [v2]
In-Reply-To: <c6dpKC5N6gEcDfY7q091CXnb99_sWNf_DzF1GOMrpwY=.22b7a62b-c1c5-47c1-bb71-7e79dc8942fb@github.com>
References: <Urd9k-uHcIG6vau9ryCuZhGBRB6TJsiB0W7Egn9CeNI=.0cc3c88d-c80d-4b7a-bed8-387832147f90@github.com>
 <c6dpKC5N6gEcDfY7q091CXnb99_sWNf_DzF1GOMrpwY=.22b7a62b-c1c5-47c1-bb71-7e79dc8942fb@github.com>
Message-ID: <fBpwRGLiL6iK91dfCgxBi8k-ThpCEtwoYBsHKMWdj-w=.66e7ab17-85cb-4e70-b730-0b022f125a99@github.com>

On Tue, 20 Feb 2024 17:13:12 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clarify comment based on review
>
> make/common/NativeCompilation.gmk line 132:
> 
>> 130: SetupNativeCompilation = $(NamedParamsMacroTemplate)
>> 131: define SetupNativeCompilationBody
>> 132:   # In this functions, helpers named Setup<Foo> are just setting variables.
> 
> Suggestion:
> 
>   # In this function, helpers named Setup<Foo> are just setting variables.
> 
> I think have tried to use the word "macro" rather than "function" in makefiles as that's what they technically are.

I was on the fence for this one. I know they are macros, but we use them like functions. But sure, I'll go with technically correct (after all, it's [the best kind of correct](https://www.youtube.com/watch?v=0ZEuWJ4muYc)).

> make/common/native/Paths.gmk line 195:
> 
>> 193: 
>> 194: ################################################################################
>> 195: define RemoveSuperfluousOutputFiles
> 
> This macro doesn't fit in either of the two categories mentioned at the top. Perhaps worth clarifying that it's different here. It performs direct actions on output files but also doesn't do it through a recipe.

I left out the third category of macros that are neither Setup nor Create, since they can do all kind of strange stuff. But now I added a comment about it; hope you feel it's enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17873#discussion_r1496315088
PR Review Comment: https://git.openjdk.org/jdk/pull/17873#discussion_r1496316773

From erikj at openjdk.org  Tue Feb 20 18:51:57 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 20 Feb 2024 18:51:57 GMT
Subject: RFR: 8325963: Clean up NativeCompilation.gmk and its newly created
 parts [v2]
In-Reply-To: <a40pSGE2TLQ7zBTvQAg5reHImtqLsfDpBqteM9vbAh0=.8ce02c5f-9a6b-44b7-b12c-e67c1fc0ba2e@github.com>
References: <Urd9k-uHcIG6vau9ryCuZhGBRB6TJsiB0W7Egn9CeNI=.0cc3c88d-c80d-4b7a-bed8-387832147f90@github.com>
 <a40pSGE2TLQ7zBTvQAg5reHImtqLsfDpBqteM9vbAh0=.8ce02c5f-9a6b-44b7-b12c-e67c1fc0ba2e@github.com>
Message-ID: <pJQHfVi_30_cnXJ5IAKPjSnC2LqYqX2Hc9ghVoyksSY=.3f4ed053-dfed-4714-a2f0-db22d8ef8982@github.com>

On Tue, 20 Feb 2024 18:34:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is a follow-up to [JDK-8325877](https://bugs.openjdk.org/browse/JDK-8325877). I was careful in that bug not to change order of any lines, only split up the original file into parts.
>> 
>> In this PR, I use the new structure to improve the design. I collect the functionality into three clearly separate phases, preparation, compilation and linking. I use consistent naming to reveal whether a function just sets up variables, or create output. I simplify and split up a few extra hard to read functions. I move some code around so it is placed more logically.
>> 
>> It can be hard to convince yourself that the changes are correct if you just look at the end result. I have tried to make small and clear changes in each separate commit, and to explain in the commit title what I am doing. I recommend reviewing this PR [commit by commit](https://github.com/openjdk/jdk/pull/17873/commits).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify comment based on review

make/common/NativeCompilation.gmk line 132:

> 130: SetupNativeCompilation = $(NamedParamsMacroTemplate)
> 131: define SetupNativeCompilationBody
> 132:   # In this functions, macros named Setup<Foo> are just setting variables.

"functions" is still grammatically wrong. Do you actually mean "this macro", "these macros" or "this file"? I think there were a couple of other mentions of "function" further down as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17873#discussion_r1496336036

From ihse at openjdk.org  Tue Feb 20 19:02:12 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 20 Feb 2024 19:02:12 GMT
Subject: RFR: 8325963: Clean up NativeCompilation.gmk and its newly created
 parts [v3]
In-Reply-To: <Urd9k-uHcIG6vau9ryCuZhGBRB6TJsiB0W7Egn9CeNI=.0cc3c88d-c80d-4b7a-bed8-387832147f90@github.com>
References: <Urd9k-uHcIG6vau9ryCuZhGBRB6TJsiB0W7Egn9CeNI=.0cc3c88d-c80d-4b7a-bed8-387832147f90@github.com>
Message-ID: <hxwG3cmQqWbHhJfwZ6H4cWY9QPBi8Pm1z3s2Xaija9Q=.84bacbe8-36e0-4c22-8c5a-f9f421f43b43@github.com>

> This is a follow-up to [JDK-8325877](https://bugs.openjdk.org/browse/JDK-8325877). I was careful in that bug not to change order of any lines, only split up the original file into parts.
> 
> In this PR, I use the new structure to improve the design. I collect the functionality into three clearly separate phases, preparation, compilation and linking. I use consistent naming to reveal whether a function just sets up variables, or create output. I simplify and split up a few extra hard to read functions. I move some code around so it is placed more logically.
> 
> It can be hard to convince yourself that the changes are correct if you just look at the end result. I have tried to make small and clear changes in each separate commit, and to explain in the commit title what I am doing. I recommend reviewing this PR [commit by commit](https://github.com/openjdk/jdk/pull/17873/commits).

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Better fix for "macro"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17873/files
  - new: https://git.openjdk.org/jdk/pull/17873/files/449cbae2..17c7690b

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

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

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

From ihse at openjdk.org  Tue Feb 20 19:02:12 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 20 Feb 2024 19:02:12 GMT
Subject: RFR: 8325963: Clean up NativeCompilation.gmk and its newly created
 parts [v2]
In-Reply-To: <pJQHfVi_30_cnXJ5IAKPjSnC2LqYqX2Hc9ghVoyksSY=.3f4ed053-dfed-4714-a2f0-db22d8ef8982@github.com>
References: <Urd9k-uHcIG6vau9ryCuZhGBRB6TJsiB0W7Egn9CeNI=.0cc3c88d-c80d-4b7a-bed8-387832147f90@github.com>
 <a40pSGE2TLQ7zBTvQAg5reHImtqLsfDpBqteM9vbAh0=.8ce02c5f-9a6b-44b7-b12c-e67c1fc0ba2e@github.com>
 <pJQHfVi_30_cnXJ5IAKPjSnC2LqYqX2Hc9ghVoyksSY=.3f4ed053-dfed-4714-a2f0-db22d8ef8982@github.com>
Message-ID: <6DDDTPDcJ_FFGXuObGnCWXh9hyHM10jkx8gHiBdeOYI=.8e88ccad-7e7d-4760-893b-10bece5d5d9c@github.com>

On Tue, 20 Feb 2024 18:49:22 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clarify comment based on review
>
> make/common/NativeCompilation.gmk line 132:
> 
>> 130: SetupNativeCompilation = $(NamedParamsMacroTemplate)
>> 131: define SetupNativeCompilationBody
>> 132:   # In this functions, macros named Setup<Foo> are just setting variables.
> 
> "functions" is still grammatically wrong. Do you actually mean "this macro", "these macros" or "this file"? I think there were a couple of other mentions of "function" further down as well.

Better now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17873#discussion_r1496346965

From jjg at openjdk.org  Tue Feb 20 19:12:54 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 20 Feb 2024 19:12:54 GMT
Subject: RFR: JDK-8324774: Add DejaVu web fonts
In-Reply-To: <Lk548ptvKbRVcPbOKEcIS8DyDR5xp27xWEjkXzSKkjA=.7de8ac81-2ead-4842-9fb3-e724d4b9afff@github.com>
References: <Lk548ptvKbRVcPbOKEcIS8DyDR5xp27xWEjkXzSKkjA=.7de8ac81-2ead-4842-9fb3-e724d4b9afff@github.com>
Message-ID: <1ACJA5M8tQa_gnmvIapfRJFbhHmTSlIHoCHebOTM_PA=.9f12cb32-6959-4cc6-9892-fb93128b1fdc@github.com>

On Tue, 30 Jan 2024 16:13:42 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> This change adds the DejaVu web fonts that were previously maintained externally to the open repository so they are available both in JDK API documentation and any API documentation generated with the `javadoc` tool. All files added in this PR are the same as the ones previously maintained externally, with the exception of added license and name/version comments in `dejavu.css`.
> 
> Copying of font files to the generated documentation is done by looking for font file names in `dejavu.css`, so font file names can be changed without changing the code. However, the font file list is hard-coded in `APITest.java`. `CheckLibraryVersions.java` is updated to make sure the name and version in the legal file matches the one in the stylesheet. Of course I also performed manual tests to make sure the font and legal files are copied to the output tree and used correctly in browsers.
> 
> Once #17411 is integrated, `dejavu.css` should also be added to the list of files checked by the new "pass-through" test.

Some suggestions.

I think there should be an option to opt-out  of using these fonts.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java line 470:

> 468:             // Extract font file names from CSS file
> 469:             URL cssURL = HtmlConfiguration.class.getResource(DocPaths.RESOURCES.resolve(cssPath).getPath());
> 470:             InputStream in = cssURL.openStream();

Put this in try-with-resources

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java line 476:

> 474:                 try (BufferedReader reader = new BufferedReader(new InputStreamReader(in))) {
> 475:                     String line;
> 476:                     while ((line = reader.readLine()) != null) {

Consider using `BufferedReader.lines`

https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/io/BufferedReader.html#lines()

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

PR Review: https://git.openjdk.org/jdk/pull/17633#pullrequestreview-1891318432
PR Review Comment: https://git.openjdk.org/jdk/pull/17633#discussion_r1496355484
PR Review Comment: https://git.openjdk.org/jdk/pull/17633#discussion_r1496357502

From ihse at openjdk.org  Tue Feb 20 20:06:06 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 20 Feb 2024 20:06:06 GMT
Subject: RFR: 8326368: compare.sh -2bins prints ugly errors on Windows
Message-ID: <_6gi71aRBRRPmsBiuqacMBChoXnepDabZPOXn9_Xiac=.2db7f5b0-4626-43cc-b98b-1fc5077c817e@github.com>

The logic in the compare script assumes that we compare two directories, and so always have an `$OTHER`. If we are using `-2dirs`, this is not the case, causing `cygpath` and the following `ls` to fail and print error messages about missing paths. These are benign but annoying.

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

Commit messages:
 - 8326368: compare.sh -2bins prints ugly errors on Windows

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

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

From erikj at openjdk.org  Tue Feb 20 21:01:56 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 20 Feb 2024 21:01:56 GMT
Subject: RFR: 8325963: Clean up NativeCompilation.gmk and its newly created
 parts [v3]
In-Reply-To: <hxwG3cmQqWbHhJfwZ6H4cWY9QPBi8Pm1z3s2Xaija9Q=.84bacbe8-36e0-4c22-8c5a-f9f421f43b43@github.com>
References: <Urd9k-uHcIG6vau9ryCuZhGBRB6TJsiB0W7Egn9CeNI=.0cc3c88d-c80d-4b7a-bed8-387832147f90@github.com>
 <hxwG3cmQqWbHhJfwZ6H4cWY9QPBi8Pm1z3s2Xaija9Q=.84bacbe8-36e0-4c22-8c5a-f9f421f43b43@github.com>
Message-ID: <QbEYtCDaQOq-MXbjPB71LXFNcEYL8T8crENg0b5eh0Y=.bb7ea732-9f23-49dc-9616-e51c64d85c3b@github.com>

On Tue, 20 Feb 2024 19:02:12 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is a follow-up to [JDK-8325877](https://bugs.openjdk.org/browse/JDK-8325877). I was careful in that bug not to change order of any lines, only split up the original file into parts.
>> 
>> In this PR, I use the new structure to improve the design. I collect the functionality into three clearly separate phases, preparation, compilation and linking. I use consistent naming to reveal whether a function just sets up variables, or create output. I simplify and split up a few extra hard to read functions. I move some code around so it is placed more logically.
>> 
>> It can be hard to convince yourself that the changes are correct if you just look at the end result. I have tried to make small and clear changes in each separate commit, and to explain in the commit title what I am doing. I recommend reviewing this PR [commit by commit](https://github.com/openjdk/jdk/pull/17873/commits).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Better fix for "macro"

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17873#pullrequestreview-1891576464

From erikj at openjdk.org  Tue Feb 20 21:03:54 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 20 Feb 2024 21:03:54 GMT
Subject: RFR: 8326368: compare.sh -2bins prints ugly errors on Windows
In-Reply-To: <_6gi71aRBRRPmsBiuqacMBChoXnepDabZPOXn9_Xiac=.2db7f5b0-4626-43cc-b98b-1fc5077c817e@github.com>
References: <_6gi71aRBRRPmsBiuqacMBChoXnepDabZPOXn9_Xiac=.2db7f5b0-4626-43cc-b98b-1fc5077c817e@github.com>
Message-ID: <RQWmSt2THzNK0xwyeyLwtiTB2wY8iKeS_IEJgCqiTKc=.3db79089-b16b-4847-bc4d-62bc2ed2b14d@github.com>

On Tue, 20 Feb 2024 20:01:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The logic in the compare script assumes that we compare two directories, and so always have an `$OTHER`. If we are using `-2dirs`, this is not the case, causing `cygpath` and the following `ls` to fail and print error messages about missing paths. These are benign but annoying.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17936#pullrequestreview-1891578612

From ihse at openjdk.org  Tue Feb 20 22:26:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 20 Feb 2024 22:26:57 GMT
Subject: Integrated: 8326368: compare.sh -2bins prints ugly errors on Windows
In-Reply-To: <_6gi71aRBRRPmsBiuqacMBChoXnepDabZPOXn9_Xiac=.2db7f5b0-4626-43cc-b98b-1fc5077c817e@github.com>
References: <_6gi71aRBRRPmsBiuqacMBChoXnepDabZPOXn9_Xiac=.2db7f5b0-4626-43cc-b98b-1fc5077c817e@github.com>
Message-ID: <g4MjqSAM6COIdy40HNuupN_IT5KBgWPKieQtHfC-eOs=.83ae95cb-f49e-4f26-9435-f6a7559ac8da@github.com>

On Tue, 20 Feb 2024 20:01:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The logic in the compare script assumes that we compare two directories, and so always have an `$OTHER`. If we are using `-2dirs`, this is not the case, causing `cygpath` and the following `ls` to fail and print error messages about missing paths. These are benign but annoying.

This pull request has now been integrated.

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

8326368: compare.sh -2bins prints ugly errors on Windows

Reviewed-by: erikj

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

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

From ihse at openjdk.org  Tue Feb 20 22:27:58 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 20 Feb 2024 22:27:58 GMT
Subject: Integrated: 8325963: Clean up NativeCompilation.gmk and its newly
 created parts
In-Reply-To: <Urd9k-uHcIG6vau9ryCuZhGBRB6TJsiB0W7Egn9CeNI=.0cc3c88d-c80d-4b7a-bed8-387832147f90@github.com>
References: <Urd9k-uHcIG6vau9ryCuZhGBRB6TJsiB0W7Egn9CeNI=.0cc3c88d-c80d-4b7a-bed8-387832147f90@github.com>
Message-ID: <VVPSITel_Es9ZJ-aORl2DJPT13KD8BYX4OXmFBhwuOM=.4b4287a5-c9d4-48a8-94b3-7682a7049f6b@github.com>

On Thu, 15 Feb 2024 14:13:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up to [JDK-8325877](https://bugs.openjdk.org/browse/JDK-8325877). I was careful in that bug not to change order of any lines, only split up the original file into parts.
> 
> In this PR, I use the new structure to improve the design. I collect the functionality into three clearly separate phases, preparation, compilation and linking. I use consistent naming to reveal whether a function just sets up variables, or create output. I simplify and split up a few extra hard to read functions. I move some code around so it is placed more logically.
> 
> It can be hard to convince yourself that the changes are correct if you just look at the end result. I have tried to make small and clear changes in each separate commit, and to explain in the commit title what I am doing. I recommend reviewing this PR [commit by commit](https://github.com/openjdk/jdk/pull/17873/commits).

This pull request has now been integrated.

Changeset: 1bd91cde
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1bd91cdebee1e9ec78ecf185529923eef40ff89c
Stats:     389 lines in 6 files changed: 134 ins; 130 del; 125 mod

8325963: Clean up NativeCompilation.gmk and its newly created parts

Reviewed-by: jwaters, erikj

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

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

From dholmes at openjdk.org  Wed Feb 21 01:03:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Feb 2024 01:03:12 GMT
Subject: RFR: 8326371: [BACKOUT] Clean up NativeCompilation.gmk and its newly
 created parts
Message-ID: <HP9sRXbsS8zVOyIXSWe7xfXMICQN9w2Auf55LldsnK4=.399aed4d-fb29-4407-b6de-f39414600f98@github.com>

Revert "8325963: Clean up NativeCompilation.gmk and its newly created parts"

This reverts commit 1bd91cdebee1e9ec78ecf185529923eef40ff89c due to code signing failures on macOS.

Thanks

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

Commit messages:
 - Revert "8325963: Clean up NativeCompilation.gmk and its newly created parts"

Changes: https://git.openjdk.org/jdk/pull/17938/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17938&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326371
  Stats: 379 lines in 6 files changed: 120 ins; 124 del; 135 mod
  Patch: https://git.openjdk.org/jdk/pull/17938.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17938/head:pull/17938

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

From mikael at openjdk.org  Wed Feb 21 01:17:59 2024
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 21 Feb 2024 01:17:59 GMT
Subject: RFR: 8326371: [BACKOUT] Clean up NativeCompilation.gmk and its
 newly created parts
In-Reply-To: <HP9sRXbsS8zVOyIXSWe7xfXMICQN9w2Auf55LldsnK4=.399aed4d-fb29-4407-b6de-f39414600f98@github.com>
References: <HP9sRXbsS8zVOyIXSWe7xfXMICQN9w2Auf55LldsnK4=.399aed4d-fb29-4407-b6de-f39414600f98@github.com>
Message-ID: <_usqObiWZ_pLY-ujIjUzXIuzDFawqB2oqglqNgF14UI=.eec4e2c5-a246-4944-b4fd-2bcf76b5ccbe@github.com>

On Wed, 21 Feb 2024 00:59:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Revert "8325963: Clean up NativeCompilation.gmk and its newly created parts"
> 
> This reverts commit 1bd91cdebee1e9ec78ecf185529923eef40ff89c due to code signing failures on macOS.
> 
> Thanks

Marked as reviewed by mikael (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17938#pullrequestreview-1891863168

From dholmes at openjdk.org  Wed Feb 21 01:17:59 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Feb 2024 01:17:59 GMT
Subject: RFR: 8326371: [BACKOUT] Clean up NativeCompilation.gmk and its
 newly created parts
In-Reply-To: <_usqObiWZ_pLY-ujIjUzXIuzDFawqB2oqglqNgF14UI=.eec4e2c5-a246-4944-b4fd-2bcf76b5ccbe@github.com>
References: <HP9sRXbsS8zVOyIXSWe7xfXMICQN9w2Auf55LldsnK4=.399aed4d-fb29-4407-b6de-f39414600f98@github.com>
 <_usqObiWZ_pLY-ujIjUzXIuzDFawqB2oqglqNgF14UI=.eec4e2c5-a246-4944-b4fd-2bcf76b5ccbe@github.com>
Message-ID: <Ew4DGzxkxN5nTH6mFT_ZqSzaTea9ztap5asEApBpaWo=.68e26bf1-450f-4ae1-b08a-bc7e3654224f@github.com>

On Wed, 21 Feb 2024 01:12:40 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> Revert "8325963: Clean up NativeCompilation.gmk and its newly created parts"
>> 
>> This reverts commit 1bd91cdebee1e9ec78ecf185529923eef40ff89c due to code signing failures on macOS.
>> 
>> Thanks
>
> Marked as reviewed by mikael (Reviewer).

Thanks for the review @vidmik !

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

PR Comment: https://git.openjdk.org/jdk/pull/17938#issuecomment-1955638459

From dholmes at openjdk.org  Wed Feb 21 01:18:00 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Feb 2024 01:18:00 GMT
Subject: Integrated: 8326371: [BACKOUT] Clean up NativeCompilation.gmk and its
 newly created parts
In-Reply-To: <HP9sRXbsS8zVOyIXSWe7xfXMICQN9w2Auf55LldsnK4=.399aed4d-fb29-4407-b6de-f39414600f98@github.com>
References: <HP9sRXbsS8zVOyIXSWe7xfXMICQN9w2Auf55LldsnK4=.399aed4d-fb29-4407-b6de-f39414600f98@github.com>
Message-ID: <na9Cw8kh0cs270AGPO687FGl6DA4ZbnCoRc2hJU0SFM=.4089fadd-54ab-4cf4-8b61-6ec9c1cefa05@github.com>

On Wed, 21 Feb 2024 00:59:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Revert "8325963: Clean up NativeCompilation.gmk and its newly created parts"
> 
> This reverts commit 1bd91cdebee1e9ec78ecf185529923eef40ff89c due to code signing failures on macOS.
> 
> Thanks

This pull request has now been integrated.

Changeset: 14f9aba9
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/14f9aba921c811eebc78d871aa24915412a19e14
Stats:     379 lines in 6 files changed: 120 ins; 124 del; 135 mod

8326371: [BACKOUT] Clean up NativeCompilation.gmk and its newly created parts

Reviewed-by: mikael

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

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

From ihse at openjdk.org  Wed Feb 21 12:16:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Feb 2024 12:16:15 GMT
Subject: RFR: 8326375: [REDO] Clean up NativeCompilation.gmk and its newly
 created parts
Message-ID: <HphLf3bIXYsYo6RzmcQe5_mjuLpxFOeUDl6z4zUN_UQ=.78bbec22-bb81-4b26-8afd-bbf6876c7f8d@github.com>

This is a redo of [JDK-8325963](https://bugs.openjdk.org/browse/JDK-8325963). The original patch caused problems on the Oracle internal CI system, and was backed out.

The difference in this patch is that `GetEntitlementsFile` can now work stand-alone if called from a custom makefile. This can be seen in a [separate commit](https://github.com/openjdk/jdk/pull/17946/commits/394bb7c2994b59e1cf977fc5e664643d0a365f78) for ease of reviewing.

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

Commit messages:
 - Make sure GetEntitlementsFile can be called from custom makefiles.
 - 8326375: [REDO] Clean up NativeCompilation.gmk and its newly created parts

Changes: https://git.openjdk.org/jdk/pull/17946/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17946&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326375
  Stats: 374 lines in 6 files changed: 127 ins; 122 del; 125 mod
  Patch: https://git.openjdk.org/jdk/pull/17946.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17946/head:pull/17946

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

From jwaters at openjdk.org  Wed Feb 21 12:42:53 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 21 Feb 2024 12:42:53 GMT
Subject: RFR: 8326375: [REDO] Clean up NativeCompilation.gmk and its newly
 created parts
In-Reply-To: <HphLf3bIXYsYo6RzmcQe5_mjuLpxFOeUDl6z4zUN_UQ=.78bbec22-bb81-4b26-8afd-bbf6876c7f8d@github.com>
References: <HphLf3bIXYsYo6RzmcQe5_mjuLpxFOeUDl6z4zUN_UQ=.78bbec22-bb81-4b26-8afd-bbf6876c7f8d@github.com>
Message-ID: <hjo2yR5E3ir_El7CQCR7oNryJEDCznVVPL_RV3lJGPQ=.ec98279d-8ae6-4ff4-90b7-bbe7f5d24e68@github.com>

On Wed, 21 Feb 2024 11:36:34 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a redo of [JDK-8325963](https://bugs.openjdk.org/browse/JDK-8325963). The original patch caused problems on the Oracle internal CI system, and was backed out.
> 
> The difference in this patch is that `GetEntitlementsFile` can now work stand-alone if called from a custom makefile. This can be seen in a [separate commit](https://github.com/openjdk/jdk/pull/17946/commits/394bb7c2994b59e1cf977fc5e664643d0a365f78) for ease of reviewing.

Marked as reviewed by jwaters (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/17946#pullrequestreview-1893089855

From ihse at openjdk.org  Wed Feb 21 13:19:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Feb 2024 13:19:00 GMT
Subject: RFR: 8326412: debuginfo files should not have executable bit set
Message-ID: <uAWwDdJicVpg-e6cCBG7qRe8zrISnFYZBG_ExbiQDE4=.2910d3e3-bd46-4da2-9397-77f29934a9d2@github.com>

When we create our debuginfo files on linux, we use objcopy to create a copy of the corresponding lib*.so or executable. In the latter case, objcopy will keep the executable bit. While this is a reasonable assumption for objcopy, we really treat the debuginfo files as data, not as executables in their own right, so we should strip the executable bit.

This was found when working with [JDK-8325342](https://bugs.openjdk.org/browse/JDK-8325342), and I there attempted to properly locate all executables and only executables.

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

Commit messages:
 - 8326412: debuginfo files should not have executable bit set

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

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

From erikj at openjdk.org  Wed Feb 21 13:39:54 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 21 Feb 2024 13:39:54 GMT
Subject: RFR: 8326375: [REDO] Clean up NativeCompilation.gmk and its newly
 created parts
In-Reply-To: <HphLf3bIXYsYo6RzmcQe5_mjuLpxFOeUDl6z4zUN_UQ=.78bbec22-bb81-4b26-8afd-bbf6876c7f8d@github.com>
References: <HphLf3bIXYsYo6RzmcQe5_mjuLpxFOeUDl6z4zUN_UQ=.78bbec22-bb81-4b26-8afd-bbf6876c7f8d@github.com>
Message-ID: <ojM2CERDdB6m6urkKDmXCDV7lbl664lBYe0tMq9uDD8=.daba27f0-4648-4fe5-beed-1091c2071b4c@github.com>

On Wed, 21 Feb 2024 11:36:34 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a redo of [JDK-8325963](https://bugs.openjdk.org/browse/JDK-8325963). The original patch caused problems on the Oracle internal CI system, and was backed out.
> 
> The difference in this patch is that `GetEntitlementsFile` can now work stand-alone if called from a custom makefile. This can be seen in a [separate commit](https://github.com/openjdk/jdk/pull/17946/commits/394bb7c2994b59e1cf977fc5e664643d0a365f78) for ease of reviewing.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17946#pullrequestreview-1893231000

From erikj at openjdk.org  Wed Feb 21 13:40:56 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 21 Feb 2024 13:40:56 GMT
Subject: RFR: 8326412: debuginfo files should not have executable bit set
In-Reply-To: <uAWwDdJicVpg-e6cCBG7qRe8zrISnFYZBG_ExbiQDE4=.2910d3e3-bd46-4da2-9397-77f29934a9d2@github.com>
References: <uAWwDdJicVpg-e6cCBG7qRe8zrISnFYZBG_ExbiQDE4=.2910d3e3-bd46-4da2-9397-77f29934a9d2@github.com>
Message-ID: <6NGu91_x_bPMQyWamk7DHoY1M3mqhXp4zZ2NS5d1eE4=.f5885013-c1f3-4f10-b670-eeddae7d9998@github.com>

On Wed, 21 Feb 2024 13:15:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> When we create our debuginfo files on linux, we use objcopy to create a copy of the corresponding lib*.so or executable. In the latter case, objcopy will keep the executable bit. While this is a reasonable assumption for objcopy, we really treat the debuginfo files as data, not as executables in their own right, so we should strip the executable bit.
> 
> This was found when working with [JDK-8325342](https://bugs.openjdk.org/browse/JDK-8325342), and I there attempted to properly locate all executables and only executables.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17947#pullrequestreview-1893232904

From ihse at openjdk.org  Wed Feb 21 13:46:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Feb 2024 13:46:59 GMT
Subject: Integrated: 8326375: [REDO] Clean up NativeCompilation.gmk and its
 newly created parts
In-Reply-To: <HphLf3bIXYsYo6RzmcQe5_mjuLpxFOeUDl6z4zUN_UQ=.78bbec22-bb81-4b26-8afd-bbf6876c7f8d@github.com>
References: <HphLf3bIXYsYo6RzmcQe5_mjuLpxFOeUDl6z4zUN_UQ=.78bbec22-bb81-4b26-8afd-bbf6876c7f8d@github.com>
Message-ID: <OdQQ9z6b9vFh3DHv0KESYyTQ9yBs7R6gCDLVxQV1tbU=.70210e15-c7db-4a9d-894f-9957cd9e4c1c@github.com>

On Wed, 21 Feb 2024 11:36:34 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a redo of [JDK-8325963](https://bugs.openjdk.org/browse/JDK-8325963). The original patch caused problems on the Oracle internal CI system, and was backed out.
> 
> The difference in this patch is that `GetEntitlementsFile` can now work stand-alone if called from a custom makefile. This can be seen in a [separate commit](https://github.com/openjdk/jdk/pull/17946/commits/394bb7c2994b59e1cf977fc5e664643d0a365f78) for ease of reviewing.

This pull request has now been integrated.

Changeset: 33834b7d
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/33834b7d14de8cca1587d8405d13aec669b6cc23
Stats:     374 lines in 6 files changed: 127 ins; 122 del; 125 mod

8326375: [REDO] Clean up NativeCompilation.gmk and its newly created parts

Reviewed-by: jwaters, erikj

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

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

From ihse at openjdk.org  Wed Feb 21 14:12:58 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Feb 2024 14:12:58 GMT
Subject: Integrated: 8326412: debuginfo files should not have executable bit
 set
In-Reply-To: <uAWwDdJicVpg-e6cCBG7qRe8zrISnFYZBG_ExbiQDE4=.2910d3e3-bd46-4da2-9397-77f29934a9d2@github.com>
References: <uAWwDdJicVpg-e6cCBG7qRe8zrISnFYZBG_ExbiQDE4=.2910d3e3-bd46-4da2-9397-77f29934a9d2@github.com>
Message-ID: <54tCN5lbwFXs5iCz0XTMIVpRmV0QwCXf2AwQJR8a-nQ=.c2204f0c-c04f-4af6-9820-76399b90467f@github.com>

On Wed, 21 Feb 2024 13:15:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> When we create our debuginfo files on linux, we use objcopy to create a copy of the corresponding lib*.so or executable. In the latter case, objcopy will keep the executable bit. While this is a reasonable assumption for objcopy, we really treat the debuginfo files as data, not as executables in their own right, so we should strip the executable bit.
> 
> This was found when working with [JDK-8325342](https://bugs.openjdk.org/browse/JDK-8325342), and I there attempted to properly locate all executables and only executables.

This pull request has now been integrated.

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

8326412: debuginfo files should not have executable bit set

Reviewed-by: erikj

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

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

From ihse at openjdk.org  Wed Feb 21 17:27:21 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Feb 2024 17:27:21 GMT
Subject: RFR: 8325342: Remove unneeded exceptions in compare.sh [v2]
In-Reply-To: <q_YwcRN3VaNpSve_xwZZkZUbMVN-4buHoiN1X-I_8s4=.945a33f3-6331-423e-afdd-bdd00933a474@github.com>
References: <q_YwcRN3VaNpSve_xwZZkZUbMVN-4buHoiN1X-I_8s4=.945a33f3-6331-423e-afdd-bdd00933a474@github.com>
Message-ID: <txQM7lySCHVAYyXi236007RnKvW_JZgoim8dq7JhuH0=.ab9126d4-11f1-4833-9a72-fe4a238c7e17@github.com>

> Over time, we have been better at addressing inconsistencies in the build, but the exceptions put in place in compare.sh have not been updated to reflect this.
> 
> This attempts to make sure we only keep those exceptions that are currently actually needed to verify a reproducible build (the primary usecase for the compare script these days).
> 
> I also discovered bugs in the script, where mismatches in a zip file did not make us report a failed comparison. I added extra code to make sure we always set the REGRESSION flag whenever we detect a problem.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:

 - Restore jar_contents exception
 - Do not compare .pdb files
 - Assume GraphViz non-determinism has been fixed in 9.0
 - Remove jar_contents exception
 - Test debug symbol files separately, for clarity
 - Merge branch 'master' into remove-compare-exceptions
 - Also fix windows debug files
 - Do not make debuginfo files executable
 - Add support for linux debug files
 - Separate out debug files
 - ... and 7 more: https://git.openjdk.org/jdk/compare/ea3a6757...2db17083

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17735/files
  - new: https://git.openjdk.org/jdk/pull/17735/files/5a4efc40..2db17083

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

  Stats: 37386 lines in 1230 files changed: 16781 ins; 13112 del; 7493 mod
  Patch: https://git.openjdk.org/jdk/pull/17735.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17735/head:pull/17735

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

From ihse at openjdk.org  Wed Feb 21 17:27:21 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Feb 2024 17:27:21 GMT
Subject: RFR: 8325342: Remove unneeded exceptions in compare.sh
In-Reply-To: <q_YwcRN3VaNpSve_xwZZkZUbMVN-4buHoiN1X-I_8s4=.945a33f3-6331-423e-afdd-bdd00933a474@github.com>
References: <q_YwcRN3VaNpSve_xwZZkZUbMVN-4buHoiN1X-I_8s4=.945a33f3-6331-423e-afdd-bdd00933a474@github.com>
Message-ID: <35veckPxoklbolF-QyLpwLQ6YmmkVUmQDGlGcH_3OLc=.dc0a4773-932d-446c-a8ed-cdc4dfa64c0e@github.com>

On Tue, 6 Feb 2024 16:53:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Over time, we have been better at addressing inconsistencies in the build, but the exceptions put in place in compare.sh have not been updated to reflect this.
> 
> This attempts to make sure we only keep those exceptions that are currently actually needed to verify a reproducible build (the primary usecase for the compare script these days).
> 
> I also discovered bugs in the script, where mismatches in a zip file did not make us report a failed comparison. I added extra code to make sure we always set the REGRESSION flag whenever we detect a problem.

I will actually rework how files are selected completely.

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

PR Comment: https://git.openjdk.org/jdk/pull/17735#issuecomment-1938940767

From ihse at openjdk.org  Wed Feb 21 17:29:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Feb 2024 17:29:54 GMT
Subject: RFR: 8325342: Remove unneeded exceptions in compare.sh
In-Reply-To: <q_YwcRN3VaNpSve_xwZZkZUbMVN-4buHoiN1X-I_8s4=.945a33f3-6331-423e-afdd-bdd00933a474@github.com>
References: <q_YwcRN3VaNpSve_xwZZkZUbMVN-4buHoiN1X-I_8s4=.945a33f3-6331-423e-afdd-bdd00933a474@github.com>
Message-ID: <v8bc27uummF1g2nCMQfT4MLewUwpuu6NXTFfi4lcTPg=.a3c34afb-f567-4d7c-9a56-6ab44120ea98@github.com>

On Tue, 6 Feb 2024 16:53:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Over time, we have been better at addressing inconsistencies in the build, but the exceptions put in place in compare.sh have not been updated to reflect this.
> 
> This attempts to make sure we only keep those exceptions that are currently actually needed to verify a reproducible build (the primary usecase for the compare script these days).
> 
> I also discovered bugs in the script, where mismatches in a zip file did not make us report a failed comparison. I added extra code to make sure we always set the REGRESSION flag whenever we detect a problem.

Ok, new try. I have redesigned how we discover files. Now we start by finding *all* files that we should compare, and then we partition out libs, zips, etc. What remains are the "other" files, so we will be sure to always check every file. I split up "other" files in two parts, debug symbol files and the "other" files proper.

I have also removed a few more exceptions I found. I have run this like 7-8 times in our CI system to check that we did not get any intermittent failures. They might still be possible, but at least they are somewhat rare. If they show up, we'll just have to reinstantiate the exception, and perhaps document it better, so we know when we can actually remove it.

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

PR Comment: https://git.openjdk.org/jdk/pull/17735#issuecomment-1957399340

From erikj at openjdk.org  Wed Feb 21 17:51:56 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 21 Feb 2024 17:51:56 GMT
Subject: RFR: 8325342: Remove unneeded exceptions in compare.sh [v2]
In-Reply-To: <txQM7lySCHVAYyXi236007RnKvW_JZgoim8dq7JhuH0=.ab9126d4-11f1-4833-9a72-fe4a238c7e17@github.com>
References: <q_YwcRN3VaNpSve_xwZZkZUbMVN-4buHoiN1X-I_8s4=.945a33f3-6331-423e-afdd-bdd00933a474@github.com>
 <txQM7lySCHVAYyXi236007RnKvW_JZgoim8dq7JhuH0=.ab9126d4-11f1-4833-9a72-fe4a238c7e17@github.com>
Message-ID: <AqHAGshyOsxcFRN3w0Vh81vTLYvWw_Diq2RgXf5si7c=.25324b48-019a-49bb-97f9-10e658ca2a8d@github.com>

On Wed, 21 Feb 2024 17:27:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Over time, we have been better at addressing inconsistencies in the build, but the exceptions put in place in compare.sh have not been updated to reflect this.
>> 
>> This attempts to make sure we only keep those exceptions that are currently actually needed to verify a reproducible build (the primary usecase for the compare script these days).
>> 
>> I also discovered bugs in the script, where mismatches in a zip file did not make us report a failed comparison. I added extra code to make sure we always set the REGRESSION flag whenever we detect a problem.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Restore jar_contents exception
>  - Do not compare .pdb files
>  - Assume GraphViz non-determinism has been fixed in 9.0
>  - Remove jar_contents exception
>  - Test debug symbol files separately, for clarity
>  - Merge branch 'master' into remove-compare-exceptions
>  - Also fix windows debug files
>  - Do not make debuginfo files executable
>  - Add support for linux debug files
>  - Separate out debug files
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/7781005f...2db17083

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17735#pullrequestreview-1894022381

From prr at openjdk.org  Wed Feb 21 22:26:55 2024
From: prr at openjdk.org (Phil Race)
Date: Wed, 21 Feb 2024 22:26:55 GMT
Subject: RFR: 8324243: Fix GCC 14 build
In-Reply-To: <5kNFvGNmbfMBSsbDDQdI9zFRT_MGovHUIqj0x71qTR4=.60349dfd-45e6-4e8d-b012-f13691387554@github.com>
References: <PmU0wltBwGECZ_1D3iQA3WCZE-evJ-Exf9f51-hXdBc=.353a8bb3-79e9-46e0-a85a-c53f62efa8aa@github.com>
 <5kNFvGNmbfMBSsbDDQdI9zFRT_MGovHUIqj0x71qTR4=.60349dfd-45e6-4e8d-b012-f13691387554@github.com>
Message-ID: <GLYcW_TilJMKYWtl_JbJXJ1PbcO-lvFhOv9po9iMR78=.c7520f94-63ee-475b-aa1f-ad5e6c18f6fd@github.com>

On Sun, 21 Jan 2024 16:55:45 GMT, Sam James <duke at openjdk.org> wrote:

>> This fixes building with GCC 14:
>> * ~Cherry-pick a fix from Harfbuzz upstream~
>> * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources
>> 
>> -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses
>> -Werror.
>> 
>> The calloc prototype is:
>> 
>> void *calloc(size_t nmemb, size_t size);
>> 
>> 
>> So, just swap the number of members and size arguments to match the prototype, as
>> we're initialising 1 struct of size `sizeof(struct ...)`. GCC then sees we're not
>> doing anything wrong.
>
> Ah, yes! FWIW, I'm still disappointed about that as well (I don't have any sort of power, just tend to do a lot of triage). Do consider sending it again when stage 1 opens again after GCC 14 is out. Persistence is key with GCC, even if your change isn't an objectionable one. It took me a little while to get used to that..

@thesamesam you need to fix the PR title to match the JBS issue just as the bot is instructing you.
Then the bots should mark this "ready" to push.

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

PR Comment: https://git.openjdk.org/jdk/pull/17506#issuecomment-1958137002

From ihse at openjdk.org  Wed Feb 21 22:37:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Feb 2024 22:37:57 GMT
Subject: Integrated: 8325342: Remove unneeded exceptions in compare.sh
In-Reply-To: <q_YwcRN3VaNpSve_xwZZkZUbMVN-4buHoiN1X-I_8s4=.945a33f3-6331-423e-afdd-bdd00933a474@github.com>
References: <q_YwcRN3VaNpSve_xwZZkZUbMVN-4buHoiN1X-I_8s4=.945a33f3-6331-423e-afdd-bdd00933a474@github.com>
Message-ID: <RN_TIGgLucxLbW1a_yY76U8K_HU55YEu0V79Kbs4gjg=.20dd7292-0bcd-413e-aa83-61b061f4b0d9@github.com>

On Tue, 6 Feb 2024 16:53:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Over time, we have been better at addressing inconsistencies in the build, but the exceptions put in place in compare.sh have not been updated to reflect this.
> 
> This attempts to make sure we only keep those exceptions that are currently actually needed to verify a reproducible build (the primary usecase for the compare script these days).
> 
> I also discovered bugs in the script, where mismatches in a zip file did not make us report a failed comparison. I added extra code to make sure we always set the REGRESSION flag whenever we detect a problem.

This pull request has now been integrated.

Changeset: 0bcece99
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0bcece995840777db660811e4b20bb018e90439b
Stats:     352 lines in 2 files changed: 137 ins; 167 del; 48 mod

8325342: Remove unneeded exceptions in compare.sh

Reviewed-by: erikj

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

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

From ihse at openjdk.org  Wed Feb 21 23:37:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Feb 2024 23:37:00 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
Message-ID: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>

**Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and JNIEXPORT on all platforms.

The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.

This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.

I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

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

Commit messages:
 - 8017234: Hotspot should stop using mapfiles

Changes: https://git.openjdk.org/jdk/pull/17955/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17955&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8017234
  Stats: 990 lines in 32 files changed: 229 ins; 578 del; 183 mod
  Patch: https://git.openjdk.org/jdk/pull/17955.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17955/head:pull/17955

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

From ihse at openjdk.org  Wed Feb 21 23:37:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Feb 2024 23:37:01 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <g0ZVkeeR7P1e4_8Z0-nQ8at63jrtZySDk8bKtub0mLw=.db5e4e9c-9ca6-4d5a-b31b-17f84981e14f@github.com>

On Wed, 21 Feb 2024 23:32:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and JNIEXPORT on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

First some general notes on related build changes: This was the last place in the build system where mapfiles where used. It will now be possible to clean up a lot of this framework, but I will do that separately after this has been integrated. Also, Hotspot is now built much closer to the rest of the native libraries in the JDK, so there is potential for more unification (e.g. placing `--exclude-libs,ALL` in a common location). This too will be done separately. 

On Windows, we still need to do the dance of finding symbols from the object files, and add them to a list of exported files (included by `-def:`). I decoupled this logic away from the old mapfile stuff, so we can safely delete the mapfile code later on. So what might look like new code in `CompileJvm.gmk` is actually just old code from `JvmMapfile.gmk` that I have cleaned up somewhat. These symbols are consumed by SA. It might be that we can limit the amount of symbols exported this way, or maybe that we can find another solution completely in SA, but that will have to be a future topic for research. For now, we keep the same exported symbols.

I have checked the resulting libjvm.so/jvm.dll using the `COMPARE_BUILD` functionality, which (among other things) analyzes differences between native libraries before and after a patch. This has verified that there is no change in the symbols of the Hotspot dynamic library on macOS/x64, macOS/aarch64 or Windows/x64. I have also gotten help from @MBaesken and @JoKern65 to confirmed that there is no effect on AIX (in fact, AIX never used the mapfile it created...). There are, however, a few minor changes on linux/x64 and linux/aarch64. I will discuss these below.

When I first started doing this conversion, I got a lot more differences. 

First of all, the `-fvisibility=hidden` flag does not apply to assembly files, so the symbols marked `.global` in these files also needed to be marked `.hidden`. (On macOS, Apple's clang assembler uses the directive `.private_extern` instead.) The assembly files had some inconsistent whitespace (using tabs instead of spaces every once in a while), which my editor kept changing, so I gave up and fixed all of them. This makes the diff artificially larger; if someone objects to this I can revert the whitespace changes.

Secondly, it turned out that there were several symbols declared `JNIEXPORT` that were not included in the symbol list, and hence were not exported on Linux. In contrast to Windows, which only relies on `JNIEXPORT`, on Linux it was necessary to both use `JNIEXPORT` and declare the symbol in the symbol list to get it actually exported. 

To be consistent with the old behavior, I have undefined `JNIEXPORT` in these files. It works to keep the output the same, but it does not look very nice. I suggest we either:

a) say we want to remove this `#undef` and actually export the functions annotated `JNIEXPORT`. This is what I would recommend. If so, let's keep the ugly undef for now, and I'll remove it in a follow-up bug. (I really would like not to change any behavior with this patch; it is intrusive enough as it is.)

b) say we really don't want to export these functions on Linux, only on Windows. In that case, we should probably replace `JNIEXPORT` with `FOO_EXPORT`, and define `FOO_EXPORT` to be `JNIEXPORT` on Windows, and blank on Linux.

This is a decision for the Hotspot team; let me know which solution you chose. (It can be different in different places, of course).

And thirdly, there seem to be a bug in gcc, which ignores the `-fvisibility=hidden` flag in certain circumstances involving templates. I could not pinpoint what conditions were necessary to trigger this bug, but in `accessBackend.cpp` I have manually added a `HIDDEN` attribute to a bunch of `arraycopy_conjoint` functions to keep them from being exported. It looks ugly; and we might be willing to accept that these functions are exported even though they should not be, to get rid of this. Or it might be that someone finds out if what is different with this declarations that trigger this bug, and constructs a work-around. (I gave up on it, though...)

About the  changes on linux/x64 and linux/aarch64: I believe the new values are in some way more correct, but I also think the difference is insignificant. The difference is that the  data (variable) symbols  `__bss_start`, `_edata` and `_end`, and the text (function) symbols `_fini` and `_init` has changed from local to global. Afaik, these are symbols created by the linker. Also, when we used a mapfile, the symbol `SUNWprivate_1.1` that was part of the mapfile definition was included in libjvm.so, and this is no longer the case. 

Finally, in the gtest libjvmo.so there are some additional differences as well. I did not really care about these, since this is only used for testing, but for the sake of completeness, here are the differences. They belong to two different categories. 

Group 1 includes four symbols like `_Z9type_nameIiEPKcv`. These come from this definition:

  template <typename T> const char* type_name();

in `test_parse_memory_size.cpp`, and is seemingly the same issue as with the `arraycopy_conjoint` functions in `accessBackend.cpp`. They have changed from local to global.

Group 2 includes symbols that seem to originate in the googletest library. They have changed
from local to global, but also to weak symbols. They match some different patterns:

* Seven symbols like `_ZNSt15_Sp_counted_ptrIPKN7testing8internal2REELN9__gnu_cxx12_Lock_policyE2EED2Ev`.
Demangled, these read `std::_Sp_counted_ptr<testing::internal::RE const*, (__gnu_cxx::_Lock_policy)2>`.

* One symbol `_ZN7testing15AssertionResultlsIA12_cEERS0_RKT_` (demangled: `testing::AssertionResult& testing::AssertionResult::operator<< <char [12]>(char const (&) [12])`)

* And finally, only on x64 (but not aarch64), one symbol `_ZN7testing4Test10HasFailureEv` (demangled: `testing::Test::HasFailure()`).

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

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1958337547

From magnus.ihse.bursie at oracle.com  Wed Feb 21 23:56:18 2024
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 00:56:18 +0100
Subject: Hotspot symbol visibility - surprising news!
In-Reply-To: <CAMrH03K+fB1p5cEyEwo-QL3BfEC6iuugdd9P=nDkHy8FCRAr0Q@mail.gmail.com>
References: <645132e0-687e-4f04-9e49-f90131294367@oracle.com>
 <ba822e64-2a9c-447f-b545-b7fda01c47ef@oracle.com>
 <CAMrH03K+fB1p5cEyEwo-QL3BfEC6iuugdd9P=nDkHy8FCRAr0Q@mail.gmail.com>
Message-ID: <542d7939-19f3-4e66-946e-a1470c36f2d5@oracle.com>

On 2024-02-19 17:43, Daniel Jeli?ski wrote:

> Hi Magnus,
>
> The "massive generated mapfile" is used on Windows. As you noticed, on
> Linux symbols are exported if they are both JNIEXPORT and listed in
> the mapfile. On Windows, the symbols are exported if they are either
> JNIEXPORT or listed in the mapfile. The Windows symbolicator needs to
> see the vftables to tell apart different object types, and these
> tables are only made available in the produced binaries through the
> mapfile. The Windows mapfile exports the vftables of every virtual
> class in libjvm, which is much more than the symbolicator actually
> needs, but that's probably a separate topic.
>
> The symbolicator on Linux does not need the mapfile.
>
> The assembly functions are correctly labelled with .globl; if we
> remove these declarations or change them to local, the code won't
> link. The right solution here is to also label them as .hidden, for
> example using this script:
>
>       sed -i -n 'p;s/\.globa\?l/.hidden/p' src/hotspot/os_cpu/*/*.S
>
> The symbols from the standard libraries are not exported by any of our
> binaries. Libjvm removes them via the use of mapfile, and all other
> libraries are linked with  -Wl,--exclude-libs,ALL; if you choose to
> remove the mapfile from libjvm, you'll need to add that parameter.

Thanks Daniel. It is clear that you have studied this in detail. I 
rediscovered most of what you said here on my journey to fix 
JDK-8017234. :-)

I guess that after the mapfile removal, it would make sense to see if we 
can simplify the process for SA on Windows. Maybe it is possible to 
steal a page from the Linux book and look into the .DLL file directly. 
And also see if there is a way to get the macOS symbolicator to work 
with core dumps, and not only live processes. This is apparently not 
working.

/Magnus



From jjg at openjdk.org  Thu Feb 22 00:17:29 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 22 Feb 2024 00:17:29 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v38]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <v4pGQYCagdT28cdABJW1F4NYIfyDmcmdQSHjER__oj4=.00669703-c320-4111-a791-3d2652e247fc@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with two additional commits since the last revision:

 - update DocCommentParser and tests to improve handling of code blocks and code spans in Markdown documentation comments
 - fix indentation, for consistency

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/25921fd0..5fc9c84a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=37
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=36-37

  Stats: 1240 lines in 4 files changed: 918 ins; 275 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/16388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388

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

From dholmes at openjdk.org  Thu Feb 22 00:20:52 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Feb 2024 00:20:52 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <g0ZVkeeR7P1e4_8Z0-nQ8at63jrtZySDk8bKtub0mLw=.db5e4e9c-9ca6-4d5a-b31b-17f84981e14f@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <g0ZVkeeR7P1e4_8Z0-nQ8at63jrtZySDk8bKtub0mLw=.db5e4e9c-9ca6-4d5a-b31b-17f84981e14f@github.com>
Message-ID: <Cd8440seSvfWXHBcZ8cx5K1qWcpf-qyET1IdFY8eWUo=.a64a2d4c-bd34-49fb-9167-8e4583add959@github.com>

On Wed, 21 Feb 2024 23:32:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> it turned out that there were several symbols declared JNIEXPORT that were not included in the symbol list, 

There appear to be two main categories of functions here:

1. Those intended for use from a debugger

Have you verified those functions can still be called from the debugger?

2. JVMCI

The Graal folk will need to chime in here as it may be that these are needed for libgraal.

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

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1958435740

From dholmes at openjdk.org  Thu Feb 22 00:32:52 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Feb 2024 00:32:52 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <qD5Ael_CjnuLVdZOdQ863VqU1KBJp1x7J1f3OPOJjcI=.fc651d8a-8640-405d-8339-bffc91b23050@github.com>

On Wed, 21 Feb 2024 23:32:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

My main concern with a change like this as that it likely has little effect on the OpenJDK itself, but we may be changing something that 3rd party applications linking with libjvm are relying on.  I realize this is a bit "hand wavy" but are we sure this presents the exact same view of libjvm as before?

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

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1958447138

From duke at openjdk.org  Thu Feb 22 01:44:01 2024
From: duke at openjdk.org (Sam James)
Date: Thu, 22 Feb 2024 01:44:01 GMT
Subject: RFR: JDK-8324243: Compilation failures in java.desktop module with
 gcc 14 [v3]
In-Reply-To: <HdMQd-rsi1Ry5jT7ffesgEm8kzjdD80VO3REUlzBQMs=.c52c56a1-b118-4833-afc9-08798afd6581@github.com>
References: <PmU0wltBwGECZ_1D3iQA3WCZE-evJ-Exf9f51-hXdBc=.353a8bb3-79e9-46e0-a85a-c53f62efa8aa@github.com>
 <HdMQd-rsi1Ry5jT7ffesgEm8kzjdD80VO3REUlzBQMs=.c52c56a1-b118-4833-afc9-08798afd6581@github.com>
Message-ID: <D8Ia7uicVoXSYYhN-Ioo370wc5ydSVzrNhmWgekmOTE=.50c748d0-b28f-4c63-acf6-5eea62447d32@github.com>

On Sat, 3 Feb 2024 10:07:26 GMT, Sam James <duke at openjdk.org> wrote:

>> This fixes building with GCC 14:
>> * ~Cherry-pick a fix from Harfbuzz upstream~
>> * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources
>> 
>> -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses
>> -Werror.
>> 
>> The calloc prototype is:
>> 
>> void *calloc(size_t nmemb, size_t size);
>> 
>> 
>> So, just swap the number of members and size arguments to match the prototype, as
>> we're initialising 1 struct of size `sizeof(struct ...)`. GCC then sees we're not
>> doing anything wrong.
>
> Sam James has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace

Thanks, I hadn't gone back and read the original comment.

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

PR Comment: https://git.openjdk.org/jdk/pull/17506#issuecomment-1958506042

From jwaters at openjdk.org  Thu Feb 22 06:30:07 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Feb 2024 06:30:07 GMT
Subject: RFR: JDK-8324243: Compilation failures in java.desktop module with
 gcc 14 [v3]
In-Reply-To: <HdMQd-rsi1Ry5jT7ffesgEm8kzjdD80VO3REUlzBQMs=.c52c56a1-b118-4833-afc9-08798afd6581@github.com>
References: <PmU0wltBwGECZ_1D3iQA3WCZE-evJ-Exf9f51-hXdBc=.353a8bb3-79e9-46e0-a85a-c53f62efa8aa@github.com>
 <HdMQd-rsi1Ry5jT7ffesgEm8kzjdD80VO3REUlzBQMs=.c52c56a1-b118-4833-afc9-08798afd6581@github.com>
Message-ID: <FUmtRQpu8PTX-9LZLFSlHqoZvrfLo7pUhPBnd5xhm_w=.ec9cdaf9-3de2-4d1c-bd98-90e37d68fb25@github.com>

On Sat, 3 Feb 2024 10:07:26 GMT, Sam James <duke at openjdk.org> wrote:

>> This fixes building with GCC 14:
>> * ~Cherry-pick a fix from Harfbuzz upstream~
>> * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources
>> 
>> -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses
>> -Werror.
>> 
>> The calloc prototype is:
>> 
>> void *calloc(size_t nmemb, size_t size);
>> 
>> 
>> So, just swap the number of members and size arguments to match the prototype, as
>> we're initialising 1 struct of size `sizeof(struct ...)`. GCC then sees we're not
>> doing anything wrong.
>
> Sam James has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace

Glad to have met you again in this Pull Request :)

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

PR Comment: https://git.openjdk.org/jdk/pull/17506#issuecomment-1958784779

From duke at openjdk.org  Thu Feb 22 06:30:07 2024
From: duke at openjdk.org (Sam James)
Date: Thu, 22 Feb 2024 06:30:07 GMT
Subject: Integrated: JDK-8324243: Compilation failures in java.desktop module
 with gcc 14
In-Reply-To: <PmU0wltBwGECZ_1D3iQA3WCZE-evJ-Exf9f51-hXdBc=.353a8bb3-79e9-46e0-a85a-c53f62efa8aa@github.com>
References: <PmU0wltBwGECZ_1D3iQA3WCZE-evJ-Exf9f51-hXdBc=.353a8bb3-79e9-46e0-a85a-c53f62efa8aa@github.com>
Message-ID: <-X1jq9XeFoJuGtHyepKxzpufsid3v8OITfUN59GlgPs=.e3948f16-4d5a-417b-a58c-988d753fe929@github.com>

On Sat, 20 Jan 2024 10:15:02 GMT, Sam James <duke at openjdk.org> wrote:

> This fixes building with GCC 14:
> * ~Cherry-pick a fix from Harfbuzz upstream~
> * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources
> 
> -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses
> -Werror.
> 
> The calloc prototype is:
> 
> void *calloc(size_t nmemb, size_t size);
> 
> 
> So, just swap the number of members and size arguments to match the prototype, as
> we're initialising 1 struct of size `sizeof(struct ...)`. GCC then sees we're not
> doing anything wrong.

This pull request has now been integrated.

Changeset: 8e5f6ddb
Author:    Sam James <sam at gentoo.org>
Committer: Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8e5f6ddb68572c0cc8b6e256e423706f6f7cec94
Stats:     6 lines in 4 files changed: 2 ins; 0 del; 4 mod

8324243: Compilation failures in java.desktop module with gcc 14

Reviewed-by: jwaters, ihse, kbarrett, prr

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

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

From duke at openjdk.org  Thu Feb 22 06:43:59 2024
From: duke at openjdk.org (Sam James)
Date: Thu, 22 Feb 2024 06:43:59 GMT
Subject: RFR: JDK-8324243: Compilation failures in java.desktop module with
 gcc 14 [v3]
In-Reply-To: <HdMQd-rsi1Ry5jT7ffesgEm8kzjdD80VO3REUlzBQMs=.c52c56a1-b118-4833-afc9-08798afd6581@github.com>
References: <PmU0wltBwGECZ_1D3iQA3WCZE-evJ-Exf9f51-hXdBc=.353a8bb3-79e9-46e0-a85a-c53f62efa8aa@github.com>
 <HdMQd-rsi1Ry5jT7ffesgEm8kzjdD80VO3REUlzBQMs=.c52c56a1-b118-4833-afc9-08798afd6581@github.com>
Message-ID: <jBnglka21JbKsrm59qtrdcLQPDoCpHUZL3CFIj9vir0=.90361df0-b16e-4fd3-a6a6-4cc8c6a02706@github.com>

On Sat, 3 Feb 2024 10:07:26 GMT, Sam James <duke at openjdk.org> wrote:

>> This fixes building with GCC 14:
>> * ~Cherry-pick a fix from Harfbuzz upstream~
>> * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources
>> 
>> -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses
>> -Werror.
>> 
>> The calloc prototype is:
>> 
>> void *calloc(size_t nmemb, size_t size);
>> 
>> 
>> So, just swap the number of members and size arguments to match the prototype, as
>> we're initialising 1 struct of size `sizeof(struct ...)`. GCC then sees we're not
>> doing anything wrong.
>
> Sam James has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace

Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/17506#issuecomment-1958804515

From jwaters at openjdk.org  Thu Feb 22 06:44:53 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Feb 2024 06:44:53 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <BAVHdaJzKtovZ1f0mrdLQI0AL_vGXRJJ2UG_w9DuCfs=.33111872-8fd0-4c06-9b23-0b41556a2cff@github.com>

On Wed, 21 Feb 2024 23:32:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

src/hotspot/share/oops/accessBackend.cpp line 36:

> 34: 
> 35: #if defined(TARGET_COMPILER_gcc)
> 36: #define HIDDEN __attribute__ ((visibility ("hidden")))

Couldn't this use [[gnu::visibility("hidden")]] instead, since HotSpot now allows C++14 Attributes? But this doesn't look like a very nice solution regardless

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498728906

From jwaters at openjdk.org  Thu Feb 22 07:15:53 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Feb 2024 07:15:53 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <17uxknoRrcfnUlWwJndQk2AWqvZv4v34JZMVQPpl81w=.34a2c1a8-d251-4f8c-bd12-2f024b4914e6@github.com>

On Wed, 21 Feb 2024 23:32:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

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

> 147: 
> 148: ifeq ($(call isTargetOs, windows), true)
> 149:   WIN_EXPORT_FILE := $(JVM_OUTPUTDIR)/win-exports.txt

Why not .def?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498758500

From djelinski at openjdk.org  Thu Feb 22 07:52:55 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 22 Feb 2024 07:52:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>

On Wed, 21 Feb 2024 23:32:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

Thanks for doing this! This is a good improvement IMO.

If the `SUNWprivate_1.1` part of the symbols is still needed, it can be added using `--default-symver` ld parameter.

You might want to run tier1-5 tests; compilation-related changes are often detected by higher-level builds and tests only.

src/hotspot/os_cpu/linux_arm/linux_arm_32.S line 35:

> 33:         .type SpinPause, %function
> 34:         .globl _Copy_conjoint_bytes
> 35:         .hidden _Copy_conjoint_bytes

This triggered a GHA failure... apparently the method `_Copy_conjoint_bytes` was removed a long time ago, and the `.globl` / `.type` declarations are the only things left. They should also be removed.

src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 74:

> 72: 
> 73: #if defined(TARGET_COMPILER_gcc)
> 74: #undef JNIEXPORT

Based on the suggestion in [this JBS comment](https://bugs.openjdk.org/browse/JDK-8017234?focusedId=14601421&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14601421), I think we can remove JNIEXPORT from all the functions in this file.

We need to keep the JNICALL though; the deprecated Win32 port needs it, not sure if it's used anywhere else.

src/hotspot/share/utilities/debug.cpp line 71:

> 69: 
> 70: #if defined(TARGET_COMPILER_gcc)
> 71: #undef JNIEXPORT

This partially reverts [JDK-8264593](https://bugs.openjdk.org/browse/JDK-8264593); @kevinjwalls will this work for you?

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

PR Review: https://git.openjdk.org/jdk/pull/17955#pullrequestreview-1895071246
PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498753308
PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498794516
PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498786497

From dnsimon at openjdk.org  Thu Feb 22 08:48:54 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 22 Feb 2024 08:48:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <Cd8440seSvfWXHBcZ8cx5K1qWcpf-qyET1IdFY8eWUo=.a64a2d4c-bd34-49fb-9167-8e4583add959@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <g0ZVkeeR7P1e4_8Z0-nQ8at63jrtZySDk8bKtub0mLw=.db5e4e9c-9ca6-4d5a-b31b-17f84981e14f@github.com>
 <Cd8440seSvfWXHBcZ8cx5K1qWcpf-qyET1IdFY8eWUo=.a64a2d4c-bd34-49fb-9167-8e4583add959@github.com>
Message-ID: <WgT5R65Kbubtx35Uyw2XAILZQZufGVOXOeS6oFk7tEk=.30c8ff36-82c7-4066-9a9e-ee3293f46810@github.com>

On Thu, 22 Feb 2024 00:18:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The Graal folk will need to chime in here as it may be that these are needed for libgraal.

They should be fine. JNI linkage is only used by the native methods in `CompilerToVM.java`.

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

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1958966709

From ihse at openjdk.org  Thu Feb 22 09:28:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 09:28:56 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <Cd8440seSvfWXHBcZ8cx5K1qWcpf-qyET1IdFY8eWUo=.a64a2d4c-bd34-49fb-9167-8e4583add959@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <g0ZVkeeR7P1e4_8Z0-nQ8at63jrtZySDk8bKtub0mLw=.db5e4e9c-9ca6-4d5a-b31b-17f84981e14f@github.com>
 <Cd8440seSvfWXHBcZ8cx5K1qWcpf-qyET1IdFY8eWUo=.a64a2d4c-bd34-49fb-9167-8e4583add959@github.com>
Message-ID: <-pzo3-C5dN9IRd4dv7k_j8E0i7jR578u1gst0U6iAFI=.34ce218c-3d3f-409a-9c60-315eaab370fa@github.com>

On Thu, 22 Feb 2024 00:18:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > it turned out that there were several symbols declared JNIEXPORT that were not included in the symbol list,
> 
> There appear to be two main categories of functions here:
> 
>     1. Those intended for use from a debugger
> 
> 
> Have you verified those functions can still be called from the debugger?
> 
>     2. JVMCI
> 
> 
> The Graal folk will need to chime in here as it may be that these are needed for libgraal.

I tried to be clear, but apparently I failed: There is *no* change to these symbols in the patch! So everything should work just as before!

The reason I even brought it up to discussion is that it required a bit of a "hack" to keep the functionality identical, and this looks suspicious in the source code.

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

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1959032516

From ihse at openjdk.org  Thu Feb 22 09:32:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 09:32:57 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <17uxknoRrcfnUlWwJndQk2AWqvZv4v34JZMVQPpl81w=.34a2c1a8-d251-4f8c-bd12-2f024b4914e6@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <17uxknoRrcfnUlWwJndQk2AWqvZv4v34JZMVQPpl81w=.34a2c1a8-d251-4f8c-bd12-2f024b4914e6@github.com>
Message-ID: <28TkIQvEbOiKscThXtUGZ24pcHI4wqrVgy6C2P6_f-4=.ae8dcc41-aedd-441c-a8ad-1526dd56db14@github.com>

On Thu, 22 Feb 2024 07:13:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> make/hotspot/lib/CompileJvm.gmk line 149:
> 
>> 147: 
>> 148: ifeq ($(call isTargetOs, windows), true)
>> 149:   WIN_EXPORT_FILE := $(JVM_OUTPUTDIR)/win-exports.txt
> 
> Why not .def?

I try to stick to established file suffixes if possible. I have never heard of .def before, but maybe that is a standard name for these kinds of files on Windows? If so, I will change it.

> src/hotspot/share/oops/accessBackend.cpp line 36:
> 
>> 34: 
>> 35: #if defined(TARGET_COMPILER_gcc)
>> 36: #define HIDDEN __attribute__ ((visibility ("hidden")))
> 
> Couldn't this use [[gnu::visibility("hidden")]] instead, since HotSpot now allows C++14 Attributes? But this doesn't look like a very nice solution regardless

We're currently using __attribute__ ((visibility ("X"))) elsewhere, so I think I should stick with that.

And, as I said in my long explanation, this is definitely a hack. The reason it is here is that I want to make sure the symbol table is 100% identical before and after this patch. 

Why this is needed, I don't know. I believe it is a bug in GCC, since we compile with -fvisibility=hidden. But I don't really know. Maybe there is something in the C++ standard that makes these functions behave differently. Perhaps they are even slightly incorrectly defined?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498935395
PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498933843

From ihse at openjdk.org  Thu Feb 22 09:39:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 09:39:53 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
Message-ID: <z5hne_1-iA5I6aud_Z1pqiiQh7lkKs-lPIVHKn8r8DY=.cd39b73b-ed93-4000-9fe3-9480fd75af9e@github.com>

On Thu, 22 Feb 2024 07:50:34 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Thanks for doing this! This is a good improvement IMO.

Thanks! 

> If the `SUNWprivate_1.1` part of the symbols is still needed, it can be added using `--default-symver` ld parameter.

Ah, good to know. In the spirit of making as minimal changes as possible in this PR, I will add it.

> You might want to run tier1-5 tests; compilation-related changes are often detected by higher-level builds and tests only.

I can run tier 4 and 5 also. But once again, the entire point of this PR being so convoluted is that there should be a minimum of differences in compilation. 

On macOS and Windows, the binaries before and after this patch are almost identical; just a few hundred assembler instructions have been reordered slightly. (Why this is even so I don't know, but in the end I did not care to dig into the details.)

On Linux, more code is shuffled around, making for a greater bit-by-bit difference. Still, the symbol tables are (almost) identical, and these changes should only affect symbol visibility, so I believe this is mostly an artifact of how the linker organises stuff.

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

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1959051714

From ihse at openjdk.org  Thu Feb 22 09:43:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 09:43:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
Message-ID: <2wcpOdg70sjre1ULOsoeTKxu7Axq46zoU9qo_bkMgdM=.87d80995-09f3-417a-9270-56dd365d2b06@github.com>

On Thu, 22 Feb 2024 07:39:51 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> src/hotspot/share/utilities/debug.cpp line 71:
> 
>> 69: 
>> 70: #if defined(TARGET_COMPILER_gcc)
>> 71: #undef JNIEXPORT
> 
> This partially reverts [JDK-8264593](https://bugs.openjdk.org/browse/JDK-8264593); @kevinjwalls will this work for you?

No, it doesn't. Even after [JDK-8264593](https://bugs.openjdk.org/browse/JDK-8264593) the symbols from debug.cpp were not exported on Linux, since they were not mentioned in `make/data/hotspot-symbols`, and thus were made local.

The reason I put this in was to keep parity with the symbol table before and after the patch.

My guess is that it was only on Windows it was necessary that the functions where JNIEXPORTed, otherwise someone would have complained after JDK-8264593. But for platform consistency, it might make sense to export these even on gcc as well. After this PR is integrated, this is easy to do -- just remove the above hack.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498952946

From ihse at openjdk.org  Thu Feb 22 09:48:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 09:48:53 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <WgT5R65Kbubtx35Uyw2XAILZQZufGVOXOeS6oFk7tEk=.30c8ff36-82c7-4066-9a9e-ee3293f46810@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <g0ZVkeeR7P1e4_8Z0-nQ8at63jrtZySDk8bKtub0mLw=.db5e4e9c-9ca6-4d5a-b31b-17f84981e14f@github.com>
 <Cd8440seSvfWXHBcZ8cx5K1qWcpf-qyET1IdFY8eWUo=.a64a2d4c-bd34-49fb-9167-8e4583add959@github.com>
 <WgT5R65Kbubtx35Uyw2XAILZQZufGVOXOeS6oFk7tEk=.30c8ff36-82c7-4066-9a9e-ee3293f46810@github.com>
Message-ID: <5TGec4SbupSAMfO0HYHGPm5zoIRUTKq6OMNVFMJnA5Q=.f9ccc438-2a59-448d-8ee7-b146b9fc01c3@github.com>

On Thu, 22 Feb 2024 08:46:16 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> > The Graal folk will need to chime in here as it may be that these are needed for libgraal.
> 
> They should be fine. JNI linkage is only used by the native methods in `CompilerToVM.java`.

Once again, it is a misunderstanding that anything here changes. These functions will stay the same before and after this PR.

However, I interpret your comment as that it is possible to remove the JNIEXPORT from these functions in a follow-up PR. And that is good to know!

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

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1959067420

From ihse at openjdk.org  Thu Feb 22 09:48:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 09:48:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
Message-ID: <5TgE0AwpCtgs4yEzn8QcO4iH4M__Sn9w2sREKBMwmwo=.49a8a5e0-f5a1-49bc-8e61-dcaa89eb4c40@github.com>

On Thu, 22 Feb 2024 07:44:48 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 74:
> 
>> 72: 
>> 73: #if defined(TARGET_COMPILER_gcc)
>> 74: #undef JNIEXPORT
> 
> Based on the suggestion in [this JBS comment](https://bugs.openjdk.org/browse/JDK-8017234?focusedId=14601421&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14601421), I think we can remove JNIEXPORT from all the functions in this file.
> 
> We need to keep the JNICALL though; the deprecated Win32 port needs it, not sure if it's used anywhere else.

I think so too. 

However, I would *really* like to do that separately as a follow up. My goal with this PR has been to make no changes in the product. Consider what would happen if we removed this, and there was some strange failure down the line. There is a high risk the entire PR would be backed out. 

If instead we remove the JNIEXPORT in a separate change, and this causes failures, then it is a much easier backout, and we would be much better informed at exactly what failed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498956646

From jwaters at openjdk.org  Thu Feb 22 09:51:55 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Feb 2024 09:51:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <28TkIQvEbOiKscThXtUGZ24pcHI4wqrVgy6C2P6_f-4=.ae8dcc41-aedd-441c-a8ad-1526dd56db14@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <17uxknoRrcfnUlWwJndQk2AWqvZv4v34JZMVQPpl81w=.34a2c1a8-d251-4f8c-bd12-2f024b4914e6@github.com>
 <28TkIQvEbOiKscThXtUGZ24pcHI4wqrVgy6C2P6_f-4=.ae8dcc41-aedd-441c-a8ad-1526dd56db14@github.com>
Message-ID: <dQ9bYEF3EilMsNU0t8Zp_UCpnlIwGodiF2pYBVKGKdg=.b1878de3-593c-4e06-b4e0-f5beb41889b9@github.com>

On Thu, 22 Feb 2024 09:30:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/hotspot/lib/CompileJvm.gmk line 149:
>> 
>>> 147: 
>>> 148: ifeq ($(call isTargetOs, windows), true)
>>> 149:   WIN_EXPORT_FILE := $(JVM_OUTPUTDIR)/win-exports.txt
>> 
>> Why not .def?
>
> I try to stick to established file suffixes if possible. I have never heard of .def before, but maybe that is a standard name for these kinds of files on Windows? If so, I will change it.

The -def option is for accepting definition files, which are usually suffixed with .def. See for instance https://github.com/openjdk/jdk/blob/10eafdc62e8216e6ef69773fe491a21346c8682d/make/modules/jdk.accessibility/Lib.gmk#L80
.def file contents typically look like this:
https://github.com/openjdk/jdk/blob/master/src/jdk.accessibility/windows/native/libwindowsaccessbridge/WinAccessBridge.DEF

The Microsoft documentation for them is here: https://learn.microsoft.com/en-us/cpp/build/reference/module-definition-dot-def-files?view=msvc-170

If the contents of WinAccessBridge.def look similar enough to the Windows exports file that is created from the dumpbin object file process, feel free to rename it

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498963562

From djelinski at openjdk.org  Thu Feb 22 09:51:56 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 22 Feb 2024 09:51:56 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <2wcpOdg70sjre1ULOsoeTKxu7Axq46zoU9qo_bkMgdM=.87d80995-09f3-417a-9270-56dd365d2b06@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
 <2wcpOdg70sjre1ULOsoeTKxu7Axq46zoU9qo_bkMgdM=.87d80995-09f3-417a-9270-56dd365d2b06@github.com>
Message-ID: <iD9Cps1c81g7BYImEu15xOQvY3Mq9IFZp5_iWU0pm0o=.abd92460-a728-48e3-a6d9-12d8a32b9e7d@github.com>

On Thu, 22 Feb 2024 09:41:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/hotspot/share/utilities/debug.cpp line 71:
>> 
>>> 69: 
>>> 70: #if defined(TARGET_COMPILER_gcc)
>>> 71: #undef JNIEXPORT
>> 
>> This partially reverts [JDK-8264593](https://bugs.openjdk.org/browse/JDK-8264593); @kevinjwalls will this work for you?
>
> No, it doesn't. Even after [JDK-8264593](https://bugs.openjdk.org/browse/JDK-8264593) the symbols from debug.cpp were not exported on Linux, since they were not mentioned in `make/data/hotspot-symbols`, and thus were made local.
> 
> The reason I put this in was to keep parity with the symbol table before and after the patch.
> 
> My guess is that it was only on Windows it was necessary that the functions where JNIEXPORTed, otherwise someone would have complained after JDK-8264593. But for platform consistency, it might make sense to export these even on gcc as well. After this PR is integrated, this is easy to do -- just remove the above hack.

they were absent from .dynsym but available in .symtab as bind: local, visibility: default. Now they are completely gone.

The symbols were supposed to be used from gdb. I'm not sure if gdb can access local symbols, so it's possible that they didn't work even before this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498964087

From ihse at openjdk.org  Thu Feb 22 09:57:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 09:57:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <qD5Ael_CjnuLVdZOdQ863VqU1KBJp1x7J1f3OPOJjcI=.fc651d8a-8640-405d-8339-bffc91b23050@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <qD5Ael_CjnuLVdZOdQ863VqU1KBJp1x7J1f3OPOJjcI=.fc651d8a-8640-405d-8339-bffc91b23050@github.com>
Message-ID: <7j108nQLaK4cLUE4ANl8gAsJby-Dg90ry1MH83Htkh0=.e7732c94-48e5-4e2b-ad08-90d3dba1bd82@github.com>

On Thu, 22 Feb 2024 00:29:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

> My main concern with a change like this as that it likely has little effect on the OpenJDK itself, but we may be changing something that 3rd party applications linking with libjvm are relying on. I realize this is a bit "hand wavy" but are we sure this presents the exact same view of libjvm as before?

I realize that my essay-style comment was a bit TL;DR, but I tried to answer questions like this ahead of time in it. Let me quote:

> I have checked the resulting libjvm.so/jvm.dll using the COMPARE_BUILD functionality, which (among other things) analyzes differences between native libraries before and after a patch. This has verified that there is no change in the symbols of the Hotspot dynamic library on macOS/x64, macOS/aarch64 or Windows/x64. I have also gotten help from @MBaesken and @JoKern65 to confirmed that there is no effect on AIX.

On linux/x64 and linux/aarch64 there are some very minor changes:

> The difference is that the data (variable) symbols __bss_start, _edata and _end, and the text (function) symbols _fini and _init has changed from local to global. Afaik, these are symbols created by the linker. Also, when we used a mapfile, the symbol SUNWprivate_1.1 that was part of the mapfile definition was included in libjvm.so, and this is no longer the case.

So yes, I have worked hard to make sure the resulting libjvm.so/jvm.dll is as close as humanly possible before and after this PR. I cannot think of a way in which 3rd party applications could even spot the difference before and after this patch. (Except for a contrived counterexample like explicitly looking up the visibility of `_init` and checking that it is indeed local...)

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

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1959081384

From jwaters at openjdk.org  Thu Feb 22 09:57:55 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Feb 2024 09:57:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <28TkIQvEbOiKscThXtUGZ24pcHI4wqrVgy6C2P6_f-4=.ae8dcc41-aedd-441c-a8ad-1526dd56db14@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <17uxknoRrcfnUlWwJndQk2AWqvZv4v34JZMVQPpl81w=.34a2c1a8-d251-4f8c-bd12-2f024b4914e6@github.com>
 <28TkIQvEbOiKscThXtUGZ24pcHI4wqrVgy6C2P6_f-4=.ae8dcc41-aedd-441c-a8ad-1526dd56db14@github.com>
Message-ID: <FfaU4QcwSZnSxWSys6H3lqIO1UHBFKCb5dJ2tmNsR00=.6d492146-71d7-4530-bcdd-e0875bf02927@github.com>

On Thu, 22 Feb 2024 09:29:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/hotspot/share/oops/accessBackend.cpp line 36:
>> 
>>> 34: 
>>> 35: #if defined(TARGET_COMPILER_gcc)
>>> 36: #define HIDDEN __attribute__ ((visibility ("hidden")))
>> 
>> Couldn't this use [[gnu::visibility("hidden")]] instead, since HotSpot now allows C++14 Attributes? But this doesn't look like a very nice solution regardless
>
> We're currently using __attribute__ ((visibility ("X"))) elsewhere, so I think I should stick with that.
> 
> And, as I said in my long explanation, this is definitely a hack. The reason it is here is that I want to make sure the symbol table is 100% identical before and after this patch. 
> 
> Why this is needed, I don't know. I believe it is a bug in GCC, since we compile with -fvisibility=hidden. But I don't really know. Maybe there is something in the C++ standard that makes these functions behave differently. Perhaps they are even slightly incorrectly defined?

Ah, I should have clarified that I did read the explaination, just that it slipped my mind at the time. I can't remember if C++14 or C++17 is the version for compilers ignoring unknown attributes though

Also, you can escape the underscores with \ to avoid GitHub formatting. GitHub can get annoying with its formatting sometimes

Is there a chance this can be fixed in a followup somehow? I could help with that, given I have access to WSL2 for Linux

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498972139

From ihse at openjdk.org  Thu Feb 22 10:02:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 10:02:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <Fmx9r9fzQ4B-8Rho8HWl8QRY3KkP835i67amQFp6Kik=.caf9a9c5-5087-4817-b30e-4b06953b144b@github.com>

On Wed, 21 Feb 2024 23:32:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

Let me also add some background to the *why* of this PR. 

A good reason is to get rid of a lot of weird code and special cases in the build. It will also speed up the build since we needed to scan all .o files with nm after they were compiled but before they were linked, adding to the slow path of linking hotspot. But for the 10+ years this has been a JBS issue it has never completely pushed the scales.

The triggering factor now is the Hermetic Java project. We need to make properly supported static libraries for all native code in the JDK. One of the main issues with creating a single static library from all the native code is symbol visibility. If the same symbol name is exported from two different libraries, this will cause a failure. This weird "dance" in Hotspot makes it much harder to reason about, or fix, issues related to symbol visibility. That is why I want to have this fixed, once and for all.

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

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1959089592

From jwaters at openjdk.org  Thu Feb 22 10:02:54 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Feb 2024 10:02:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <iD9Cps1c81g7BYImEu15xOQvY3Mq9IFZp5_iWU0pm0o=.abd92460-a728-48e3-a6d9-12d8a32b9e7d@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
 <2wcpOdg70sjre1ULOsoeTKxu7Axq46zoU9qo_bkMgdM=.87d80995-09f3-417a-9270-56dd365d2b06@github.com>
 <iD9Cps1c81g7BYImEu15xOQvY3Mq9IFZp5_iWU0pm0o=.abd92460-a728-48e3-a6d9-12d8a32b9e7d@github.com>
Message-ID: <EhViMvCbwUI2HUVsMdUAgr3tB4S1luXqdrG8cNbwtlA=.7b8ddcb7-ea13-4955-9b83-76ed79f1adce@github.com>

On Thu, 22 Feb 2024 09:49:41 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> No, it doesn't. Even after [JDK-8264593](https://bugs.openjdk.org/browse/JDK-8264593) the symbols from debug.cpp were not exported on Linux, since they were not mentioned in `make/data/hotspot-symbols`, and thus were made local.
>> 
>> The reason I put this in was to keep parity with the symbol table before and after the patch.
>> 
>> My guess is that it was only on Windows it was necessary that the functions where JNIEXPORTed, otherwise someone would have complained after JDK-8264593. But for platform consistency, it might make sense to export these even on gcc as well. After this PR is integrated, this is easy to do -- just remove the above hack.
>
> they were absent from .dynsym but available in .symtab as bind: local, visibility: default. Now they are completely gone.
> 
> The symbols were supposed to be used from gdb. I'm not sure if gdb can access local symbols, so it's possible that they didn't work even before this change.

> But for platform consistency, it might make sense to export these even on gcc as well.

JDK-8288293 would definitely like that a lot

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498978685

From ihse at openjdk.org  Thu Feb 22 10:20:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 10:20:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <FfaU4QcwSZnSxWSys6H3lqIO1UHBFKCb5dJ2tmNsR00=.6d492146-71d7-4530-bcdd-e0875bf02927@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <17uxknoRrcfnUlWwJndQk2AWqvZv4v34JZMVQPpl81w=.34a2c1a8-d251-4f8c-bd12-2f024b4914e6@github.com>
 <28TkIQvEbOiKscThXtUGZ24pcHI4wqrVgy6C2P6_f-4=.ae8dcc41-aedd-441c-a8ad-1526dd56db14@github.com>
 <FfaU4QcwSZnSxWSys6H3lqIO1UHBFKCb5dJ2tmNsR00=.6d492146-71d7-4530-bcdd-e0875bf02927@github.com>
Message-ID: <A1r4AEShJI_4GfYz3lxkxopCNYuaMF-zhmhuhd493gY=.c112b7c1-5d21-4074-8967-48b48387bd23@github.com>

On Thu, 22 Feb 2024 09:55:21 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> We're currently using __attribute__ ((visibility ("X"))) elsewhere, so I think I should stick with that.
>> 
>> And, as I said in my long explanation, this is definitely a hack. The reason it is here is that I want to make sure the symbol table is 100% identical before and after this patch. 
>> 
>> Why this is needed, I don't know. I believe it is a bug in GCC, since we compile with -fvisibility=hidden. But I don't really know. Maybe there is something in the C++ standard that makes these functions behave differently. Perhaps they are even slightly incorrectly defined?
>
> Ah, I should have clarified that I did read the explaination, just that it slipped my mind at the time. I can't remember if C++14 or C++17 is the version for compilers ignoring unknown attributes though
> 
> Also, you can escape the underscores with \ to avoid GitHub formatting. GitHub can get annoying with its formatting sometimes
> 
> Is there a chance this can be fixed in a followup somehow? I could help with that, given I have access to WSL2 for Linux

You mean making a search/replace from `__attribute__ ((foo))` to `[[gnu::foo)]]` in the code base? It seems a bit like unnecessary churn to me. We have 100+ places in the code with `__attribute__`. If you really want to try to push that agenda, be my guest. But do it in a separate PR. ;-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499001259

From jwaters at openjdk.org  Thu Feb 22 10:20:54 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Feb 2024 10:20:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <A1r4AEShJI_4GfYz3lxkxopCNYuaMF-zhmhuhd493gY=.c112b7c1-5d21-4074-8967-48b48387bd23@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <17uxknoRrcfnUlWwJndQk2AWqvZv4v34JZMVQPpl81w=.34a2c1a8-d251-4f8c-bd12-2f024b4914e6@github.com>
 <28TkIQvEbOiKscThXtUGZ24pcHI4wqrVgy6C2P6_f-4=.ae8dcc41-aedd-441c-a8ad-1526dd56db14@github.com>
 <FfaU4QcwSZnSxWSys6H3lqIO1UHBFKCb5dJ2tmNsR00=.6d492146-71d7-4530-bcdd-e0875bf02927@github.com>
 <A1r4AEShJI_4GfYz3lxkxopCNYuaMF-zhmhuhd493gY=.c112b7c1-5d21-4074-8967-48b48387bd23@github.com>
Message-ID: <bCCiR8BHjfb_LNAuneO4lfRx1VY4UE8f1irt43V97vQ=.0010380e-f54d-439e-8877-5ba9a75fe71f@github.com>

On Thu, 22 Feb 2024 10:15:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Ah, I should have clarified that I did read the explaination, just that it slipped my mind at the time. I can't remember if C++14 or C++17 is the version for compilers ignoring unknown attributes though
>> 
>> Also, you can escape the underscores with \ to avoid GitHub formatting. GitHub can get annoying with its formatting sometimes
>> 
>> Is there a chance this can be fixed in a followup somehow? I could help with that, given I have access to WSL2 for Linux
>
> You mean making a search/replace from `__attribute__ ((foo))` to `[[gnu::foo)]]` in the code base? It seems a bit like unnecessary churn to me. We have 100+ places in the code with `__attribute__`. If you really want to try to push that agenda, be my guest. But do it in a separate PR. ;-)

Oh no, by fix I meant removing the HIDDEN attribute and somehow fixing that issue differently, not replacing everything with C++ Attributes!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499004595

From ihse at openjdk.org  Thu Feb 22 10:27:06 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 10:27:06 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v2]
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <12hoUFbZkWHBpiXs0TPiMYGW3sSvBX_536mvSSG-y-8=.21abcef9-9a2b-4558-ba19-dddfd7931f9f@github.com>

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Rename the Windows export file to .def
 - Remove unused symbol _Copy_conjoint_bytes on linux/arm32

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17955/files
  - new: https://git.openjdk.org/jdk/pull/17955/files/04857e8e..27b4df53

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

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

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

From ihse at openjdk.org  Thu Feb 22 10:37:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 10:37:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v2]
In-Reply-To: <z5hne_1-iA5I6aud_Z1pqiiQh7lkKs-lPIVHKn8r8DY=.cd39b73b-ed93-4000-9fe3-9480fd75af9e@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
 <z5hne_1-iA5I6aud_Z1pqiiQh7lkKs-lPIVHKn8r8DY=.cd39b73b-ed93-4000-9fe3-9480fd75af9e@github.com>
Message-ID: <g1RnggtuOtSZtr923djUJzeXYx53NZuZYJgOjqN36WM=.5eecdf1f-6d23-4e3e-9368-e1fe00fd2f98@github.com>

On Thu, 22 Feb 2024 09:37:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > If the `SUNWprivate_1.1` part of the symbols is still needed, it can be added using `--default-symver` ld parameter.
> 
> Ah, good to know. In the spirit of making as minimal changes as possible in this PR, I will add it.

Unfortunately, that was not so easy. :( `--default-symver` is only available on the bfd ld, not on gold (which is what Oracle uses). :-(

https://sourceware.org/bugzilla/show_bug.cgi?id=15910

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

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1959157991

From kevinw at openjdk.org  Thu Feb 22 11:18:54 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 22 Feb 2024 11:18:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v2]
In-Reply-To: <EhViMvCbwUI2HUVsMdUAgr3tB4S1luXqdrG8cNbwtlA=.7b8ddcb7-ea13-4955-9b83-76ed79f1adce@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
 <2wcpOdg70sjre1ULOsoeTKxu7Axq46zoU9qo_bkMgdM=.87d80995-09f3-417a-9270-56dd365d2b06@github.com>
 <iD9Cps1c81g7BYImEu15xOQvY3Mq9IFZp5_iWU0pm0o=.abd92460-a728-48e3-a6d9-12d8a32b9e7d@github.com>
 <EhViMvCbwUI2HUVsMdUAgr3tB4S1luXqdrG8cNbwtlA=.7b8ddcb7-ea13-4955-9b83-76ed79f1adce@github.com>
Message-ID: <lIVvvltNqX9EzhzaitISyBocIyA3C4ZjJv83ldUnmeg=.a21613ca-ba82-4412-8040-2058fba56661@github.com>

On Thu, 22 Feb 2024 09:59:48 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> they were absent from .dynsym but available in .symtab as bind: local, visibility: default. Now they are completely gone.
>> 
>> The symbols were supposed to be used from gdb. I'm not sure if gdb can access local symbols, so it's possible that they didn't work even before this change.
>
>> But for platform consistency, it might make sense to export these even on gcc as well.
> 
> JDK-8288293 would definitely like that a lot

Thanks - when I last tried, e.g. "call universe()" would work on Linux/gdb, so I think gdb did resolve a local symbol (which cannot be found by callling dlsym, but can be found in the binary symboltable).
On Windows the debug.cpp symbols just weren't in the binary at all, then with JDK-8264593 JNIEXPORT they were, and appeared in the .map file we generate also.

So I am saying I added the JNIEXPORT for Windows, to get the debug.cpp symbols into the binary.
This removes JNIEXPORT for gcc, which already had the debug.cpp symbols in the binary.

But I will go check this...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499086833

From dnsimon at openjdk.org  Thu Feb 22 11:59:54 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 22 Feb 2024 11:59:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <5TGec4SbupSAMfO0HYHGPm5zoIRUTKq6OMNVFMJnA5Q=.f9ccc438-2a59-448d-8ee7-b146b9fc01c3@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <g0ZVkeeR7P1e4_8Z0-nQ8at63jrtZySDk8bKtub0mLw=.db5e4e9c-9ca6-4d5a-b31b-17f84981e14f@github.com>
 <Cd8440seSvfWXHBcZ8cx5K1qWcpf-qyET1IdFY8eWUo=.a64a2d4c-bd34-49fb-9167-8e4583add959@github.com>
 <WgT5R65Kbubtx35Uyw2XAILZQZufGVOXOeS6oFk7tEk=.30c8ff36-82c7-4066-9a9e-ee3293f46810@github.com>
 <5TGec4SbupSAMfO0HYHGPm5zoIRUTKq6OMNVFMJnA5Q=.f9ccc438-2a59-448d-8ee7-b146b9fc01c3@github.com>
Message-ID: <bjUm6YFU-0Z9wxg8EM7CWtHsP4yNp4VSYjmIcTjJQjw=.fa383933-82bf-44d6-815a-916698a2b804@github.com>

On Thu, 22 Feb 2024 09:46:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> However, I interpret your comment as that it is possible to remove the JNIEXPORT from these functions in a follow-up PR. And that is good to know!

I believe you're right. In any case, most of the JVMCI tests will fail if JNIEXPORT is removed and it turns out to be needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1959300756

From ihse at openjdk.org  Thu Feb 22 12:26:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 12:26:53 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v2]
In-Reply-To: <lIVvvltNqX9EzhzaitISyBocIyA3C4ZjJv83ldUnmeg=.a21613ca-ba82-4412-8040-2058fba56661@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
 <2wcpOdg70sjre1ULOsoeTKxu7Axq46zoU9qo_bkMgdM=.87d80995-09f3-417a-9270-56dd365d2b06@github.com>
 <iD9Cps1c81g7BYImEu15xOQvY3Mq9IFZp5_iWU0pm0o=.abd92460-a728-48e3-a6d9-12d8a32b9e7d@github.com>
 <EhViMvCbwUI2HUVsMdUAgr3tB4S1luXqdrG8cNbwtlA=.7b8ddcb7-ea13-4955-9b83-76ed79f1adce@github.com>
 <lIVvvltNqX9EzhzaitISyBocIyA3C4ZjJv83ldUnmeg=.a21613ca-ba82-4412-8040-2058fba56661@github.com>
Message-ID: <E9y5WFeGqqskboveKh7YamHgbz6Ur5QdJji2uOxzt6c=.4aad38fd-6a31-4881-a2b8-b145d22a6763@github.com>

On Thu, 22 Feb 2024 11:16:37 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>>> But for platform consistency, it might make sense to export these even on gcc as well.
>> 
>> JDK-8288293 would definitely like that a lot
>
> Thanks - when I last tried, e.g. "call universe()" would work on Linux/gdb, so I think gdb did resolve a local symbol (which cannot be found by callling dlsym, but can be found in the binary symboltable).
> On Windows the debug.cpp symbols just weren't in the binary at all, then with JDK-8264593 JNIEXPORT they were, and appeared in the .map file we generate also.
> 
> So I am saying I added the JNIEXPORT for Windows, to get the debug.cpp symbols into the binary.
> This removes JNIEXPORT for gcc, which already had the debug.cpp symbols in the binary.
> 
> But I will go check this...

> they were absent from .dynsym but available in .symtab as bind: local, visibility: default. Now they are completely gone.

I don't think that statement is correct. Or else my understanding about symbol tables is incomplete. Both `nm` (which shows `.symtab`) and `nm -D` (which shows `.dynsym`) are identical for the libjvm.so before and after the patch wrt to the JNIEXPORTed debug.cpp functions.

Was this a statement of your understanding of the situation, or could you spot an actual difference? If it is the latter, please let me know how I can view this difference.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499163789

From ihse at openjdk.org  Thu Feb 22 12:29:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 12:29:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v2]
In-Reply-To: <E9y5WFeGqqskboveKh7YamHgbz6Ur5QdJji2uOxzt6c=.4aad38fd-6a31-4881-a2b8-b145d22a6763@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
 <2wcpOdg70sjre1ULOsoeTKxu7Axq46zoU9qo_bkMgdM=.87d80995-09f3-417a-9270-56dd365d2b06@github.com>
 <iD9Cps1c81g7BYImEu15xOQvY3Mq9IFZp5_iWU0pm0o=.abd92460-a728-48e3-a6d9-12d8a32b9e7d@github.com>
 <EhViMvCbwUI2HUVsMdUAgr3tB4S1luXqdrG8cNbwtlA=.7b8ddcb7-ea13-4955-9b83-76ed79f1adce@github.com>
 <lIVvvltNqX9EzhzaitISyBocIyA3C4ZjJv83ldUnmeg=.a21613ca-ba82-4412-8040-2058fba56661@github.com>
 <E9y5WFeGqqskboveKh7YamHgbz6Ur5QdJji2uOxzt6c=.4aad38fd-6a31-4881-a2b8-b145d22a6763@github.com>
Message-ID: <Wo15zScdWr27VO2St0-ExVqddH1wWLdS2cnRF6Yq1wE=.505b59eb-9942-4b85-901d-97715025c078@github.com>

On Thu, 22 Feb 2024 12:24:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Thanks - when I last tried, e.g. "call universe()" would work on Linux/gdb, so I think gdb did resolve a local symbol (which cannot be found by callling dlsym, but can be found in the binary symboltable).
>> On Windows the debug.cpp symbols just weren't in the binary at all, then with JDK-8264593 JNIEXPORT they were, and appeared in the .map file we generate also.
>> 
>> So I am saying I added the JNIEXPORT for Windows, to get the debug.cpp symbols into the binary.
>> This removes JNIEXPORT for gcc, which already had the debug.cpp symbols in the binary.
>> 
>> But I will go check this...
>
>> they were absent from .dynsym but available in .symtab as bind: local, visibility: default. Now they are completely gone.
> 
> I don't think that statement is correct. Or else my understanding about symbol tables is incomplete. Both `nm` (which shows `.symtab`) and `nm -D` (which shows `.dynsym`) are identical for the libjvm.so before and after the patch wrt to the JNIEXPORTed debug.cpp functions.
> 
> Was this a statement of your understanding of the situation, or could you spot an actual difference? If it is the latter, please let me know how I can view this difference.

Your comment had me go and elfdump the entire libjvm.so and compare the entire output... :-) Now at least I understand why there were so many spurious changes in the linux binary -- the old symbols were named e.g. `JVM_MonitorWait@@SUNWprivate_1.1` while the new one are just named `JVM_MonitorWait`. This caused the segment to be shorter, and this in turned offsetted all following position, so the change cascaded down.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499167151

From ihse at openjdk.org  Thu Feb 22 13:30:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 13:30:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v2]
In-Reply-To: <Wo15zScdWr27VO2St0-ExVqddH1wWLdS2cnRF6Yq1wE=.505b59eb-9942-4b85-901d-97715025c078@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
 <2wcpOdg70sjre1ULOsoeTKxu7Axq46zoU9qo_bkMgdM=.87d80995-09f3-417a-9270-56dd365d2b06@github.com>
 <iD9Cps1c81g7BYImEu15xOQvY3Mq9IFZp5_iWU0pm0o=.abd92460-a728-48e3-a6d9-12d8a32b9e7d@github.com>
 <EhViMvCbwUI2HUVsMdUAgr3tB4S1luXqdrG8cNbwtlA=.7b8ddcb7-ea13-4955-9b83-76ed79f1adce@github.com>
 <lIVvvltNqX9EzhzaitISyBocIyA3C4ZjJv83ldUnmeg=.a21613ca-ba82-4412-8040-2058fba56661@github.com>
 <E9y5WFeGqqskboveKh7YamHgbz6Ur5QdJji2uOxzt6c=.4aad38fd-6a31-4881-a2b8-b145d22a6763@github.com>
 <Wo15zScdWr27VO2St0-ExVqddH1wWLdS2cnRF6Yq1wE=.505b59eb-9942-4b85-901d-97715025c078@github.com>
Message-ID: <Y9p2b3b_z8muEidBlBBrpCwLumHrKejUvxfzqZxnBjo=.a9119066-f460-4ec0-aa58-c8d78c721f6f@github.com>

On Thu, 22 Feb 2024 12:27:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> they were absent from .dynsym but available in .symtab as bind: local, visibility: default. Now they are completely gone.
>> 
>> I don't think that statement is correct. Or else my understanding about symbol tables is incomplete. Both `nm` (which shows `.symtab`) and `nm -D` (which shows `.dynsym`) are identical for the libjvm.so before and after the patch wrt to the JNIEXPORTed debug.cpp functions.
>> 
>> Was this a statement of your understanding of the situation, or could you spot an actual difference? If it is the latter, please let me know how I can view this difference.
>
> Your comment had me go and elfdump the entire libjvm.so and compare the entire output... :-) Now at least I understand why there were so many spurious changes in the linux binary -- the old symbols were named e.g. `JVM_MonitorWait@@SUNWprivate_1.1` while the new one are just named `JVM_MonitorWait`. This caused the segment to be shorter, and this in turned offsetted all following position, so the change cascaded down.

Ok, I see now that there is indeed a slight difference. The debug.cpp symbols are present as local symbols in the .symtab, both before and after this patch. However, before this patch they had visibility DEFAULT and now they have visibility HIDDEN. I don't think this matters for anything except the linker, but I should probably verify that they are still correctly usable from gcc.

I would appreciate it if someone could provide a step-by-step instruction on how to verify these functions on gdb (I haven't used it for 10-15 years so I apologize if I'm a bit rusty), or provide a pointer to where I can find such instructions. Is this supposed to work on core dumps, live attached processes or both?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499242980

From ihse at openjdk.org  Thu Feb 22 13:39:26 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 13:39:26 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v3]
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <B5_kr9qJwfypMGingeJ0OGrxFl4ICJCNTwxyocqXo60=.8f13d5c6-9150-4dde-ba85-d6340d2c8dc7@github.com>

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Restore linker script to linux/gcc builds

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17955/files
  - new: https://git.openjdk.org/jdk/pull/17955/files/27b4df53..26b1e194

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

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

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

From ihse at openjdk.org  Thu Feb 22 13:39:26 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 13:39:26 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v2]
In-Reply-To: <12hoUFbZkWHBpiXs0TPiMYGW3sSvBX_536mvSSG-y-8=.21abcef9-9a2b-4558-ba19-dddfd7931f9f@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <12hoUFbZkWHBpiXs0TPiMYGW3sSvBX_536mvSSG-y-8=.21abcef9-9a2b-4558-ba19-dddfd7931f9f@github.com>
Message-ID: <0Inj4SqHl36K4FzxPfbfyA20_7x8GyGMngBfuNEGsf8=.9cba3073-cfdd-43a4-828a-4ec362dcaaf3@github.com>

On Thu, 22 Feb 2024 10:27:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Rename the Windows export file to .def
>  - Remove unused symbol _Copy_conjoint_bytes on linux/arm32

I just realized I could keep an extremely simplified linker script ("mapfile") for gcc, and thereby keeping the `@SUNWprivate_1.1` on the exported symbols, and keeping `__bss_start` and friends local. This further minimizes the difference to the existing libjvm.so for gcc builds. 

I think we can get rid of this as well going forward, but as with other cleanups, let's do that separately.

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

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1959467819

From ihse at openjdk.org  Thu Feb 22 13:54:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 13:54:56 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v3]
In-Reply-To: <bCCiR8BHjfb_LNAuneO4lfRx1VY4UE8f1irt43V97vQ=.0010380e-f54d-439e-8877-5ba9a75fe71f@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <17uxknoRrcfnUlWwJndQk2AWqvZv4v34JZMVQPpl81w=.34a2c1a8-d251-4f8c-bd12-2f024b4914e6@github.com>
 <28TkIQvEbOiKscThXtUGZ24pcHI4wqrVgy6C2P6_f-4=.ae8dcc41-aedd-441c-a8ad-1526dd56db14@github.com>
 <FfaU4QcwSZnSxWSys6H3lqIO1UHBFKCb5dJ2tmNsR00=.6d492146-71d7-4530-bcdd-e0875bf02927@github.com>
 <A1r4AEShJI_4GfYz3lxkxopCNYuaMF-zhmhuhd493gY=.c112b7c1-5d21-4074-8967-48b48387bd23@github.com>
 <bCCiR8BHjfb_LNAuneO4lfRx1VY4UE8f1irt43V97vQ=.0010380e-f54d-439e-8877-5ba9a75fe71f@github.com>
Message-ID: <rSSQn-eaJbthjFJBhKKLm9-GuvWLPhA293t5_AThMoE=.7dc91c10-b655-4b24-830c-3bb61ca99ff6@github.com>

On Thu, 22 Feb 2024 10:18:21 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> You mean making a search/replace from `__attribute__ ((foo))` to `[[gnu::foo)]]` in the code base? It seems a bit like unnecessary churn to me. We have 100+ places in the code with `__attribute__`. If you really want to try to push that agenda, be my guest. But do it in a separate PR. ;-)
>
> Oh no, by fix I meant removing the HIDDEN attribute and somehow fixing that issue differently, not replacing everything with C++ Attributes!

Well, I hope that can be done, but it depends... As I see it, there are three possible ways to get rid of this `HIDDEN`.

1) Accept that we export these functions on gcc, and just remove the attribute. (Kind of capitulating to the bug.)

2) See if there is a way we can work around this problem, by changing something in how these functions are defined, that does not trigger this bug.

3) Have this bug fixed in gcc, and move to a minimum version of gcc that includes this fix.

I'm not terribly keen on any of these solutions. I think 2, if it is possible, would be the simplest and cleanest. Or 1, if we really think this HIDDEN workaround is worse than the problem it solves (unintentionally exporting symbols).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499275242

From kevinw at openjdk.org  Thu Feb 22 14:07:56 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 22 Feb 2024 14:07:56 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v3]
In-Reply-To: <Y9p2b3b_z8muEidBlBBrpCwLumHrKejUvxfzqZxnBjo=.a9119066-f460-4ec0-aa58-c8d78c721f6f@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
 <2wcpOdg70sjre1ULOsoeTKxu7Axq46zoU9qo_bkMgdM=.87d80995-09f3-417a-9270-56dd365d2b06@github.com>
 <iD9Cps1c81g7BYImEu15xOQvY3Mq9IFZp5_iWU0pm0o=.abd92460-a728-48e3-a6d9-12d8a32b9e7d@github.com>
 <EhViMvCbwUI2HUVsMdUAgr3tB4S1luXqdrG8cNbwtlA=.7b8ddcb7-ea13-4955-9b83-76ed79f1adce@github.com>
 <lIVvvltNqX9EzhzaitISyBocIyA3C4ZjJv83ldUnmeg=.a21613ca-ba82-4412-8040-2058fba56661@github.com>
 <E9y5WFeGqqskboveKh7YamHgbz6Ur5QdJji2uOxzt6c=.4aad38fd-6a31-4881-a2b8-b145d22a6763@github.com>
 <Wo15zScdWr27VO2St0-ExVqddH1wWLdS2cnRF6Yq1wE=.505b59eb-9942-4b85-901d-97715025c078@github.com>
 <Y9p2b3b_z8muEidBlBBrpCwLumHrKejUvxfzqZxnBjo=.a9119066-f460-4ec0-aa58-c8d78c721f6f@github.com>
Message-ID: <Kt8zuxrBV-xUzZI29-eMuQFoLU_phXcCB4qc63pe-PU=.06c7f6a1-0e01-4386-903e-bc81e5de1fb1@github.com>

On Thu, 22 Feb 2024 13:28:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Your comment had me go and elfdump the entire libjvm.so and compare the entire output... :-) Now at least I understand why there were so many spurious changes in the linux binary -- the old symbols were named e.g. `JVM_MonitorWait@@SUNWprivate_1.1` while the new one are just named `JVM_MonitorWait`. This caused the segment to be shorter, and this in turned offsetted all following position, so the change cascaded down.
>
> Ok, I see now that there is indeed a slight difference. The debug.cpp symbols are present as local symbols in the .symtab, both before and after this patch. However, before this patch they had visibility DEFAULT and now they have visibility HIDDEN. I don't think this matters for anything except the linker, but I should probably verify that they are still correctly usable from gcc.
> 
> I would appreciate it if someone could provide a step-by-step instruction on how to verify these functions on gdb (I haven't used it for 10-15 years so I apologize if I'm a bit rusty), or provide a pointer to where I can find such instructions. Is this supposed to work on core dumps, live attached processes or both?

On a latest JDK build today, in Linux I can attach to a live process (not a core dump):
  gdb --pid PID
..and type:
  call universe()
(I think you need to switch to a JavaThread first) and see on the JVM's output:

"Executing universe"
Heap
 garbage-first heap   total reserved 30932992K,  ...etc...
 

Removing JNIEXPORT here on Linux and rebuilding: still works.

readelf shows: 
existing build (using JNIEXPORT):
 32252: 0000000000698160   249 FUNC    LOCAL  DEFAULT   11 universe

without JNIEXPORT:
 32252: 0000000000698160   249 FUNC    LOCAL  HIDDEN    11 universe

So gdb on Linux can call a HIDDEN function, i.e. without the JNIEXPORT.  It seems happy either way, not affected by visibility.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499294627

From jwaters at openjdk.org  Thu Feb 22 14:17:04 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Feb 2024 14:17:04 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v3]
In-Reply-To: <rSSQn-eaJbthjFJBhKKLm9-GuvWLPhA293t5_AThMoE=.7dc91c10-b655-4b24-830c-3bb61ca99ff6@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <17uxknoRrcfnUlWwJndQk2AWqvZv4v34JZMVQPpl81w=.34a2c1a8-d251-4f8c-bd12-2f024b4914e6@github.com>
 <28TkIQvEbOiKscThXtUGZ24pcHI4wqrVgy6C2P6_f-4=.ae8dcc41-aedd-441c-a8ad-1526dd56db14@github.com>
 <FfaU4QcwSZnSxWSys6H3lqIO1UHBFKCb5dJ2tmNsR00=.6d492146-71d7-4530-bcdd-e0875bf02927@github.com>
 <A1r4AEShJI_4GfYz3lxkxopCNYuaMF-zhmhuhd493gY=.c112b7c1-5d21-4074-8967-48b48387bd23@github.com>
 <bCCiR8BHjfb_LNAuneO4lfRx1VY4UE8f1irt43V97vQ=.0010380e-f54d-439e-8877-5ba9a75fe71f@github.com>
 <rSSQn-eaJbthjFJBhKKLm9-GuvWLPhA293t5_AThMoE=.7dc91c10-b655-4b24-830c-3bb61ca99ff6@github.com>
Message-ID: <eKOLOhDFnBx9Ne1hfOYleMnz5iGt8Nb5g6JJ3S7b63Q=.b2744208-182b-47a7-a0ef-5b44061cdfb4@github.com>

On Thu, 22 Feb 2024 13:52:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Oh no, by fix I meant removing the HIDDEN attribute and somehow fixing that issue differently, not replacing everything with C++ Attributes!
>
> Well, I hope that can be done, but it depends... As I see it, there are three possible ways to get rid of this `HIDDEN`.
> 
> 1) Accept that we export these functions on gcc, and just remove the attribute. (Kind of capitulating to the bug.)
> 
> 2) See if there is a way we can work around this problem, by changing something in how these functions are defined, that does not trigger this bug.
> 
> 3) Have this bug fixed in gcc, and move to a minimum version of gcc that includes this fix.
> 
> I'm not terribly keen on any of these solutions. I think 2, if it is possible, would be the simplest and cleanest. Or 1, if we really think this HIDDEN workaround is worse than the problem it solves (unintentionally exporting symbols).

I see, seems like it's an unfortunate situation where a fix is hard or even impossible. If we file a gcc bug for it now, it'll get fixed in some insanely new gcc version (such as gcc 15 or 16) and we'd have to jump to that version, which I'm sure no one is going to like :(

Nevertheless, since there are so many instances of it, I suggest #pragma GCC visibility push(hidden) instead of adding a new macro to this file, in my opinion it's somewhat cleaner and also makes the change smaller.

#pragma GCC visibility push(hidden)
// Junk that needs hidden visibility to work properly
#pragma GCC visibility pop

Also, why TARGET_COMPILER_gcc instead of __GNUC__? Does this have to work with Apple Clang on macOS as well?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499309573

From ihse at openjdk.org  Thu Feb 22 14:32:12 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 14:32:12 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v4]
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <QWOxD_Kcb04DD6jdgPIiJRcapXZtivFeoU0wlB0VNWA=.4509074e-ebf0-4332-a1fa-6e7458d6b7de@github.com>

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Rename the version script to version-script.txt

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17955/files
  - new: https://git.openjdk.org/jdk/pull/17955/files/26b1e194..ad1d53c9

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

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

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

From erikj at openjdk.org  Thu Feb 22 14:32:12 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 22 Feb 2024 14:32:12 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <7j108nQLaK4cLUE4ANl8gAsJby-Dg90ry1MH83Htkh0=.e7732c94-48e5-4e2b-ad08-90d3dba1bd82@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <qD5Ael_CjnuLVdZOdQ863VqU1KBJp1x7J1f3OPOJjcI=.fc651d8a-8640-405d-8339-bffc91b23050@github.com>
 <7j108nQLaK4cLUE4ANl8gAsJby-Dg90ry1MH83Htkh0=.e7732c94-48e5-4e2b-ad08-90d3dba1bd82@github.com>
Message-ID: <OlWBwMQB9opCYtf86_yTJ5-8zmwcgUuqyqVcaLzRCrM=.8448b5d5-928b-4755-81b8-69ccde611280@github.com>

On Thu, 22 Feb 2024 09:53:53 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The difference is that the data (variable) symbols __bss_start, _edata and _end, and the text (function) symbols _fini and _init has changed from local to global. Afaik, these are symbols created by the linker. Also, when we used a mapfile, the symbol SUNWprivate_1.1 that was part of the mapfile definition was included in libjvm.so, and this is no longer the case.

Regarding SUNWprivate_1.1, reading [JDK-4916160](https://bugs.openjdk.org/browse/JDK-4916160) it seems like it could cause problems for native user libraries linked against an older JDK version if we remove it. I think this is what David Holmes was referring to. So it seems like a good idea to figure out a way to keep it around.

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

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1959567183

From kevinw at openjdk.org  Thu Feb 22 14:35:55 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 22 Feb 2024 14:35:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v4]
In-Reply-To: <Kt8zuxrBV-xUzZI29-eMuQFoLU_phXcCB4qc63pe-PU=.06c7f6a1-0e01-4386-903e-bc81e5de1fb1@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
 <2wcpOdg70sjre1ULOsoeTKxu7Axq46zoU9qo_bkMgdM=.87d80995-09f3-417a-9270-56dd365d2b06@github.com>
 <iD9Cps1c81g7BYImEu15xOQvY3Mq9IFZp5_iWU0pm0o=.abd92460-a728-48e3-a6d9-12d8a32b9e7d@github.com>
 <EhViMvCbwUI2HUVsMdUAgr3tB4S1luXqdrG8cNbwtlA=.7b8ddcb7-ea13-4955-9b83-76ed79f1adce@github.com>
 <lIVvvltNqX9EzhzaitISyBocIyA3C4ZjJv83ldUnmeg=.a21613ca-ba82-4412-8040-2058fba56661@github.com>
 <E9y5WFeGqqskboveKh7YamHgbz6Ur5QdJji2uOxzt6c=.4aad38fd-6a31-4881-a2b8-b145d22a6763@github.com>
 <Wo15zScdWr27VO2St0-ExVqddH1wWLdS2cnRF6Yq1wE=.505b59eb-9942-4b85-901d-97715025c078@github.com>
 <Y9p2b3b_z8muEidBlBBrpCwLumHrKejUvxfzqZxnBjo=.a9119066-f460-4ec0-aa58-c8d78c721f6f@github.com>
 <Kt8zuxrBV-xUzZI29-eMuQFoLU_phXcCB4qc63pe-PU=.06c7f6a1-0e01-4386-903e-bc81e5de1fb1@github.com>
Message-ID: <vIH043hYabyI97214HCCxnzP2YcrCNr2pEkeLWs6tM4=.069f3df2-fa1d-4d2c-842e-5aa1e7d915ff@github.com>

On Thu, 22 Feb 2024 14:05:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Ok, I see now that there is indeed a slight difference. The debug.cpp symbols are present as local symbols in the .symtab, both before and after this patch. However, before this patch they had visibility DEFAULT and now they have visibility HIDDEN. I don't think this matters for anything except the linker, but I should probably verify that they are still correctly usable from gcc.
>> 
>> I would appreciate it if someone could provide a step-by-step instruction on how to verify these functions on gdb (I haven't used it for 10-15 years so I apologize if I'm a bit rusty), or provide a pointer to where I can find such instructions. Is this supposed to work on core dumps, live attached processes or both?
>
> On a latest JDK build today, in Linux I can attach to a live process (not a core dump):
>   gdb --pid PID
> ..and type:
>   call universe()
> (I think you need to switch to a JavaThread first) and see on the JVM's output:
> 
> "Executing universe"
> Heap
>  garbage-first heap   total reserved 30932992K,  ...etc...
>  
> 
> Removing JNIEXPORT here on Linux and rebuilding: still works.
> 
> readelf shows: 
> existing build (using JNIEXPORT):
>  32252: 0000000000698160   249 FUNC    LOCAL  DEFAULT   11 universe
> 
> without JNIEXPORT:
>  32252: 0000000000698160   249 FUNC    LOCAL  HIDDEN    11 universe
> 
> So gdb on Linux can call a HIDDEN function, i.e. without the JNIEXPORT.  It seems happy either way, not affected by visibility.

Windows:
Attach Visual Studio,
in the Immediate Window, type (funny VS syntax I do not claim to understand):

{,,JVM}universe()

...and on the JVM's console window I see:

"Executing universe"
Heap
 garbage-first heap   total reserved 8343552K,...etc...

(It actually did nothing on the first invocation for me, I have typed it 5 times, only got 4 sets of output.  But the symbol is working...)

In that working (JNIEXPORT) case, the map file jdk/bin/server/jvm.dll.map shows:

 0001:0027ff50       universe                   0000000180280f50 f   debug.obj

(I do like that we call it jvm.dll.map now, not just "jvm.map"!)

Test removing JNIEXPORT:
 
Without JNIEXPORT, on Windows, the symbol universe is just not there.  Nothing in the map file.  In Visual Studio:

{,,JVM}universe()
identifier "universe" is undefined

That confirms the expected Windows behaviour: we still need JNIEXPORT to make debug.cpp utils callable by a debugger.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499341256

From jwaters at openjdk.org  Thu Feb 22 14:42:54 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Feb 2024 14:42:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v4]
In-Reply-To: <vIH043hYabyI97214HCCxnzP2YcrCNr2pEkeLWs6tM4=.069f3df2-fa1d-4d2c-842e-5aa1e7d915ff@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
 <2wcpOdg70sjre1ULOsoeTKxu7Axq46zoU9qo_bkMgdM=.87d80995-09f3-417a-9270-56dd365d2b06@github.com>
 <iD9Cps1c81g7BYImEu15xOQvY3Mq9IFZp5_iWU0pm0o=.abd92460-a728-48e3-a6d9-12d8a32b9e7d@github.com>
 <EhViMvCbwUI2HUVsMdUAgr3tB4S1luXqdrG8cNbwtlA=.7b8ddcb7-ea13-4955-9b83-76ed79f1adce@github.com>
 <lIVvvltNqX9EzhzaitISyBocIyA3C4ZjJv83ldUnmeg=.a21613ca-ba82-4412-8040-2058fba56661@github.com>
 <E9y5WFeGqqskboveKh7YamHgbz6Ur5QdJji2uOxzt6c=.4aad38fd-6a31-4881-a2b8-b145d22a6763@github.com>
 <Wo15zScdWr27VO2St0-ExVqddH1wWLdS2cnRF6Yq1wE=.505b59eb-9942-4b85-901d-97715025c078@github.com>
 <Y9p2b3b_z8muEidBlBBrpCwLumHrKejUvxfzqZxnBjo=.a9119066-f460-4ec0-aa58-c8d78c721f6f@github.com>
 <Kt8zuxrBV-xUzZI29-eMuQFoLU_phXcCB4qc63pe-PU=.06c7f6a1-0e01-4386-903e-bc81e5de1fb1@github.com>
 <vIH043hYabyI97214HCCxnzP2YcrCNr2pEk
 eLWs6tM4=.069f3df2-fa1d-4d2c-842e-5aa1e7d915ff@github.com>
Message-ID: <YI4DuNIo8Zg90K3vUxfbJMkihF299RgKWnoaiidPRDA=.9a4fb18b-28b0-4418-b887-f190077590d2@github.com>

On Thu, 22 Feb 2024 14:33:18 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> (I do like that we call it jvm.dll.map now, not just "jvm.map"!)

You can thank @fthevenet for that! :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499355063

From hannesw at openjdk.org  Thu Feb 22 14:56:13 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 22 Feb 2024 14:56:13 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v38]
In-Reply-To: <v4pGQYCagdT28cdABJW1F4NYIfyDmcmdQSHjER__oj4=.00669703-c320-4111-a791-3d2652e247fc@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <v4pGQYCagdT28cdABJW1F4NYIfyDmcmdQSHjER__oj4=.00669703-c320-4111-a791-3d2652e247fc@github.com>
Message-ID: <lZ0LMtIaIccoOtMm4jDBR1FgfXOk82GHrGkqgjFCBOw=.ec4699ff-ddde-4fed-ba22-960ab9a60538@github.com>

On Thu, 22 Feb 2024 00:17:29 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update DocCommentParser and tests to improve handling of code blocks and code spans in Markdown documentation comments
>  - fix indentation, for consistency

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1373:

> 1371:                 while (indent < currIndent) {
> 1372:                     currIndent = indentStack.pop();
> 1373:                 }

This new Markdown class looks very good!

I think in this place we also need to check for indented code blocks, since we reduced `currIndent` and may have 4 or more character indentation compared to the new `currIndent` value. 

My tentative fix is to add the following code here, but maybe there's a more elegant solution by restructuring the method to first check for `indent < currIndent` and then for new indented code blocks.


                if (indent >= currIndent + 4 && !isParagraph(prevLineKind)) {
                    blockId++;
                    lineKind = LineKind.INDENTED_CODE_BLOCK;
                    return;
                }


The following could be added to `TestMarkdownCodeBlocks.java` to test this case:


            POST_LIST_INDENT(
                    """
                         1.  list item
                         
                             second paragraph
                       
                            {@code CODE}
                            @Anno

                        end""",
                    """
                        <ol>
                        <li>
                        <p>list item</p>
                        <p>second paragraph</p>
                        </li>
                        </ol>
                        <pre><code>{@code CODE}
                        @Anno
                        </code></pre>
                        <p>end</p>"""),

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1499375866

From ihse at openjdk.org  Thu Feb 22 15:09:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 15:09:56 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <OlWBwMQB9opCYtf86_yTJ5-8zmwcgUuqyqVcaLzRCrM=.8448b5d5-928b-4755-81b8-69ccde611280@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <qD5Ael_CjnuLVdZOdQ863VqU1KBJp1x7J1f3OPOJjcI=.fc651d8a-8640-405d-8339-bffc91b23050@github.com>
 <7j108nQLaK4cLUE4ANl8gAsJby-Dg90ry1MH83Htkh0=.e7732c94-48e5-4e2b-ad08-90d3dba1bd82@github.com>
 <OlWBwMQB9opCYtf86_yTJ5-8zmwcgUuqyqVcaLzRCrM=.8448b5d5-928b-4755-81b8-69ccde611280@github.com>
Message-ID: <npFPREy6ZiUTGMH7oH-1PTOJkEy6TAtk4ZxUi9eG5vQ=.799f9c60-0757-48fd-b6de-b70d3bc32b02@github.com>

On Thu, 22 Feb 2024 14:28:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Regarding SUNWprivate_1.1, reading [JDK-4916160](https://bugs.openjdk.org/browse/JDK-4916160) it seems like it could cause problems for native user libraries linked against an older JDK version if we remove it. I think this is what David Holmes was referring to. So it seems like a good idea to figure out a way to keep it around.

"Forward compatibility issue : 1.4.1_03 onwards". Wow, that's a blast from the past! The sins of the fathers, etc. :)

I'm not sure I understand JDK-4916160 completely, but it seems they had the opposite situation -- prior to 1.4.1_03 we did not link with version scripts, and from 1.4.1_03 we did. And this was closed as "not an issue".

Nevertheless, I have found a way to keep the `SUNWprivate_1.1` that is not too ugly, so with the latest commit to this PR I am doing that. I have now verified that this makes no visible difference in the symbol tables at all between the current libjvm.so and the one produced with this patch on gcc. There is still a difference in the ordering of symbols; it seems like the linker is using a hash table and something is making it different -- perhaps the explicit ordering given in the old mapfile affected the way the linker produced the output. So it is still not a bit-by-bit equality, but it is as far as it is reasonable to get.

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

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1959646396

From jjg at openjdk.org  Thu Feb 22 15:17:10 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 22 Feb 2024 15:17:10 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v38]
In-Reply-To: <lZ0LMtIaIccoOtMm4jDBR1FgfXOk82GHrGkqgjFCBOw=.ec4699ff-ddde-4fed-ba22-960ab9a60538@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <v4pGQYCagdT28cdABJW1F4NYIfyDmcmdQSHjER__oj4=.00669703-c320-4111-a791-3d2652e247fc@github.com>
 <lZ0LMtIaIccoOtMm4jDBR1FgfXOk82GHrGkqgjFCBOw=.ec4699ff-ddde-4fed-ba22-960ab9a60538@github.com>
Message-ID: <GFw06006VTxdN05GICC5FMB-JEj7tD_GyYdhFUzIals=.66d6226d-95e7-4164-9864-c773d8100fe6@github.com>

On Thu, 22 Feb 2024 14:53:11 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update DocCommentParser and tests to improve handling of code blocks and code spans in Markdown documentation comments
>>  - fix indentation, for consistency
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1373:
> 
>> 1371:                 while (indent < currIndent) {
>> 1372:                     currIndent = indentStack.pop();
>> 1373:                 }
> 
> This new Markdown class looks very good!
> 
> I think in this place we also need to check for indented code blocks, since we reduced `currIndent` and may have 4 or more character indentation compared to the new `currIndent` value. 
> 
> My tentative fix is to add the following code here, but maybe a more elegant solution can be found by restructuring the method to first check for `indent < currIndent` and then only having to check for new indented code blocks once.
> 
> 
>                 if (indent >= currIndent + 4 && !isParagraph(prevLineKind)) {
>                     blockId++;
>                     lineKind = LineKind.INDENTED_CODE_BLOCK;
>                     return;
>                 }
> 
> 
> The following could be added to `TestMarkdownCodeBlocks.java` to test this case:
> 
> 
>             POST_LIST_INDENT(
>                     """
>                          1.  list item
>                          
>                              second paragraph
>                        
>                             {@code CODE}
>                             @Anno
> 
>                         end""",
>                     """
>                         <ol>
>                         <li>
>                         <p>list item</p>
>                         <p>second paragraph</p>
>                         </li>
>                         </ol>
>                         <pre><code>{@code CODE}
>                         @Anno
>                         </code></pre>
>                         <p>end</p>"""),

Thanks.  I will investigate your hint to look for a more elegant solution.  Thanks for the new test case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1499408829

From ihse at openjdk.org  Thu Feb 22 15:28:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 15:28:57 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v4]
In-Reply-To: <eKOLOhDFnBx9Ne1hfOYleMnz5iGt8Nb5g6JJ3S7b63Q=.b2744208-182b-47a7-a0ef-5b44061cdfb4@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <17uxknoRrcfnUlWwJndQk2AWqvZv4v34JZMVQPpl81w=.34a2c1a8-d251-4f8c-bd12-2f024b4914e6@github.com>
 <28TkIQvEbOiKscThXtUGZ24pcHI4wqrVgy6C2P6_f-4=.ae8dcc41-aedd-441c-a8ad-1526dd56db14@github.com>
 <FfaU4QcwSZnSxWSys6H3lqIO1UHBFKCb5dJ2tmNsR00=.6d492146-71d7-4530-bcdd-e0875bf02927@github.com>
 <A1r4AEShJI_4GfYz3lxkxopCNYuaMF-zhmhuhd493gY=.c112b7c1-5d21-4074-8967-48b48387bd23@github.com>
 <bCCiR8BHjfb_LNAuneO4lfRx1VY4UE8f1irt43V97vQ=.0010380e-f54d-439e-8877-5ba9a75fe71f@github.com>
 <rSSQn-eaJbthjFJBhKKLm9-GuvWLPhA293t5_AThMoE=.7dc91c10-b655-4b24-830c-3bb61ca99ff6@github.com>
 <eKOLOhDFnBx9Ne1hfOYleMnz5iGt8Nb5g6JJ3S7b63Q=.b2744208-182b-47a7-a0ef-5b44061cdfb4@github.com>
Message-ID: <EIXdI32FQTr9GWePU0HfJjQEoQvJm_8u6wTFRo-7p6o=.8e4518c3-4533-43de-99f8-24b9cd5ffde5@github.com>

On Thu, 22 Feb 2024 14:11:54 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Well, I hope that can be done, but it depends... As I see it, there are three possible ways to get rid of this `HIDDEN`.
>> 
>> 1) Accept that we export these functions on gcc, and just remove the attribute. (Kind of capitulating to the bug.)
>> 
>> 2) See if there is a way we can work around this problem, by changing something in how these functions are defined, that does not trigger this bug.
>> 
>> 3) Have this bug fixed in gcc, and move to a minimum version of gcc that includes this fix.
>> 
>> I'm not terribly keen on any of these solutions. I think 2, if it is possible, would be the simplest and cleanest. Or 1, if we really think this HIDDEN workaround is worse than the problem it solves (unintentionally exporting symbols).
>
> I see, seems like it's an unfortunate situation where a fix is hard or even impossible. If we file a gcc bug for it now, it'll get fixed in some insanely new gcc version (such as gcc 15 or 16) and we'd have to jump to that version, which I'm sure no one is going to like :(
> 
> Nevertheless, since there are so many instances of it, I suggest #pragma GCC visibility push(hidden) instead of adding a new macro to this file, in my opinion it's somewhat cleaner and also makes the change smaller.
> 
> #pragma GCC visibility push(hidden)
> // Junk that needs hidden visibility to work properly
> #pragma GCC visibility pop
> 
> Also, why TARGET_COMPILER_gcc instead of __GNUC__? Does this have to work with Apple Clang on macOS as well?

This is not an issue with clang, only gcc.

My understanding was that the proper way to test for compiler in Hotspot code was by using `TARGET_COMPILER_gcc`.

I can try using the `#pragma` route instead; if it works I agree it is slightly better than to sprinkle `HIDDEN` all over the place.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499427455

From ihse at openjdk.org  Thu Feb 22 15:32:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 15:32:56 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v4]
In-Reply-To: <YI4DuNIo8Zg90K3vUxfbJMkihF299RgKWnoaiidPRDA=.9a4fb18b-28b0-4418-b887-f190077590d2@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
 <2wcpOdg70sjre1ULOsoeTKxu7Axq46zoU9qo_bkMgdM=.87d80995-09f3-417a-9270-56dd365d2b06@github.com>
 <iD9Cps1c81g7BYImEu15xOQvY3Mq9IFZp5_iWU0pm0o=.abd92460-a728-48e3-a6d9-12d8a32b9e7d@github.com>
 <EhViMvCbwUI2HUVsMdUAgr3tB4S1luXqdrG8cNbwtlA=.7b8ddcb7-ea13-4955-9b83-76ed79f1adce@github.com>
 <lIVvvltNqX9EzhzaitISyBocIyA3C4ZjJv83ldUnmeg=.a21613ca-ba82-4412-8040-2058fba56661@github.com>
 <E9y5WFeGqqskboveKh7YamHgbz6Ur5QdJji2uOxzt6c=.4aad38fd-6a31-4881-a2b8-b145d22a6763@github.com>
 <Wo15zScdWr27VO2St0-ExVqddH1wWLdS2cnRF6Yq1wE=.505b59eb-9942-4b85-901d-97715025c078@github.com>
 <Y9p2b3b_z8muEidBlBBrpCwLumHrKejUvxfzqZxnBjo=.a9119066-f460-4ec0-aa58-c8d78c721f6f@github.com>
 <Kt8zuxrBV-xUzZI29-eMuQFoLU_phXcCB4qc63pe-PU=.06c7f6a1-0e01-4386-903e-bc81e5de1fb1@github.com>
 <vIH043hYabyI97214HCCxnzP2YcrCNr2pEk
 eLWs6tM4=.069f3df2-fa1d-4d2c-842e-5aa1e7d915ff@github.com>
 <YI4DuNIo8Zg90K3vUxfbJMkihF299RgKWnoaiidPRDA=.9a4fb18b-28b0-4418-b887-f190077590d2@github.com>
Message-ID: <VMHrBhtOTAzQXtAivx9ed688DfKy-ps37URGTgBNdzo=.4b9d2f7b-7010-4a26-87a7-0520f2c83350@github.com>

On Thu, 22 Feb 2024 14:40:36 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Windows:
>> Attach Visual Studio,
>> in the Immediate Window, type (funny VS syntax I do not claim to understand):
>> 
>> {,,JVM}universe()
>> 
>> ...and on the JVM's console window I see:
>> 
>> "Executing universe"
>> Heap
>>  garbage-first heap   total reserved 8343552K,...etc...
>> 
>> (It actually did nothing on the first invocation for me, I have typed it 5 times, only got 4 sets of output.  But the symbol is working...)
>> 
>> In that working (JNIEXPORT) case, the map file jdk/bin/server/jvm.dll.map shows:
>> 
>>  0001:0027ff50       universe                   0000000180280f50 f   debug.obj
>> 
>> (I do like that we call it jvm.dll.map now, not just "jvm.map"!)
>> 
>> Test removing JNIEXPORT:
>>  
>> Without JNIEXPORT, on Windows, the symbol universe is just not there.  Nothing in the map file.  In Visual Studio:
>> 
>> {,,JVM}universe()
>> identifier "universe" is undefined
>> 
>> That confirms the expected Windows behaviour: we still need JNIEXPORT to make debug.cpp utils callable by a debugger.
>
>> (I do like that we call it jvm.dll.map now, not just "jvm.map"!)
> 
> You can thank @fthevenet for that! :)

> Removing JNIEXPORT here on Linux and rebuilding: still works.
> 
> readelf shows: existing build (using JNIEXPORT): 32252: 0000000000698160 249 FUNC LOCAL DEFAULT 11 universe
> 
> without JNIEXPORT: 32252: 0000000000698160 249 FUNC LOCAL HIDDEN 11 universe
> 
> So gdb on Linux can call a HIDDEN function, i.e. without the JNIEXPORT. It seems happy either way, not affected by visibility.

@kevinjwalls Thank you for testing this for me!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499434437

From ihse at openjdk.org  Thu Feb 22 16:15:23 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 16:15:23 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v5]
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Use #pragma instead of HIDDEN define

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17955/files
  - new: https://git.openjdk.org/jdk/pull/17955/files/ad1d53c9..00e40a7f

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

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

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

From ihse at openjdk.org  Thu Feb 22 16:31:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 16:31:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v5]
In-Reply-To: <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
Message-ID: <HFkUkKFyXrNb5A-43YJGKnWMkOjy_sB3kU4NcA6iz0g=.6a08a4c1-17b5-40a5-937d-0ec81f2239bb@github.com>

On Thu, 22 Feb 2024 16:15:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use #pragma instead of HIDDEN define

I have created https://github.com/openjdk/jdk/pull/17967 as a dependent PR, to show the kind of changes I would like to see on top of this one. It will remove much of the ugliness in this patch, but at the cost of actually changing behavior.

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

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1959815352

From jjg at openjdk.org  Thu Feb 22 18:52:23 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 22 Feb 2024 18:52:23 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v39]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <5SSS_1z3Obdod4_VuERMXIEGR1MJO4HPJ0S809IHIbw=.99506367-dacb-4b75-b1c6-116f5b6f842e@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  refactor tests for Markdown headings into a separate test class.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/5fc9c84a..72420419

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=38
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=37-38

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

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

From jjg at openjdk.org  Thu Feb 22 19:17:04 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 22 Feb 2024 19:17:04 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v38]
In-Reply-To: <GFw06006VTxdN05GICC5FMB-JEj7tD_GyYdhFUzIals=.66d6226d-95e7-4164-9864-c773d8100fe6@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <v4pGQYCagdT28cdABJW1F4NYIfyDmcmdQSHjER__oj4=.00669703-c320-4111-a791-3d2652e247fc@github.com>
 <lZ0LMtIaIccoOtMm4jDBR1FgfXOk82GHrGkqgjFCBOw=.ec4699ff-ddde-4fed-ba22-960ab9a60538@github.com>
 <GFw06006VTxdN05GICC5FMB-JEj7tD_GyYdhFUzIals=.66d6226d-95e7-4164-9864-c773d8100fe6@github.com>
Message-ID: <yOLgfI9s-ucYNS_TkfFnF-PSeT45Jwbr9ezb1dKXhxs=.87c81bb6-8f22-4a32-bd86-67854eb3abf7@github.com>

On Thu, 22 Feb 2024 15:14:32 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1373:
>> 
>>> 1371:                 while (indent < currIndent) {
>>> 1372:                     currIndent = indentStack.pop();
>>> 1373:                 }
>> 
>> This new Markdown class looks very good!
>> 
>> I think in this place we also need to check for indented code blocks, since we reduced `currIndent` and may have 4 or more character indentation compared to the new `currIndent` value. 
>> 
>> My tentative fix is to add the following code here, but maybe a more elegant solution can be found by restructuring the method to first check for `indent < currIndent` and then only having to check for new indented code blocks once.
>> 
>> 
>>                 if (indent >= currIndent + 4 && !isParagraph(prevLineKind)) {
>>                     blockId++;
>>                     lineKind = LineKind.INDENTED_CODE_BLOCK;
>>                     return;
>>                 }
>> 
>> 
>> The following could be added to `TestMarkdownCodeBlocks.java` to test this case:
>> 
>> 
>>             POST_LIST_INDENT(
>>                     """
>>                          1.  list item
>>                          
>>                              second paragraph
>>                        
>>                             {@code CODE}
>>                             @Anno
>> 
>>                         end""",
>>                     """
>>                         <ol>
>>                         <li>
>>                         <p>list item</p>
>>                         <p>second paragraph</p>
>>                         </li>
>>                         </ol>
>>                         <pre><code>{@code CODE}
>>                         @Anno
>>                         </code></pre>
>>                         <p>end</p>"""),
>
> Thanks.  I will investigate your hint to look for a more elegant solution.  Thanks for the new test case.

>I think in this place we also need to check for indented code blocks, since we reduced currIndent and may have 4 or more character indentation compared to the new currIndent value.

This seems wrong. Surely, we should not reduce the indentation and then for the same line in the comment check for an extra-indented line. Or else I am missing something.

That being said, thanks for the test case. I will investigate it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1499779864

From jjg at openjdk.org  Thu Feb 22 19:20:03 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 22 Feb 2024 19:20:03 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v38]
In-Reply-To: <yOLgfI9s-ucYNS_TkfFnF-PSeT45Jwbr9ezb1dKXhxs=.87c81bb6-8f22-4a32-bd86-67854eb3abf7@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <v4pGQYCagdT28cdABJW1F4NYIfyDmcmdQSHjER__oj4=.00669703-c320-4111-a791-3d2652e247fc@github.com>
 <lZ0LMtIaIccoOtMm4jDBR1FgfXOk82GHrGkqgjFCBOw=.ec4699ff-ddde-4fed-ba22-960ab9a60538@github.com>
 <GFw06006VTxdN05GICC5FMB-JEj7tD_GyYdhFUzIals=.66d6226d-95e7-4164-9864-c773d8100fe6@github.com>
 <yOLgfI9s-ucYNS_TkfFnF-PSeT45Jwbr9ezb1dKXhxs=.87c81bb6-8f22-4a32-bd86-67854eb3abf7@github.com>
Message-ID: <c-Pj-sknElhYrvYqC7a9MTd_Kn5KktGnvXtvz2-RXeE=.0ae724da-1770-495a-a4c9-126a61d7e9b3@github.com>

On Thu, 22 Feb 2024 19:13:57 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Thanks.  I will investigate your hint to look for a more elegant solution.  Thanks for the new test case.
>
>>I think in this place we also need to check for indented code blocks, since we reduced currIndent and may have 4 or more character indentation compared to the new currIndent value.
> 
> This seems wrong. Surely, we should not reduce the indentation and then for the same line in the comment check for an extra-indented line. Or else I am missing something.
> 
> That being said, thanks for the test case. I will investigate it.

Update: I see and understand your test case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1499787391

From mikael at openjdk.org  Thu Feb 22 20:41:55 2024
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 22 Feb 2024 20:41:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v5]
In-Reply-To: <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
Message-ID: <GqHSMhaqW60MrimKY0DlSGt1Nl2B_vzPp_EjjH0T_oo=.b3d55d7b-e545-4cbf-bcd3-60b36283b878@github.com>

On Thu, 22 Feb 2024 16:15:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use #pragma instead of HIDDEN define

Not a review but I did want to mention that I proved to myself that your addition of `.hidden` for the assembly file symbols is the right thing to do. In particular, when we compile the .cpp files with the `-fvisibility=hidden` flag that's exactly what g++ does in the background.

Just a thought: Perhaps worth introducing some kind of macro that captures defining a symbol in assembly code (something that does `.globl` + `.hidden` on Linux and `.private_extern` on `__APPLE__`?

Also, separate from this change: perhaps worth turning on whitespace checking (no tabs) for .S files?

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

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1960276436

From jjg at openjdk.org  Thu Feb 22 20:47:25 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 22 Feb 2024 20:47:25 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v40]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <ir_8ofnXSTpl0w9d-a47PuuGX6QLp8Lcnc4jPoVAIl8=.3aaf8ef9-5997-44ae-b8ee-0b83cb80967e@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  fix Markdown.update for new POST_LIST_INDENT test case given in review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/72420419..27bc0b9d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=39
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=38-39

  Stats: 94 lines in 4 files changed: 53 ins; 16 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/16388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388

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

From jjg at openjdk.org  Thu Feb 22 20:52:10 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 22 Feb 2024 20:52:10 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v38]
In-Reply-To: <c-Pj-sknElhYrvYqC7a9MTd_Kn5KktGnvXtvz2-RXeE=.0ae724da-1770-495a-a4c9-126a61d7e9b3@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <v4pGQYCagdT28cdABJW1F4NYIfyDmcmdQSHjER__oj4=.00669703-c320-4111-a791-3d2652e247fc@github.com>
 <lZ0LMtIaIccoOtMm4jDBR1FgfXOk82GHrGkqgjFCBOw=.ec4699ff-ddde-4fed-ba22-960ab9a60538@github.com>
 <GFw06006VTxdN05GICC5FMB-JEj7tD_GyYdhFUzIals=.66d6226d-95e7-4164-9864-c773d8100fe6@github.com>
 <yOLgfI9s-ucYNS_TkfFnF-PSeT45Jwbr9ezb1dKXhxs=.87c81bb6-8f22-4a32-bd86-67854eb3abf7@github.com>
 <c-Pj-sknElhYrvYqC7a9MTd_Kn5KktGnvXtvz2-RXeE=.0ae724da-1770-495a-a4c9-126a61d7e9b3@github.com>
Message-ID: <mC1vsfZi_1FTX5mQ4d4ZNmSiSJcmhg0ENUc4UwO1nU0=.555fc394-f1d9-4f84-9061-f192725d9835@github.com>

On Thu, 22 Feb 2024 19:17:09 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>>>I think in this place we also need to check for indented code blocks, since we reduced currIndent and may have 4 or more character indentation compared to the new currIndent value.
>> 
>> This seems wrong. Surely, we should not reduce the indentation and then for the same line in the comment check for an extra-indented line. Or else I am missing something.
>> 
>> That being said, thanks for the test case. I will investigate it.
>
> Update: I see and understand your test case.

Update: I found that more elegant solution you hinted at, by refactoring the method from nested `if` statements to a series of checks with early returns.

The test case you provided now works as expected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1499918026

From jjg at openjdk.org  Thu Feb 22 21:00:35 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 22 Feb 2024 21:00:35 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v41]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <WkCCiFicRs9pw6GfmGtqlojAaHFuLfyfnw1elgmajiA=.cd12a572-8339-4869-9292-59b6fd347529@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  fix whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/27bc0b9d..40616865

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=40
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=39-40

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

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

From ihse at openjdk.org  Thu Feb 22 21:07:04 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 21:07:04 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v5]
In-Reply-To: <GqHSMhaqW60MrimKY0DlSGt1Nl2B_vzPp_EjjH0T_oo=.b3d55d7b-e545-4cbf-bcd3-60b36283b878@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
 <GqHSMhaqW60MrimKY0DlSGt1Nl2B_vzPp_EjjH0T_oo=.b3d55d7b-e545-4cbf-bcd3-60b36283b878@github.com>
Message-ID: <U9kUaw7Vtpdauxj-jFNXBNTVkbbQy2Gkh9axyk0N8cM=.2fab5edf-f63e-440b-892e-aac749600d90@github.com>

On Thu, 22 Feb 2024 20:38:42 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Just a thought: Perhaps worth introducing some kind of macro that captures defining a symbol in assembly code (something that does .globl + .hidden on Linux and .private_extern on __APPLE__?

I have thought the same. :) There seem to be room for improvement in a simple "framework" to reduce duplication across the .S files. (There is also plenty of room for improvement in coordinating the style across the .S files...) I believe one reason this has not yet happened is that up until a year or two ago, most Hotspot assembly files where .s (which are not preprocessed) as opposed to .S. I standardized on .S for all assembly code in the JDK project in JDK-8264188, and after that, the door has been open for the Hotspot developers to create such a macro.

> Also, separate from this change: perhaps worth turning on whitespace checking (no tabs) for .S files?

I'm [way ahead](https://github.com/magicus/jdk/tree/fix-jcheck-assembly-files) of you there. :) That is the next one up my pipeline in "turning on jcheck for all text files, one file type at the time". But is a chore, really, to get those kinds of fixes approved. And I wanted to get progress in the mapfile question first.

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

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1960310460

From dholmes at openjdk.org  Thu Feb 22 22:21:53 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Feb 2024 22:21:53 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234
In-Reply-To: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
Message-ID: <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>

On Thu, 22 Feb 2024 16:28:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been integrated, it is possible to do some cleanup. The goal of [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change any behavior, even if that behavior seemed odd.
> 
> Now let's try to fix that. We can:
> 
> a) remove JNIEXPORT from c2v functions.
> b) make debug.cpp functions exported similarly on all platforms.
> c) remove JNIEXPORT from aarch64 asm debug function.
> 
> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.

src/hotspot/cpu/aarch64/assembler_aarch64.cpp line 122:

> 120:   }
> 121: 
> 122:   void das1(uintptr_t insn) {

Doesn't this need to be exported for debugging on Windows-Aarch64?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1500001316

From dholmes at openjdk.org  Thu Feb 22 22:22:54 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Feb 2024 22:22:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <-pzo3-C5dN9IRd4dv7k_j8E0i7jR578u1gst0U6iAFI=.34ce218c-3d3f-409a-9c60-315eaab370fa@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <g0ZVkeeR7P1e4_8Z0-nQ8at63jrtZySDk8bKtub0mLw=.db5e4e9c-9ca6-4d5a-b31b-17f84981e14f@github.com>
 <Cd8440seSvfWXHBcZ8cx5K1qWcpf-qyET1IdFY8eWUo=.a64a2d4c-bd34-49fb-9167-8e4583add959@github.com>
 <-pzo3-C5dN9IRd4dv7k_j8E0i7jR578u1gst0U6iAFI=.34ce218c-3d3f-409a-9c60-315eaab370fa@github.com>
Message-ID: <oNoc9WvyhmiWPyT54itZtCrX9AIB3A99b3L8jfUcZCA=.f208e657-a6b5-4b38-92ea-022dbaba7c52@github.com>

On Thu, 22 Feb 2024 09:26:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I tried to be clear, but apparently I failed: There is no change to these symbols in the patch! So everything should work just as before!

Yes but "should work" and "does work" may not be the same unless you have actually verified the functionality. That said I now see that we only actually need to export on Windows for the debugging functions to work, so I agree everything should work just fine in that regard.

Apologies - It took me a little while to click to the fact not all JNIEXPORT symbols were actually being exported due to their omission in the mapfile - hence the need to now actually hide them to keep things working the same. (FWIW I don't think it matters if we export the debug functions unnecessarily on some platforms - I'd go for code simplicity/consistency. EDIT and I see you went that way too.)

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

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1960416613

From dholmes at openjdk.org  Thu Feb 22 22:25:54 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Feb 2024 22:25:54 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234
In-Reply-To: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
Message-ID: <1qV4pOnr-4-d-Z_dFPFJ_sPN06vWCfE4yjRjHaLYsgA=.4f20d03f-92cd-46be-b224-f9d5c50aa3a1@github.com>

On Thu, 22 Feb 2024 16:28:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been integrated, it is possible to do some cleanup. The goal of [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change any behavior, even if that behavior seemed odd.
> 
> Now let's try to fix that. We can:
> 
> a) remove JNIEXPORT from c2v functions.
> b) make debug.cpp functions exported similarly on all platforms.
> c) remove JNIEXPORT from aarch64 asm debug function.
> 
> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.

With the one exception above I agree with these choices going forward. I don't think it matters that exporting for the debugger is not actually necessary on some platforms, and so code simplicity wins out for me. That said the litmus test will be whether hermetic Java encounters any conflicts.

Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/17967#issuecomment-1960427179

From jjg at openjdk.org  Thu Feb 22 23:20:31 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 22 Feb 2024 23:20:31 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v42]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <BYhObV610c2nUt1KyZyl1tSawl2C9lvTp24XWnUUzuA=.e591edce-ee80-4beb-91d4-f9cd45505025@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  add support for (top-level) trailing code blocks
  add simple test case with tabs
  add TestMarkdownCodeBlocks.testTypical

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/40616865..d460ee33

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=41
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=40-41

  Stats: 143 lines in 3 files changed: 135 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/16388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388

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

From djelinski at openjdk.org  Fri Feb 23 07:50:55 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 23 Feb 2024 07:50:55 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234
In-Reply-To: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
Message-ID: <-iT0dy_iA2G0QOIKTPzWbmAoq5R5nBztXQGadPM3Txg=.0e4db140-d4ef-482e-a9ef-55067d4ffbed@github.com>

On Thu, 22 Feb 2024 16:28:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been integrated, it is possible to do some cleanup. The goal of [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change any behavior, even if that behavior seemed odd.
> 
> Now let's try to fix that. We can:
> 
> a) remove JNIEXPORT from c2v functions.
> b) make debug.cpp functions exported similarly on all platforms.
> c) remove JNIEXPORT from aarch64 asm debug function.
> 
> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.

Nice cleanup!

src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 1027:

> 1025: 
> 1026: extern "C" {
> 1027: VMStructEntry* jvmciHotSpotVMStructs = JVMCIVMStructs::localHotSpotVMStructs;

All these globals are unused now. You can remove them.

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

PR Review: https://git.openjdk.org/jdk/pull/17967#pullrequestreview-1897492946
PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1500284610

From djelinski at openjdk.org  Fri Feb 23 08:20:55 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 23 Feb 2024 08:20:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v5]
In-Reply-To: <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
Message-ID: <hqw0OeOo_jBuqfttrP7zJHFMTcN3yorEcF0Go214L-U=.65c0ea99-c55d-4ed4-ae27-1790e68b417d@github.com>

On Thu, 22 Feb 2024 16:15:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use #pragma instead of HIDDEN define

src/hotspot/share/oops/accessBackend.cpp line 40:

> 38: #if defined(TARGET_COMPILER_gcc)
> 39: // Needed to work around bug in gcc causing these symbols to be visible despite -fvisibility=hidden
> 40: #pragma GCC visibility push(hidden)

does it work for you? because it doesn't hide the arraycopy symbols for me. The explicit visibility(hidden) attribute did work.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1500329388

From ihse at openjdk.org  Fri Feb 23 11:03:58 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 11:03:58 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v5]
In-Reply-To: <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
Message-ID: <Bx5k6oYtUpIkRhI1c93vOpfTA5ECFQPfZ_BhW0hFtcM=.f26ded4c-d816-4be3-b1d0-b0b2aff61be6@github.com>

On Thu, 22 Feb 2024 16:15:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use #pragma instead of HIDDEN define

Just to confirm: this PR passes tier 1-5.

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

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1961125415

From ihse at openjdk.org  Fri Feb 23 11:06:04 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 11:06:04 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v2]
In-Reply-To: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
Message-ID: <AiV2aNRCeWDaFG8nyNqQ9dYGr6WZyL_dwyLwfsicaik=.216fbdd3-ea34-41a9-9c44-b400fd33b3d8@github.com>

> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been integrated, it is possible to do some cleanup. The goal of [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change any behavior, even if that behavior seemed odd.
> 
> Now let's try to fix that. We can:
> 
> a) remove JNIEXPORT from c2v functions.
> b) make debug.cpp functions exported similarly on all platforms.
> c) remove JNIEXPORT from aarch64 asm debug function.
> 
> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Remove jvmci globals

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17967/files
  - new: https://git.openjdk.org/jdk/pull/17967/files/18b3f1d6..216d0db5

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

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

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

From ihse at openjdk.org  Fri Feb 23 11:13:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 11:13:56 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v2]
In-Reply-To: <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
Message-ID: <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>

On Thu, 22 Feb 2024 22:18:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove jvmci globals
>
> src/hotspot/cpu/aarch64/assembler_aarch64.cpp line 122:
> 
>> 120:   }
>> 121: 
>> 122:   void das1(uintptr_t insn) {
> 
> Doesn't this need to be exported for debugging on Windows-Aarch64?

Ah, right, there is a Windows/aarch64 port. Forgot about it. :(

I don't know who maintains/cares about that port anymore. Pinging @mo-beck @lewurm @luhenry. Do anyone of you care about this anymore? If not, do you know if anyone has taken up the baton? (Or maybe it's time to retire the Windows/aarch64 port)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1500517200

From burban at openjdk.org  Fri Feb 23 11:37:53 2024
From: burban at openjdk.org (Bernhard Urban-Forster)
Date: Fri, 23 Feb 2024 11:37:53 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v2]
In-Reply-To: <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
 <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>
Message-ID: <WAwoF5K4yWv40dWrX1VjUfeVGYy918KDHp4qvuRQ5xM=.2aa20484-2def-46dc-b20f-4e866748e048@github.com>

On Fri, 23 Feb 2024 11:11:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/assembler_aarch64.cpp line 122:
>> 
>>> 120:   }
>>> 121: 
>>> 122:   void das1(uintptr_t insn) {
>> 
>> Doesn't this need to be exported for debugging on Windows-Aarch64?
>
> Ah, right, there is a Windows/aarch64 port. Forgot about it. :(
> 
> I don't know who maintains/cares about that port anymore. Pinging @mo-beck @lewurm @luhenry. Do anyone of you care about this anymore? If not, do you know if anyone has taken up the baton? (Or maybe it's time to retire the Windows/aarch64 port)

cc @karianna @gdams, is there a Windows/AArch64 owner?

> Or maybe it's time to retire the Windows/aarch64 port

I guess Windows/AArch64 as a platform hasn't really taken off _yet_, give it a few more years ? I certainly would not advocate for removing it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1500542216

From ihse at openjdk.org  Fri Feb 23 11:43:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 11:43:53 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v2]
In-Reply-To: <WAwoF5K4yWv40dWrX1VjUfeVGYy918KDHp4qvuRQ5xM=.2aa20484-2def-46dc-b20f-4e866748e048@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
 <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>
 <WAwoF5K4yWv40dWrX1VjUfeVGYy918KDHp4qvuRQ5xM=.2aa20484-2def-46dc-b20f-4e866748e048@github.com>
Message-ID: <1enXmdMITwK96Lz35sCWmkob9sLgKKt1N2Lp0NSldNc=.81d72c1e-0f11-452d-a55a-674f775fee47@github.com>

On Fri, 23 Feb 2024 11:35:19 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

>> Ah, right, there is a Windows/aarch64 port. Forgot about it. :(
>> 
>> I don't know who maintains/cares about that port anymore. Pinging @mo-beck @lewurm @luhenry. Do anyone of you care about this anymore? If not, do you know if anyone has taken up the baton? (Or maybe it's time to retire the Windows/aarch64 port)
>
> cc @karianna @gdams, is there a Windows/AArch64 owner?
> 
>> Or maybe it's time to retire the Windows/aarch64 port
> 
> I guess Windows/AArch64 as a platform hasn't really taken off _yet_, give it a few more years ? I certainly would not advocate for removing it.

Instead of discussing removal of windows/aarch64 (although the general rule in OpenJDK is that ports that are not maintained by anyone should be removed); let's stick to the question here: do we need to export `das1()` for debugging?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1500547680

From jwaters at openjdk.org  Fri Feb 23 11:50:54 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Feb 2024 11:50:54 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v2]
In-Reply-To: <AiV2aNRCeWDaFG8nyNqQ9dYGr6WZyL_dwyLwfsicaik=.216fbdd3-ea34-41a9-9c44-b400fd33b3d8@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <AiV2aNRCeWDaFG8nyNqQ9dYGr6WZyL_dwyLwfsicaik=.216fbdd3-ea34-41a9-9c44-b400fd33b3d8@github.com>
Message-ID: <Nf5G91Y0KH5h6V369Kg7mO3MTrZKe7GUp4bHfPbuP-0=.2c6d5485-82ef-44e9-84d7-d852a4558a4a@github.com>

On Fri, 23 Feb 2024 11:06:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been integrated, it is possible to do some cleanup. The goal of [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change any behavior, even if that behavior seemed odd.
>> 
>> Now let's try to fix that. We can:
>> 
>> a) remove JNIEXPORT from c2v functions.
>> b) make debug.cpp functions exported similarly on all platforms.
>> c) remove JNIEXPORT from aarch64 asm debug function.
>> 
>> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove jvmci globals

Marked as reviewed by jwaters (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/17967#pullrequestreview-1897936208

From burban at openjdk.org  Fri Feb 23 12:05:57 2024
From: burban at openjdk.org (Bernhard Urban-Forster)
Date: Fri, 23 Feb 2024 12:05:57 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v2]
In-Reply-To: <1enXmdMITwK96Lz35sCWmkob9sLgKKt1N2Lp0NSldNc=.81d72c1e-0f11-452d-a55a-674f775fee47@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
 <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>
 <WAwoF5K4yWv40dWrX1VjUfeVGYy918KDHp4qvuRQ5xM=.2aa20484-2def-46dc-b20f-4e866748e048@github.com>
 <1enXmdMITwK96Lz35sCWmkob9sLgKKt1N2Lp0NSldNc=.81d72c1e-0f11-452d-a55a-674f775fee47@github.com>
Message-ID: <bmgatRS3iZ6J35-pwQQ81ev8-lMBeyFcN6jzQFk_qno=.369060d2-3e1f-45c9-bad6-71bbc921b647@github.com>

On Fri, 23 Feb 2024 11:41:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> cc @karianna @gdams, is there a Windows/AArch64 owner?
>> 
>>> Or maybe it's time to retire the Windows/aarch64 port
>> 
>> I guess Windows/AArch64 as a platform hasn't really taken off _yet_, give it a few more years ? I certainly would not advocate for removing it.
>
> Instead of discussing removal of windows/aarch64 (although the general rule in OpenJDK is that ports that are not maintained by anyone should be removed); let's stick to the question here: do we need to export `das1()` for debugging?

Personally I have never used `das`/`das1` on any AArch64 port when debugging.  I guess it was somewhat handy when the backend was originally developed.  I would argue that the built-in disassembler of any debugger and `disnm` from `debug.cpp` are good enough, and thus `das`/`das1` can be removed.  What do you think @theRealAph ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1500568587

From mbaesken at openjdk.org  Fri Feb 23 12:23:54 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 23 Feb 2024 12:23:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v5]
In-Reply-To: <Bx5k6oYtUpIkRhI1c93vOpfTA5ECFQPfZ_BhW0hFtcM=.f26ded4c-d816-4be3-b1d0-b0b2aff61be6@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
 <Bx5k6oYtUpIkRhI1c93vOpfTA5ECFQPfZ_BhW0hFtcM=.f26ded4c-d816-4be3-b1d0-b0b2aff61be6@github.com>
Message-ID: <bS__uPDEKVk-0o6PvRBtOicHdBWcnQu_oBBLptF2Hvk=.904db0db-863d-4185-8db5-de6dbe90c9f2@github.com>

On Fri, 23 Feb 2024 11:01:47 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Just to confirm: this PR passes tier 1-5.

We had the PR in our SAP internal build/test queue, so issues seen with it.

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

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1961232277

From ihse at openjdk.org  Fri Feb 23 12:38:23 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 12:38:23 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v6]
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <wvVBVyQswVhKlZM7Ux8ifRbqpqCoebaGJjqWHzuW6Gw=.67f9d62d-e669-4ade-8d97-94df4eeceed8@github.com>

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Use #pragma instead of HIDDEN define"
  
  This reverts commit 00e40a7f6e4cdef6592d72b3d08063cdcc41532a.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17955/files
  - new: https://git.openjdk.org/jdk/pull/17955/files/00e40a7f..7be8372a

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

  Stats: 31 lines in 1 file changed: 4 ins; 7 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/17955.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17955/head:pull/17955

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

From ihse at openjdk.org  Fri Feb 23 12:38:23 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 12:38:23 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v5]
In-Reply-To: <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
Message-ID: <kW1yBSV9G1v638XVumotNDpFlqxWl6TrJxSADh0-o9A=.0b7bf068-90be-4a23-bdb3-8030dc7ffc6c@github.com>

On Thu, 22 Feb 2024 16:15:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use #pragma instead of HIDDEN define

> We had the PR in our SAP internal build/test queue, so issues seen with it.

What issues did you see? Or was that a typo for "no issues"?

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

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1961248385

From mbaesken at openjdk.org  Fri Feb 23 12:38:23 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 23 Feb 2024 12:38:23 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v5]
In-Reply-To: <kW1yBSV9G1v638XVumotNDpFlqxWl6TrJxSADh0-o9A=.0b7bf068-90be-4a23-bdb3-8030dc7ffc6c@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
 <kW1yBSV9G1v638XVumotNDpFlqxWl6TrJxSADh0-o9A=.0b7bf068-90be-4a23-bdb3-8030dc7ffc6c@github.com>
Message-ID: <pN1koUwdey6yogGOs3LmVbC7ZeJUVmJNpTtoCKwjRFo=.ac73851f-982c-48a0-b57d-bc62f7d143b9@github.com>

On Fri, 23 Feb 2024 12:33:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > We had the PR in our SAP internal build/test queue, so issues seen with it.
> 
> What issues did you see? Or was that a typo for "no issues"?

Sorry Magnus, tests were fine no issues were observed.

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

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1961250951

From ihse at openjdk.org  Fri Feb 23 12:38:23 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 12:38:23 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v5]
In-Reply-To: <hqw0OeOo_jBuqfttrP7zJHFMTcN3yorEcF0Go214L-U=.65c0ea99-c55d-4ed4-ae27-1790e68b417d@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
 <hqw0OeOo_jBuqfttrP7zJHFMTcN3yorEcF0Go214L-U=.65c0ea99-c55d-4ed4-ae27-1790e68b417d@github.com>
Message-ID: <7o1sb2wW6T1LX8oN3G2J5JHrzBYCUwemoA6vqfxF5Og=.5fbe541a-371f-470a-a55e-a8a66c3ac630@github.com>

On Fri, 23 Feb 2024 08:18:17 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use #pragma instead of HIDDEN define
>
> src/hotspot/share/oops/accessBackend.cpp line 40:
> 
>> 38: #if defined(TARGET_COMPILER_gcc)
>> 39: // Needed to work around bug in gcc causing these symbols to be visible despite -fvisibility=hidden
>> 40: #pragma GCC visibility push(hidden)
> 
> does it work for you? because it doesn't hide the arraycopy symbols for me. The explicit visibility(hidden) attribute did work.

You are absolutely correct. I thought I checked that it did work, but I must have messed up somehow, because now that I retest, I see that it did not have any effect. I'm reverting that change. Thanks for being attentive!

(Presumably, gcc already knew that it where compiling with visibility hidden, so the pragma did nothing, in contrast with the explicit attribute on individual functions.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1500596597

From ihse at openjdk.org  Fri Feb 23 12:41:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 12:41:18 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v3]
In-Reply-To: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
Message-ID: <TsgvKQoINmIhgo92uwRwBynKrX4hwVicrl1TMoOSK6k=.b07ed6bf-15c7-4834-ba21-2e062d35c4fb@github.com>

> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been integrated, it is possible to do some cleanup. The goal of [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change any behavior, even if that behavior seemed odd.
> 
> Now let's try to fix that. We can:
> 
> a) remove JNIEXPORT from c2v functions.
> b) make debug.cpp functions exported similarly on all platforms.
> c) remove JNIEXPORT from aarch64 asm debug function.
> 
> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Remove jvmci globals
 - 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17967/files
  - new: https://git.openjdk.org/jdk/pull/17967/files/216d0db5..b6bd5f22

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

  Stats: 31 lines in 1 file changed: 4 ins; 7 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/17967.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17967/head:pull/17967

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

From djelinski at openjdk.org  Fri Feb 23 12:41:55 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 23 Feb 2024 12:41:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v6]
In-Reply-To: <wvVBVyQswVhKlZM7Ux8ifRbqpqCoebaGJjqWHzuW6Gw=.67f9d62d-e669-4ade-8d97-94df4eeceed8@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <wvVBVyQswVhKlZM7Ux8ifRbqpqCoebaGJjqWHzuW6Gw=.67f9d62d-e669-4ade-8d97-94df4eeceed8@github.com>
Message-ID: <Q8u6EqPKibxDuixCm6i4jeM1nFybu-tkmoHtjfNKPQw=.2e7c8dfa-a8a1-401d-b772-146878710373@github.com>

On Fri, 23 Feb 2024 12:38:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Use #pragma instead of HIDDEN define"
>   
>   This reverts commit 00e40a7f6e4cdef6592d72b3d08063cdcc41532a.

Great. The only remaining difference I see is that the PR adds the following export:

_ZGRN14AsyncLogWriter4NoneE_@@SUNWprivate_1.1

Any idea what it might be? If not, I guess we can live with that.

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

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1961255985

From ihse at openjdk.org  Fri Feb 23 12:46:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 12:46:00 GMT
Subject: RFR: 8326406: Remove mapfile support from makefiles
Message-ID: <2EPPAU63apAOBbSIvzLhgAhGcCvGLCUe2BZHqWCBQno=.74a66c6b-7d20-4545-bb11-b2d63bf275fb@github.com>

Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) is done, we have no need for mapfiles anymore in the JDK project. The mapfile handling was inherited from the old build system and is just messy. We should remove it to make the linking process more clear.

Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.

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

Depends on: https://git.openjdk.org/jdk/pull/17955

Commit messages:
 - 8326406: Remove mapfile support from makefiles

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

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

From jwaters at openjdk.org  Fri Feb 23 12:58:55 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Feb 2024 12:58:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v6]
In-Reply-To: <EIXdI32FQTr9GWePU0HfJjQEoQvJm_8u6wTFRo-7p6o=.8e4518c3-4533-43de-99f8-24b9cd5ffde5@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <17uxknoRrcfnUlWwJndQk2AWqvZv4v34JZMVQPpl81w=.34a2c1a8-d251-4f8c-bd12-2f024b4914e6@github.com>
 <28TkIQvEbOiKscThXtUGZ24pcHI4wqrVgy6C2P6_f-4=.ae8dcc41-aedd-441c-a8ad-1526dd56db14@github.com>
 <FfaU4QcwSZnSxWSys6H3lqIO1UHBFKCb5dJ2tmNsR00=.6d492146-71d7-4530-bcdd-e0875bf02927@github.com>
 <A1r4AEShJI_4GfYz3lxkxopCNYuaMF-zhmhuhd493gY=.c112b7c1-5d21-4074-8967-48b48387bd23@github.com>
 <bCCiR8BHjfb_LNAuneO4lfRx1VY4UE8f1irt43V97vQ=.0010380e-f54d-439e-8877-5ba9a75fe71f@github.com>
 <rSSQn-eaJbthjFJBhKKLm9-GuvWLPhA293t5_AThMoE=.7dc91c10-b655-4b24-830c-3bb61ca99ff6@github.com>
 <eKOLOhDFnBx9Ne1hfOYleMnz5iGt8Nb5g6JJ3S7b63Q=.b2744208-182b-47a7-a0ef-5b44061cdfb4@github.com>
 <EIXdI32FQTr9GWePU0HfJjQEoQvJm_8u6wTFRo-7p6o=.8e4518c3-4533-43de-99f8-24b9cd5ffde5@github.com>
Message-ID: <6McYQFZjV07KjPrHScf7jKNAMtsmS9kbfWgI97_rUX8=.20999798-92e9-4e4c-a1ea-24787d2b88ba@github.com>

On Thu, 22 Feb 2024 15:26:34 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I see, seems like it's an unfortunate situation where a fix is hard or even impossible. If we file a gcc bug for it now, it'll get fixed in some insanely new gcc version (such as gcc 15 or 16) and we'd have to jump to that version, which I'm sure no one is going to like :(
>> 
>> Nevertheless, since there are so many instances of it, I suggest #pragma GCC visibility push(hidden) instead of adding a new macro to this file, in my opinion it's somewhat cleaner and also makes the change smaller.
>> 
>> #pragma GCC visibility push(hidden)
>> // Junk that needs hidden visibility to work properly
>> #pragma GCC visibility pop
>> 
>> Also, why TARGET_COMPILER_gcc instead of __GNUC__? Does this have to work with Apple Clang on macOS as well?
>
> This is not an issue with clang, only gcc.
> 
> My understanding was that the proper way to test for compiler in Hotspot code was by using `TARGET_COMPILER_gcc`.
> 
> I can try using the `#pragma` route instead; if it works I agree it is slightly better than to sprinkle `HIDDEN` all over the place.

Drat, I thought the pragma would work. Sorry.

I would file a bug for gcc, but I have no idea what to even describe it as

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1500624847

From erikj at openjdk.org  Fri Feb 23 13:56:55 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 23 Feb 2024 13:56:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v2]
In-Reply-To: <0Inj4SqHl36K4FzxPfbfyA20_7x8GyGMngBfuNEGsf8=.9cba3073-cfdd-43a4-828a-4ec362dcaaf3@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <12hoUFbZkWHBpiXs0TPiMYGW3sSvBX_536mvSSG-y-8=.21abcef9-9a2b-4558-ba19-dddfd7931f9f@github.com>
 <0Inj4SqHl36K4FzxPfbfyA20_7x8GyGMngBfuNEGsf8=.9cba3073-cfdd-43a4-828a-4ec362dcaaf3@github.com>
Message-ID: <-Cqtxv3gK-PQ__1WEPOg_ls4KG0xAeU-yJV1668TUKI=.632a12f6-74c2-4e27-a448-0a5b469cc22e@github.com>

On Thu, 22 Feb 2024 13:36:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I just realized I could keep an extremely simplified linker script ("mapfile") for gcc, and thereby keeping the `@SUNWprivate_1.1` on the exported symbols, and keeping `__bss_start` and friends local. This further minimizes the difference to the existing libjvm.so for gcc builds.

Why do this just for GCC? Shouldn't this be for Linux as we are doing it for backwards compatibility with user JNI libraries.

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

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1961367943

From djelinski at openjdk.org  Fri Feb 23 14:12:56 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 23 Feb 2024 14:12:56 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v6]
In-Reply-To: <wvVBVyQswVhKlZM7Ux8ifRbqpqCoebaGJjqWHzuW6Gw=.67f9d62d-e669-4ade-8d97-94df4eeceed8@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <wvVBVyQswVhKlZM7Ux8ifRbqpqCoebaGJjqWHzuW6Gw=.67f9d62d-e669-4ade-8d97-94df4eeceed8@github.com>
Message-ID: <bE3-ecBvgYUgjgz58QwIYHW-f8L1332NOyQMH9rE-hQ=.302a7b23-e189-4926-8f10-2f3bfc758f87@github.com>

On Fri, 23 Feb 2024 12:38:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Use #pragma instead of HIDDEN define"
>   
>   This reverts commit 00e40a7f6e4cdef6592d72b3d08063cdcc41532a.

Windows-x64 and Linux-x64 look fine to me.

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17955#pullrequestreview-1898203882

From jwaters at openjdk.org  Fri Feb 23 14:19:53 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Feb 2024 14:19:53 GMT
Subject: RFR: 8326406: Remove mapfile support from makefiles
In-Reply-To: <2EPPAU63apAOBbSIvzLhgAhGcCvGLCUe2BZHqWCBQno=.74a66c6b-7d20-4545-bb11-b2d63bf275fb@github.com>
References: <2EPPAU63apAOBbSIvzLhgAhGcCvGLCUe2BZHqWCBQno=.74a66c6b-7d20-4545-bb11-b2d63bf275fb@github.com>
Message-ID: <1ioZ1at9TwD_76i7WOacRAIKxVHXzY6aeTXkGvo7sy4=.23f4abd7-667e-4381-bee3-e9f911222e96@github.com>

On Fri, 23 Feb 2024 12:42:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) is done, we have no need for mapfiles anymore in the JDK project. The mapfile handling was inherited from the old build system and is just messy. We should remove it to make the linking process more clear.
> 
> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.

Marked as reviewed by jwaters (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/17982#pullrequestreview-1898222180

From erikj at openjdk.org  Fri Feb 23 14:54:53 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 23 Feb 2024 14:54:53 GMT
Subject: RFR: 8326406: Remove mapfile support from makefiles
In-Reply-To: <2EPPAU63apAOBbSIvzLhgAhGcCvGLCUe2BZHqWCBQno=.74a66c6b-7d20-4545-bb11-b2d63bf275fb@github.com>
References: <2EPPAU63apAOBbSIvzLhgAhGcCvGLCUe2BZHqWCBQno=.74a66c6b-7d20-4545-bb11-b2d63bf275fb@github.com>
Message-ID: <DODpf1_RXwhY7Id1skXP-y5x93ULpXIFvniKwnmY-Fc=.2c954ae6-2f35-40a0-a084-0cf5d4106311@github.com>

On Fri, 23 Feb 2024 12:42:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) is done, we have no need for mapfiles anymore in the JDK project. The mapfile handling was inherited from the old build system and is just messy. We should remove it to make the linking process more clear.
> 
> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17982#pullrequestreview-1898299670

From ihse at openjdk.org  Fri Feb 23 15:22:13 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 15:22:13 GMT
Subject: RFR: 8326585: COMPARE_BUILD=PATCH fails if patch -R fails
Message-ID: <Z4CjLwTbTc6qtJuRM7q4kDnBmsCGEnoynzf0s3Ai11w=.516a8299-52b1-497f-bb55-9415fa4ab05f@github.com>

At the end of a COMPARE_BUILD run with a patch file, the build tries to revert the patch to restore the workspace as it was. On some versions of patch, this fails if one or more files were deleted, causing the makefile to abort just before the actual comparison. :-(

Reverting the patch is just a courtesy act for running on a developer workspace, so even if this fails, we should continue with the comparison.

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

Commit messages:
 - 8326585: COMPARE_BUILD=PATCH fails if patch -R fails

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

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

From ihse at openjdk.org  Fri Feb 23 16:28:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 16:28:01 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution
Message-ID: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>

The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).

There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).

The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.

Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.

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

Commit messages:
 - 8326583: Remove over-generalized DefineNativeToolchain solution

Changes: https://git.openjdk.org/jdk/pull/17986/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17986&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326583
  Stats: 225 lines in 14 files changed: 55 ins; 137 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/17986.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17986/head:pull/17986

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

From ihse at openjdk.org  Fri Feb 23 16:29:06 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 16:29:06 GMT
Subject: RFR: 8326587: Split Link.gmk into a Windows and Unix part
Message-ID: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>

There is not much overlap on how linking is done on Windows on one hand, and on all Unix platforms on the other. This makes Link.gmk basically consists of two parts, each in it own half of if statements, and the few common parts are artificially shoehorned in to fit both sides.

The code will be much clearer if we just split this into two different files.

Note that this PR slightly collides with JDK-8326583 (https://github.com/openjdk/jdk/pull/17986). Whichever of this goes in first will mean that the other one needs to make some adaptations.

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

Commit messages:
 - 8326587: Split Link.gmk into a Windows and Unix part

Changes: https://git.openjdk.org/jdk/pull/17987/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17987&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326587
  Stats: 659 lines in 13 files changed: 362 ins; 283 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/17987.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17987/head:pull/17987

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

From ihse at openjdk.org  Fri Feb 23 17:01:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 17:01:54 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution
In-Reply-To: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
Message-ID: <EL5wZKbTi4Oo5JvwTI2a46OzE5x9f5nMRelbjXZ9i8E=.71b7aa49-ef7d-4199-9690-9e57183c6401@github.com>

On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
> 
> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
> 
> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
> 
> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.

I have verified that there is no differences in the resulting output using COMPARE_BUILD, for the platforms in Oracle's CI: windows-x64,linux-x64,linux-aarch64,macosx-x64,macosx-aarch64, confirming that this is a pure build system refactoring.

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1961679913

From erikj at openjdk.org  Fri Feb 23 17:26:52 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 23 Feb 2024 17:26:52 GMT
Subject: RFR: 8326585: COMPARE_BUILD=PATCH fails if patch -R fails
In-Reply-To: <Z4CjLwTbTc6qtJuRM7q4kDnBmsCGEnoynzf0s3Ai11w=.516a8299-52b1-497f-bb55-9415fa4ab05f@github.com>
References: <Z4CjLwTbTc6qtJuRM7q4kDnBmsCGEnoynzf0s3Ai11w=.516a8299-52b1-497f-bb55-9415fa4ab05f@github.com>
Message-ID: <dMcLJD_AqEgfwfGxXbxlfeYkoXwZY-RMRF0armuFqEQ=.a2ed82b3-5204-4e43-97db-bb7c1d2a6c4d@github.com>

On Fri, 23 Feb 2024 15:18:11 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> At the end of a COMPARE_BUILD run with a patch file, the build tries to revert the patch to restore the workspace as it was. On some versions of patch, this fails if one or more files were deleted, causing the makefile to abort just before the actual comparison. :-(
> 
> Reverting the patch is just a courtesy act for running on a developer workspace, so even if this fails, we should continue with the comparison.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17983#pullrequestreview-1898603155

From ihse at openjdk.org  Fri Feb 23 17:34:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 17:34:56 GMT
Subject: Integrated: 8326585: COMPARE_BUILD=PATCH fails if patch -R fails
In-Reply-To: <Z4CjLwTbTc6qtJuRM7q4kDnBmsCGEnoynzf0s3Ai11w=.516a8299-52b1-497f-bb55-9415fa4ab05f@github.com>
References: <Z4CjLwTbTc6qtJuRM7q4kDnBmsCGEnoynzf0s3Ai11w=.516a8299-52b1-497f-bb55-9415fa4ab05f@github.com>
Message-ID: <sVvmSUWLnadktfTyL1tdC8GbS7gv38k_jVVjr5qSMck=.3036d1c1-c04a-4b9b-b84f-c384df672ce2@github.com>

On Fri, 23 Feb 2024 15:18:11 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> At the end of a COMPARE_BUILD run with a patch file, the build tries to revert the patch to restore the workspace as it was. On some versions of patch, this fails if one or more files were deleted, causing the makefile to abort just before the actual comparison. :-(
> 
> Reverting the patch is just a courtesy act for running on a developer workspace, so even if this fails, we should continue with the comparison.

This pull request has now been integrated.

Changeset: 27574b38
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/27574b384cb5c46358a8bba1bffa8d57d85f6670
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

8326585: COMPARE_BUILD=PATCH fails if patch -R fails

Reviewed-by: erikj

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

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

From erikj at openjdk.org  Fri Feb 23 18:19:53 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 23 Feb 2024 18:19:53 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution
In-Reply-To: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
Message-ID: <TlFRoK5j_lXVKxw3quLpub4-807o9nWucWpPf9pKuZs=.6aa870a1-bb43-4382-9328-3e2288c43f4a@github.com>

On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
> 
> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
> 
> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
> 
> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17986#pullrequestreview-1898688421

From naoto at openjdk.org  Fri Feb 23 21:29:54 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 23 Feb 2024 21:29:54 GMT
Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK
Message-ID: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>

This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted.

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

Commit messages:
 - cleanup
 - BreakIteratorProvider available locales fix
 - clean-up
 - test fixes
 - makeZoneData.pl fix
 - Vanguard fix
 - test fixes
 - tz fixes
 - Specification changes
 - Restoring a test
 - ... and 29 more: https://git.openjdk.org/jdk/compare/b419e951...f3db6099

Changes: https://git.openjdk.org/jdk/pull/17991/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17991&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8174269
  Stats: 67652 lines in 566 files changed: 478 ins; 66408 del; 766 mod
  Patch: https://git.openjdk.org/jdk/pull/17991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17991/head:pull/17991

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

From ihse at openjdk.org  Fri Feb 23 21:31:29 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 21:31:29 GMT
Subject: RFR: 8326587: Split Link.gmk into a Windows and Unix part [v2]
In-Reply-To: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
References: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
Message-ID: <1mF5_28ZETvfsfi6gD0W0YCUiIp9xDphPY1NZf5twls=.b077d236-84fc-43cf-9b85-e70629d7e5b3@github.com>

> There is not much overlap on how linking is done on Windows on one hand, and on all Unix platforms on the other. This makes Link.gmk basically consists of two parts, each in it own half of if statements, and the few common parts are artificially shoehorned in to fit both sides.
> 
> The code will be much clearer if we just split this into two different files.
> 
> Note that this PR slightly collides with JDK-8326583 (https://github.com/openjdk/jdk/pull/17986). Whichever of this goes in first will mean that the other one needs to make some adaptations.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8326587: Split Link.gmk into a Windows and Unix part

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

Changes: https://git.openjdk.org/jdk/pull/17987/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17987&range=01
  Stats: 668 lines in 13 files changed: 371 ins; 283 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/17987.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17987/head:pull/17987

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

From erikj at openjdk.org  Fri Feb 23 21:31:29 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 23 Feb 2024 21:31:29 GMT
Subject: RFR: 8326587: Split Link.gmk into a Windows and Unix part
In-Reply-To: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
References: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
Message-ID: <HFMzhUCniFajX08pefRBngDo9k9pqgW6Ea8OpiR3J20=.d09bdcdb-4fec-4c07-a423-bfa72a88de49@github.com>

On Fri, 23 Feb 2024 16:24:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> There is not much overlap on how linking is done on Windows on one hand, and on all Unix platforms on the other. This makes Link.gmk basically consists of two parts, each in it own half of if statements, and the few common parts are artificially shoehorned in to fit both sides.
> 
> The code will be much clearer if we just split this into two different files.
> 
> Note that this PR slightly collides with JDK-8326583 (https://github.com/openjdk/jdk/pull/17986). Whichever of this goes in first will mean that the other one needs to make some adaptations.

Is it really a good idea to split makefiles based on target platform? It creates a less flexible separation that makes experimentation with different combinations of toolchains and platforms much harder. We currently have a pretty well established mapping between target platform and toolchain type in practice, while trying to keep the concepts somewhat separated, but this kind of change really cements that mapping. Given Julian's ambition for making it possible to compile for Windows using a different toolchain, I'm not sure this is the right way to go.

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

PR Comment: https://git.openjdk.org/jdk/pull/17987#issuecomment-1961739183

From ihse at openjdk.org  Fri Feb 23 21:31:29 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 21:31:29 GMT
Subject: RFR: 8326587: Split Link.gmk into a Windows and Unix part
In-Reply-To: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
References: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
Message-ID: <Vbt2UZ2A9OwRxKkS-8EC1wevsKmRj2OUBYu4kAAp0cs=.17314d0f-964b-4f8e-a50d-e0d382cc688d@github.com>

On Fri, 23 Feb 2024 16:24:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> There is not much overlap on how linking is done on Windows on one hand, and on all Unix platforms on the other. This makes Link.gmk basically consists of two parts, each in it own half of if statements, and the few common parts are artificially shoehorned in to fit both sides.
> 
> The code will be much clearer if we just split this into two different files.
> 
> Note that this PR slightly collides with JDK-8326583 (https://github.com/openjdk/jdk/pull/17986). Whichever of this goes in first will mean that the other one needs to make some adaptations.

I have verified that there is no differences in the resulting output using COMPARE_BUILD, for the platforms in Oracle's CI: windows-x64,linux-x64,linux-aarch64,macosx-x64,macosx-aarch64, confirming that this is a pure build system refactoring.

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

PR Comment: https://git.openjdk.org/jdk/pull/17987#issuecomment-1962011909

From ihse at openjdk.org  Fri Feb 23 21:34:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 21:34:03 GMT
Subject: RFR: 8326587: Separate out Microsoft toolchain linking
In-Reply-To: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
References: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
Message-ID: <2zsgTlDhtnz0Z0wz5DyH51nH9QDktaaTRYPx_AVmUBQ=.a9a9a6d9-2fbb-439b-8339-1b541f6f80ee@github.com>

On Fri, 23 Feb 2024 16:24:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> There is not much overlap on how linking is done on Windows on one hand, and on all Unix platforms on the other. This makes Link.gmk basically consists of two parts, each in it own half of if statements, and the few common parts are artificially shoehorned in to fit both sides.
> 
> The code will be much clearer if we just split this into two different files.
> 
> Note that this PR slightly collides with JDK-8326583 (https://github.com/openjdk/jdk/pull/17986). Whichever of this goes in first will mean that the other one needs to make some adaptations.

Ok, fair enough, I should have phrase this split as "Microsoft toolchain" and "everything else". The point is that linking is vastly different on Windows than on other platforms. Our efforts to force "lib" to behave as "ar" etc was far-fetched to begin with. And to fully support static libraries, we need to separate the static linking into several steps, running ld, objcopy and then finally ar There is no correspondence to of this at all with the Microsoft toolchain, and trying to shoehorn this in is just going to make matters worse.

I'll rename the split according to toolchain and not platform. (And then I think this will actually help Julian, since we'll push the microsoft strangeness away in a separate file.) Sounds OK to you then?

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

PR Comment: https://git.openjdk.org/jdk/pull/17987#issuecomment-1962018364

From ihse at openjdk.org  Fri Feb 23 21:40:22 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 21:40:22 GMT
Subject: RFR: 8326587: Separate out Microsoft toolchain linking [v3]
In-Reply-To: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
References: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
Message-ID: <0WRbl7Go_vt9S12RkwTYi5wECYZhqDPFPSQaYmJ6org=.c9502b99-c066-4f60-93df-8ea6aca1bf61@github.com>

> There is not much overlap on how linking is done on Windows on one hand, and on all Unix platforms on the other. This makes Link.gmk basically consists of two parts, each in it own half of if statements, and the few common parts are artificially shoehorned in to fit both sides.
> 
> The code will be much clearer if we just split this into two different files.
> 
> Note that this PR slightly collides with JDK-8326583 (https://github.com/openjdk/jdk/pull/17986). Whichever of this goes in first will mean that the other one needs to make some adaptations.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Rename Windows to Microsoft

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17987/files
  - new: https://git.openjdk.org/jdk/pull/17987/files/27500808..afd1edd7

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

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

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

From erikj at openjdk.org  Fri Feb 23 22:07:55 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 23 Feb 2024 22:07:55 GMT
Subject: RFR: 8326587: Separate out Microsoft toolchain linking
In-Reply-To: <2zsgTlDhtnz0Z0wz5DyH51nH9QDktaaTRYPx_AVmUBQ=.a9a9a6d9-2fbb-439b-8339-1b541f6f80ee@github.com>
References: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
 <2zsgTlDhtnz0Z0wz5DyH51nH9QDktaaTRYPx_AVmUBQ=.a9a9a6d9-2fbb-439b-8339-1b541f6f80ee@github.com>
Message-ID: <bwukMSinwh1sdWrj9jory5xND4uw4xFXm1OJbw43BJA=.c7785cc5-6ce5-453a-a9ff-582ffb1a9e1f@github.com>

On Fri, 23 Feb 2024 21:31:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Ok, fair enough, I should have phrase this split as "Microsoft toolchain" and "everything else". The point is that linking is vastly different on Windows than on other platforms. Our efforts to force "lib" to behave as "ar" etc was far-fetched to begin with. And to fully support static libraries, we need to separate the static linking into several steps, running ld, objcopy and then finally ar There is no correspondence to of this at all with the Microsoft toolchain, and trying to shoehorn this in is just going to make matters worse.
> 
> I'll rename the split according to toolchain and not platform. (And then I think this will actually help Julian, since we'll push the microsoft strangeness away in a separate file.) Sounds OK to you then?

That sounds good to me, thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/17987#issuecomment-1962063986

From erikj at openjdk.org  Fri Feb 23 22:22:58 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 23 Feb 2024 22:22:58 GMT
Subject: RFR: 8326587: Separate out Microsoft toolchain linking [v3]
In-Reply-To: <0WRbl7Go_vt9S12RkwTYi5wECYZhqDPFPSQaYmJ6org=.c9502b99-c066-4f60-93df-8ea6aca1bf61@github.com>
References: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
 <0WRbl7Go_vt9S12RkwTYi5wECYZhqDPFPSQaYmJ6org=.c9502b99-c066-4f60-93df-8ea6aca1bf61@github.com>
Message-ID: <z8Pe75XuElB5yt1HjRn-LnmQbXMtSZdLosduhgcWiUE=.d4be1be4-e870-4baf-8220-1150ca6a3a87@github.com>

On Fri, 23 Feb 2024 21:40:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> There is not much overlap on how linking is done on Windows on one hand, and on all Unix platforms on the other. This makes Link.gmk basically consists of two parts, each in it own half of if statements, and the few common parts are artificially shoehorned in to fit both sides.
>> 
>> The code will be much clearer if we just split this into two different files.
>> 
>> Note that this PR slightly collides with JDK-8326583 (https://github.com/openjdk/jdk/pull/17986). Whichever of this goes in first will mean that the other one needs to make some adaptations.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename Windows to Microsoft

I think this looks good. There looks to be a conflict with https://github.com/openjdk/jdk/pull/17986, but I assume you are aware.

make/autoconf/flags-other.m4 line 45:

> 43: AC_DEFUN([FLAGS_SETUP_LIBFLAGS],
> 44: [
> 45:     # LIB is used to create static libraries on Windows

indentation.

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

PR Review: https://git.openjdk.org/jdk/pull/17987#pullrequestreview-1899019687
PR Review Comment: https://git.openjdk.org/jdk/pull/17987#discussion_r1501222826

From jjg at openjdk.org  Fri Feb 23 22:27:43 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 23 Feb 2024 22:27:43 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v43]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <gwFu9c4-Y_zksoJ1Tu4eJ-rJm0DEf2EYCZj2OVVIrUE=.9e9533b9-751e-4dfd-890e-4dc48c3399ea@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Refactor most of TestMarkdown.java into separate tests, grouped by functionality

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/d460ee33..398f93fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=42
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=41-42

  Stats: 2001 lines in 9 files changed: 1143 ins; 857 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388

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

From jwaters at openjdk.org  Sat Feb 24 06:06:53 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 24 Feb 2024 06:06:53 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution
In-Reply-To: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
Message-ID: <Fz9PgUQ1lrYfk4Qa9Wgi8sNIo2IGC6uTgEXc4aKEyyI=.cbe5ac19-077c-434c-91c9-d6fd3d6c6392@github.com>

On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
> 
> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
> 
> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
> 
> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.

!!!

Not to be a party pooper, but this seems like it removes pretty some useful functionality from the build system. What if this is needed down the line? On the motivation of this change, TOOLCHAIN_LINK_CXX is pretty clear that the linker to be used is g++ instead of gcc for instance, while the new LANG parameter makes it look like SetupNativeCompilation only accepts and compiles C++ files if C++ is passed, and only C files if the new default of C is passed (For anyone looking in on this Pull Request who isn't familiar with the build system, it can compile a mix of both without issue). I'm not particularly sure this is a good idea, since a lot of flexibility seems to be lost with this change. I don't seem to see any simplification to SetupNativeCompilation either, maybe I'm missing something?

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1962269640

From jwaters at openjdk.org  Sat Feb 24 06:23:13 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 24 Feb 2024 06:23:13 GMT
Subject: RFR: 8326587: Separate out Microsoft toolchain linking
In-Reply-To: <bwukMSinwh1sdWrj9jory5xND4uw4xFXm1OJbw43BJA=.c7785cc5-6ce5-453a-a9ff-582ffb1a9e1f@github.com>
References: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
 <2zsgTlDhtnz0Z0wz5DyH51nH9QDktaaTRYPx_AVmUBQ=.a9a9a6d9-2fbb-439b-8339-1b541f6f80ee@github.com>
 <bwukMSinwh1sdWrj9jory5xND4uw4xFXm1OJbw43BJA=.c7785cc5-6ce5-453a-a9ff-582ffb1a9e1f@github.com>
Message-ID: <RoUJopnQFbBrI0TmVJugxkgY2GGH9GQLpqK0PZfQ9ZY=.5fa2f79e-007e-4479-bada-bc23c2897d3e@github.com>

On Fri, 23 Feb 2024 22:05:44 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> And then I think this will actually help Julian, since we'll push the microsoft strangeness away in a separate file

Thanks! Though I do first need to rebase on top of it and fix all the merge conflicts first...
(Thinking about it, this likely means I have to excise some of the Microsoft linking logic out into the "regular" linking file since some of the Microsoft linking process is used by Windows linking in general, even with the gcc toolchain)

Just a comment: Why not reuse the AR variable for lib rather than introduce an entirely new LIB variable? The logic treating lib.exe as ar is gone with this change, but that doesn't mean they have to be split into entirely different variables. LinkMicrosoft could just run $($1_AR) without treating it as ar. This saves one autoconf and Makefile variable

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

PR Comment: https://git.openjdk.org/jdk/pull/17987#issuecomment-1962272988

From alanb at openjdk.org  Sat Feb 24 08:38:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 24 Feb 2024 08:38:53 GMT
Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK
In-Reply-To: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
Message-ID: <Cfmsp8XmJXvUJg1XrwGcYl2AFHZWSSSEIC4K02WQFM8=.a78634e3-5127-4149-9d11-f290c2963929@github.com>

On Fri, 23 Feb 2024 21:24:10 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted.

>From a stewardship perspective I think we've done the right steps. To summarize:

- JDK 8 added the option to use CLDR locale data (JEP 127).
- JDK 9 switched to using CLDR locale data by default (JEP 252) with the option to run with -Djava.locale.providers=COMPAT and use the legacy/unmaintained locale data.
- JDK 21 added a warning when you run with -Djava.locale.providers=COMPAT announcing that this provider will be removed in a future release.
- With the proposal here, running with -Djava.locale.providers=COMPAT will print a warning to say that the configuration is ignored.

The reduction of 10Mb will be welcomed. There are likely projects that run their tests with the COMPAT provider. There may be some application deployments too. I've seen a few projects do changes in response to the run-time warning introduced in JDK 21 but there are likely projects/applications that will be "surprised" when they upgrade to JDK 23+ and tests fail. So I think one will need a bit of socialization and a loud release note.

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

PR Comment: https://git.openjdk.org/jdk/pull/17991#issuecomment-1962299087

From ihse at openjdk.org  Sat Feb 24 10:02:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sat, 24 Feb 2024 10:02:54 GMT
Subject: RFR: 8326587: Separate out Microsoft toolchain linking
In-Reply-To: <RoUJopnQFbBrI0TmVJugxkgY2GGH9GQLpqK0PZfQ9ZY=.5fa2f79e-007e-4479-bada-bc23c2897d3e@github.com>
References: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
 <2zsgTlDhtnz0Z0wz5DyH51nH9QDktaaTRYPx_AVmUBQ=.a9a9a6d9-2fbb-439b-8339-1b541f6f80ee@github.com>
 <bwukMSinwh1sdWrj9jory5xND4uw4xFXm1OJbw43BJA=.c7785cc5-6ce5-453a-a9ff-582ffb1a9e1f@github.com>
 <RoUJopnQFbBrI0TmVJugxkgY2GGH9GQLpqK0PZfQ9ZY=.5fa2f79e-007e-4479-bada-bc23c2897d3e@github.com>
Message-ID: <llrUBMECmyUzaYyxasX9cTYJXxN4u4aCownBtcREg3U=.197141d2-fc20-4956-8b96-148b4d0c2664@github.com>

On Sat, 24 Feb 2024 06:20:54 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Why not reuse the AR variable for lib rather than introduce an entirely new LIB variable? 

The reason will become more apparent as I progress towards proper handling of static libs. In short, AR is not by far a 1-to-1 mapping with LIB. On non-Microsoft toolchains, we are basically going to do static linking by ld + objcopy + ar; on Windows, it's just lib. So there is nothing to be gained by pretending that lib is ar.

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

PR Comment: https://git.openjdk.org/jdk/pull/17987#issuecomment-1962316021

From aturbanov at openjdk.org  Sat Feb 24 18:25:55 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 24 Feb 2024 18:25:55 GMT
Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK
In-Reply-To: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
Message-ID: <Lnw5mul2lWX734gWaneeJgbUXN6SP_jKKb_ZNqCEb1w=.51ac15dd-b3a4-4649-800b-0e4742ccde26@github.com>

On Fri, 23 Feb 2024 21:24:10 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted.

make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 768:

> 766:         var availableIds = getAvailableZoneIds();
> 767: 
> 768:         availableIds.stream().forEach(tzid -> {

Suggestion:

        availableIds.forEach(tzid -> {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1501677693

From karianna at openjdk.org  Sat Feb 24 20:04:53 2024
From: karianna at openjdk.org (Martijn Verburg)
Date: Sat, 24 Feb 2024 20:04:53 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v3]
In-Reply-To: <bmgatRS3iZ6J35-pwQQ81ev8-lMBeyFcN6jzQFk_qno=.369060d2-3e1f-45c9-bad6-71bbc921b647@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
 <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>
 <WAwoF5K4yWv40dWrX1VjUfeVGYy918KDHp4qvuRQ5xM=.2aa20484-2def-46dc-b20f-4e866748e048@github.com>
 <1enXmdMITwK96Lz35sCWmkob9sLgKKt1N2Lp0NSldNc=.81d72c1e-0f11-452d-a55a-674f775fee47@github.com>
 <bmgatRS3iZ6J35-pwQQ81ev8-lMBeyFcN6jzQFk_qno=.369060d2-3e1f-45c9-bad6-71bbc921b647@github.com>
Message-ID: <c-DwcGAX3JX-gnQ0CWuGzI09K5SCdQ_yxnBP-q9HT1o=.903a2615-8255-4bbf-aaa3-2e9fb0ae84f5@github.com>

On Fri, 23 Feb 2024 12:03:37 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

>> Instead of discussing removal of windows/aarch64 (although the general rule in OpenJDK is that ports that are not maintained by anyone should be removed); let's stick to the question here: do we need to export `das1()` for debugging?
>
> Personally I have never used `das`/`das1` on any AArch64 port when debugging.  I guess it was somewhat handy when the backend was originally developed.  I would argue that the built-in disassembler of any debugger and `disnm` from `debug.cpp` are good enough, and thus `das`/`das1` can be removed.  What do you think @theRealAph ?

Hi all - yes the Windows Arm port is maintained by Microsoft's JDK team. How can we help in this particular case?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1501690000

From karianna at openjdk.org  Sat Feb 24 20:04:53 2024
From: karianna at openjdk.org (Martijn Verburg)
Date: Sat, 24 Feb 2024 20:04:53 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v3]
In-Reply-To: <c-DwcGAX3JX-gnQ0CWuGzI09K5SCdQ_yxnBP-q9HT1o=.903a2615-8255-4bbf-aaa3-2e9fb0ae84f5@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
 <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>
 <WAwoF5K4yWv40dWrX1VjUfeVGYy918KDHp4qvuRQ5xM=.2aa20484-2def-46dc-b20f-4e866748e048@github.com>
 <1enXmdMITwK96Lz35sCWmkob9sLgKKt1N2Lp0NSldNc=.81d72c1e-0f11-452d-a55a-674f775fee47@github.com>
 <bmgatRS3iZ6J35-pwQQ81ev8-lMBeyFcN6jzQFk_qno=.369060d2-3e1f-45c9-bad6-71bbc921b647@github.com>
 <c-DwcGAX3JX-gnQ0CWuGzI09K5SCdQ_yxnBP-q9HT1o=.903a2615-8255-4bbf-aaa3-2e9fb0ae84f5@github.com>
Message-ID: <o3KeCSV9VoJrmFKEsfKPCJ0cnuYbZZcjY18qYWSXZns=.fc08ab1b-d6f3-4158-8291-63e2663c2992@github.com>

On Sat, 24 Feb 2024 20:00:34 GMT, Martijn Verburg <karianna at openjdk.org> wrote:

>> Personally I have never used `das`/`das1` on any AArch64 port when debugging.  I guess it was somewhat handy when the backend was originally developed.  I would argue that the built-in disassembler of any debugger and `disnm` from `debug.cpp` are good enough, and thus `das`/`das1` can be removed.  What do you think @theRealAph ?
>
> Hi all - yes the Windows Arm port is maintained by Microsoft's JDK team. How can we help in this particular case?

I assume you want to know if we use DAS/DAS1 for debugging purposes on that platform?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1501690156

From aph at openjdk.org  Mon Feb 26 08:57:58 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 26 Feb 2024 08:57:58 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v3]
In-Reply-To: <o3KeCSV9VoJrmFKEsfKPCJ0cnuYbZZcjY18qYWSXZns=.fc08ab1b-d6f3-4158-8291-63e2663c2992@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
 <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>
 <WAwoF5K4yWv40dWrX1VjUfeVGYy918KDHp4qvuRQ5xM=.2aa20484-2def-46dc-b20f-4e866748e048@github.com>
 <1enXmdMITwK96Lz35sCWmkob9sLgKKt1N2Lp0NSldNc=.81d72c1e-0f11-452d-a55a-674f775fee47@github.com>
 <bmgatRS3iZ6J35-pwQQ81ev8-lMBeyFcN6jzQFk_qno=.369060d2-3e1f-45c9-bad6-71bbc921b647@github.com>
 <c-DwcGAX3JX-gnQ0CWuGzI09K5SCdQ_yxnBP-q9HT1o=.903a2615-8255-4bbf-aaa3-2e9fb0ae84f5@github.com>
 <o3KeCSV9VoJrmFKEsfKPCJ0cnuYbZZcjY18qYWSXZns=.fc08ab1b-d6f3-4158-8291-63e2663c2992@github.com>
Message-ID: <PjRWrB0x0vcYcQoa6EK62usvbNr_AFa_IN2ljCLrDDI=.4d69297c-6996-4cb7-9bd6-50f961c43686@github.com>

On Sat, 24 Feb 2024 20:01:50 GMT, Martijn Verburg <karianna at openjdk.org> wrote:

>> Hi all - yes the Windows Arm port is maintained by Microsoft's JDK team. How can we help in this particular case?
>
> I assume you want to know if we use DAS/DAS1 for debugging purposes on that platform?

I use `das` every day. In contrast, I don't know what `das1` is for.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1502240540

From ihse at openjdk.org  Mon Feb 26 10:46:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Feb 2024 10:46:53 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution
In-Reply-To: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
Message-ID: <_PhDAdwBOdLadnoyFkOp3P7i9SC7MkakgujqRJ5shNE=.54492764-dfb5-4a90-a47d-d0a8a7625cdc@github.com>

On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
> 
> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
> 
> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
> 
> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.

First some general remarks. The thing about generalization is that you need to take it in right enough doses -- too much is just as problematic as too little. You can represent any program with a Turing machine that can read or write, and move a head back and forth. That is extremely general, and completely hopeless to program in. The right amount of generalization is reached when it helps you express the underlying ideas in a easy-to-understand way. If you got duplication, then it means something needs to be more generalized. But if you have a general solution that is only ever used in a single way, then you have over-generalization.

Secondly, trust the VCS. Keeping code around since it might be "needed down the line" is a very bad reason. If we will need it again, we can restore it from the history. My experience is that these things practically never happens -- even if you need something similar in the future, the requirements are almost always different enough that the old system did not work anyway.

And now over to more specific comments about this patch. There was a historic need for this function. When it was created, we started a new build system from the ground up to consolidate a myriad of different ways to build parts of the product. There were no good standardized toolchain, and we had a requirement to really handle different toolchains. Then during the years we have chipped away at all the odds bits and pieces, until the entire build uses (basically) the same toolchain -- the only difference is the linker argument. And, of course, the orthogonal question if we're targeting the build machine or the target machine, when cross-compiling. This is a very clear concept in the rest of the build system, but it was diffused in the toolchain profiles by making it look like we just have another "profile", like it was another version of gcc. 

So in this PR we replace a very general idea of a "profile" with two distinct options that we really care about -- what platform to target, and how we call the linker.

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1963821493

From ihse at openjdk.org  Mon Feb 26 10:51:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Feb 2024 10:51:54 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution
In-Reply-To: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
Message-ID: <cqq9qP243QpUZjj5ZF0qfaGu3KKjbi1HbdMChU2GoU4=.345062c7-8510-4c86-9671-7699924bfc0d@github.com>

On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
> 
> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
> 
> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
> 
> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.

I could have chosen to name the `LANG` argument e.g. `LINKER_LANG`. If you insist, I can go back and rename it like this also. But there was a reason I chose the more general `LANG`, and that is because we have other unresolved issues regarding C vs C++ in the build. We don't handle CFLAGS vs CXXFLAGS very well, and we have several convoluted fixes (that just smells "black magic") to get the build to work. My instinct is that these are highly correlated to the choice of linker -- basically, in the old build system, there were a difference between C-libs anc C++-libs that were not properly carried over to the new build system. My intention is to continue this work by aligning flags etc with this property as well. But this is future work, so one could argue that with just this patch, the name `LANG` is overly broad. 

I thought it was okay, in the light of future development, and the wish to keep argument names succinct, but if you object I can rename it.

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1963835032

From ihse at openjdk.org  Mon Feb 26 10:59:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Feb 2024 10:59:57 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v6]
In-Reply-To: <Q8u6EqPKibxDuixCm6i4jeM1nFybu-tkmoHtjfNKPQw=.2e7c8dfa-a8a1-401d-b772-146878710373@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <wvVBVyQswVhKlZM7Ux8ifRbqpqCoebaGJjqWHzuW6Gw=.67f9d62d-e669-4ade-8d97-94df4eeceed8@github.com>
 <Q8u6EqPKibxDuixCm6i4jeM1nFybu-tkmoHtjfNKPQw=.2e7c8dfa-a8a1-401d-b772-146878710373@github.com>
Message-ID: <lUGJBPTFMt9yVkPVMLmh8zDdXYkRtZm8Kk5xXnDpWOY=.ba653ee5-f1ca-4936-920b-43afd3e013d2@github.com>

On Fri, 23 Feb 2024 12:38:56 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Great. The only remaining difference I see is that the PR adds the following export:
> 
> ```
> _ZGRN14AsyncLogWriter4NoneE_@@SUNWprivate_1.1
> ```
> 
> Any idea what it might be? If not, I guess we can live with that.

No. I vaguely recognize this symbol as sticking out, but can't find it now in my runs. Which gcc version are you using?

I think this is another example of the gcc bug. `c++filt` says `reference temporary #0 for AsyncLogWriter::None`; I guess this is from `logAsyncWriter.cpp` line 47-49:

// LogDecorator::None applies to 'constant initialization' because of its constexpr constructor.
const LogDecorations& AsyncLogWriter::None = LogDecorations(LogLevel::Warning, LogTagSetMapping<LogTag::__NO_TAG>::tagset(),
                                      LogDecorators::None);


But I think we can live with that anyway, even if it gets exported for some gcc versions after this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1963855021

From ihse at openjdk.org  Mon Feb 26 11:03:19 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Feb 2024 11:03:19 GMT
Subject: RFR: 8326587: Separate out Microsoft toolchain linking [v3]
In-Reply-To: <8T0fMFPYWN06vymFJC0__R9LZzYI2VGxa8H2jFb7U6I=.81c0b2cc-a892-43f0-bc77-dd05894795e6@github.com>
References: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
 <0WRbl7Go_vt9S12RkwTYi5wECYZhqDPFPSQaYmJ6org=.c9502b99-c066-4f60-93df-8ea6aca1bf61@github.com>
 <z8Pe75XuElB5yt1HjRn-LnmQbXMtSZdLosduhgcWiUE=.d4be1be4-e870-4baf-8220-1150ca6a3a87@github.com>
 <8T0fMFPYWN06vymFJC0__R9LZzYI2VGxa8H2jFb7U6I=.81c0b2cc-a892-43f0-bc77-dd05894795e6@github.com>
Message-ID: <wrXOTZ7DTJ2oUlCUUzzjwhamUS3PxTUqxg5mI9LLbVI=.02d5b3cc-bcd4-40b3-944f-3d41acaeac46@github.com>

On Mon, 26 Feb 2024 10:58:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/autoconf/flags-other.m4 line 45:
>> 
>>> 43: AC_DEFUN([FLAGS_SETUP_LIBFLAGS],
>>> 44: [
>>> 45:     # LIB is used to create static libraries on Windows
>> 
>> indentation.
>
> Bummer, I missed this. :-( I will fix it in https://github.com/openjdk/jdk/pull/17986.

Oh, actually, I could not push. I thought you had approved this. Well, that saved me so that I could fix this. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17987#discussion_r1502422485

From ihse at openjdk.org  Mon Feb 26 11:03:19 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Feb 2024 11:03:19 GMT
Subject: RFR: 8326587: Separate out Microsoft toolchain linking [v3]
In-Reply-To: <z8Pe75XuElB5yt1HjRn-LnmQbXMtSZdLosduhgcWiUE=.d4be1be4-e870-4baf-8220-1150ca6a3a87@github.com>
References: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
 <0WRbl7Go_vt9S12RkwTYi5wECYZhqDPFPSQaYmJ6org=.c9502b99-c066-4f60-93df-8ea6aca1bf61@github.com>
 <z8Pe75XuElB5yt1HjRn-LnmQbXMtSZdLosduhgcWiUE=.d4be1be4-e870-4baf-8220-1150ca6a3a87@github.com>
Message-ID: <8T0fMFPYWN06vymFJC0__R9LZzYI2VGxa8H2jFb7U6I=.81c0b2cc-a892-43f0-bc77-dd05894795e6@github.com>

On Fri, 23 Feb 2024 22:09:10 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename Windows to Microsoft
>
> make/autoconf/flags-other.m4 line 45:
> 
>> 43: AC_DEFUN([FLAGS_SETUP_LIBFLAGS],
>> 44: [
>> 45:     # LIB is used to create static libraries on Windows
> 
> indentation.

Bummer, I missed this. :-( I will fix it in https://github.com/openjdk/jdk/pull/17986.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17987#discussion_r1502419762

From ihse at openjdk.org  Mon Feb 26 11:03:19 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Feb 2024 11:03:19 GMT
Subject: RFR: 8326587: Separate out Microsoft toolchain linking [v4]
In-Reply-To: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
References: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
Message-ID: <HYFyUc2JNWsgIqztJTKsz262oUPwqESI22Mu6uJCg9M=.22244884-b52f-4dce-84be-441605bfcf5e@github.com>

> There is not much overlap on how linking is done on Windows on one hand, and on all Unix platforms on the other. This makes Link.gmk basically consists of two parts, each in it own half of if statements, and the few common parts are artificially shoehorned in to fit both sides.
> 
> The code will be much clearer if we just split this into two different files.
> 
> Note that this PR slightly collides with JDK-8326583 (https://github.com/openjdk/jdk/pull/17986). Whichever of this goes in first will mean that the other one needs to make some adaptations.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix indentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17987/files
  - new: https://git.openjdk.org/jdk/pull/17987/files/afd1edd7..1bdc1350

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

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

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

From jwaters at openjdk.org  Mon Feb 26 11:54:54 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 26 Feb 2024 11:54:54 GMT
Subject: RFR: 8326587: Separate out Microsoft toolchain linking
In-Reply-To: <llrUBMECmyUzaYyxasX9cTYJXxN4u4aCownBtcREg3U=.197141d2-fc20-4956-8b96-148b4d0c2664@github.com>
References: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
 <2zsgTlDhtnz0Z0wz5DyH51nH9QDktaaTRYPx_AVmUBQ=.a9a9a6d9-2fbb-439b-8339-1b541f6f80ee@github.com>
 <bwukMSinwh1sdWrj9jory5xND4uw4xFXm1OJbw43BJA=.c7785cc5-6ce5-453a-a9ff-582ffb1a9e1f@github.com>
 <RoUJopnQFbBrI0TmVJugxkgY2GGH9GQLpqK0PZfQ9ZY=.5fa2f79e-007e-4479-bada-bc23c2897d3e@github.com>
 <llrUBMECmyUzaYyxasX9cTYJXxN4u4aCownBtcREg3U=.197141d2-fc20-4956-8b96-148b4d0c2664@github.com>
Message-ID: <bEyHpDX7Wpp4XwcjiG4LaxVskqdtySLf7Q4_AuVetUw=.f64b3292-b544-492a-a3d7-ff7635458cb0@github.com>

On Sat, 24 Feb 2024 10:00:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> And then I think this will actually help Julian, since we'll push the microsoft strangeness away in a separate file
>> 
>> Thanks! Though I do first need to rebase on top of it and fix all the merge conflicts first...
>> (Thinking about it, this likely means I have to excise some of the Microsoft linking logic out into the "regular" linking file since some of the Microsoft linking process is used by Windows linking in general, even with the gcc toolchain)
>> 
>> Just a comment: Why not reuse the AR variable for lib rather than introduce an entirely new LIB variable? The logic treating lib.exe as ar is gone with this change, but that doesn't mean they have to be split into entirely different variables. LinkMicrosoft could just run $($1_AR) without treating it as ar. This saves one autoconf and Makefile variable
>
>> Why not reuse the AR variable for lib rather than introduce an entirely new LIB variable? 
> 
> The reason will become more apparent as I progress towards proper handling of static libs. In short, AR is not by far a 1-to-1 mapping with LIB. On non-Microsoft toolchains, we are basically going to do static linking by ld + objcopy + ar; on Windows, it's just lib. So there is nothing to be gained by pretending that lib is ar.

> @magicus This pull request has not yet been marked as ready for integration.

That last second save is nothing short of impressive haha

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

PR Comment: https://git.openjdk.org/jdk/pull/17987#issuecomment-1963966880

From lorris.creantor at gmail.com  Mon Feb 26 13:40:13 2024
From: lorris.creantor at gmail.com (Lorris)
Date: Mon, 26 Feb 2024 14:40:13 +0100
Subject: Build the jdk with new or modified sources
Message-ID: <D01E146A-DD9A-4485-8F0E-AF6F5C554D54@gmail.com>

Hello,

I?m trying to build the JDK (version 23, my fork is up to date as of 2024/02/26) while adding new source files and also adding some fields or methods in existing files (in java.base and java.compiler modules). My problem is that when I try to build the image, most of the time (it seems to depend on the date of the last edited file) the new files and members I have added aren?t visible to the compiler which results in an error. Until now I have been using a workaround by building two times, firstly, only with the new code declarations and, secondly, with the references to this code. However, I?m now seeing the limits of this method.

Regards,
Lorris Creantor


From erik.joelsson at oracle.com  Mon Feb 26 13:59:40 2024
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Mon, 26 Feb 2024 05:59:40 -0800
Subject: Build the jdk with new or modified sources
In-Reply-To: <D01E146A-DD9A-4485-8F0E-AF6F5C554D54@gmail.com>
References: <D01E146A-DD9A-4485-8F0E-AF6F5C554D54@gmail.com>
Message-ID: <1aa9d412-0064-4216-b6bc-9d883991f1a7@oracle.com>

Hello Lorris,

This is not expected behavior. Building incrementally is expected to 
work correctly.

If you are making changes to java.base and then trying to use those 
changes from any of java.compiler, jdk.compiler and jdk.javadoc, you 
will have problems as those three modules have to be compatible with the 
previous JDK version (21 in this case). We build those modules for the 
"interim langtools" which is then used to compile the rest of the JDK by 
running this interim javac compiler on the boot jdk. I think the 
problems you are seeing appear when building the interim versions of 
these modules as they will never see the updates you are making to 
java.base.

If that isn't the issue, could you share more details on what kind of 
environment you are building on (OS, arch etc), how you configured the 
build and the make command line you are using?

/Erik

On 2/26/24 05:40, Lorris wrote:
> Hello,
>
> I?m trying to build the JDK (version 23, my fork is up to date as of 2024/02/26) while adding new source files and also adding some fields or methods in existing files (in java.base and java.compiler modules). My problem is that when I try to build the image, most of the time (it seems to depend on the date of the last edited file) the new files and members I have added aren?t visible to the compiler which results in an error. Until now I have been using a workaround by building two times, firstly, only with the new code declarations and, secondly, with the references to this code. However, I?m now seeing the limits of this method.
>
> Regards,
> Lorris Creantor
>

From erikj at openjdk.org  Mon Feb 26 14:24:56 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 26 Feb 2024 14:24:56 GMT
Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK
In-Reply-To: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
Message-ID: <yMkjMg_sPOSggftcHvV29FzSs05bRzz8_3sFsk74RWI=.05aff5ca-25df-44da-9b1c-33acd8104db3@github.com>

On Fri, 23 Feb 2024 21:24:10 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted.

make/modules/java.base/gensrc/GensrcLocaleData.gmk line 58:

> 56:   ifeq ($(MODULE), jdk.localedata)
> 57:     $(shell $(RM) $(SUPPORT_OUTPUTDIR)/gensrc/jdk.localedata/sun/util/resources/cldr/provider/CLDRLocaleDataMetaInfo_jdk_localedata.java)
> 58:   endif

The remainder of this file doesn't seem to be doing anything useful. Do we really need to keep it around? If I understand this correctly, the files referenced and deleted here are generated by the cldrconverter. Is that build tool relying on make removing the file first? Reading the java source, my impression is that it will generate the file unconditionally regardless of the files current existence as long as the tool is run.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1502691516

From erikj at openjdk.org  Mon Feb 26 14:32:54 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 26 Feb 2024 14:32:54 GMT
Subject: RFR: 8326587: Separate out Microsoft toolchain linking [v4]
In-Reply-To: <HYFyUc2JNWsgIqztJTKsz262oUPwqESI22Mu6uJCg9M=.22244884-b52f-4dce-84be-441605bfcf5e@github.com>
References: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
 <HYFyUc2JNWsgIqztJTKsz262oUPwqESI22Mu6uJCg9M=.22244884-b52f-4dce-84be-441605bfcf5e@github.com>
Message-ID: <xZ3nyfMsmOkqUz6-6737o74fslc_wPcLdPOQPI8wutg=.e2cdd3f4-7d9c-4938-9fd5-2231d31eba66@github.com>

On Mon, 26 Feb 2024 11:03:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> There is not much overlap on how linking is done on Windows on one hand, and on all Unix platforms on the other. This makes Link.gmk basically consists of two parts, each in it own half of if statements, and the few common parts are artificially shoehorned in to fit both sides.
>> 
>> The code will be much clearer if we just split this into two different files.
>> 
>> Note that this PR slightly collides with JDK-8326583 (https://github.com/openjdk/jdk/pull/17986). Whichever of this goes in first will mean that the other one needs to make some adaptations.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17987#pullrequestreview-1901031264

From ihse at openjdk.org  Mon Feb 26 15:48:50 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Feb 2024 15:48:50 GMT
Subject: Integrated: 8326587: Separate out Microsoft toolchain linking
In-Reply-To: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
References: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
Message-ID: <EsWP5dAtSX4-H3j_0fswKh8R40uZwbGTabykb0Nsia0=.0cedcc80-1a2a-4fbc-97df-2ed6222b578e@github.com>

On Fri, 23 Feb 2024 16:24:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> There is not much overlap on how linking is done on Windows on one hand, and on all Unix platforms on the other. This makes Link.gmk basically consists of two parts, each in it own half of if statements, and the few common parts are artificially shoehorned in to fit both sides.
> 
> The code will be much clearer if we just split this into two different files.
> 
> Note that this PR slightly collides with JDK-8326583 (https://github.com/openjdk/jdk/pull/17986). Whichever of this goes in first will mean that the other one needs to make some adaptations.

This pull request has now been integrated.

Changeset: 3780ad31
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3780ad3133302a91e082dd4e8526425799e88e1f
Stats:     265 lines in 12 files changed: 158 ins; 70 del; 37 mod

8326587: Separate out Microsoft toolchain linking

Reviewed-by: erikj

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

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

From ihse at openjdk.org  Mon Feb 26 15:57:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Feb 2024 15:57:03 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v2]
In-Reply-To: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
Message-ID: <idcHMk7Iu7vm0lVHn7PlcrpzGXVKuOfrkxhVtq5eK6c=.4e806a0e-fac2-4a5f-8521-d35a3ac4effc@github.com>

> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
> 
> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
> 
> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
> 
> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Reword "lib" comment to fit in better
 - Merge branch 'master' into remove-toolchain-define
 - 8326583: Remove over-generalized DefineNativeToolchain solution

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

Changes: https://git.openjdk.org/jdk/pull/17986/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17986&range=01
  Stats: 231 lines in 14 files changed: 58 ins; 142 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/17986.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17986/head:pull/17986

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

From aleonard at openjdk.org  Mon Feb 26 16:05:56 2024
From: aleonard at openjdk.org (Andrew Leonard)
Date: Mon, 26 Feb 2024 16:05:56 GMT
Subject: RFR: 8326685: Linux builds not reproducible if two builds configured
 in different build folders
Message-ID: <H7AGuwEU6Ri9SjUsHrkuCT7jhnVpo3WUbir8BAdKWek=.24beadcd-1f13-4fa6-8ea8-8d3ab6bdc227@github.com>

Adds Linux -fdebug-prefix-map'ing for SUPPORT_OUTPUTDIR and HOTSPOT_OUTPUTDIR when absolute paths are not allowed in the binaries, thus making the building of a JDK identically reproducible from different build directories.

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

Commit messages:
 - 8326685: Linux builds not reproducible if two builds configured in different build folders

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

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

From ihse at openjdk.org  Mon Feb 26 16:18:14 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Feb 2024 16:18:14 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v7]
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <TQ6cEW0z4kPTgmO71_ngAknaBp52wY5RzAfA85eQ_Pg=.7406352f-c3b5-4198-b219-1a29c783e049@github.com>

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Merge branch 'master' into hotspot-symbols-proper
 - Revert "Use #pragma instead of HIDDEN define"
   
   This reverts commit 00e40a7f6e4cdef6592d72b3d08063cdcc41532a.
 - Use #pragma instead of HIDDEN define
 - Rename the version script to version-script.txt
 - Restore linker script to linux/gcc builds
 - Rename the Windows export file to .def
 - Remove unused symbol _Copy_conjoint_bytes on linux/arm32
 - 8017234: Hotspot should stop using mapfiles

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17955/files
  - new: https://git.openjdk.org/jdk/pull/17955/files/7be8372a..6100950b

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

  Stats: 7746 lines in 141 files changed: 5392 ins; 1355 del; 999 mod
  Patch: https://git.openjdk.org/jdk/pull/17955.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17955/head:pull/17955

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

From aleonard at openjdk.org  Mon Feb 26 16:21:43 2024
From: aleonard at openjdk.org (Andrew Leonard)
Date: Mon, 26 Feb 2024 16:21:43 GMT
Subject: RFR: 8326685: Linux builds not reproducible if two builds
 configured in different build folders
In-Reply-To: <H7AGuwEU6Ri9SjUsHrkuCT7jhnVpo3WUbir8BAdKWek=.24beadcd-1f13-4fa6-8ea8-8d3ab6bdc227@github.com>
References: <H7AGuwEU6Ri9SjUsHrkuCT7jhnVpo3WUbir8BAdKWek=.24beadcd-1f13-4fa6-8ea8-8d3ab6bdc227@github.com>
Message-ID: <4Hm_7afD3CCQmYSEZ6x5xtb_oj4HWdPchqYukH4U7iA=.3ec57bd2-8195-47a7-9e28-d6f0e52a690a@github.com>

On Mon, 26 Feb 2024 16:00:42 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> Adds Linux -fdebug-prefix-map'ing for SUPPORT_OUTPUTDIR and HOTSPOT_OUTPUTDIR when absolute paths are not allowed in the binaries, thus making the building of a JDK identically reproducible from different build directories.

Tested locally on an aarch64 VM, with two build directories, build1 and build2. The resulting jdk image was identical.

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

PR Comment: https://git.openjdk.org/jdk/pull/18009#issuecomment-1964558021

From ihse at openjdk.org  Mon Feb 26 16:35:48 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Feb 2024 16:35:48 GMT
Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK
In-Reply-To: <yMkjMg_sPOSggftcHvV29FzSs05bRzz8_3sFsk74RWI=.05aff5ca-25df-44da-9b1c-33acd8104db3@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
 <yMkjMg_sPOSggftcHvV29FzSs05bRzz8_3sFsk74RWI=.05aff5ca-25df-44da-9b1c-33acd8104db3@github.com>
Message-ID: <-T_RAaAiyq9ZHn6kynwrZL4w3UHwq7ANs5xIRC5OOMI=.4e2c4392-c766-4d1c-ba0c-e85d28e377db@github.com>

On Mon, 26 Feb 2024 14:20:40 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted.
>
> make/modules/java.base/gensrc/GensrcLocaleData.gmk line 58:
> 
>> 56:   ifeq ($(MODULE), jdk.localedata)
>> 57:     $(shell $(RM) $(SUPPORT_OUTPUTDIR)/gensrc/jdk.localedata/sun/util/resources/cldr/provider/CLDRLocaleDataMetaInfo_jdk_localedata.java)
>> 58:   endif
> 
> The remainder of this file doesn't seem to be doing anything useful. Do we really need to keep it around? If I understand this correctly, the files referenced and deleted here are generated by the cldrconverter. Is that build tool relying on make removing the file first? Reading the java source, my impression is that it will generate the file unconditionally regardless of the files current existence as long as the tool is run.

Actually, as the file currently in the PR, it does not seem like it does anything at all, since we no longer create `_the.locale_resources`. Or... hm, without that file, `PREV_LOCALE_RESOURCES` will always be empty. I wonder what `$(filter-out $(PREV_LOCALE_RESOURCES), $(LOCALE_RESOURCES))` returns in that case. If it is empty, then this file does nothing. If it is `$(LOCALE_RESOURCES)`, then we will unconditionally rm the two files.

I believe the original intention was to spot added or removed locale resources, and use that to trigger a re-generation. This does not seem to work at all anymore. Do we still need that kind of behavior?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1502955421

From ihse at openjdk.org  Mon Feb 26 16:41:46 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Feb 2024 16:41:46 GMT
Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK
In-Reply-To: <-T_RAaAiyq9ZHn6kynwrZL4w3UHwq7ANs5xIRC5OOMI=.4e2c4392-c766-4d1c-ba0c-e85d28e377db@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
 <yMkjMg_sPOSggftcHvV29FzSs05bRzz8_3sFsk74RWI=.05aff5ca-25df-44da-9b1c-33acd8104db3@github.com>
 <-T_RAaAiyq9ZHn6kynwrZL4w3UHwq7ANs5xIRC5OOMI=.4e2c4392-c766-4d1c-ba0c-e85d28e377db@github.com>
Message-ID: <t8R7zXUDK90UrUFuHWlTpvGnOnh7YadJrzPYYxFm2Gw=.574aedef-d82b-4037-97d3-329ac6dfa986@github.com>

On Mon, 26 Feb 2024 16:33:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/modules/java.base/gensrc/GensrcLocaleData.gmk line 58:
>> 
>>> 56:   ifeq ($(MODULE), jdk.localedata)
>>> 57:     $(shell $(RM) $(SUPPORT_OUTPUTDIR)/gensrc/jdk.localedata/sun/util/resources/cldr/provider/CLDRLocaleDataMetaInfo_jdk_localedata.java)
>>> 58:   endif
>> 
>> The remainder of this file doesn't seem to be doing anything useful. Do we really need to keep it around? If I understand this correctly, the files referenced and deleted here are generated by the cldrconverter. Is that build tool relying on make removing the file first? Reading the java source, my impression is that it will generate the file unconditionally regardless of the files current existence as long as the tool is run.
>
> Actually, as the file currently in the PR, it does not seem like it does anything at all, since we no longer create `_the.locale_resources`. Or... hm, without that file, `PREV_LOCALE_RESOURCES` will always be empty. I wonder what `$(filter-out $(PREV_LOCALE_RESOURCES), $(LOCALE_RESOURCES))` returns in that case. If it is empty, then this file does nothing. If it is `$(LOCALE_RESOURCES)`, then we will unconditionally rm the two files.
> 
> I believe the original intention was to spot added or removed locale resources, and use that to trigger a re-generation. This does not seem to work at all anymore. Do we still need that kind of behavior?

Oh, this is a rabbit hole. :-( 

I tried to figure out where `CLDRBaseLocaleDataMetaInfo.java` comes from; I could not see where we generated that file. Turns out it is created in `make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java`, in the function `generateMetaInfo()`. I assume this is called as part of calling the CLDRConverter buildtool. But this is done in `make/modules/[java.base|jdk.localedata]/Gensrc.gmk`. So if we need to invalidate that build tool result, it should be done in these files.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1502964932

From djelinski at openjdk.org  Mon Feb 26 16:47:46 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 26 Feb 2024 16:47:46 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v7]
In-Reply-To: <TQ6cEW0z4kPTgmO71_ngAknaBp52wY5RzAfA85eQ_Pg=.7406352f-c3b5-4198-b219-1a29c783e049@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <TQ6cEW0z4kPTgmO71_ngAknaBp52wY5RzAfA85eQ_Pg=.7406352f-c3b5-4198-b219-1a29c783e049@github.com>
Message-ID: <S5IB9JPnGz2UBlJFInTjltwjbomfVvXytmAol_IATfA=.bfc67f99-7eef-42d4-a367-d8a281ebcfbe@github.com>

On Mon, 26 Feb 2024 16:18:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into hotspot-symbols-proper
>  - Revert "Use #pragma instead of HIDDEN define"
>    
>    This reverts commit 00e40a7f6e4cdef6592d72b3d08063cdcc41532a.
>  - Use #pragma instead of HIDDEN define
>  - Rename the version script to version-script.txt
>  - Restore linker script to linux/gcc builds
>  - Rename the Windows export file to .def
>  - Remove unused symbol _Copy_conjoint_bytes on linux/arm32
>  - 8017234: Hotspot should stop using mapfiles

This is on GCC 9.4.0, Ubuntu 20.04.
I wonder if the reference to a temporary was intentional... but I guess that's a subject for another PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1964619969

From ihse at openjdk.org  Mon Feb 26 17:34:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Feb 2024 17:34:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v8]
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <_Gdp3pxakc2Q0rYlCnz0TK0o1WbSkM2CX_pKfd_QRsU=.d7129f84-2241-496b-9764-72aa4fc3b3cf@github.com>

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Use --exclude-libs and -version-script on linux/clang too

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17955/files
  - new: https://git.openjdk.org/jdk/pull/17955/files/6100950b..c58764a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17955&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17955&range=06-07

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17955.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17955/head:pull/17955

PR: https://git.openjdk.org/jdk/pull/17955

From ihse at openjdk.org  Mon Feb 26 17:37:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Feb 2024 17:37:52 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v7]
In-Reply-To: <TQ6cEW0z4kPTgmO71_ngAknaBp52wY5RzAfA85eQ_Pg=.7406352f-c3b5-4198-b219-1a29c783e049@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <TQ6cEW0z4kPTgmO71_ngAknaBp52wY5RzAfA85eQ_Pg=.7406352f-c3b5-4198-b219-1a29c783e049@github.com>
Message-ID: <4M3Qd_S0d-nR_m85Sd4Y1ynJl09XtwoJOSMVp5de1PA=.2798f37e-eabb-4dc6-80d6-92b2aa8889c5@github.com>

On Mon, 26 Feb 2024 16:18:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into hotspot-symbols-proper
>  - Revert "Use #pragma instead of HIDDEN define"
>    
>    This reverts commit 00e40a7f6e4cdef6592d72b3d08063cdcc41532a.
>  - Use #pragma instead of HIDDEN define
>  - Rename the version script to version-script.txt
>  - Restore linker script to linux/gcc builds
>  - Rename the Windows export file to .def
>  - Remove unused symbol _Copy_conjoint_bytes on linux/arm32
>  - 8017234: Hotspot should stop using mapfiles

Can I get a second Hotspot reviewer for the Hotspot changes?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1964722207

From ihse at openjdk.org  Mon Feb 26 17:37:49 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Feb 2024 17:37:49 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v2]
In-Reply-To: <-Cqtxv3gK-PQ__1WEPOg_ls4KG0xAeU-yJV1668TUKI=.632a12f6-74c2-4e27-a448-0a5b469cc22e@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <12hoUFbZkWHBpiXs0TPiMYGW3sSvBX_536mvSSG-y-8=.21abcef9-9a2b-4558-ba19-dddfd7931f9f@github.com>
 <0Inj4SqHl36K4FzxPfbfyA20_7x8GyGMngBfuNEGsf8=.9cba3073-cfdd-43a4-828a-4ec362dcaaf3@github.com>
 <-Cqtxv3gK-PQ__1WEPOg_ls4KG0xAeU-yJV1668TUKI=.632a12f6-74c2-4e27-a448-0a5b469cc22e@github.com>
Message-ID: <fqdz-3x241k4jmI02gP5fC7ax7L4R6lRUWiYcJcifJo=.b701061d-15e8-41e3-98b8-815ccbdd20ed@github.com>

On Fri, 23 Feb 2024 13:54:36 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > I just realized I could keep an extremely simplified linker script ("mapfile") for gcc, and thereby keeping the `@SUNWprivate_1.1` on the exported symbols, and keeping `__bss_start` and friends local. This further minimizes the difference to the existing libjvm.so for gcc builds.
> 
> Why do this just for GCC? Shouldn't this be for Linux as we are doing it for backwards compatibility with user JNI libraries.

Good point. I did not really consider the case of clang on linux, since this is a secondary option, and I did not believe keeping consistency there was important. But as you say, the fix is trivial and makes a lot of sense. I have now verified that the symbols look identical when compiling with clang, between this PR and the latest (and hopefully last!) update, and mainline.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1964720104

From erikj at openjdk.org  Mon Feb 26 19:29:45 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 26 Feb 2024 19:29:45 GMT
Subject: RFR: 8326685: Linux builds not reproducible if two builds
 configured in different build folders
In-Reply-To: <H7AGuwEU6Ri9SjUsHrkuCT7jhnVpo3WUbir8BAdKWek=.24beadcd-1f13-4fa6-8ea8-8d3ab6bdc227@github.com>
References: <H7AGuwEU6Ri9SjUsHrkuCT7jhnVpo3WUbir8BAdKWek=.24beadcd-1f13-4fa6-8ea8-8d3ab6bdc227@github.com>
Message-ID: <qIHv1OoZXw2E5GOLWzfnY1RWPOohaQDlS0dznx9bBds=.04f0021c-cd40-4118-841f-5383d75eeb33@github.com>

On Mon, 26 Feb 2024 16:00:42 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> Adds Linux -fdebug-prefix-map'ing for SUPPORT_OUTPUTDIR and HOTSPOT_OUTPUTDIR when absolute paths are not allowed in the binaries, thus making the building of a JDK identically reproducible from different build directories.

make/autoconf/flags-cflags.m4 line 126:

> 124:             DEBUG_PREFIX_MAP_GCC_INCLUDE_PATHS
> 125:             DEBUG_PREFIX_CFLAGS="$DEBUG_PREFIX_CFLAGS -fdebug-prefix-map=\$(SUPPORT_OUTPUTDIR)/="
> 126:             DEBUG_PREFIX_CFLAGS="$DEBUG_PREFIX_CFLAGS -fdebug-prefix-map=\$(HOTSPOT_OUTPUTDIR)/="

This is only a problem if the build directory is located outside the workspace root. In the case where the build directory is inside the root, I think it would be preferable to stick to just the one prefix map, for consistent relative paths for all affected files. If the build directory is outside, like in your example, I would suggest adding just `$(OUTPUTDIR)/=` to both `-fdebug-prefix-map` and `-fmacro-prefix-map` for consistency. We don't seem to have a variable indicating if the OUTPUTDIR is inside WORKSPACE_ROOT or not, but we can add one in basic.m4 where the OUTPUTDIR is initialized. Then you can conditionally add the extra prefix maps based on that variable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18009#discussion_r1503181748

From erikj at openjdk.org  Mon Feb 26 19:32:46 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 26 Feb 2024 19:32:46 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v8]
In-Reply-To: <_Gdp3pxakc2Q0rYlCnz0TK0o1WbSkM2CX_pKfd_QRsU=.d7129f84-2241-496b-9764-72aa4fc3b3cf@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <_Gdp3pxakc2Q0rYlCnz0TK0o1WbSkM2CX_pKfd_QRsU=.d7129f84-2241-496b-9764-72aa4fc3b3cf@github.com>
Message-ID: <G_FvCgiPHmG90CLV_iijU2YYwUtKnaCxXqiAPnHqmUo=.3414c8e4-c26c-4016-8aa8-0759c4e65d8d@github.com>

On Mon, 26 Feb 2024 17:34:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use --exclude-libs and -version-script on linux/clang too

>From a build point of view, I think this looks good now.

-------------

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17955#pullrequestreview-1901822546

From ihse at openjdk.org  Mon Feb 26 20:09:43 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Feb 2024 20:09:43 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v3]
In-Reply-To: <PjRWrB0x0vcYcQoa6EK62usvbNr_AFa_IN2ljCLrDDI=.4d69297c-6996-4cb7-9bd6-50f961c43686@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
 <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>
 <WAwoF5K4yWv40dWrX1VjUfeVGYy918KDHp4qvuRQ5xM=.2aa20484-2def-46dc-b20f-4e866748e048@github.com>
 <1enXmdMITwK96Lz35sCWmkob9sLgKKt1N2Lp0NSldNc=.81d72c1e-0f11-452d-a55a-674f775fee47@github.com>
 <bmgatRS3iZ6J35-pwQQ81ev8-lMBeyFcN6jzQFk_qno=.369060d2-3e1f-45c9-bad6-71bbc921b647@github.com>
 <c-DwcGAX3JX-gnQ0CWuGzI09K5SCdQ_yxnBP-q9HT1o=.903a2615-8255-4bbf-aaa3-2e9fb0ae84f5@github.com>
 <o3KeCSV9VoJrmFKEsfKPCJ0cnuYbZZcjY18qYWSXZns=.fc08ab1b-d6f3-4158-8291-63e2663c2992@github.com>
 <PjRWrB0x0vcYcQoa6EK62usvbNr_AFa_IN2ljCLrDDI=.4d69297c-6996-4cb7-9bd6-50f961c43686@github.com>
Message-ID: <2E0F9OsixwTZ_Mq9OfUx1BQUStc92p0evM8KCbhz3jc=.18fd874c-f02a-406a-a8b7-c2cea0be8074@github.com>

On Mon, 26 Feb 2024 08:55:04 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> I assume you want to know if we use DAS/DAS1 for debugging purposes on that platform?
>
> I use `das` every day. In contrast, I don't know what `das1` is for.

It does not sound like anyone object to the removal of `JNIEXPORT` for `das1`, then.

Or should I just remove the entire function, if it serves no purpose that any current maintainers know or care about?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1503232370

From ihse at openjdk.org  Mon Feb 26 20:21:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Feb 2024 20:21:55 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v3]
In-Reply-To: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
Message-ID: <o-l6trdn97rwwcDyjzofXQ2MKmF50VJATpHTIqlw6w0=.aafa550e-f53a-42bb-ae54-2c7aaab04f00@github.com>

> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
> 
> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
> 
> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
> 
> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Rename LANG to LINK_TYPE

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17986/files
  - new: https://git.openjdk.org/jdk/pull/17986/files/f8a18690..5f446abd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17986&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17986&range=01-02

  Stats: 27 lines in 13 files changed: 0 ins; 0 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/17986.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17986/head:pull/17986

PR: https://git.openjdk.org/jdk/pull/17986

From ihse at openjdk.org  Mon Feb 26 20:21:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Feb 2024 20:21:55 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution
In-Reply-To: <Fz9PgUQ1lrYfk4Qa9Wgi8sNIo2IGC6uTgEXc4aKEyyI=.cbe5ac19-077c-434c-91c9-d6fd3d6c6392@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <Fz9PgUQ1lrYfk4Qa9Wgi8sNIo2IGC6uTgEXc4aKEyyI=.cbe5ac19-077c-434c-91c9-d6fd3d6c6392@github.com>
Message-ID: <2eorUGW4rI8MmbcbMAHrIHCm8cetjtaG87C6dyD_UgQ=.75c5ae8c-8ff9-4d0b-8031-66f51baffbbc@github.com>

On Sat, 24 Feb 2024 06:04:40 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
>> 
>> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
>> 
>> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
>> 
>> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.
>
> !!!
> 
> Not to be a party pooper, but this seems like it removes pretty some useful functionality from the build system. What if this is needed down the line? On the motivation of this change, TOOLCHAIN_LINK_CXX is pretty clear that the linker to be used is g++ instead of gcc for instance, while the new LANG parameter makes it look like SetupNativeCompilation only accepts and compiles C++ files if C++ is passed, and only C files if the new default of C is passed (For anyone looking in on this Pull Request who isn't familiar with the build system, it can compile a mix of both without issue). I'm not particularly sure this is a good idea, since a lot of flexibility seems to be lost with this change. I don't seem to see any simplification to SetupNativeCompilation either, maybe I'm missing something?

I renamed LANG to LINK_TYPE, to not make it overly general. @TheShermanTanker Are you okay with this patch now?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1965176131

From ihse at openjdk.org  Mon Feb 26 21:22:43 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Feb 2024 21:22:43 GMT
Subject: RFR: 8326685: Linux builds not reproducible if two builds
 configured in different build folders
In-Reply-To: <qIHv1OoZXw2E5GOLWzfnY1RWPOohaQDlS0dznx9bBds=.04f0021c-cd40-4118-841f-5383d75eeb33@github.com>
References: <H7AGuwEU6Ri9SjUsHrkuCT7jhnVpo3WUbir8BAdKWek=.24beadcd-1f13-4fa6-8ea8-8d3ab6bdc227@github.com>
 <qIHv1OoZXw2E5GOLWzfnY1RWPOohaQDlS0dznx9bBds=.04f0021c-cd40-4118-841f-5383d75eeb33@github.com>
Message-ID: <cD5OvNnbhfjQ5IWTLo5Bg2ViCmfRjx2nmjlNE-1AAmE=.94f6b1ad-8ed7-475b-a4ba-de46749ca099@github.com>

On Mon, 26 Feb 2024 19:26:33 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Adds Linux -fdebug-prefix-map'ing for SUPPORT_OUTPUTDIR and HOTSPOT_OUTPUTDIR when absolute paths are not allowed in the binaries, thus making the building of a JDK identically reproducible from different build directories.
>
> make/autoconf/flags-cflags.m4 line 126:
> 
>> 124:             DEBUG_PREFIX_MAP_GCC_INCLUDE_PATHS
>> 125:             DEBUG_PREFIX_CFLAGS="$DEBUG_PREFIX_CFLAGS -fdebug-prefix-map=\$(SUPPORT_OUTPUTDIR)/="
>> 126:             DEBUG_PREFIX_CFLAGS="$DEBUG_PREFIX_CFLAGS -fdebug-prefix-map=\$(HOTSPOT_OUTPUTDIR)/="
> 
> This is only a problem if the build directory is located outside the workspace root. In the case where the build directory is inside the root, I think it would be preferable to stick to just the one prefix map, for consistent relative paths for all affected files. If the build directory is outside, like in your example, I would suggest adding just `$(OUTPUTDIR)/=` to both `-fdebug-prefix-map` and `-fmacro-prefix-map` for consistency. We don't seem to have a variable indicating if the OUTPUTDIR is inside WORKSPACE_ROOT or not, but we can add one in basic.m4 where the OUTPUTDIR is initialized. Then you can conditionally add the extra prefix maps based on that variable.

I have not thought this fully through, but just throwing out a question: would this work even if one build directory were inside the workspace root, and the other not?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18009#discussion_r1503314922

From magnus.ihse.bursie at oracle.com  Mon Feb 26 21:22:59 2024
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 26 Feb 2024 22:22:59 +0100
Subject: Build the jdk with new or modified sources
In-Reply-To: <D01E146A-DD9A-4485-8F0E-AF6F5C554D54@gmail.com>
References: <D01E146A-DD9A-4485-8F0E-AF6F5C554D54@gmail.com>
Message-ID: <6fcee447-027e-438c-aae8-7194e965eff3@oracle.com>

On 2024-02-26 14:40, Lorris wrote:

> (it seems to depend on the date of the last edited file)

Just checking: do you have a problem with clock skew on your machine, or 
are you using some tools that modify time stamps on modified files? The 
make machinery depends on the fact that edited files should have a newer 
timestamp. If this does not work properly, dependency tracking will fail.

/Magnus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240226/7dc12771/attachment.htm>

From naoto at openjdk.org  Mon Feb 26 21:32:22 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 26 Feb 2024 21:32:22 GMT
Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v2]
In-Reply-To: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
Message-ID: <IcFvEIwNAN3UYmdfSCluSVgDpBZ1m3WBpUdhEP6BDN8=.ec60812a-4fa3-4414-834c-bf6ac0cf9dc8@github.com>

> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Update make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17991/files
  - new: https://git.openjdk.org/jdk/pull/17991/files/f3db6099..270afef5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17991&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17991&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17991/head:pull/17991

PR: https://git.openjdk.org/jdk/pull/17991

From naoto at openjdk.org  Mon Feb 26 21:32:22 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 26 Feb 2024 21:32:22 GMT
Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v2]
In-Reply-To: <t8R7zXUDK90UrUFuHWlTpvGnOnh7YadJrzPYYxFm2Gw=.574aedef-d82b-4037-97d3-329ac6dfa986@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
 <yMkjMg_sPOSggftcHvV29FzSs05bRzz8_3sFsk74RWI=.05aff5ca-25df-44da-9b1c-33acd8104db3@github.com>
 <-T_RAaAiyq9ZHn6kynwrZL4w3UHwq7ANs5xIRC5OOMI=.4e2c4392-c766-4d1c-ba0c-e85d28e377db@github.com>
 <t8R7zXUDK90UrUFuHWlTpvGnOnh7YadJrzPYYxFm2Gw=.574aedef-d82b-4037-97d3-329ac6dfa986@github.com>
Message-ID: <qrzYtN_jnoGhlU9vhDv61ZAztKshcLpZ1Z3gEac494Q=.1c9e5c19-71d2-46b5-9d88-1a7bd6ac0b2d@github.com>

On Mon, 26 Feb 2024 16:39:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Actually, as the file currently in the PR, it does not seem like it does anything at all, since we no longer create `_the.locale_resources`. Or... hm, without that file, `PREV_LOCALE_RESOURCES` will always be empty. I wonder what `$(filter-out $(PREV_LOCALE_RESOURCES), $(LOCALE_RESOURCES))` returns in that case. If it is empty, then this file does nothing. If it is `$(LOCALE_RESOURCES)`, then we will unconditionally rm the two files.
>> 
>> I believe the original intention was to spot added or removed locale resources, and use that to trigger a re-generation. This does not seem to work at all anymore. Do we still need that kind of behavior?
>
> Oh, this is a rabbit hole. :-( 
> 
> I tried to figure out where `CLDRBaseLocaleDataMetaInfo.java` comes from; I could not see where we generated that file. Turns out it is created in `make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java`, in the function `generateMetaInfo()`. I assume this is called as part of calling the CLDRConverter buildtool. But this is done in `make/modules/[java.base|jdk.localedata]/Gensrc.gmk`. So if we need to invalidate that build tool result, it should be done in these files.

Thanks. Good points.
As CLDR tool generates those files, `GensrcLocaleData.gmk` no longer seems necessary. I will remove it after I do some testings.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1503323383

From erikj at openjdk.org  Mon Feb 26 22:07:42 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 26 Feb 2024 22:07:42 GMT
Subject: RFR: 8326685: Linux builds not reproducible if two builds
 configured in different build folders
In-Reply-To: <cD5OvNnbhfjQ5IWTLo5Bg2ViCmfRjx2nmjlNE-1AAmE=.94f6b1ad-8ed7-475b-a4ba-de46749ca099@github.com>
References: <H7AGuwEU6Ri9SjUsHrkuCT7jhnVpo3WUbir8BAdKWek=.24beadcd-1f13-4fa6-8ea8-8d3ab6bdc227@github.com>
 <qIHv1OoZXw2E5GOLWzfnY1RWPOohaQDlS0dznx9bBds=.04f0021c-cd40-4118-841f-5383d75eeb33@github.com>
 <cD5OvNnbhfjQ5IWTLo5Bg2ViCmfRjx2nmjlNE-1AAmE=.94f6b1ad-8ed7-475b-a4ba-de46749ca099@github.com>
Message-ID: <aJ-1NmJeSfjO98Na6z5QICPewN_pujd7KJq5dv4fJrY=.99344368-7c66-423a-a501-52ceca998ecc@github.com>

On Mon, 26 Feb 2024 21:20:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/autoconf/flags-cflags.m4 line 126:
>> 
>>> 124:             DEBUG_PREFIX_MAP_GCC_INCLUDE_PATHS
>>> 125:             DEBUG_PREFIX_CFLAGS="$DEBUG_PREFIX_CFLAGS -fdebug-prefix-map=\$(SUPPORT_OUTPUTDIR)/="
>>> 126:             DEBUG_PREFIX_CFLAGS="$DEBUG_PREFIX_CFLAGS -fdebug-prefix-map=\$(HOTSPOT_OUTPUTDIR)/="
>> 
>> This is only a problem if the build directory is located outside the workspace root. In the case where the build directory is inside the root, I think it would be preferable to stick to just the one prefix map, for consistent relative paths for all affected files. If the build directory is outside, like in your example, I would suggest adding just `$(OUTPUTDIR)/=` to both `-fdebug-prefix-map` and `-fmacro-prefix-map` for consistency. We don't seem to have a variable indicating if the OUTPUTDIR is inside WORKSPACE_ROOT or not, but we can add one in basic.m4 where the OUTPUTDIR is initialized. Then you can conditionally add the extra prefix maps based on that variable.
>
> I have not thought this fully through, but just throwing out a question: would this work even if one build directory were inside the workspace root, and the other not?

Oh you are right, we should always add the OUTPUTDIR to both maps regardless of if it's internal to the WORKSPACE_ROOT or not. Paths relative to the OUTPUTDIR should be stable across builds in different output directories, but paths inside the OUTPUTDIR, expressed as relative to the WORKSPACE_ROOT will vary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18009#discussion_r1503367524

From dlutker at openjdk.org  Mon Feb 26 23:22:51 2024
From: dlutker at openjdk.org (Dan Lutker)
Date: Mon, 26 Feb 2024 23:22:51 GMT
Subject: RFR: 8326717: Disable stringop-overflow in shenandoahLock.cpp
Message-ID: <1ID_DqZyIvonwE3O3eT4iq6yB6RApPfUMjOqZgbqB8I=.665e68bf-eadd-4f26-8b33-115d26dac827@github.com>

Local fastdebug builds are working with GCC 13.2.1 on Linux aarch64.

-------------

Commit messages:
 - Disable stringop-overflow in shenandoahLock.cpp

Changes: https://git.openjdk.org/jdk/pull/18017/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18017&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326717
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18017.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18017/head:pull/18017

PR: https://git.openjdk.org/jdk/pull/18017

From naoto at openjdk.org  Mon Feb 26 23:37:16 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 26 Feb 2024 23:37:16 GMT
Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v3]
In-Reply-To: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
Message-ID: <AwqwbQZ7ceosvQLDgN0vStaf3MOL1sbFymXQ2s5veQc=.3b3a988f-29d3-40c4-8417-c575560752a7@github.com>

> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Remove `GensrcLocaleData.gmk`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17991/files
  - new: https://git.openjdk.org/jdk/pull/17991/files/270afef5..f68df434

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17991&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17991&range=01-02

  Stats: 71 lines in 3 files changed: 0 ins; 70 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17991/head:pull/17991

PR: https://git.openjdk.org/jdk/pull/17991

From jlu at openjdk.org  Mon Feb 26 23:56:46 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 26 Feb 2024 23:56:46 GMT
Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v3]
In-Reply-To: <AwqwbQZ7ceosvQLDgN0vStaf3MOL1sbFymXQ2s5veQc=.3b3a988f-29d3-40c4-8417-c575560752a7@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
 <AwqwbQZ7ceosvQLDgN0vStaf3MOL1sbFymXQ2s5veQc=.3b3a988f-29d3-40c4-8417-c575560752a7@github.com>
Message-ID: <095k-M23L8vXjgo9GHoobMhjDXFi3OXbhUEOhRCVKu4=.4a004e22-d5a8-4a7e-b73f-875078dd5239@github.com>

On Mon, 26 Feb 2024 23:37:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove `GensrcLocaleData.gmk`

Still working on getting a better understanding of all the parts here, but left some initial comments.

src/java.base/share/classes/java/util/Locale.java line 57:

> 55: import jdk.internal.vm.annotation.Stable;
> 56: 
> 57: import sun.security.action.GetPropertyAction;

Although trivial change, not sure if the file needs a copyright year bump; not exactly sure on the policy here.

src/java.base/share/classes/sun/util/locale/provider/FallbackLocaleProviderAdapter.java line 86:

> 84:     @Override
> 85:     // In order to correctly report supported locales
> 86:     public BreakIteratorProvider getBreakIteratorProvider() {

More for my understanding but I am curious why FallbackLocaleProviderAdapter has to override `getBreakIteratorProvider`, but can rely on the `getCollatorProvider` from JRELocaleProviderAdapter? Also wondering why "BreakIteratorRules" is fetched when JRELocaleProviderAdapter fetches "FormatData" if the data is the same COMPAT data.

test/jdk/java/text/Format/DateFormat/Bug6683975.java line 27:

> 25:  * @test
> 26:  * @bug 6683975 8008577 8174269
> 27:  * @summary Make sure that date is formatted correctlyin th locale.

not your change and typo doc nit, but,

Suggestion:

 * @summary Make sure that date is formatted correctly in th locale.

test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 30:

> 28:  *          Tests both COMPAT and CLDR data.
> 29:  * @modules jdk.localedata
> 30:  * @run junit/othervm -Djava.locale.providers=COMPAT CurrencyFormat

The methods `currencySymbolsTest`, `currencySymbolsDataProvider`, and `getFutureSymbol` can be removed since they are for COMPAT only. 

The string array `expectedCOMPATData` can be removed from the data provider method `currencyFormatDataProvider` as well as `isCompat` variable and usage.

_CurrencySymbols.properties_ can also be deleted since that is what `currencySymbolsDataProvider` uses to build the data and no other tests rely on the file.

-------------

PR Review: https://git.openjdk.org/jdk/pull/17991#pullrequestreview-1901683460
PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1503317351
PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1503375503
PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1503301324
PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1503105517

From jlu at openjdk.org  Mon Feb 26 23:56:48 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 26 Feb 2024 23:56:48 GMT
Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v2]
In-Reply-To: <IcFvEIwNAN3UYmdfSCluSVgDpBZ1m3WBpUdhEP6BDN8=.ec60812a-4fa3-4414-834c-bf6ac0cf9dc8@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
 <IcFvEIwNAN3UYmdfSCluSVgDpBZ1m3WBpUdhEP6BDN8=.ec60812a-4fa3-4414-834c-bf6ac0cf9dc8@github.com>
Message-ID: <xFyIPJpaJiToxxuMhYN1k52fcRZkmTCTbZih7FW8BsA=.7d71f216-bb4c-4857-973f-5c03c53ac8e8@github.com>

On Mon, 26 Feb 2024 21:32:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

test/jdk/java/util/Locale/CompatWarning.java line 28:

> 26:  * @bug 8304982 8174269
> 27:  * @summary Check if a warning is logged with COMPAT locale provider
> 28:  * @run main/othervm -Djava.locale.providers=COMPAT CompatWarning

Is it worth adding runs with COMPAT specified with other providers (both before and/or after) for coverage sake. Such as `@run main/othervm -Djava.locale.providers=SPI,COMPAT CompatWarning`.

test/jdk/java/util/Locale/ExpectedAdapterTypes.java line 27:

> 25:  * @test
> 26:  * @bug 8008577 8138613 8174269
> 27:  * @summary Check whether CLDR locale provider adapter is enabled by default

Unless I'm mistaken, there aren't any other dedicated tests to ensuring the FALLBACK adapter is included, it might be worth updating the summary to make it apparent that while the default preference list has CLDR, _FALLBACK_ is always appended, since that is new behavior.

test/jdk/java/util/Locale/LocaleProvidersFormat.java line 80:

> 78:     @Test
> 79:     @EnabledOnOs(WINDOWS)
> 80:     @EnabledIfSystemProperty(named = "user.language", matches = "ja")

Thanks for fixing, as it is `HOST` the locale value should be based on the machine at startup. Although, I'm wondering how the test passed previously then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1503399036
PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1503401752
PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1503397390

From erikj at openjdk.org  Tue Feb 27 00:01:43 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 27 Feb 2024 00:01:43 GMT
Subject: RFR: 8326717: Disable stringop-overflow in shenandoahLock.cpp
In-Reply-To: <1ID_DqZyIvonwE3O3eT4iq6yB6RApPfUMjOqZgbqB8I=.665e68bf-eadd-4f26-8b33-115d26dac827@github.com>
References: <1ID_DqZyIvonwE3O3eT4iq6yB6RApPfUMjOqZgbqB8I=.665e68bf-eadd-4f26-8b33-115d26dac827@github.com>
Message-ID: <i2K8dORAljYS69qXp9JeH1SFMJSDCebUSYd81E88bgs=.409f182b-ea02-4c50-93db-cd5bb18846c4@github.com>

On Mon, 26 Feb 2024 23:07:02 GMT, Dan Lutker <dlutker at openjdk.org> wrote:

> Local fastdebug builds are working with GCC 13.2.1 on Linux aarch64.

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18017#pullrequestreview-1902265572

From naoto at openjdk.org  Tue Feb 27 00:20:39 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Feb 2024 00:20:39 GMT
Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v4]
In-Reply-To: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
Message-ID: <TcOgOfIzr3Eev7OYCiPr0wZygAlarJLMCUf4-Iua-WE=.8da29011-b594-4780-b307-ed6bfc456feb@github.com>

> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/java/text/Format/DateFormat/Bug6683975.java
  
  Co-authored-by: Justin Lu <Justin.lu at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17991/files
  - new: https://git.openjdk.org/jdk/pull/17991/files/f68df434..a75637f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17991&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17991&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17991/head:pull/17991

PR: https://git.openjdk.org/jdk/pull/17991

From naoto at openjdk.org  Tue Feb 27 00:24:08 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Feb 2024 00:24:08 GMT
Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v5]
In-Reply-To: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
Message-ID: <5oS5x968YgpeRo6Bf6SQGnPvgLONaDi5hl7fRkeqYbg=.7f120d7c-6719-4a0e-97b8-823eccd0f809@github.com>

> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Addressing review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17991/files
  - new: https://git.openjdk.org/jdk/pull/17991/files/a75637f2..d5953788

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17991&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17991&range=03-04

  Stats: 232 lines in 4 files changed: 4 ins; 226 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17991/head:pull/17991

PR: https://git.openjdk.org/jdk/pull/17991

From naoto at openjdk.org  Tue Feb 27 00:31:47 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Feb 2024 00:31:47 GMT
Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v5]
In-Reply-To: <095k-M23L8vXjgo9GHoobMhjDXFi3OXbhUEOhRCVKu4=.4a004e22-d5a8-4a7e-b73f-875078dd5239@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
 <AwqwbQZ7ceosvQLDgN0vStaf3MOL1sbFymXQ2s5veQc=.3b3a988f-29d3-40c4-8417-c575560752a7@github.com>
 <095k-M23L8vXjgo9GHoobMhjDXFi3OXbhUEOhRCVKu4=.4a004e22-d5a8-4a7e-b73f-875078dd5239@github.com>
Message-ID: <GBrhdN2b2AI4Y5q5SFFeEOaacEV4nlAtPqkInXUK_qo=.872de5db-0c4b-4f16-b7da-44745855a05a@github.com>

On Mon, 26 Feb 2024 22:11:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing review comments
>
> src/java.base/share/classes/sun/util/locale/provider/FallbackLocaleProviderAdapter.java line 86:
> 
>> 84:     @Override
>> 85:     // In order to correctly report supported locales
>> 86:     public BreakIteratorProvider getBreakIteratorProvider() {
> 
> More for my understanding but I am curious why FallbackLocaleProviderAdapter has to override `getBreakIteratorProvider`, but can rely on the `getCollatorProvider` from JRELocaleProviderAdapter? Also wondering why "BreakIteratorRules" is fetched when JRELocaleProviderAdapter fetches "FormatData" if the data is the same COMPAT data.

`COMPAT` used to offer supported locales for the ones that exist as resource bundles. For `Collator`, `JRELocaleProviderAdapter` had a list for `CollationData` resource bundles, but `BreakIterator` shared with `FormatData`, which now only has root/en/ja (for Gan-nen support). So it had to override the method and return `th` (this is the main function for `BreakIterator` as of now)

> test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 30:
> 
>> 28:  *          Tests both COMPAT and CLDR data.
>> 29:  * @modules jdk.localedata
>> 30:  * @run junit/othervm -Djava.locale.providers=COMPAT CurrencyFormat
> 
> The methods `currencySymbolsTest`, `currencySymbolsDataProvider`, and `getFutureSymbol` can be removed since they are for COMPAT only. 
> 
> The string array `expectedCOMPATData` can be removed from the data provider method `currencyFormatDataProvider` as well as `isCompat` variable and usage.
> 
> _CurrencySymbols.properties_ can also be deleted since that is what `currencySymbolsDataProvider` uses to build the data and no other tests rely on the file.

Good catch! Removed `COMPAT` related tests/data.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1503478694
PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1503478605

From naoto at openjdk.org  Tue Feb 27 00:31:49 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Feb 2024 00:31:49 GMT
Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v2]
In-Reply-To: <xFyIPJpaJiToxxuMhYN1k52fcRZkmTCTbZih7FW8BsA=.7d71f216-bb4c-4857-973f-5c03c53ac8e8@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
 <IcFvEIwNAN3UYmdfSCluSVgDpBZ1m3WBpUdhEP6BDN8=.ec60812a-4fa3-4414-834c-bf6ac0cf9dc8@github.com>
 <xFyIPJpaJiToxxuMhYN1k52fcRZkmTCTbZih7FW8BsA=.7d71f216-bb4c-4857-973f-5c03c53ac8e8@github.com>
Message-ID: <7N_bnofe_S9KafqXU1y4vHCDBuw-HwAaOoh93jHq46k=.1e8271d7-9a48-4b68-acb0-55ae104c1c56@github.com>

On Mon, 26 Feb 2024 22:38:50 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java
>>   
>>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>
> test/jdk/java/util/Locale/ExpectedAdapterTypes.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8008577 8138613 8174269
>> 27:  * @summary Check whether CLDR locale provider adapter is enabled by default
> 
> Unless I'm mistaken, there aren't any other dedicated tests to ensuring the FALLBACK adapter is included, it might be worth updating the summary to make it apparent that while the default preference list has CLDR, _FALLBACK_ is always appended, since that is new behavior.

I believe some tests will break if `FALLBACK` is not included in the preferred list. I am kind of hesitant to specify it in the command line for the sake of testing, as it is not a public constant.

> test/jdk/java/util/Locale/LocaleProvidersFormat.java line 80:
> 
>> 78:     @Test
>> 79:     @EnabledOnOs(WINDOWS)
>> 80:     @EnabledIfSystemProperty(named = "user.language", matches = "ja")
> 
> Thanks for fixing, as it is `HOST` the locale value should be based on the machine at startup. Although, I'm wondering how the test passed previously then.

Right, it only works if the underlying machine is configured with ja locale as the default.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1503478795
PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1503478741

From jiangli at openjdk.org  Tue Feb 27 01:32:51 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 27 Feb 2024 01:32:51 GMT
Subject: RFR: 8326587: Separate out Microsoft toolchain linking [v4]
In-Reply-To: <HYFyUc2JNWsgIqztJTKsz262oUPwqESI22Mu6uJCg9M=.22244884-b52f-4dce-84be-441605bfcf5e@github.com>
References: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
 <HYFyUc2JNWsgIqztJTKsz262oUPwqESI22Mu6uJCg9M=.22244884-b52f-4dce-84be-441605bfcf5e@github.com>
Message-ID: <-6lUo6KUh120r7SqQzz-1DWmU7OJ9btSE6vpWIrVeaA=.627c7f01-de11-4730-99b3-13464c30a063@github.com>

On Mon, 26 Feb 2024 11:03:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> There is not much overlap on how linking is done on Windows on one hand, and on all Unix platforms on the other. This makes Link.gmk basically consists of two parts, each in it own half of if statements, and the few common parts are artificially shoehorned in to fit both sides.
>> 
>> The code will be much clearer if we just split this into two different files.
>> 
>> Note that this PR slightly collides with JDK-8326583 (https://github.com/openjdk/jdk/pull/17986). Whichever of this goes in first will mean that the other one needs to make some adaptations.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation

make/common/native/Link.gmk line 131:

> 129: 	    $(if $$($1_LINK_OBJS_RELATIVE), $$(CD) $$(OUTPUTDIR) ; ) \
> 130: 	      $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $$($1_SYSROOT_LDFLAGS) \
> 131: 	        -o $$($1_TARGET_RELOCATABLE) \

I noticed this change that replaces `$(LD_OUT_OPTION)` with `-o` when reviewing our integration changes. $1_LINK_OBJS_RELATIVE is currently only supported on Linux/clang, it still seems good to not take away the flexibility of specifying the non-linker specific option string here. Any thoughts?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17987#discussion_r1503520025

From jwaters at openjdk.org  Tue Feb 27 05:22:51 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 27 Feb 2024 05:22:51 GMT
Subject: RFR: 8326587: Separate out Microsoft toolchain linking [v4]
In-Reply-To: <-6lUo6KUh120r7SqQzz-1DWmU7OJ9btSE6vpWIrVeaA=.627c7f01-de11-4730-99b3-13464c30a063@github.com>
References: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
 <HYFyUc2JNWsgIqztJTKsz262oUPwqESI22Mu6uJCg9M=.22244884-b52f-4dce-84be-441605bfcf5e@github.com>
 <-6lUo6KUh120r7SqQzz-1DWmU7OJ9btSE6vpWIrVeaA=.627c7f01-de11-4730-99b3-13464c30a063@github.com>
Message-ID: <b_sMqRY8QKG-UIP9eqTWMsJiD8Jt6V7s3jV2LDRxQUc=.d3483d8a-3af9-4244-ac4d-3f75b74cdc1f@github.com>

On Tue, 27 Feb 2024 01:30:17 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix indentation
>
> make/common/native/Link.gmk line 131:
> 
>> 129: 	    $(if $$($1_LINK_OBJS_RELATIVE), $$(CD) $$(OUTPUTDIR) ; ) \
>> 130: 	      $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $$($1_SYSROOT_LDFLAGS) \
>> 131: 	        -o $$($1_TARGET_RELOCATABLE) \
> 
> I noticed this change that replaces `$(LD_OUT_OPTION)` with `-o` when reviewing our integration changes. $1_LINK_OBJS_RELATIVE is currently only supported on Linux/clang, it still seems good to not take away the flexibility of specifying the non-linker specific option string here. Any thoughts?

I tend to agree, this should not have been changed to specifying -o directly. We generally keep options inside Makefile variables rather than directly passing them like this, much like how $(OBJ_SUFFIX) was recently used to replace directly specifying the object file suffix in the make system

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17987#discussion_r1503652472

From dholmes at openjdk.org  Tue Feb 27 05:31:51 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 27 Feb 2024 05:31:51 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v8]
In-Reply-To: <_Gdp3pxakc2Q0rYlCnz0TK0o1WbSkM2CX_pKfd_QRsU=.d7129f84-2241-496b-9764-72aa4fc3b3cf@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <_Gdp3pxakc2Q0rYlCnz0TK0o1WbSkM2CX_pKfd_QRsU=.d7129f84-2241-496b-9764-72aa4fc3b3cf@github.com>
Message-ID: <fzFOimK2m4KMD9Q_8-x-WjdC1OjV5rwl7_Zt0MSLST4=.14e7e333-9c87-4d99-b9d1-df844e48d9b9@github.com>

On Mon, 26 Feb 2024 17:34:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use --exclude-libs and -version-script on linux/clang too

Given discussions and additional testing/validation, the hotspot changes appear okay. Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17955#pullrequestreview-1902551792

From shade at openjdk.org  Tue Feb 27 07:36:50 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 27 Feb 2024 07:36:50 GMT
Subject: RFR: 8326717: Disable stringop-overflow in shenandoahLock.cpp
In-Reply-To: <1ID_DqZyIvonwE3O3eT4iq6yB6RApPfUMjOqZgbqB8I=.665e68bf-eadd-4f26-8b33-115d26dac827@github.com>
References: <1ID_DqZyIvonwE3O3eT4iq6yB6RApPfUMjOqZgbqB8I=.665e68bf-eadd-4f26-8b33-115d26dac827@github.com>
Message-ID: <0xNfAEVBGFzEF2f53jY1YRRHZ1MPwKguW_8E0A9zTj4=.2ad1968f-ecb5-4d08-906f-e978b8405c39@github.com>

On Mon, 26 Feb 2024 23:07:02 GMT, Dan Lutker <dlutker at openjdk.org> wrote:

> Local fastdebug builds are working with GCC 13.2.1 on Linux aarch64.

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18017#pullrequestreview-1902721965

From dlutker at openjdk.org  Tue Feb 27 07:36:51 2024
From: dlutker at openjdk.org (Dan Lutker)
Date: Tue, 27 Feb 2024 07:36:51 GMT
Subject: Integrated: 8326717: Disable stringop-overflow in shenandoahLock.cpp
In-Reply-To: <1ID_DqZyIvonwE3O3eT4iq6yB6RApPfUMjOqZgbqB8I=.665e68bf-eadd-4f26-8b33-115d26dac827@github.com>
References: <1ID_DqZyIvonwE3O3eT4iq6yB6RApPfUMjOqZgbqB8I=.665e68bf-eadd-4f26-8b33-115d26dac827@github.com>
Message-ID: <y2D6wt1IayhqgC6TlhkFloSD3YEq0Y54_FVww4Ji3O4=.4612df91-462b-4984-8adc-62fe2c6180a7@github.com>

On Mon, 26 Feb 2024 23:07:02 GMT, Dan Lutker <dlutker at openjdk.org> wrote:

> Local fastdebug builds are working with GCC 13.2.1 on Linux aarch64.

This pull request has now been integrated.

Changeset: 97aca09e
Author:    Dan Lutker <dlutker at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/97aca09e586c086f8130b394682f45724f08b3a4
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8326717: Disable stringop-overflow in shenandoahLock.cpp

Reviewed-by: erikj, shade

-------------

PR: https://git.openjdk.org/jdk/pull/18017

From jwaters at openjdk.org  Tue Feb 27 07:38:43 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 27 Feb 2024 07:38:43 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v3]
In-Reply-To: <o-l6trdn97rwwcDyjzofXQ2MKmF50VJATpHTIqlw6w0=.aafa550e-f53a-42bb-ae54-2c7aaab04f00@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <o-l6trdn97rwwcDyjzofXQ2MKmF50VJATpHTIqlw6w0=.aafa550e-f53a-42bb-ae54-2c7aaab04f00@github.com>
Message-ID: <MGH--y-zM5TzYr_MWh4t4UXU-6I--RRrqcxORgkVY2k=.33db9924-c42f-4cc7-8857-0c4ed73dc2e0@github.com>

On Mon, 26 Feb 2024 20:21:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
>> 
>> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
>> 
>> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
>> 
>> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename LANG to LINK_TYPE

Thanks for the run down on the history of the build system! I'm sorry it took me a day to respond, I must have missed this in my inbox while going over the GitHub activity of the day. Given that the function was meant for the older build system, it now seems reasonable to replace it with this newer solution. In the worst case scenario, a backout is possible, as was suggested. I would have said that LANG is an ok name and that there was no need to rename it to LINK_TYPE after the context given and the knowledge that future work was planned for it, had I read this earlier though :(

This is also the first time I've ever had an objection to a Pull Request. Feels weird, really

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1965949353

From djelinski at openjdk.org  Tue Feb 27 08:10:44 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 27 Feb 2024 08:10:44 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v3]
In-Reply-To: <o-l6trdn97rwwcDyjzofXQ2MKmF50VJATpHTIqlw6w0=.aafa550e-f53a-42bb-ae54-2c7aaab04f00@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <o-l6trdn97rwwcDyjzofXQ2MKmF50VJATpHTIqlw6w0=.aafa550e-f53a-42bb-ae54-2c7aaab04f00@github.com>
Message-ID: <g5AkodtQxduUbHzXa_NxL44JxkjhTWJQK4lMxY_HC2k=.64a88123-9933-4e38-9885-34f12ca42ecc@github.com>

On Mon, 26 Feb 2024 20:21:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
>> 
>> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
>> 
>> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
>> 
>> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename LANG to LINK_TYPE

can we get rid of LDCXX? On my system LDCXX is mapped to `g++` and LD is `gcc`; I searched for the differences, and the only thing I could find is that `g++` implicitly adds `-lstdc++ -shared-libgcc`; I suppose we could explicitly add these options, and use gcc everywhere.

See:
https://stackoverflow.com/a/172592
https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1965991536

From aleonard at openjdk.org  Tue Feb 27 08:15:45 2024
From: aleonard at openjdk.org (Andrew Leonard)
Date: Tue, 27 Feb 2024 08:15:45 GMT
Subject: RFR: 8326685: Linux builds not reproducible if two builds
 configured in different build folders
In-Reply-To: <aJ-1NmJeSfjO98Na6z5QICPewN_pujd7KJq5dv4fJrY=.99344368-7c66-423a-a501-52ceca998ecc@github.com>
References: <H7AGuwEU6Ri9SjUsHrkuCT7jhnVpo3WUbir8BAdKWek=.24beadcd-1f13-4fa6-8ea8-8d3ab6bdc227@github.com>
 <qIHv1OoZXw2E5GOLWzfnY1RWPOohaQDlS0dznx9bBds=.04f0021c-cd40-4118-841f-5383d75eeb33@github.com>
 <cD5OvNnbhfjQ5IWTLo5Bg2ViCmfRjx2nmjlNE-1AAmE=.94f6b1ad-8ed7-475b-a4ba-de46749ca099@github.com>
 <aJ-1NmJeSfjO98Na6z5QICPewN_pujd7KJq5dv4fJrY=.99344368-7c66-423a-a501-52ceca998ecc@github.com>
Message-ID: <4JEcPy9kgLmMA1BYPzlbYIw3ZooEaKSfcVBjYVZFOKs=.483e6541-aac8-4f0e-aa33-278b56cce494@github.com>

On Mon, 26 Feb 2024 22:05:34 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> I have not thought this fully through, but just throwing out a question: would this work even if one build directory were inside the workspace root, and the other not?
>
> Oh you are right, we should always add the OUTPUTDIR to both maps regardless of if it's internal to the WORKSPACE_ROOT or not. Paths relative to the OUTPUTDIR should be stable across builds in different output directories, but paths inside the OUTPUTDIR, expressed as relative to the WORKSPACE_ROOT will vary.

> I have not thought this fully through, but just throwing out a question: would this work even if one build directory were inside the workspace root, and the other not?

Yes, I have tested that scenario as well, and does work. It was in fact the scenario in which I discovered the problem in the first place.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18009#discussion_r1503805898

From jwaters at openjdk.org  Tue Feb 27 08:17:46 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 27 Feb 2024 08:17:46 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v3]
In-Reply-To: <g5AkodtQxduUbHzXa_NxL44JxkjhTWJQK4lMxY_HC2k=.64a88123-9933-4e38-9885-34f12ca42ecc@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <o-l6trdn97rwwcDyjzofXQ2MKmF50VJATpHTIqlw6w0=.aafa550e-f53a-42bb-ae54-2c7aaab04f00@github.com>
 <g5AkodtQxduUbHzXa_NxL44JxkjhTWJQK4lMxY_HC2k=.64a88123-9933-4e38-9885-34f12ca42ecc@github.com>
Message-ID: <fl7S90DiuqboQxU2bjfRgpi9vco6wS_MT6Z8rWs5z08=.13a415a4-5607-41f2-b99b-17a2922a0bff@github.com>

On Tue, 27 Feb 2024 08:07:38 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> can we get rid of LDCXX? On my system LDCXX is mapped to `g++` and LD is `gcc`; I searched for the differences, and the only thing I could find is that `g++` implicitly adds `-lstdc++ -shared-libgcc`; I suppose we could explicitly add these options, and use gcc everywhere.
> 
> See: https://stackoverflow.com/a/172592 https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

I don't think that's a good idea, the differences between the gcc and g++ drivers are supposed to be (opaque) implementation details. Doing so would make us dependent on internal mechanisms of gcc subject to change between versions and would make bugfixing hard to do if such a change really happened and the linker command line got messed up as a result (This likely would impact clang too, unless I am mistaken?)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966002485

From aleonard at openjdk.org  Tue Feb 27 08:21:43 2024
From: aleonard at openjdk.org (Andrew Leonard)
Date: Tue, 27 Feb 2024 08:21:43 GMT
Subject: RFR: 8326685: Linux builds not reproducible if two builds
 configured in different build folders
In-Reply-To: <4JEcPy9kgLmMA1BYPzlbYIw3ZooEaKSfcVBjYVZFOKs=.483e6541-aac8-4f0e-aa33-278b56cce494@github.com>
References: <H7AGuwEU6Ri9SjUsHrkuCT7jhnVpo3WUbir8BAdKWek=.24beadcd-1f13-4fa6-8ea8-8d3ab6bdc227@github.com>
 <qIHv1OoZXw2E5GOLWzfnY1RWPOohaQDlS0dznx9bBds=.04f0021c-cd40-4118-841f-5383d75eeb33@github.com>
 <cD5OvNnbhfjQ5IWTLo5Bg2ViCmfRjx2nmjlNE-1AAmE=.94f6b1ad-8ed7-475b-a4ba-de46749ca099@github.com>
 <aJ-1NmJeSfjO98Na6z5QICPewN_pujd7KJq5dv4fJrY=.99344368-7c66-423a-a501-52ceca998ecc@github.com>
 <4JEcPy9kgLmMA1BYPzlbYIw3ZooEaKSfcVBjYVZFOKs=.483e6541-aac8-4f0e-aa33-278b56cce494@github.com>
Message-ID: <Azfhf9El2JasL81iVCL0IcN_pY70TI3ztpwBnwsbQ8o=.b24a9e86-3acc-4914-952d-793cc148d317@github.com>

On Tue, 27 Feb 2024 08:13:07 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Oh you are right, we should always add the OUTPUTDIR to both maps regardless of if it's internal to the WORKSPACE_ROOT or not. Paths relative to the OUTPUTDIR should be stable across builds in different output directories, but paths inside the OUTPUTDIR, expressed as relative to the WORKSPACE_ROOT will vary.
>
>> I have not thought this fully through, but just throwing out a question: would this work even if one build directory were inside the workspace root, and the other not?
> 
> Yes, I have tested that scenario as well, and does work. It was in fact the scenario in which I discovered the problem in the first place.

> Oh you are right, we should always add the OUTPUTDIR to both maps regardless of if it's internal to the WORKSPACE_ROOT or not. Paths relative to the OUTPUTDIR should be stable across builds in different output directories, but paths inside the OUTPUTDIR, expressed as relative to the WORKSPACE_ROOT will vary.

@erikj79 @magicus Yes, it needs to always be present as you've pointed out the OUTPUTDIR when within the WORKSPACE will be eg.WORKSPACE/build/linux-aarch64-server-release/support and the standard WORKSPACE mapping will make that build/linux-aarch64-server-release/support, but a build dir outside will be simply <any_path>/support

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18009#discussion_r1503813251

From jwaters at openjdk.org  Tue Feb 27 08:32:45 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 27 Feb 2024 08:32:45 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v3]
In-Reply-To: <o-l6trdn97rwwcDyjzofXQ2MKmF50VJATpHTIqlw6w0=.aafa550e-f53a-42bb-ae54-2c7aaab04f00@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <o-l6trdn97rwwcDyjzofXQ2MKmF50VJATpHTIqlw6w0=.aafa550e-f53a-42bb-ae54-2c7aaab04f00@github.com>
Message-ID: <IhdZ8Lh3uMDfI7LRLncPB5q9K3AoUAH2gUXUkJiZvRI=.a1f8d84d-3616-4729-9fe0-e10dd6de4c57@github.com>

On Mon, 26 Feb 2024 20:21:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
>> 
>> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
>> 
>> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
>> 
>> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename LANG to LINK_TYPE

Just a small question by the way: All those new parameters to SetupNativeCompilation, were they always there and the comments about them were just missing from the documentation about the function?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966025499

From lorris.creantor at gmail.com  Tue Feb 27 09:57:04 2024
From: lorris.creantor at gmail.com (Lorris)
Date: Tue, 27 Feb 2024 10:57:04 +0100
Subject: Build the jdk with new or modified sources
In-Reply-To: <1aa9d412-0064-4216-b6bc-9d883991f1a7@oracle.com>
References: <D01E146A-DD9A-4485-8F0E-AF6F5C554D54@gmail.com>
 <1aa9d412-0064-4216-b6bc-9d883991f1a7@oracle.com>
Message-ID: <4BC4C046-D733-4562-A7D5-77919DC17145@gmail.com>

Yes indeed, I am trying to use those changes from the jdk.compiler module. How can I make this work without causing problem when building the interim module ?

Lorris

> On 26 Feb 2024, at 14:59, erik.joelsson at oracle.com wrote:
> 
> Hello Lorris,
> 
> This is not expected behavior. Building incrementally is expected to work correctly.
> 
> If you are making changes to java.base and then trying to use those changes from any of java.compiler, jdk.compiler and jdk.javadoc, you will have problems as those three modules have to be compatible with the previous JDK version (21 in this case). We build those modules for the "interim langtools" which is then used to compile the rest of the JDK by running this interim javac compiler on the boot jdk. I think the problems you are seeing appear when building the interim versions of these modules as they will never see the updates you are making to java.base.
> 
> If that isn't the issue, could you share more details on what kind of environment you are building on (OS, arch etc), how you configured the build and the make command line you are using?
> 
> /Erik
> 
> On 2/26/24 05:40, Lorris wrote:
>> Hello,
>> 
>> I?m trying to build the JDK (version 23, my fork is up to date as of 2024/02/26) while adding new source files and also adding some fields or methods in existing files (in java.base and java.compiler modules). My problem is that when I try to build the image, most of the time (it seems to depend on the date of the last edited file) the new files and members I have added aren?t visible to the compiler which results in an error. Until now I have been using a workaround by building two times, firstly, only with the new code declarations and, secondly, with the references to this code. However, I?m now seeing the limits of this method.
>> 
>> Regards,
>> Lorris Creantor
>> 


From ihse at openjdk.org  Tue Feb 27 10:30:05 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Feb 2024 10:30:05 GMT
Subject: Integrated: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <sEjTPQawLffg22H2dsPlfpeytizNb2ALmngDHyBk8_A=.4d288316-0892-43d4-abe7-5e7548c22d6c@github.com>

On Wed, 21 Feb 2024 23:32:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

This pull request has now been integrated.

Changeset: da14aa46
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/da14aa463b8fcd56ba1f1a4cdb3e3f7b19f78964
Stats:     1001 lines in 33 files changed: 239 ins; 578 del; 184 mod

8017234: Hotspot should stop using mapfiles

Reviewed-by: djelinski, erikj, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/17955

From ihse at openjdk.org  Tue Feb 27 10:33:20 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Feb 2024 10:33:20 GMT
Subject: RFR: 8326406: Remove mapfile support from makefiles [v2]
In-Reply-To: <2EPPAU63apAOBbSIvzLhgAhGcCvGLCUe2BZHqWCBQno=.74a66c6b-7d20-4545-bb11-b2d63bf275fb@github.com>
References: <2EPPAU63apAOBbSIvzLhgAhGcCvGLCUe2BZHqWCBQno=.74a66c6b-7d20-4545-bb11-b2d63bf275fb@github.com>
Message-ID: <c2I8SCotsW2h0H2SDNLvmcEFN2dt7HygEyqZrpQ7NBo=.672961e5-a23d-4f51-a6f1-3f4a49c2825a@github.com>

> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) is done, we have no need for mapfiles anymore in the JDK project. The mapfile handling was inherited from the old build system and is just messy. We should remove it to make the linking process more clear.
> 
> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17982/files
  - new: https://git.openjdk.org/jdk/pull/17982/files/85a076ef..85a076ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17982&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17982&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17982.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17982/head:pull/17982

PR: https://git.openjdk.org/jdk/pull/17982

From ihse at openjdk.org  Tue Feb 27 10:34:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Feb 2024 10:34:53 GMT
Subject: RFR: 8326685: Linux builds not reproducible if two builds
 configured in different build folders
In-Reply-To: <Azfhf9El2JasL81iVCL0IcN_pY70TI3ztpwBnwsbQ8o=.b24a9e86-3acc-4914-952d-793cc148d317@github.com>
References: <H7AGuwEU6Ri9SjUsHrkuCT7jhnVpo3WUbir8BAdKWek=.24beadcd-1f13-4fa6-8ea8-8d3ab6bdc227@github.com>
 <qIHv1OoZXw2E5GOLWzfnY1RWPOohaQDlS0dznx9bBds=.04f0021c-cd40-4118-841f-5383d75eeb33@github.com>
 <cD5OvNnbhfjQ5IWTLo5Bg2ViCmfRjx2nmjlNE-1AAmE=.94f6b1ad-8ed7-475b-a4ba-de46749ca099@github.com>
 <aJ-1NmJeSfjO98Na6z5QICPewN_pujd7KJq5dv4fJrY=.99344368-7c66-423a-a501-52ceca998ecc@github.com>
 <4JEcPy9kgLmMA1BYPzlbYIw3ZooEaKSfcVBjYVZFOKs=.483e6541-aac8-4f0e-aa33-278b56cce494@github.com>
 <Azfhf9El2JasL81iVCL0IcN_pY70TI3ztpwBnwsbQ8o=.b24a9e86-3acc-4914-952d-793cc148d317@github.com>
Message-ID: <C0Zujw04xFKPwFK5TmJY0CtTf4p1zWZbgU8QE5eZ-fE=.1d04b2c2-f5f5-490e-a981-89fbd52626fa@github.com>

On Tue, 27 Feb 2024 08:19:11 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>>> I have not thought this fully through, but just throwing out a question: would this work even if one build directory were inside the workspace root, and the other not?
>> 
>> Yes, I have tested that scenario as well, and does work. It was in fact the scenario in which I discovered the problem in the first place.
>
>> Oh you are right, we should always add the OUTPUTDIR to both maps regardless of if it's internal to the WORKSPACE_ROOT or not. Paths relative to the OUTPUTDIR should be stable across builds in different output directories, but paths inside the OUTPUTDIR, expressed as relative to the WORKSPACE_ROOT will vary.
> 
> @erikj79 @magicus Yes, it needs to always be present as you've pointed out the OUTPUTDIR when within the WORKSPACE will be eg.WORKSPACE/build/linux-aarch64-server-release/support and the standard WORKSPACE mapping will make that build/linux-aarch64-server-release/support, but a build dir outside will be simply <any_path>/support

It seems correct to include the output dir in the remapping, but I have two objections/questions to the way you are doing it.
1) Why not just use OUTPUTDIR instead of the two specialized subdirs? That is simpler, more general and future-proof.
2) Why not expand the value of the OUTPUTDIR variable? I.e.  

 DEBUG_PREFIX_CFLAGS="$DEBUG_PREFIX_CFLAGS -fdebug-prefix-map=$OUTPUTDIR/="
 ```

instead of trying to preserve it as a variable to be expanded in the make execution.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18009#discussion_r1504006780

From ihse at openjdk.org  Tue Feb 27 10:37:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Feb 2024 10:37:53 GMT
Subject: RFR: 8326685: Linux builds not reproducible if two builds
 configured in different build folders
In-Reply-To: <C0Zujw04xFKPwFK5TmJY0CtTf4p1zWZbgU8QE5eZ-fE=.1d04b2c2-f5f5-490e-a981-89fbd52626fa@github.com>
References: <H7AGuwEU6Ri9SjUsHrkuCT7jhnVpo3WUbir8BAdKWek=.24beadcd-1f13-4fa6-8ea8-8d3ab6bdc227@github.com>
 <qIHv1OoZXw2E5GOLWzfnY1RWPOohaQDlS0dznx9bBds=.04f0021c-cd40-4118-841f-5383d75eeb33@github.com>
 <cD5OvNnbhfjQ5IWTLo5Bg2ViCmfRjx2nmjlNE-1AAmE=.94f6b1ad-8ed7-475b-a4ba-de46749ca099@github.com>
 <aJ-1NmJeSfjO98Na6z5QICPewN_pujd7KJq5dv4fJrY=.99344368-7c66-423a-a501-52ceca998ecc@github.com>
 <4JEcPy9kgLmMA1BYPzlbYIw3ZooEaKSfcVBjYVZFOKs=.483e6541-aac8-4f0e-aa33-278b56cce494@github.com>
 <Azfhf9El2JasL81iVCL0IcN_pY70TI3ztpwBnwsbQ8o=.b24a9e86-3acc-4914-952d-793cc148d317@github.com>
 <C0Zujw04xFKPwFK5TmJY0CtTf4p1zWZbgU8QE5eZ-fE=.1d04b2c2-f5f5-490e-a981-89fbd52626fa@github.com>
Message-ID: <MFq2phBNWiBn5B7IsUX7i5bR3HED89pEA6XK3fpEv58=.017154a0-cb3e-49ad-995d-9ac847ab98a5@github.com>

On Tue, 27 Feb 2024 10:32:24 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> Oh you are right, we should always add the OUTPUTDIR to both maps regardless of if it's internal to the WORKSPACE_ROOT or not. Paths relative to the OUTPUTDIR should be stable across builds in different output directories, but paths inside the OUTPUTDIR, expressed as relative to the WORKSPACE_ROOT will vary.
>> 
>> @erikj79 @magicus Yes, it needs to always be present as you've pointed out the OUTPUTDIR when within the WORKSPACE will be eg.WORKSPACE/build/linux-aarch64-server-release/support and the standard WORKSPACE mapping will make that build/linux-aarch64-server-release/support, but a build dir outside will be simply <any_path>/support
>
> It seems correct to include the output dir in the remapping, but I have two objections/questions to the way you are doing it.
> 1) Why not just use OUTPUTDIR instead of the two specialized subdirs? That is simpler, more general and future-proof.
> 2) Why not expand the value of the OUTPUTDIR variable? I.e.  
> 
>  DEBUG_PREFIX_CFLAGS="$DEBUG_PREFIX_CFLAGS -fdebug-prefix-map=$OUTPUTDIR/="
>  ```
> 
> instead of trying to preserve it as a variable to be expanded in the make execution.

Also, this mapping business is getting really convoluted. :-( I did not like it as it was, and this patch makes it even worse. I think we need to rewrite this to create some kind of dict/map, and then iterate over the map and apply `-fdebug-prefix-map` to all items in the map. Unfortunately, the data structures available in shell scripts is limited and will make this a bit tricky to pull off. :(

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18009#discussion_r1504011145

From ihse at openjdk.org  Tue Feb 27 10:58:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Feb 2024 10:58:00 GMT
Subject: RFR: 8326406: Remove mapfile support from makefiles [v3]
In-Reply-To: <2EPPAU63apAOBbSIvzLhgAhGcCvGLCUe2BZHqWCBQno=.74a66c6b-7d20-4545-bb11-b2d63bf275fb@github.com>
References: <2EPPAU63apAOBbSIvzLhgAhGcCvGLCUe2BZHqWCBQno=.74a66c6b-7d20-4545-bb11-b2d63bf275fb@github.com>
Message-ID: <WBTsQmrakA_HDtssXANkfrwc5ESXdwmw3ohMADTrVUo=.20b9614c-2cb1-44cc-871e-dd5ff380c798@github.com>

> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) is done, we have no need for mapfiles anymore in the JDK project. The mapfile handling was inherited from the old build system and is just messy. We should remove it to make the linking process more clear.
> 
> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - SetupLinkingMicrosoft is not needed once mapfiles are removed
 - Merge branch 'master' into remove-mapfile-support
 - 8326406: Remove mapfile support from makefiles
 - Revert "Use #pragma instead of HIDDEN define"
   
   This reverts commit 00e40a7f6e4cdef6592d72b3d08063cdcc41532a.
 - Use #pragma instead of HIDDEN define
 - Rename the version script to version-script.txt
 - Restore linker script to linux/gcc builds
 - Rename the Windows export file to .def
 - Remove unused symbol _Copy_conjoint_bytes on linux/arm32
 - 8017234: Hotspot should stop using mapfiles

-------------

Changes: https://git.openjdk.org/jdk/pull/17982/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17982&range=02
  Stats: 70 lines in 5 files changed: 0 ins; 62 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/17982.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17982/head:pull/17982

PR: https://git.openjdk.org/jdk/pull/17982

From ihse at openjdk.org  Tue Feb 27 10:58:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Feb 2024 10:58:00 GMT
Subject: Integrated: 8326406: Remove mapfile support from makefiles
In-Reply-To: <2EPPAU63apAOBbSIvzLhgAhGcCvGLCUe2BZHqWCBQno=.74a66c6b-7d20-4545-bb11-b2d63bf275fb@github.com>
References: <2EPPAU63apAOBbSIvzLhgAhGcCvGLCUe2BZHqWCBQno=.74a66c6b-7d20-4545-bb11-b2d63bf275fb@github.com>
Message-ID: <zxWthaWC_Uaqoe9DVv3vdUA83zU2Mp3Fk1P78YAtZnE=.5216cdba-cca9-40eb-91fd-12d3fa27b1b4@github.com>

On Fri, 23 Feb 2024 12:42:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) is done, we have no need for mapfiles anymore in the JDK project. The mapfile handling was inherited from the old build system and is just messy. We should remove it to make the linking process more clear.
> 
> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.

This pull request has now been integrated.

Changeset: bceaed6d
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bceaed6d4de391d1fdac0d35384c415a7c484d28
Stats:     70 lines in 5 files changed: 0 ins; 62 del; 8 mod

8326406: Remove mapfile support from makefiles

Reviewed-by: jwaters, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/17982

From ihse at openjdk.org  Tue Feb 27 11:01:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Feb 2024 11:01:03 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v4]
In-Reply-To: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
Message-ID: <wHGBIhPuYhFHpOmp-pckQClVnS4sODTqkZHqNbI5tB4=.cd8f6adb-14a4-4160-92cc-41e7b871ad2d@github.com>

> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been integrated, it is possible to do some cleanup. The goal of [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change any behavior, even if that behavior seemed odd.
> 
> Now let's try to fix that. We can:
> 
> a) remove JNIEXPORT from c2v functions.
> b) make debug.cpp functions exported similarly on all platforms.
> c) remove JNIEXPORT from aarch64 asm debug function.
> 
> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.

Magnus Ihse Bursie 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 hotspot-symbols-followup
 - Remove jvmci globals
 - 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234
 - Revert "Use #pragma instead of HIDDEN define"
   
   This reverts commit 00e40a7f6e4cdef6592d72b3d08063cdcc41532a.
 - Use #pragma instead of HIDDEN define
 - Rename the version script to version-script.txt
 - Restore linker script to linux/gcc builds
 - Rename the Windows export file to .def
 - Remove unused symbol _Copy_conjoint_bytes on linux/arm32
 - 8017234: Hotspot should stop using mapfiles

-------------

Changes: https://git.openjdk.org/jdk/pull/17967/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17967&range=03
  Stats: 12 lines in 3 files changed: 0 ins; 8 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/17967.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17967/head:pull/17967

PR: https://git.openjdk.org/jdk/pull/17967

From aleonard at openjdk.org  Tue Feb 27 11:04:52 2024
From: aleonard at openjdk.org (Andrew Leonard)
Date: Tue, 27 Feb 2024 11:04:52 GMT
Subject: RFR: 8326685: Linux builds not reproducible if two builds
 configured in different build folders
In-Reply-To: <MFq2phBNWiBn5B7IsUX7i5bR3HED89pEA6XK3fpEv58=.017154a0-cb3e-49ad-995d-9ac847ab98a5@github.com>
References: <H7AGuwEU6Ri9SjUsHrkuCT7jhnVpo3WUbir8BAdKWek=.24beadcd-1f13-4fa6-8ea8-8d3ab6bdc227@github.com>
 <qIHv1OoZXw2E5GOLWzfnY1RWPOohaQDlS0dznx9bBds=.04f0021c-cd40-4118-841f-5383d75eeb33@github.com>
 <cD5OvNnbhfjQ5IWTLo5Bg2ViCmfRjx2nmjlNE-1AAmE=.94f6b1ad-8ed7-475b-a4ba-de46749ca099@github.com>
 <aJ-1NmJeSfjO98Na6z5QICPewN_pujd7KJq5dv4fJrY=.99344368-7c66-423a-a501-52ceca998ecc@github.com>
 <4JEcPy9kgLmMA1BYPzlbYIw3ZooEaKSfcVBjYVZFOKs=.483e6541-aac8-4f0e-aa33-278b56cce494@github.com>
 <Azfhf9El2JasL81iVCL0IcN_pY70TI3ztpwBnwsbQ8o=.b24a9e86-3acc-4914-952d-793cc148d317@github.com>
 <C0Zujw04xFKPwFK5TmJY0CtTf4p1zWZbgU8QE5eZ-fE=.1d04b2c2-f5f5-490e-a981-89fbd52626fa@github.com>
 <MFq2phBNWiBn5B7IsUX7i5bR3HED89pEA6XK3fpEv58=.017154a0-cb3e-49ad-995d-9ac847ab98a5@github.com>
Message-ID: <lSo_gRIueKa7dGIkjfsK1DBZ8fW6KjUEU6a6D9iW8kk=.b7217a61-bb4d-4a32-b131-84c3c5637238@github.com>

On Tue, 27 Feb 2024 10:35:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> It seems correct to include the output dir in the remapping, but I have two objections/questions to the way you are doing it.
>> 1) Why not just use OUTPUTDIR instead of the two specialized subdirs? That is simpler, more general and future-proof.
>> 2) Why not expand the value of the OUTPUTDIR variable? I.e.  
>> 
>>  DEBUG_PREFIX_CFLAGS="$DEBUG_PREFIX_CFLAGS -fdebug-prefix-map=$OUTPUTDIR/="
>>  ```
>> 
>> instead of trying to preserve it as a variable to be expanded in the make execution.
>
> Also, this mapping business is getting really convoluted. :-( I did not like it as it was, and this patch makes it even worse. I think we need to rewrite this to create some kind of dict/map, and then iterate over the map and apply `-fdebug-prefix-map` to all items in the map. Unfortunately, the data structures available in shell scripts is limited and will make this a bit tricky to pull off. :(

> It seems correct to include the output dir in the remapping, but I have two objections/questions to the way you are doing it.
> 
>     1. Why not just use OUTPUTDIR instead of the two specialized subdirs? That is simpler, more general and future-proof.
> 
>     2. Why not expand the value of the OUTPUTDIR variable? I.e.
> 
> 
> ```
>  DEBUG_PREFIX_CFLAGS="$DEBUG_PREFIX_CFLAGS -fdebug-prefix-map=$OUTPUTDIR/="
> ```
> 
> instead of trying to preserve it as a variable to be expanded in the make execution.

Ah thanks @magicus I hadn't seen that existed! that would simplify it, i'll try that now

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18009#discussion_r1504043380

From aleonard at openjdk.org  Tue Feb 27 11:04:52 2024
From: aleonard at openjdk.org (Andrew Leonard)
Date: Tue, 27 Feb 2024 11:04:52 GMT
Subject: RFR: 8326685: Linux builds not reproducible if two builds
 configured in different build folders
In-Reply-To: <lSo_gRIueKa7dGIkjfsK1DBZ8fW6KjUEU6a6D9iW8kk=.b7217a61-bb4d-4a32-b131-84c3c5637238@github.com>
References: <H7AGuwEU6Ri9SjUsHrkuCT7jhnVpo3WUbir8BAdKWek=.24beadcd-1f13-4fa6-8ea8-8d3ab6bdc227@github.com>
 <qIHv1OoZXw2E5GOLWzfnY1RWPOohaQDlS0dznx9bBds=.04f0021c-cd40-4118-841f-5383d75eeb33@github.com>
 <cD5OvNnbhfjQ5IWTLo5Bg2ViCmfRjx2nmjlNE-1AAmE=.94f6b1ad-8ed7-475b-a4ba-de46749ca099@github.com>
 <aJ-1NmJeSfjO98Na6z5QICPewN_pujd7KJq5dv4fJrY=.99344368-7c66-423a-a501-52ceca998ecc@github.com>
 <4JEcPy9kgLmMA1BYPzlbYIw3ZooEaKSfcVBjYVZFOKs=.483e6541-aac8-4f0e-aa33-278b56cce494@github.com>
 <Azfhf9El2JasL81iVCL0IcN_pY70TI3ztpwBnwsbQ8o=.b24a9e86-3acc-4914-952d-793cc148d317@github.com>
 <C0Zujw04xFKPwFK5TmJY0CtTf4p1zWZbgU8QE5eZ-fE=.1d04b2c2-f5f5-490e-a981-89fbd52626fa@github.com>
 <MFq2phBNWiBn5B7IsUX7i5bR3HED89pEA6XK3fpEv58=.017154a0-cb3e-49ad-995d-9ac847ab98a5@github.com>
 <lSo_gRIueKa7dGIkjfsK1DBZ8fW6KjUEU6a6D9iW8kk=.b7217a61-bb4d-4a32-b131-84c3c5637238@github.com>
Message-ID: <wOkXFvB28hFcjaqvok3v7ljm7tC386PzzNVzbna0aWU=.b35cde88-5f00-47b8-add9-87ca2e7b1364@github.com>

On Tue, 27 Feb 2024 10:59:54 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Also, this mapping business is getting really convoluted. :-( I did not like it as it was, and this patch makes it even worse. I think we need to rewrite this to create some kind of dict/map, and then iterate over the map and apply `-fdebug-prefix-map` to all items in the map. Unfortunately, the data structures available in shell scripts is limited and will make this a bit tricky to pull off. :(
>
>> It seems correct to include the output dir in the remapping, but I have two objections/questions to the way you are doing it.
>> 
>>     1. Why not just use OUTPUTDIR instead of the two specialized subdirs? That is simpler, more general and future-proof.
>> 
>>     2. Why not expand the value of the OUTPUTDIR variable? I.e.
>> 
>> 
>> ```
>>  DEBUG_PREFIX_CFLAGS="$DEBUG_PREFIX_CFLAGS -fdebug-prefix-map=$OUTPUTDIR/="
>> ```
>> 
>> instead of trying to preserve it as a variable to be expanded in the make execution.
> 
> Ah thanks @magicus I hadn't seen that existed! that would simplify it, i'll try that now

> Also, this mapping business is getting really convoluted. :-( I did not like it as it was, and this patch makes it even worse. I think we need to rewrite this to create some kind of dict/map, and then iterate over the map and apply `-fdebug-prefix-map` to all items in the map. Unfortunately, the data structures available in shell scripts is limited and will make this a bit tricky to pull off. :(

yeah, although that's not easy for example for the gcc include paths that we have to work out based on the users compiler paths, so it wouldn't be a simple dict

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18009#discussion_r1504046943

From ihse at openjdk.org  Tue Feb 27 11:08:48 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Feb 2024 11:08:48 GMT
Subject: RFR: 8326587: Separate out Microsoft toolchain linking [v4]
In-Reply-To: <b_sMqRY8QKG-UIP9eqTWMsJiD8Jt6V7s3jV2LDRxQUc=.d3483d8a-3af9-4244-ac4d-3f75b74cdc1f@github.com>
References: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
 <HYFyUc2JNWsgIqztJTKsz262oUPwqESI22Mu6uJCg9M=.22244884-b52f-4dce-84be-441605bfcf5e@github.com>
 <-6lUo6KUh120r7SqQzz-1DWmU7OJ9btSE6vpWIrVeaA=.627c7f01-de11-4730-99b3-13464c30a063@github.com>
 <b_sMqRY8QKG-UIP9eqTWMsJiD8Jt6V7s3jV2LDRxQUc=.d3483d8a-3af9-4244-ac4d-3f75b74cdc1f@github.com>
Message-ID: <uvNqbMlSJeNNOXp1rqyATgoHRkWCzey4m-HGMW61uDE=.f991fc3d-2f46-472e-b3e4-db8d8977c1b2@github.com>

On Tue, 27 Feb 2024 05:20:11 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> make/common/native/Link.gmk line 131:
>> 
>>> 129: 	    $(if $$($1_LINK_OBJS_RELATIVE), $$(CD) $$(OUTPUTDIR) ; ) \
>>> 130: 	      $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $$($1_SYSROOT_LDFLAGS) \
>>> 131: 	        -o $$($1_TARGET_RELOCATABLE) \
>> 
>> I noticed this change that replaces `$(LD_OUT_OPTION)` with `-o` when reviewing our integration changes. $1_LINK_OBJS_RELATIVE is currently only supported on Linux/clang, it still seems good to not take away the flexibility of specifying the non-linker specific option string here. Any thoughts?
>
> I tend to agree, this should not have been changed to specifying -o directly. We generally keep options inside Makefile variables rather than directly passing them like this, much like how $(OBJ_SUFFIX) was recently used to replace directly specifying the object file suffix in the make system

This was actually an important part of this PR, trying to combat the all too general solution we had when trying to combine microsoft and non-microsoft linking. On all Unix-style linkers, the option to mark the output file is `-o `. That is such a fundemental option that we do not want to make it general, especially not considering the additional difficulty that the corresponding option for the microsoft `link.exe` is to specify `/out:<filename>`, without a space. This forced us to define LD_OUT_OPTION as `-o$(SPACE)` on unix linkers, and it forced us to setup the linker command line with `$(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE)` with no space between. 

That is in clear contrast with how we can add multiple sets of command line options like e.g. `(LDFLAGS_CXX_PARTIAL_LINKING) $$($1_SYSROOT_LDFLAGS)` where we can just stack them after each other with a space between.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17987#discussion_r1504049839

From ihse at openjdk.org  Tue Feb 27 11:08:48 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Feb 2024 11:08:48 GMT
Subject: RFR: 8326587: Separate out Microsoft toolchain linking [v4]
In-Reply-To: <uvNqbMlSJeNNOXp1rqyATgoHRkWCzey4m-HGMW61uDE=.f991fc3d-2f46-472e-b3e4-db8d8977c1b2@github.com>
References: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
 <HYFyUc2JNWsgIqztJTKsz262oUPwqESI22Mu6uJCg9M=.22244884-b52f-4dce-84be-441605bfcf5e@github.com>
 <-6lUo6KUh120r7SqQzz-1DWmU7OJ9btSE6vpWIrVeaA=.627c7f01-de11-4730-99b3-13464c30a063@github.com>
 <b_sMqRY8QKG-UIP9eqTWMsJiD8Jt6V7s3jV2LDRxQUc=.d3483d8a-3af9-4244-ac4d-3f75b74cdc1f@github.com>
 <uvNqbMlSJeNNOXp1rqyATgoHRkWCzey4m-HGMW61uDE=.f991fc3d-2f46-472e-b3e4-db8d8977c1b2@github.com>
Message-ID: <0rlFEeMIQlB2f_NYa5BvYKpZ2oq_-b8Qv7RP8PfV7iM=.7f7beab6-88b0-4da6-a11f-e11fa91b2e9c@github.com>

On Tue, 27 Feb 2024 11:04:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I tend to agree, this should not have been changed to specifying -o directly. We generally keep options inside Makefile variables rather than directly passing them like this, much like how $(OBJ_SUFFIX) was recently used to replace directly specifying the object file suffix in the make system
>
> This was actually an important part of this PR, trying to combat the all too general solution we had when trying to combine microsoft and non-microsoft linking. On all Unix-style linkers, the option to mark the output file is `-o `. That is such a fundemental option that we do not want to make it general, especially not considering the additional difficulty that the corresponding option for the microsoft `link.exe` is to specify `/out:<filename>`, without a space. This forced us to define LD_OUT_OPTION as `-o$(SPACE)` on unix linkers, and it forced us to setup the linker command line with `$(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE)` with no space between. 
> 
> That is in clear contrast with how we can add multiple sets of command line options like e.g. `(LDFLAGS_CXX_PARTIAL_LINKING) $$($1_SYSROOT_LDFLAGS)` where we can just stack them after each other with a space between.

Also, 

> the flexibility of specifying the non-linker specific option here

I don't know what you mean by that. LD_OUT_OPTION was thought of as an abstraction between the difference of `-o ` and `/out:`. It should not be used to include anything else, so no flexibility is lost.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17987#discussion_r1504051487

From ihse at openjdk.org  Tue Feb 27 11:19:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Feb 2024 11:19:59 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v3]
In-Reply-To: <fl7S90DiuqboQxU2bjfRgpi9vco6wS_MT6Z8rWs5z08=.13a415a4-5607-41f2-b99b-17a2922a0bff@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <o-l6trdn97rwwcDyjzofXQ2MKmF50VJATpHTIqlw6w0=.aafa550e-f53a-42bb-ae54-2c7aaab04f00@github.com>
 <g5AkodtQxduUbHzXa_NxL44JxkjhTWJQK4lMxY_HC2k=.64a88123-9933-4e38-9885-34f12ca42ecc@github.com>
 <fl7S90DiuqboQxU2bjfRgpi9vco6wS_MT6Z8rWs5z08=.13a415a4-5607-41f2-b99b-17a2922a0bff@github.com>
Message-ID: <qVY8G3YCtV5tT1ZHXUVTQh4FbX7_aDEYpX7d8LvG8rY=.bf557f0f-a205-4592-841c-c81d83cac22e@github.com>

On Tue, 27 Feb 2024 08:14:56 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> can we get rid of LDCXX?

Yeah, that is something I plan to look into. Linking C++ object files with gcc will fail; and it  might be that linking pure C with g++ might be problematic. If this is the case, I hope we can at least determine this automatically which linker frontend to use, i.e. selecting g++ as linker frontend if there is at least one .cpp file in the set of sources.

This PR is actually a kind of prerequisite for that kind of work.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966312751

From ihse at openjdk.org  Tue Feb 27 11:19:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Feb 2024 11:19:59 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v3]
In-Reply-To: <IhdZ8Lh3uMDfI7LRLncPB5q9K3AoUAH2gUXUkJiZvRI=.a1f8d84d-3616-4729-9fe0-e10dd6de4c57@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <o-l6trdn97rwwcDyjzofXQ2MKmF50VJATpHTIqlw6w0=.aafa550e-f53a-42bb-ae54-2c7aaab04f00@github.com>
 <IhdZ8Lh3uMDfI7LRLncPB5q9K3AoUAH2gUXUkJiZvRI=.a1f8d84d-3616-4729-9fe0-e10dd6de4c57@github.com>
Message-ID: <84uF4N9DtS5RqXpGr2X8x-QZkztakWV8XYlq1aGP6Ac=.0d0ea683-75c0-4e97-97bf-e30eefe1e170@github.com>

On Tue, 27 Feb 2024 08:29:44 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> All those new parameters to SetupNativeCompilation, were they always there and the comments about them were just missing from the documentation about the function?

Yep. The toolchain definition was a way to "package" multiple arguments to SetupNativeCompilation, so you did not have to specify them individually in each call. But in the end they just turned into "normal" arguments to SetupNativeCompilation (but undocumented...).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966314926

From ihse at openjdk.org  Tue Feb 27 11:19:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Feb 2024 11:19:59 GMT
Subject: Integrated: 8326583: Remove over-generalized DefineNativeToolchain
 solution
In-Reply-To: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
Message-ID: <pK_M8V-MQoCXBRHBsUHz2EVWBVELkftarz89Km-t8CU=.23d9fae7-58ed-4810-bc26-68a438a75025@github.com>

On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
> 
> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
> 
> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
> 
> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.

This pull request has now been integrated.

Changeset: ac3ce2aa
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ac3ce2aa156332fc4e6f33018ff669657ab4b797
Stats:     231 lines in 14 files changed: 58 ins; 142 del; 31 mod

8326583: Remove over-generalized DefineNativeToolchain solution

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/jdk/pull/17986

From ihse at openjdk.org  Tue Feb 27 11:19:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Feb 2024 11:19:59 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
Message-ID: <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>

> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
> 
> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
> 
> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
> 
> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.

Magnus Ihse Bursie 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 remove-toolchain-define
 - Rename LANG to LINK_TYPE
 - Reword "lib" comment to fit in better
 - Merge branch 'master' into remove-toolchain-define
 - 8326583: Remove over-generalized DefineNativeToolchain solution

-------------

Changes: https://git.openjdk.org/jdk/pull/17986/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17986&range=03
  Stats: 231 lines in 14 files changed: 58 ins; 142 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/17986.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17986/head:pull/17986

PR: https://git.openjdk.org/jdk/pull/17986

From ihse at openjdk.org  Tue Feb 27 11:26:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Feb 2024 11:26:53 GMT
Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v5]
In-Reply-To: <5oS5x968YgpeRo6Bf6SQGnPvgLONaDi5hl7fRkeqYbg=.7f120d7c-6719-4a0e-97b8-823eccd0f809@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
 <5oS5x968YgpeRo6Bf6SQGnPvgLONaDi5hl7fRkeqYbg=.7f120d7c-6719-4a0e-97b8-823eccd0f809@github.com>
Message-ID: <43IaJIrElCQ3VrWzD3pXNJVvTv39T24dtC46t5yAY0A=.c6ee8393-954d-4e67-bb8c-ddb97518dfd5@github.com>

On Tue, 27 Feb 2024 00:24:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review comments

This looks good from a build perspective. Actually, it looks great! :) I'm happy to get rid of this old strange construct.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17991#pullrequestreview-1903238470

From jwaters at openjdk.org  Tue Feb 27 11:29:47 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 27 Feb 2024 11:29:47 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v3]
In-Reply-To: <qVY8G3YCtV5tT1ZHXUVTQh4FbX7_aDEYpX7d8LvG8rY=.bf557f0f-a205-4592-841c-c81d83cac22e@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <o-l6trdn97rwwcDyjzofXQ2MKmF50VJATpHTIqlw6w0=.aafa550e-f53a-42bb-ae54-2c7aaab04f00@github.com>
 <g5AkodtQxduUbHzXa_NxL44JxkjhTWJQK4lMxY_HC2k=.64a88123-9933-4e38-9885-34f12ca42ecc@github.com>
 <fl7S90DiuqboQxU2bjfRgpi9vco6wS_MT6Z8rWs5z08=.13a415a4-5607-41f2-b99b-17a2922a0bff@github.com>
 <qVY8G3YCtV5tT1ZHXUVTQh4FbX7_aDEYpX7d8LvG8rY=.bf557f0f-a205-4592-841c-c81d83cac22e@github.com>
Message-ID: <Xqxr2UkGR0b-F0izo8_Kfhd3QGchBqBQk5yltPVXUvM=.37d85154-ebb8-4a33-aea2-917154d864bd@github.com>

On Tue, 27 Feb 2024 11:09:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > can we get rid of LDCXX?
> 
> Yeah, that is something I plan to look into. Linking C++ object files with gcc will fail; and it might be that linking pure C with g++ might be problematic. If this is the case, I hope we can at least determine this automatically which linker frontend to use, i.e. selecting g++ as linker frontend if there is at least one .cpp file in the set of sources.
> 
> This PR is actually a kind of prerequisite for that kind of work.

I'd certainly opt for selecting which linker driver to use automatically than using one for both; According to some discussions with several gcc maintainers (https://web.libera.chat/) they really aren't meant to be intermingled
Also was fine with LANG; There wasn't a need to change it to LINK_TYPE, but oh well

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966341897

From djelinski at openjdk.org  Tue Feb 27 11:46:48 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 27 Feb 2024 11:46:48 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
Message-ID: <j_bCjV-RsNfPyF5eR7ngMmgco-6cL5RyDHDXg19Xd_o=.4d9469af-cc23-483f-b04e-deaf429e8423@github.com>

On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
>> 
>> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
>> 
>> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
>> 
>> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.
>
> Magnus Ihse Bursie 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 remove-toolchain-define
>  - Rename LANG to LINK_TYPE
>  - Reword "lib" comment to fit in better
>  - Merge branch 'master' into remove-toolchain-define
>  - 8326583: Remove over-generalized DefineNativeToolchain solution

FWIW, when I added `-lstdc++` before both `-static-libstdc++` and replaced LDCXX with LD, the code compiled and linked just fine.
Both GCC and G++ call the same linker, and the parameter differences are well documented. It's only a matter of deciding if we want to keep the complexity of selecting the executable to use or not.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966368056

From aleonard at openjdk.org  Tue Feb 27 11:53:03 2024
From: aleonard at openjdk.org (Andrew Leonard)
Date: Tue, 27 Feb 2024 11:53:03 GMT
Subject: RFR: 8326685: Linux builds not reproducible if two builds
 configured in different build folders [v2]
In-Reply-To: <H7AGuwEU6Ri9SjUsHrkuCT7jhnVpo3WUbir8BAdKWek=.24beadcd-1f13-4fa6-8ea8-8d3ab6bdc227@github.com>
References: <H7AGuwEU6Ri9SjUsHrkuCT7jhnVpo3WUbir8BAdKWek=.24beadcd-1f13-4fa6-8ea8-8d3ab6bdc227@github.com>
Message-ID: <QBbK0B3n1KZcCK5r8k6u3_9vok9qB7sq_EKRfg8xt_w=.7963df5f-dfe7-4edf-9c89-7fd0d5f03033@github.com>

> Adds Linux -fdebug-prefix-map'ing for SUPPORT_OUTPUTDIR and HOTSPOT_OUTPUTDIR when absolute paths are not allowed in the binaries, thus making the building of a JDK identically reproducible from different build directories.

Andrew Leonard has updated the pull request incrementally with two additional commits since the last revision:

 - 8326685: Linux builds not reproducible if two builds configured in different build folders
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8326685: Linux builds not reproducible if two builds configured in different build folders
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18009/files
  - new: https://git.openjdk.org/jdk/pull/18009/files/d3200dd3..4bd1d3dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18009&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18009&range=00-01

  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18009.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18009/head:pull/18009

PR: https://git.openjdk.org/jdk/pull/18009

From aleonard at openjdk.org  Tue Feb 27 11:53:03 2024
From: aleonard at openjdk.org (Andrew Leonard)
Date: Tue, 27 Feb 2024 11:53:03 GMT
Subject: RFR: 8326685: Linux builds not reproducible if two builds
 configured in different build folders [v2]
In-Reply-To: <MFq2phBNWiBn5B7IsUX7i5bR3HED89pEA6XK3fpEv58=.017154a0-cb3e-49ad-995d-9ac847ab98a5@github.com>
References: <H7AGuwEU6Ri9SjUsHrkuCT7jhnVpo3WUbir8BAdKWek=.24beadcd-1f13-4fa6-8ea8-8d3ab6bdc227@github.com>
 <qIHv1OoZXw2E5GOLWzfnY1RWPOohaQDlS0dznx9bBds=.04f0021c-cd40-4118-841f-5383d75eeb33@github.com>
 <cD5OvNnbhfjQ5IWTLo5Bg2ViCmfRjx2nmjlNE-1AAmE=.94f6b1ad-8ed7-475b-a4ba-de46749ca099@github.com>
 <aJ-1NmJeSfjO98Na6z5QICPewN_pujd7KJq5dv4fJrY=.99344368-7c66-423a-a501-52ceca998ecc@github.com>
 <4JEcPy9kgLmMA1BYPzlbYIw3ZooEaKSfcVBjYVZFOKs=.483e6541-aac8-4f0e-aa33-278b56cce494@github.com>
 <Azfhf9El2JasL81iVCL0IcN_pY70TI3ztpwBnwsbQ8o=.b24a9e86-3acc-4914-952d-793cc148d317@github.com>
 <C0Zujw04xFKPwFK5TmJY0CtTf4p1zWZbgU8QE5eZ-fE=.1d04b2c2-f5f5-490e-a981-89fbd52626fa@github.com>
 <MFq2phBNWiBn5B7IsUX7i5bR3HED89pEA6XK3fpEv58=.017154a0-cb3e-49ad-995d-9ac847ab98a5@github.com>
Message-ID: <E0XeI3Ud3ci4ngDTaaGq9iZ0oVcwBrzmxygIa5jYeCg=.c6becbd0-89e0-4981-9e1c-545fc67f151d@github.com>

On Tue, 27 Feb 2024 10:35:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> It seems correct to include the output dir in the remapping, but I have two objections/questions to the way you are doing it.
>> 1) Why not just use OUTPUTDIR instead of the two specialized subdirs? That is simpler, more general and future-proof.
>> 2) Why not expand the value of the OUTPUTDIR variable? I.e.  
>> 
>>  DEBUG_PREFIX_CFLAGS="$DEBUG_PREFIX_CFLAGS -fdebug-prefix-map=$OUTPUTDIR/="
>>  ```
>> 
>> instead of trying to preserve it as a variable to be expanded in the make execution.
>
> Also, this mapping business is getting really convoluted. :-( I did not like it as it was, and this patch makes it even worse. I think we need to rewrite this to create some kind of dict/map, and then iterate over the map and apply `-fdebug-prefix-map` to all items in the map. Unfortunately, the data structures available in shell scripts is limited and will make this a bit tricky to pull off. :(

@magicus thank you for the tip, it works nicely, ready for re-review please

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18009#discussion_r1504103093

From ihse at openjdk.org  Tue Feb 27 12:01:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Feb 2024 12:01:53 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <j_bCjV-RsNfPyF5eR7ngMmgco-6cL5RyDHDXg19Xd_o=.4d9469af-cc23-483f-b04e-deaf429e8423@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
 <j_bCjV-RsNfPyF5eR7ngMmgco-6cL5RyDHDXg19Xd_o=.4d9469af-cc23-483f-b04e-deaf429e8423@github.com>
Message-ID: <btoCBQli8SsrygvxZxjBFBnKIRtMFadmE-Sl0D3sPxM=.850b3f59-1973-4be0-9979-25e96fd4e01d@github.com>

On Tue, 27 Feb 2024 11:44:31 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> FWIW, when I added -lstdc++ before both -static-libstdc++ and replaced LDCXX with LD, the code compiled and linked just fine.
Both GCC and G++ call the same linker, and the parameter differences are well documented. It's only a matter of deciding if we want to keep the complexity of selecting the executable to use or not.

My thinking matches yours. It would be nice to get rid of LDCXX. I'll look into it as a follow-up project.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966390350

From ihse at openjdk.org  Tue Feb 27 12:02:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Feb 2024 12:02:52 GMT
Subject: RFR: 8326685: Linux builds not reproducible if two builds
 configured in different build folders [v2]
In-Reply-To: <QBbK0B3n1KZcCK5r8k6u3_9vok9qB7sq_EKRfg8xt_w=.7963df5f-dfe7-4edf-9c89-7fd0d5f03033@github.com>
References: <H7AGuwEU6Ri9SjUsHrkuCT7jhnVpo3WUbir8BAdKWek=.24beadcd-1f13-4fa6-8ea8-8d3ab6bdc227@github.com>
 <QBbK0B3n1KZcCK5r8k6u3_9vok9qB7sq_EKRfg8xt_w=.7963df5f-dfe7-4edf-9c89-7fd0d5f03033@github.com>
Message-ID: <gsmD6kGDtWdQ6r2ttvq94nueFBFtk3UVG3tqLa9pEvQ=.0cba58d7-ca79-4b86-b2a0-c7029441e2a4@github.com>

On Tue, 27 Feb 2024 11:53:03 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Adds Linux -fdebug-prefix-map'ing for SUPPORT_OUTPUTDIR and HOTSPOT_OUTPUTDIR when absolute paths are not allowed in the binaries, thus making the building of a JDK identically reproducible from different build directories.
>
> Andrew Leonard has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8326685: Linux builds not reproducible if two builds configured in different build folders
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8326685: Linux builds not reproducible if two builds configured in different build folders
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Marked as reviewed by ihse (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18009#pullrequestreview-1903307285

From ihse at openjdk.org  Tue Feb 27 12:02:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Feb 2024 12:02:52 GMT
Subject: RFR: 8326685: Linux builds not reproducible if two builds
 configured in different build folders [v2]
In-Reply-To: <E0XeI3Ud3ci4ngDTaaGq9iZ0oVcwBrzmxygIa5jYeCg=.c6becbd0-89e0-4981-9e1c-545fc67f151d@github.com>
References: <H7AGuwEU6Ri9SjUsHrkuCT7jhnVpo3WUbir8BAdKWek=.24beadcd-1f13-4fa6-8ea8-8d3ab6bdc227@github.com>
 <qIHv1OoZXw2E5GOLWzfnY1RWPOohaQDlS0dznx9bBds=.04f0021c-cd40-4118-841f-5383d75eeb33@github.com>
 <cD5OvNnbhfjQ5IWTLo5Bg2ViCmfRjx2nmjlNE-1AAmE=.94f6b1ad-8ed7-475b-a4ba-de46749ca099@github.com>
 <aJ-1NmJeSfjO98Na6z5QICPewN_pujd7KJq5dv4fJrY=.99344368-7c66-423a-a501-52ceca998ecc@github.com>
 <4JEcPy9kgLmMA1BYPzlbYIw3ZooEaKSfcVBjYVZFOKs=.483e6541-aac8-4f0e-aa33-278b56cce494@github.com>
 <Azfhf9El2JasL81iVCL0IcN_pY70TI3ztpwBnwsbQ8o=.b24a9e86-3acc-4914-952d-793cc148d317@github.com>
 <C0Zujw04xFKPwFK5TmJY0CtTf4p1zWZbgU8QE5eZ-fE=.1d04b2c2-f5f5-490e-a981-89fbd52626fa@github.com>
 <MFq2phBNWiBn5B7IsUX7i5bR3HED89pEA6XK3fpEv58=.017154a0-cb3e-49ad-995d-9ac847ab98a5@github.com>
 <E0XeI3Ud3ci4ngDTaaGq9iZ0oVcwBrzmxygIa5jYeCg=.c6becbd0-89e0-4981-9e1c-545fc67f151d@github.com>
Message-ID: <Pukrxyu1yaTkrQZf7yZt8SkmaOvLqcoVKULhCxe5Jhs=.f67f9bdf-84c9-440e-929b-82bf4310bfa1@github.com>

On Tue, 27 Feb 2024 11:50:35 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Also, this mapping business is getting really convoluted. :-( I did not like it as it was, and this patch makes it even worse. I think we need to rewrite this to create some kind of dict/map, and then iterate over the map and apply `-fdebug-prefix-map` to all items in the map. Unfortunately, the data structures available in shell scripts is limited and will make this a bit tricky to pull off. :(
>
> @magicus thank you for the tip, it works nicely, ready for re-review please

Looks good to me now, but please let Erik have a look as well before pushing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18009#discussion_r1504114547

From jwaters at openjdk.org  Tue Feb 27 12:50:48 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 27 Feb 2024 12:50:48 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
Message-ID: <wuo24mj4CQl0UsYobcdJcyJAlMNP9lENjN48QDaeEXw=.6fc92cd3-9671-487c-ae05-df8fbf16fdce@github.com>

On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
>> 
>> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
>> 
>> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
>> 
>> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.
>
> Magnus Ihse Bursie 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 remove-toolchain-define
>  - Rename LANG to LINK_TYPE
>  - Reword "lib" comment to fit in better
>  - Merge branch 'master' into remove-toolchain-define
>  - 8326583: Remove over-generalized DefineNativeToolchain solution

I can't really say I agree, but I guess we'll see where this goes from here first

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966471047

From lorris.creantor at gmail.com  Tue Feb 27 13:13:38 2024
From: lorris.creantor at gmail.com (Lorris)
Date: Tue, 27 Feb 2024 14:13:38 +0100
Subject: Build the jdk with new or modified sources
In-Reply-To: <6fcee447-027e-438c-aae8-7194e965eff3@oracle.com>
References: <D01E146A-DD9A-4485-8F0E-AF6F5C554D54@gmail.com>
 <6fcee447-027e-438c-aae8-7194e965eff3@oracle.com>
Message-ID: <8F6A97E8-1F3A-418C-9981-2C63DFF883DC@gmail.com>

I don?t have problems with clock skew (or at least I never encountered any problem with it until today). The problem I was referring to in this statement is when I modify a class A, to add for example a method to it, and then reference this new method in another file B, when I build for the first time, I won?t have any problem. Although, if after this build I modify the B file, the next build will result in an error stating that the A method does not exist. If the A class has been modified after the files referencing the new methods it contains everything works correctly, but not vice versa.

Lorris

> On 26 Feb 2024, at 22:22, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> On 2024-02-26 14:40, Lorris wrote:
> 
>> (it seems to depend on the date of the last edited file)
> Just checking: do you have a problem with clock skew on your machine, or are you using some tools that modify time stamps on modified files? The make machinery depends on the fact that edited files should have a newer timestamp. If this does not work properly, dependency tracking will fail.
> 
> /Magnus
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240227/ea56041d/attachment-0001.htm>

From aleonard at openjdk.org  Tue Feb 27 13:44:15 2024
From: aleonard at openjdk.org (Andrew Leonard)
Date: Tue, 27 Feb 2024 13:44:15 GMT
Subject: RFR: 8326685: Linux builds not reproducible if two builds
 configured in different build folders [v3]
In-Reply-To: <H7AGuwEU6Ri9SjUsHrkuCT7jhnVpo3WUbir8BAdKWek=.24beadcd-1f13-4fa6-8ea8-8d3ab6bdc227@github.com>
References: <H7AGuwEU6Ri9SjUsHrkuCT7jhnVpo3WUbir8BAdKWek=.24beadcd-1f13-4fa6-8ea8-8d3ab6bdc227@github.com>
Message-ID: <VQVXq-tE3rJXA4IdRnQagsf6zJc7jcHrGf83tMXSYyA=.97c65ecc-667d-4bc2-8936-adaf1cce56e9@github.com>

> Adds Linux -fdebug-prefix-map'ing for SUPPORT_OUTPUTDIR and HOTSPOT_OUTPUTDIR when absolute paths are not allowed in the binaries, thus making the building of a JDK identically reproducible from different build directories.

Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:

  Re-trigger actions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18009/files
  - new: https://git.openjdk.org/jdk/pull/18009/files/4bd1d3dd..1af645c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18009&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18009&range=01-02

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18009.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18009/head:pull/18009

PR: https://git.openjdk.org/jdk/pull/18009

From lujaniuk at openjdk.org  Tue Feb 27 14:00:00 2024
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Tue, 27 Feb 2024 14:00:00 GMT
Subject: RFR: 8326831 Clarify test harness control variables in make help
Message-ID: <fFsKNZyBt9eMjW-6ku43H9fAbWj7WT2QXw4qNFd5Yzw=.c9055542-0c8d-47f4-b085-1f4f03bf9e1b@github.com>

Clarifying text in `make help` output on how to list variables for e.g. JTREG='...'.

-------------

Commit messages:
 - 8326831 Clarify test harness control variables in make help

Changes: https://git.openjdk.org/jdk/pull/18028/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18028&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326831
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18028.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18028/head:pull/18028

PR: https://git.openjdk.org/jdk/pull/18028

From lujaniuk at openjdk.org  Tue Feb 27 14:00:00 2024
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Tue, 27 Feb 2024 14:00:00 GMT
Subject: RFR: 8326831 Clarify test harness control variables in make help
In-Reply-To: <fFsKNZyBt9eMjW-6ku43H9fAbWj7WT2QXw4qNFd5Yzw=.c9055542-0c8d-47f4-b085-1f4f03bf9e1b@github.com>
References: <fFsKNZyBt9eMjW-6ku43H9fAbWj7WT2QXw4qNFd5Yzw=.c9055542-0c8d-47f4-b085-1f4f03bf9e1b@github.com>
Message-ID: <rV4AzEVhtStphlGFhHdAtbUeqOEfNm7CNMhAgdDf1KE=.f5823c0c-559a-4c43-b2e1-17c665e87d78@github.com>

On Tue, 27 Feb 2024 13:55:53 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> Clarifying text in `make help` output on how to list variables for e.g. JTREG='...'.

I'll note that you still need to run configure to execute `make test-only JTREG=help`. Should this really be necessary?

Also, while `make test-only JTREG=help` lists the valid options, it still does nothing to document their meaning.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18028#issuecomment-1966607480
PR Comment: https://git.openjdk.org/jdk/pull/18028#issuecomment-1966609174

From sgehwolf at openjdk.org  Tue Feb 27 15:23:09 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 27 Feb 2024 15:23:09 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v18]
In-Reply-To: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
Message-ID: <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>

> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app b
 eing modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.manage...

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Only show runtime image suffix for JDK modules

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14787/files
  - new: https://git.openjdk.org/jdk/pull/14787/files/00caf77c..b034cce2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=16-17

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

PR: https://git.openjdk.org/jdk/pull/14787

From luhenry at openjdk.org  Tue Feb 27 15:38:53 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Tue, 27 Feb 2024 15:38:53 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v4]
In-Reply-To: <2E0F9OsixwTZ_Mq9OfUx1BQUStc92p0evM8KCbhz3jc=.18fd874c-f02a-406a-a8b7-c2cea0be8074@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
 <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>
 <WAwoF5K4yWv40dWrX1VjUfeVGYy918KDHp4qvuRQ5xM=.2aa20484-2def-46dc-b20f-4e866748e048@github.com>
 <1enXmdMITwK96Lz35sCWmkob9sLgKKt1N2Lp0NSldNc=.81d72c1e-0f11-452d-a55a-674f775fee47@github.com>
 <bmgatRS3iZ6J35-pwQQ81ev8-lMBeyFcN6jzQFk_qno=.369060d2-3e1f-45c9-bad6-71bbc921b647@github.com>
 <c-DwcGAX3JX-gnQ0CWuGzI09K5SCdQ_yxnBP-q9HT1o=.903a2615-8255-4bbf-aaa3-2e9fb0ae84f5@github.com>
 <o3KeCSV9VoJrmFKEsfKPCJ0cnuYbZZcjY18qYWSXZns=.fc08ab1b-d6f3-4158-8291-63e2663c2992@github.com>
 <PjRWrB0x0vcYcQoa6EK62usvbNr_AFa_IN2ljCLrDDI=.4d69297c-6996-4cb7-9bd6-50f961c43686@github.com>
 <2E0F9OsixwTZ_Mq9OfUx1BQUStc92p0evM8KCbhz3jc=.18fd874c-f02a-406a-a8b7-c2cea0be8074@github.com>
Message-ID: <mCVfkxElPQgZzHyyDrGxQEEzhc16HGL0WhZYEIRBwgM=.6b0383ff-0928-4b07-8688-2d0835bbb1c7@github.com>

On Mon, 26 Feb 2024 20:07:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I use `das` every day. In contrast, I don't know what `das1` is for.
>
> It does not sound like anyone object to the removal of `JNIEXPORT` for `das1`, then.
> 
> Or should I just remove the entire function, if it serves no purpose that any current maintainers know or care about?

You can probably remove the entire function given it's an indirection to `das` anyway. I remember using it for debugging during the first stages of the Windows-AArch64 port but I've long forgotten about it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1504463486

From aleonard at openjdk.org  Tue Feb 27 15:53:54 2024
From: aleonard at openjdk.org (Andrew Leonard)
Date: Tue, 27 Feb 2024 15:53:54 GMT
Subject: RFR: 8326685: Linux builds not reproducible if two builds
 configured in different build folders [v3]
In-Reply-To: <VQVXq-tE3rJXA4IdRnQagsf6zJc7jcHrGf83tMXSYyA=.97c65ecc-667d-4bc2-8936-adaf1cce56e9@github.com>
References: <H7AGuwEU6Ri9SjUsHrkuCT7jhnVpo3WUbir8BAdKWek=.24beadcd-1f13-4fa6-8ea8-8d3ab6bdc227@github.com>
 <VQVXq-tE3rJXA4IdRnQagsf6zJc7jcHrGf83tMXSYyA=.97c65ecc-667d-4bc2-8936-adaf1cce56e9@github.com>
Message-ID: <Dr2Axy4XBwDIzW2yKoJjguoHHOTjnXew3Xiu3MxWvRM=.fc0648a6-5f9d-410a-b17d-36b916bf51dc@github.com>

On Tue, 27 Feb 2024 13:44:15 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Adds Linux -fdebug-prefix-map'ing for SUPPORT_OUTPUTDIR and HOTSPOT_OUTPUTDIR when absolute paths are not allowed in the binaries, thus making the building of a JDK identically reproducible from different build directories.
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-trigger actions

@erikj79 ready for re-review please

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18009#issuecomment-1966869370

From adinn at openjdk.org  Tue Feb 27 16:13:54 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 27 Feb 2024 16:13:54 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v4]
In-Reply-To: <mCVfkxElPQgZzHyyDrGxQEEzhc16HGL0WhZYEIRBwgM=.6b0383ff-0928-4b07-8688-2d0835bbb1c7@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
 <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>
 <WAwoF5K4yWv40dWrX1VjUfeVGYy918KDHp4qvuRQ5xM=.2aa20484-2def-46dc-b20f-4e866748e048@github.com>
 <1enXmdMITwK96Lz35sCWmkob9sLgKKt1N2Lp0NSldNc=.81d72c1e-0f11-452d-a55a-674f775fee47@github.com>
 <bmgatRS3iZ6J35-pwQQ81ev8-lMBeyFcN6jzQFk_qno=.369060d2-3e1f-45c9-bad6-71bbc921b647@github.com>
 <c-DwcGAX3JX-gnQ0CWuGzI09K5SCdQ_yxnBP-q9HT1o=.903a2615-8255-4bbf-aaa3-2e9fb0ae84f5@github.com>
 <o3KeCSV9VoJrmFKEsfKPCJ0cnuYbZZcjY18qYWSXZns=.fc08ab1b-d6f3-4158-8291-63e2663c2992@github.com>
 <PjRWrB0x0vcYcQoa6EK62usvbNr_AFa_IN2ljCLrDDI=.4d69297c-6996-4cb7-9bd6-50f961c43686@github.com>
 <2E0F9OsixwTZ_Mq9OfUx1BQUStc92p0evM8KCbhz3jc=.18fd874c-f02a-406a-a8b7-c2cea0be8074@github.com>
 <mCVfkxElPQgZzHyyDrGxQEEzhc16HGL0WhZ
 YEIRBwgM=.6b0383ff-0928-4b07-8688-2d0835bbb1c7@github.com>
Message-ID: <yrrTlGniHMLv8PraqWDbFjX5EhBRDgihfAAWxKNYQxY=.31e527b0-2942-4ca8-a729-8bc3636178a8@github.com>

On Tue, 27 Feb 2024 15:35:56 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> It does not sound like anyone object to the removal of `JNIEXPORT` for `das1`, then.
>> 
>> Or should I just remove the entire function, if it serves no purpose that any current maintainers know or care about?
>
> You can probably remove the entire function given it's an indirection to `das` anyway. I remember using it for debugging during the first stages of the Windows-AArch64 port but I've long forgotten about it.

@luhenry @magicus das1 was added when we were implementing the AArch64 port in order to help us integrate the debugger support we provided when running JITted code on our AArch64 simulator into gdb. Now that we have real hardware it is redundant.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1504535787

From jiangli at openjdk.org  Tue Feb 27 16:57:02 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 27 Feb 2024 16:57:02 GMT
Subject: RFR: 8326587: Separate out Microsoft toolchain linking [v4]
In-Reply-To: <0rlFEeMIQlB2f_NYa5BvYKpZ2oq_-b8Qv7RP8PfV7iM=.7f7beab6-88b0-4da6-a11f-e11fa91b2e9c@github.com>
References: <1m-unY-wbiAjD7cvHWMdowjUkK6zDnNagoPMQp0UKhI=.b8a8415f-08b0-4773-a38c-70740ac6a773@github.com>
 <HYFyUc2JNWsgIqztJTKsz262oUPwqESI22Mu6uJCg9M=.22244884-b52f-4dce-84be-441605bfcf5e@github.com>
 <-6lUo6KUh120r7SqQzz-1DWmU7OJ9btSE6vpWIrVeaA=.627c7f01-de11-4730-99b3-13464c30a063@github.com>
 <b_sMqRY8QKG-UIP9eqTWMsJiD8Jt6V7s3jV2LDRxQUc=.d3483d8a-3af9-4244-ac4d-3f75b74cdc1f@github.com>
 <uvNqbMlSJeNNOXp1rqyATgoHRkWCzey4m-HGMW61uDE=.f991fc3d-2f46-472e-b3e4-db8d8977c1b2@github.com>
 <0rlFEeMIQlB2f_NYa5BvYKpZ2oq_-b8Qv7RP8PfV7iM=.7f7beab6-88b0-4da6-a11f-e11fa91b2e9c@github.com>
Message-ID: <WQ7DykHwK-uTbO2lskTUyw5yvBLOHXVw6XsQ6PwKwes=.e1a8144b-8513-41eb-ab11-d63bc42e5ce2@github.com>

On Tue, 27 Feb 2024 11:06:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This was actually an important part of this PR, trying to combat the all too general solution we had when trying to combine microsoft and non-microsoft linking. On all Unix-style linkers, the option to mark the output file is `-o `. That is such a fundemental option that we do not want to make it general, especially not considering the additional difficulty that the corresponding option for the microsoft `link.exe` is to specify `/out:<filename>`, without a space. This forced us to define LD_OUT_OPTION as `-o$(SPACE)` on unix linkers, and it forced us to setup the linker command line with `$(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE)` with no space between. 
>> 
>> That is in clear contrast with how we can add multiple sets of command line options like e.g. `(LDFLAGS_CXX_PARTIAL_LINKING) $$($1_SYSROOT_LDFLAGS)` where we can just stack them after each other with a space between.
>
> Also, 
> 
>> the flexibility of specifying the non-linker specific option here
> 
> I don't know what you mean by that. LD_OUT_OPTION was thought of as an abstraction between the difference of `-o ` and `/out:`. It should not be used to include anything else, so no flexibility is lost.

Thanks for the explanation. With the separation of Microsoft linking and this handling the Unix style linking only, using the non-general `-o` seems reasonable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17987#discussion_r1504622620

From naoto at openjdk.org  Tue Feb 27 17:00:48 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Feb 2024 17:00:48 GMT
Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v5]
In-Reply-To: <43IaJIrElCQ3VrWzD3pXNJVvTv39T24dtC46t5yAY0A=.c6ee8393-954d-4e67-bb8c-ddb97518dfd5@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
 <5oS5x968YgpeRo6Bf6SQGnPvgLONaDi5hl7fRkeqYbg=.7f120d7c-6719-4a0e-97b8-823eccd0f809@github.com>
 <43IaJIrElCQ3VrWzD3pXNJVvTv39T24dtC46t5yAY0A=.c6ee8393-954d-4e67-bb8c-ddb97518dfd5@github.com>
Message-ID: <ok2WX2WCH33F7Ou6Z-v5Xex6S8-h4vjTcKLCDEc7Te8=.e5f399bd-2a6d-484e-beb6-a6a800ac6c18@github.com>

On Tue, 27 Feb 2024 11:24:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing review comments
>
> This looks good from a build perspective. Actually, it looks great! :) I'm happy to get rid of this old strange construct.

Thanks, @magicus 

> to get rid of this old strange construct.

Removing legacy clutter is exactly the purpose of this exercise!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17991#issuecomment-1967125233

From jonathan.gibbons at oracle.com  Tue Feb 27 17:07:07 2024
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 27 Feb 2024 09:07:07 -0800
Subject: Build the jdk with new or modified sources
In-Reply-To: <4BC4C046-D733-4562-A7D5-77919DC17145@gmail.com>
References: <D01E146A-DD9A-4485-8F0E-AF6F5C554D54@gmail.com>
 <1aa9d412-0064-4216-b6bc-9d883991f1a7@oracle.com>
 <4BC4C046-D733-4562-A7D5-77919DC17145@gmail.com>
Message-ID: <4ea25026-5f0c-4eb9-8eca-d5f7fc903770@oracle.com>

Lorris,

You cannot use new API in java.base in the code for javac, meaning the 
java.compiler and jdk.compiler modules. This is an ingherent limitation 
of the bootstrap process.

-- Jon

On 2/27/24 1:57 AM, Lorris wrote:
> Yes indeed, I am trying to use those changes from the jdk.compiler module. How can I make this work without causing problem when building the interim module ?
>
> Lorris
>
>> On 26 Feb 2024, at 14:59, erik.joelsson at oracle.com wrote:
>>
>> Hello Lorris,
>>
>> This is not expected behavior. Building incrementally is expected to work correctly.
>>
>> If you are making changes to java.base and then trying to use those changes from any of java.compiler, jdk.compiler and jdk.javadoc, you will have problems as those three modules have to be compatible with the previous JDK version (21 in this case). We build those modules for the "interim langtools" which is then used to compile the rest of the JDK by running this interim javac compiler on the boot jdk. I think the problems you are seeing appear when building the interim versions of these modules as they will never see the updates you are making to java.base.
>>
>> If that isn't the issue, could you share more details on what kind of environment you are building on (OS, arch etc), how you configured the build and the make command line you are using?
>>
>> /Erik
>>
>> On 2/26/24 05:40, Lorris wrote:
>>> Hello,
>>>
>>> I?m trying to build the JDK (version 23, my fork is up to date as of 2024/02/26) while adding new source files and also adding some fields or methods in existing files (in java.base and java.compiler modules). My problem is that when I try to build the image, most of the time (it seems to depend on the date of the last edited file) the new files and members I have added aren?t visible to the compiler which results in an error. Until now I have been using a workaround by building two times, firstly, only with the new code declarations and, secondly, with the references to this code. However, I?m now seeing the limits of this method.
>>>
>>> Regards,
>>> Lorris Creantor
>>>

From erikj at openjdk.org  Tue Feb 27 20:46:43 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 27 Feb 2024 20:46:43 GMT
Subject: RFR: 8326831 Clarify test harness control variables in make help
In-Reply-To: <fFsKNZyBt9eMjW-6ku43H9fAbWj7WT2QXw4qNFd5Yzw=.c9055542-0c8d-47f4-b085-1f4f03bf9e1b@github.com>
References: <fFsKNZyBt9eMjW-6ku43H9fAbWj7WT2QXw4qNFd5Yzw=.c9055542-0c8d-47f4-b085-1f4f03bf9e1b@github.com>
Message-ID: <yiQqRAvw-Lcmn3ectJWDOI-xCqm76sezAm-vNaVaYMM=.38b648ee-1804-482b-9afa-fd85df5bd04d@github.com>

On Tue, 27 Feb 2024 13:55:53 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> Clarifying text in `make help` output on how to list variables for e.g. JTREG='...'.

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18028#pullrequestreview-1904771315

From erikj at openjdk.org  Tue Feb 27 20:59:52 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 27 Feb 2024 20:59:52 GMT
Subject: RFR: 8326831 Clarify test harness control variables in make help
In-Reply-To: <rV4AzEVhtStphlGFhHdAtbUeqOEfNm7CNMhAgdDf1KE=.f5823c0c-559a-4c43-b2e1-17c665e87d78@github.com>
References: <fFsKNZyBt9eMjW-6ku43H9fAbWj7WT2QXw4qNFd5Yzw=.c9055542-0c8d-47f4-b085-1f4f03bf9e1b@github.com>
 <rV4AzEVhtStphlGFhHdAtbUeqOEfNm7CNMhAgdDf1KE=.f5823c0c-559a-4c43-b2e1-17c665e87d78@github.com>
Message-ID: <yKgfohp8XvmRvvCfW07X-xs9q5FxjaJEAQ7UbW1u6JE=.cea12394-ca86-4e17-a5f9-2d79af9ad88e@github.com>

On Tue, 27 Feb 2024 13:56:56 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> I'll note that you still need to run configure to execute make test-only JTREG=help. Should this really be necessary?

I agree that it would be convenient, in some rare usecase, to be able to run this without configure, but the added complexity needed to implement that is hardly worth the effort. In practice, if you are about to run `make test`, and trying to construct your command line, you would have already run configure.

> Also, while `make test-only JTREG=help` lists the valid options, it still does nothing to document their meaning.

The documentation for running tests can be found in `doc/testing.md`. The help output from make is just meant to be a short version reminder for common cases. The list is constructed programmatically from the makefile constructs used to define the possible parameters, so it's guaranteed to be up to date. That is also why you must call the same target as when using the parameter (`test` or `test-only` in this case) as otherwise you wouldn't end up in the makefile where the parameters are defined. You can't really expect makefiles to be fully self documenting as we are limited by what we can reasonably implement in makefiles after all, and these makefiles are really pushing the boundaries of that already.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18028#issuecomment-1967575782

From ihse at openjdk.org  Tue Feb 27 21:46:17 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Feb 2024 21:46:17 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v5]
In-Reply-To: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
Message-ID: <ApQbL-hj7jaPj5WBhIdDXBVXrM5mBHpPtBmrlHG13K0=.225315ae-8d9b-4842-a78a-b87fe888a5e5@github.com>

> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been integrated, it is possible to do some cleanup. The goal of [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change any behavior, even if that behavior seemed odd.
> 
> Now let's try to fix that. We can:
> 
> a) remove JNIEXPORT from c2v functions.
> b) make debug.cpp functions exported similarly on all platforms.
> c) remove JNIEXPORT from aarch64 asm debug function.
> 
> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.

Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:

 - Why did these creep back in? Merge error?
 - Remove #undef JNIEXPORT
 - Remove das1()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17967/files
  - new: https://git.openjdk.org/jdk/pull/17967/files/43c3513b..387d243b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17967&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17967&range=03-04

  Stats: 24 lines in 4 files changed: 0 ins; 24 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17967.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17967/head:pull/17967

PR: https://git.openjdk.org/jdk/pull/17967

From ihse at openjdk.org  Tue Feb 27 21:46:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Feb 2024 21:46:18 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v4]
In-Reply-To: <wHGBIhPuYhFHpOmp-pckQClVnS4sODTqkZHqNbI5tB4=.cd8f6adb-14a4-4160-92cc-41e7b871ad2d@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <wHGBIhPuYhFHpOmp-pckQClVnS4sODTqkZHqNbI5tB4=.cd8f6adb-14a4-4160-92cc-41e7b871ad2d@github.com>
Message-ID: <kK6vY0FUvUZkS0C34eTiBBYXYSe0xfpxyelXw8ZRVZ4=.2975cf18-696c-4955-9431-efbd9b5e93b1@github.com>

On Tue, 27 Feb 2024 11:01:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been integrated, it is possible to do some cleanup. The goal of [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change any behavior, even if that behavior seemed odd.
>> 
>> Now let's try to fix that. We can:
>> 
>> a) remove JNIEXPORT from c2v functions.
>> b) make debug.cpp functions exported similarly on all platforms.
>> c) remove JNIEXPORT from aarch64 asm debug function.
>> 
>> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.
>
> Magnus Ihse Bursie 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 hotspot-symbols-followup
>  - Remove jvmci globals
>  - 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234
>  - Revert "Use #pragma instead of HIDDEN define"
>    
>    This reverts commit 00e40a7f6e4cdef6592d72b3d08063cdcc41532a.
>  - Use #pragma instead of HIDDEN define
>  - Rename the version script to version-script.txt
>  - Restore linker script to linux/gcc builds
>  - Rename the Windows export file to .def
>  - Remove unused symbol _Copy_conjoint_bytes on linux/arm32
>  - 8017234: Hotspot should stop using mapfiles

There was a bit back and forth with this PR, but now I believe it is finally ready. Any reviewers?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17967#issuecomment-1967657651

From ihse at openjdk.org  Tue Feb 27 21:46:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Feb 2024 21:46:18 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v5]
In-Reply-To: <yrrTlGniHMLv8PraqWDbFjX5EhBRDgihfAAWxKNYQxY=.31e527b0-2942-4ca8-a729-8bc3636178a8@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
 <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>
 <WAwoF5K4yWv40dWrX1VjUfeVGYy918KDHp4qvuRQ5xM=.2aa20484-2def-46dc-b20f-4e866748e048@github.com>
 <1enXmdMITwK96Lz35sCWmkob9sLgKKt1N2Lp0NSldNc=.81d72c1e-0f11-452d-a55a-674f775fee47@github.com>
 <bmgatRS3iZ6J35-pwQQ81ev8-lMBeyFcN6jzQFk_qno=.369060d2-3e1f-45c9-bad6-71bbc921b647@github.com>
 <c-DwcGAX3JX-gnQ0CWuGzI09K5SCdQ_yxnBP-q9HT1o=.903a2615-8255-4bbf-aaa3-2e9fb0ae84f5@github.com>
 <o3KeCSV9VoJrmFKEsfKPCJ0cnuYbZZcjY18qYWSXZns=.fc08ab1b-d6f3-4158-8291-63e2663c2992@github.com>
 <PjRWrB0x0vcYcQoa6EK62usvbNr_AFa_IN2ljCLrDDI=.4d69297c-6996-4cb7-9bd6-50f961c43686@github.com>
 <2E0F9OsixwTZ_Mq9OfUx1BQUStc92p0evM8KCbhz3jc=.18fd874c-f02a-406a-a8b7-c2cea0be8074@github.com>
 <mCVfkxElPQgZzHyyDrGxQEEzhc16HGL0WhZ
 YEIRBwgM=.6b0383ff-0928-4b07-8688-2d0835bbb1c7@github.com>
 <yrrTlGniHMLv8PraqWDbFjX5EhBRDgihfAAWxKNYQxY=.31e527b0-2942-4ca8-a729-8bc3636178a8@github.com>
Message-ID: <5boFfR3_uytbIyM1w3SrApZ76sHIJmmfgKdeK4mWqNY=.5e299d88-0fb9-4d57-bbd7-f01a12bc651e@github.com>

On Tue, 27 Feb 2024 16:11:34 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> You can probably remove the entire function given it's an indirection to `das` anyway. I remember using it for debugging during the first stages of the Windows-AArch64 port but I've long forgotten about it.
>
> @luhenry @magicus das1 was added when we were implementing the AArch64 port in order to help us integrate the debugger support we provided when running JITted code on our AArch64 simulator into gdb. Now that we have real hardware it is redundant.

Thanks @adinn for the confirmation! I've now removed it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1505045060

From bstafford at openjdk.org  Tue Feb 27 22:06:52 2024
From: bstafford at openjdk.org (Brian Stafford)
Date: Tue, 27 Feb 2024 22:06:52 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v5]
In-Reply-To: <bmgatRS3iZ6J35-pwQQ81ev8-lMBeyFcN6jzQFk_qno=.369060d2-3e1f-45c9-bad6-71bbc921b647@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
 <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>
 <WAwoF5K4yWv40dWrX1VjUfeVGYy918KDHp4qvuRQ5xM=.2aa20484-2def-46dc-b20f-4e866748e048@github.com>
 <1enXmdMITwK96Lz35sCWmkob9sLgKKt1N2Lp0NSldNc=.81d72c1e-0f11-452d-a55a-674f775fee47@github.com>
 <bmgatRS3iZ6J35-pwQQ81ev8-lMBeyFcN6jzQFk_qno=.369060d2-3e1f-45c9-bad6-71bbc921b647@github.com>
Message-ID: <lgop3BvNeg0qlKvQhqL01frqudmgOUU__Onz8HjNf_Q=.7d572f20-0e18-4ef9-b6ee-1bd07c9c27a6@github.com>

On Fri, 23 Feb 2024 12:03:37 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

>> Instead of discussing removal of windows/aarch64 (although the general rule in OpenJDK is that ports that are not maintained by anyone should be removed); let's stick to the question here: do we need to export `das1()` for debugging?
>
> Personally I have never used `das`/`das1` on any AArch64 port when debugging.  I guess it was somewhat handy when the backend was originally developed.  I would argue that the built-in disassembler of any debugger and `disnm` from `debug.cpp` are good enough, and thus `das`/`das1` can be removed.  What do you think @theRealAph ?

Removal makes sense - thank you @lewurm, @luhenry, and @adinn for your input!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1505070224

From erikj at openjdk.org  Tue Feb 27 22:14:55 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 27 Feb 2024 22:14:55 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v18]
In-Reply-To: <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <S-4JCw7WZk7VQlwffF_uKhDbnzVWsLrKO8Ad3hemP20=.cfea84fc-995a-4b7b-a233-8c269ff7c556@github.com>
Message-ID: <GhW_EsutSYyiQDxy4m6KuWnpAZl9VL7jhyc8a3QWCUM=.f2ca2f6a-0c9d-4d9f-9a00-da6d12e09ada@github.com>

On Tue, 27 Feb 2024 15:23:09 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Only show runtime image suffix for JDK modules

>From a build point of view, I don't have much to complain about. See inline comments for some nits.

make/autoconf/jdk-options.m4 line 596:

> 594: ################################################################################
> 595: #
> 596: # jlink related.

This part of the comment seems a bit redundant.

make/autoconf/spec.gmk.template line 904:

> 902: RL_INTERMEDIATE_IMAGE_SUBDIR := runtime-link-initial-jdk
> 903: RL_INTERMEDIATE_IMAGE_DIR := $(IMAGES_OUTPUTDIR)/$(RL_INTERMEDIATE_IMAGE_SUBDIR)
> 904: 

This intermediate directory is only used inside the Images.gmk. I don't think we need to define it in spec. It can be a local variable in Images.gmk. Also, unless you really want this intermediate image in "images" as some kind of deliverable I would prefer to put it somewhere under `$(SUPPORT_OUTPUTDIR)/images`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14787#pullrequestreview-1904905122
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1505071076
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1505072553

From erikj at openjdk.org  Tue Feb 27 22:17:54 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 27 Feb 2024 22:17:54 GMT
Subject: RFR: 8326685: Linux builds not reproducible if two builds
 configured in different build folders [v3]
In-Reply-To: <VQVXq-tE3rJXA4IdRnQagsf6zJc7jcHrGf83tMXSYyA=.97c65ecc-667d-4bc2-8936-adaf1cce56e9@github.com>
References: <H7AGuwEU6Ri9SjUsHrkuCT7jhnVpo3WUbir8BAdKWek=.24beadcd-1f13-4fa6-8ea8-8d3ab6bdc227@github.com>
 <VQVXq-tE3rJXA4IdRnQagsf6zJc7jcHrGf83tMXSYyA=.97c65ecc-667d-4bc2-8936-adaf1cce56e9@github.com>
Message-ID: <kMNZ6Yf5dPel8nNBskFA8D0x4AzDZfBk4bcGiEg5h78=.23c37b01-0476-46a5-8b81-f90ff3723e3a@github.com>

On Tue, 27 Feb 2024 13:44:15 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Adds Linux -fdebug-prefix-map'ing for SUPPORT_OUTPUTDIR and HOTSPOT_OUTPUTDIR when absolute paths are not allowed in the binaries, thus making the building of a JDK identically reproducible from different build directories.
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-trigger actions

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18009#pullrequestreview-1904920207

From kbarrett at openjdk.org  Wed Feb 28 02:10:53 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 28 Feb 2024 02:10:53 GMT
Subject: RFR: 8325880: Require minimum Open XL C/C++ version 17.1.1
In-Reply-To: <mYhkdea6XL09IsDZzeSMKCw5k2nWmB0bbVZfAA2bmIE=.b4d15383-e5e9-4e06-aef3-57cf104fc9bb@github.com>
References: <mYhkdea6XL09IsDZzeSMKCw5k2nWmB0bbVZfAA2bmIE=.b4d15383-e5e9-4e06-aef3-57cf104fc9bb@github.com>
Message-ID: <eR7IQsF2YZ7HxbnN4hvPoUdsB-hRqUPiF2qhyufijM0=.0f865590-7f80-4866-b41f-dfea44605b7d@github.com>

On Wed, 14 Feb 2024 22:43:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that updates the minimum supported version of IBM
> Open XL C/C++.  SAP dropped support for older versions in JDK 22, only
> supporting the version specified in this change.
> 
> I need someone from the aix-ppc porters to test and review the change.

There was one bit of discussion about this tool chain upgrade over in the PR for enabling C++17:
https://github.com/openjdk/jdk/pull/14988#issuecomment-1741985638
Has that been sufficiently answered?  Good to go here?  @aixtools

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17857#issuecomment-1968058127

From kbarrett at openjdk.org  Wed Feb 28 02:19:53 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 28 Feb 2024 02:19:53 GMT
Subject: RFR: 8325878: Require minimum Clang version 13
In-Reply-To: <zSj7alqhcE-_CnzPzWSc9bIKCZtTew_WaSTIkx5qHhQ=.ca1dc065-38d1-4b33-9ae5-e1a86d47c53a@github.com>
References: <zSj7alqhcE-_CnzPzWSc9bIKCZtTew_WaSTIkx5qHhQ=.ca1dc065-38d1-4b33-9ae5-e1a86d47c53a@github.com>
Message-ID: <5fx6VScpYbmcA1IdxmpcWorWeyewGwMWp4bMIbvqmVE=.da0add87-f0f9-45dc-aa0d-1280e2e592a9@github.com>

On Thu, 15 Feb 2024 05:19:45 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that updates the minimum supported version of Clang
> to be used for building OpenJDK from 3.5 to 13.
> 
> This permits enabling C++17 (JDK-8314488), though Clang 5 might suffice for
> that. A minimum of Clang 13 also obtains a critical bug fix for the [[noreturn]]
> attribute (see JDK-8303805).
> 
> Testing: mach5 tier1, which includes building with a recent version of Xcode/clang.

There was some discussion of clang versions over in the PR proposing to enable
C++17 (https://github.com/openjdk/jdk/pull/14988).  The minimum version
proposed here (13) seemed acceptable from that discussion.  Good to go here?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17862#issuecomment-1968065624

From kbarrett at openjdk.org  Wed Feb 28 02:47:47 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 28 Feb 2024 02:47:47 GMT
Subject: RFR: 8325881: Require minimum gcc version 10
In-Reply-To: <M0am_3VbHFaY6j5Ci1-DGeqfU7KOrTJeaymKvQ_EXyc=.c102258b-c728-4718-8061-1346e37e0276@github.com>
References: <M0am_3VbHFaY6j5Ci1-DGeqfU7KOrTJeaymKvQ_EXyc=.c102258b-c728-4718-8061-1346e37e0276@github.com>
Message-ID: <rjj3SBoEbP64e5hSzCgILUSQ_aDVVY3F3Ca5lyOy5Gc=.e47efc7c-01f5-43de-bac8-dbbba44e97de@github.com>

On Sat, 17 Feb 2024 08:28:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that updates the minimum supported version of gcc
> to be used for building OpenJDK from 6.0 to 10.0.
> 
> This permits enabling C++17 (JDK-8314488), though gcc 9.0 might suffice for
> that. A minimum of gcc 10 also obtains the primitives needed to support a
> work-alick for std::is_constant_evaluated (added in C++20). There are a bunch
> of improvements that would be enabled by that. Having it would also allow the
> elimination of a bit of a mess in the HotSpot assert macros that was needed to
> work around the lack of that feature (JDK-8303805). Either current or proposed
> minimum versions of other supported compilers also provide the needed
> primitives.
> 
> Testing: mach5 tier1 (uses gcc13.2 on gcc-based platforms)
> Locally (linux-x64) built and ran tier1 with gcc10.3.

There was some discussion of gcc versions over in the PR proposing to enable C++17:
https://github.com/openjdk/jdk/pull/14988#issuecomment-1895511862
https://github.com/openjdk/jdk/pull/14988#issuecomment-1895729165
Has that been sufficiently answered?  Good to go here?
@shipilev @theRealAph @TheRealMDoerr

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17899#issuecomment-1968089822

From dholmes at openjdk.org  Wed Feb 28 04:09:44 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 28 Feb 2024 04:09:44 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v5]
In-Reply-To: <ApQbL-hj7jaPj5WBhIdDXBVXrM5mBHpPtBmrlHG13K0=.225315ae-8d9b-4842-a78a-b87fe888a5e5@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <ApQbL-hj7jaPj5WBhIdDXBVXrM5mBHpPtBmrlHG13K0=.225315ae-8d9b-4842-a78a-b87fe888a5e5@github.com>
Message-ID: <YESDVVEaRi5rh5AjG8aFPF3hexsOyeEBX9wkP5vFGew=.24e174c8-d905-4177-af14-9d64a4985bd6@github.com>

On Tue, 27 Feb 2024 21:46:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been integrated, it is possible to do some cleanup. The goal of [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change any behavior, even if that behavior seemed odd.
>> 
>> Now let's try to fix that. We can:
>> 
>> a) remove JNIEXPORT from c2v functions.
>> b) make debug.cpp functions exported similarly on all platforms.
>> c) remove JNIEXPORT from aarch64 asm debug function.
>> 
>> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.
>
> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Why did these creep back in? Merge error?
>  - Remove #undef JNIEXPORT
>  - Remove das1()

Seems fine to me. Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17967#pullrequestreview-1905265100

From djelinski at openjdk.org  Wed Feb 28 05:46:53 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 28 Feb 2024 05:46:53 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v5]
In-Reply-To: <ApQbL-hj7jaPj5WBhIdDXBVXrM5mBHpPtBmrlHG13K0=.225315ae-8d9b-4842-a78a-b87fe888a5e5@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <ApQbL-hj7jaPj5WBhIdDXBVXrM5mBHpPtBmrlHG13K0=.225315ae-8d9b-4842-a78a-b87fe888a5e5@github.com>
Message-ID: <0kCemyTCfBScy9elbcKjZ_yfYDp6ZjXeo9L60tN0E6k=.36d1a7ae-f2e0-47ed-9de9-4c240a558324@github.com>

On Tue, 27 Feb 2024 21:46:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been integrated, it is possible to do some cleanup. The goal of [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change any behavior, even if that behavior seemed odd.
>> 
>> Now let's try to fix that. We can:
>> 
>> a) remove JNIEXPORT from c2v functions.
>> b) make debug.cpp functions exported similarly on all platforms.
>> c) remove JNIEXPORT from aarch64 asm debug function.
>> 
>> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.
>
> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Why did these creep back in? Merge error?
>  - Remove #undef JNIEXPORT
>  - Remove das1()

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17967#pullrequestreview-1905367506

From mdoerr at openjdk.org  Wed Feb 28 08:13:52 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 28 Feb 2024 08:13:52 GMT
Subject: RFR: 8325881: Require minimum gcc version 10
In-Reply-To: <M0am_3VbHFaY6j5Ci1-DGeqfU7KOrTJeaymKvQ_EXyc=.c102258b-c728-4718-8061-1346e37e0276@github.com>
References: <M0am_3VbHFaY6j5Ci1-DGeqfU7KOrTJeaymKvQ_EXyc=.c102258b-c728-4718-8061-1346e37e0276@github.com>
Message-ID: <SIO2fG339ao8TEVgoVTt7KagcrOe4mhdJEqxYLupavI=.2d361687-3bb0-42e8-93ec-49940a3e3cc4@github.com>

On Sat, 17 Feb 2024 08:28:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that updates the minimum supported version of gcc
> to be used for building OpenJDK from 6.0 to 10.0.
> 
> This permits enabling C++17 (JDK-8314488), though gcc 9.0 might suffice for
> that. A minimum of gcc 10 also obtains the primitives needed to support a
> work-alick for std::is_constant_evaluated (added in C++20). There are a bunch
> of improvements that would be enabled by that. Having it would also allow the
> elimination of a bit of a mess in the HotSpot assert macros that was needed to
> work around the lack of that feature (JDK-8303805). Either current or proposed
> minimum versions of other supported compilers also provide the needed
> primitives.
> 
> Testing: mach5 tier1 (uses gcc13.2 on gcc-based platforms)
> Locally (linux-x64) built and ran tier1 with gcc10.3.

I have no objections. We already build with gcc 11. Some machines may need to get a newer gcc, but I think that's acceptable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17899#issuecomment-1968440090

From aleonard at openjdk.org  Wed Feb 28 08:40:56 2024
From: aleonard at openjdk.org (Andrew Leonard)
Date: Wed, 28 Feb 2024 08:40:56 GMT
Subject: Integrated: 8326685: Linux builds not reproducible if two builds
 configured in different build folders
In-Reply-To: <H7AGuwEU6Ri9SjUsHrkuCT7jhnVpo3WUbir8BAdKWek=.24beadcd-1f13-4fa6-8ea8-8d3ab6bdc227@github.com>
References: <H7AGuwEU6Ri9SjUsHrkuCT7jhnVpo3WUbir8BAdKWek=.24beadcd-1f13-4fa6-8ea8-8d3ab6bdc227@github.com>
Message-ID: <Aljnw9Wz_EyMzx5sAlFHclOMWyb3SZqzWAslGKEhvgM=.751b57d4-7948-42be-9da6-6aeca52e1f45@github.com>

On Mon, 26 Feb 2024 16:00:42 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> Adds Linux -fdebug-prefix-map'ing for SUPPORT_OUTPUTDIR and HOTSPOT_OUTPUTDIR when absolute paths are not allowed in the binaries, thus making the building of a JDK identically reproducible from different build directories.

This pull request has now been integrated.

Changeset: 3b90ddfe
Author:    Andrew Leonard <aleonard at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b90ddfefea36d9f7f08ff11cd0cb099aa32b02b
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8326685: Linux builds not reproducible if two builds configured in different build folders

Reviewed-by: ihse, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/18009

From lujaniuk at openjdk.org  Wed Feb 28 09:13:51 2024
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Wed, 28 Feb 2024 09:13:51 GMT
Subject: RFR: 8326831 Clarify test harness control variables in make help
In-Reply-To: <fFsKNZyBt9eMjW-6ku43H9fAbWj7WT2QXw4qNFd5Yzw=.c9055542-0c8d-47f4-b085-1f4f03bf9e1b@github.com>
References: <fFsKNZyBt9eMjW-6ku43H9fAbWj7WT2QXw4qNFd5Yzw=.c9055542-0c8d-47f4-b085-1f4f03bf9e1b@github.com>
Message-ID: <Lx7x4qZAzKGZ6A1faboI1ufrOBYNcoYSP5agInS6m3A=.83834f1e-9a0e-43b9-8374-5ec157911a1f@github.com>

On Tue, 27 Feb 2024 13:55:53 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> Clarifying text in `make help` output on how to list variables for e.g. JTREG='...'.

Thanks for the insight Erik!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18028#issuecomment-1968538692

From shade at openjdk.org  Wed Feb 28 09:17:46 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 28 Feb 2024 09:17:46 GMT
Subject: RFR: 8325881: Require minimum gcc version 10
In-Reply-To: <M0am_3VbHFaY6j5Ci1-DGeqfU7KOrTJeaymKvQ_EXyc=.c102258b-c728-4718-8061-1346e37e0276@github.com>
References: <M0am_3VbHFaY6j5Ci1-DGeqfU7KOrTJeaymKvQ_EXyc=.c102258b-c728-4718-8061-1346e37e0276@github.com>
Message-ID: <_Iia0aAYJfp0pl5RI6_myNxnce6-MCSMUYCHOMmjHiY=.d6d26ad6-bdc6-4c6b-896f-c373555dd281@github.com>

On Sat, 17 Feb 2024 08:28:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that updates the minimum supported version of gcc
> to be used for building OpenJDK from 6.0 to 10.0.
> 
> This permits enabling C++17 (JDK-8314488), though gcc 9.0 might suffice for
> that. A minimum of gcc 10 also obtains the primitives needed to support a
> work-alick for std::is_constant_evaluated (added in C++20). There are a bunch
> of improvements that would be enabled by that. Having it would also allow the
> elimination of a bit of a mess in the HotSpot assert macros that was needed to
> work around the lack of that feature (JDK-8303805). Either current or proposed
> minimum versions of other supported compilers also provide the needed
> primitives.
> 
> Testing: mach5 tier1 (uses gcc13.2 on gcc-based platforms)
> Locally (linux-x64) built and ran tier1 with gcc10.3.

I have no objections either. Let me check with our team if this breaks anything hard for our builds.

-------------

PR Review: https://git.openjdk.org/jdk/pull/17899#pullrequestreview-1905704494

From ihse at openjdk.org  Wed Feb 28 10:35:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Feb 2024 10:35:56 GMT
Subject: Integrated: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234
In-Reply-To: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
Message-ID: <AnciZWb0ft7evyF3yrQwUzMHaottyN5slfMiJQg2LzA=.88eca899-fb1d-4d4d-8c87-42edb71c3a79@github.com>

On Thu, 22 Feb 2024 16:28:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been integrated, it is possible to do some cleanup. The goal of [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change any behavior, even if that behavior seemed odd.
> 
> Now let's try to fix that. We can:
> 
> a) remove JNIEXPORT from c2v functions.
> b) make debug.cpp functions exported similarly on all platforms.
> c) remove JNIEXPORT from aarch64 asm debug function.
> 
> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.

This pull request has now been integrated.

Changeset: e6b3bda2
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e6b3bda2c30ea7932a8a20027e1ef2e805610f14
Stats:     35 lines in 4 files changed: 0 ins; 32 del; 3 mod

8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234

Reviewed-by: djelinski, jwaters, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/17967

From ihse at openjdk.org  Wed Feb 28 11:32:07 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Feb 2024 11:32:07 GMT
Subject: RFR: 8326947: Minimize MakeBase.gmk
Message-ID: <Zacq5On-Rnkhi-uUfL_TDbHbzDtqxe-SQ-eyL7673l8=.c40c1bc0-e490-471b-be98-a553cc51efcf@github.com>

This is part of a general "spring cleaning" of the build system, addressing old code that has bit-rotted, been subject to lava flow, or just had bad or smelly code that we've never gotten around to fix.

This particular patch tries to make MakeBase truly minimal; only including the core parts of the build system that all makefiles will need. This is now limited to essential functionality for named parameter functions, variable dependency, tool execution, logging and fixpath functionality. MakeBase still includes Utils.gmk and FileUtils.gmk, and thus "provides" this functionality as well. Separating these out as well will be the subject of a future patch.

-------------

Commit messages:
 - Whitespace fix
 - MakeBase.gmk should not include MakeIO.gmk anymore
 - MakeBase.gmk should not include CopyFiles.gmk anymore
 - Reorder BaseUtils.gmk to make more sense
 - Move some more functionality to BaseUtils.gmk
 - Create BaseUtils.gmk with the most basic stuff
 - Move all file stuff from Utils.gmk to FileUtils.gmk
 - Document the purpose of MakeBase
 - Move SOURCE_REVISION_TRACKER to where it is used.
 - Move timers to InitSupport where they are used
 - ... and 3 more: https://git.openjdk.org/jdk/compare/1ab6bd43...3c86bcfe

Changes: https://git.openjdk.org/jdk/pull/18041/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18041&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326947
  Stats: 1099 lines in 43 files changed: 607 ins; 480 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/18041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18041/head:pull/18041

PR: https://git.openjdk.org/jdk/pull/18041

From ihse at openjdk.org  Wed Feb 28 11:32:07 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Feb 2024 11:32:07 GMT
Subject: RFR: 8326947: Minimize MakeBase.gmk
In-Reply-To: <Zacq5On-Rnkhi-uUfL_TDbHbzDtqxe-SQ-eyL7673l8=.c40c1bc0-e490-471b-be98-a553cc51efcf@github.com>
References: <Zacq5On-Rnkhi-uUfL_TDbHbzDtqxe-SQ-eyL7673l8=.c40c1bc0-e490-471b-be98-a553cc51efcf@github.com>
Message-ID: <XrkJxvP9huixhz-3aO3N_KXMZ4tIO2pEFFb8tqzZsr4=.9e8478a6-31f3-439e-80b7-9a28907aae8f@github.com>

On Wed, 28 Feb 2024 11:24:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is part of a general "spring cleaning" of the build system, addressing old code that has bit-rotted, been subject to lava flow, or just had bad or smelly code that we've never gotten around to fix.
> 
> This particular patch tries to make MakeBase truly minimal; only including the core parts of the build system that all makefiles will need. This is now limited to essential functionality for named parameter functions, variable dependency, tool execution, logging and fixpath functionality. MakeBase still includes Utils.gmk and FileUtils.gmk, and thus "provides" this functionality as well. Separating these out as well will be the subject of a future patch.

I have verified using `COMPARE_BUILD` on windows-x64, linux-x64, linux-aarch64, macosx-x64 and macosx-aarch64 that there are no differences in the resulting build.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18041#issuecomment-1968778732

From gli at openjdk.org  Wed Feb 28 12:19:43 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 28 Feb 2024 12:19:43 GMT
Subject: RFR: 8326831 Clarify test harness control variables in make help
In-Reply-To: <fFsKNZyBt9eMjW-6ku43H9fAbWj7WT2QXw4qNFd5Yzw=.c9055542-0c8d-47f4-b085-1f4f03bf9e1b@github.com>
References: <fFsKNZyBt9eMjW-6ku43H9fAbWj7WT2QXw4qNFd5Yzw=.c9055542-0c8d-47f4-b085-1f4f03bf9e1b@github.com>
Message-ID: <P4q_Px93g3ifIWO-67yx9xiRwPFKp4kMrBgifvrv5UU=.c3b2305d-565d-4739-a961-4b854cc9838d@github.com>

On Tue, 27 Feb 2024 13:55:53 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> Clarifying text in `make help` output on how to list variables for e.g. JTREG='...'.

I use the command `make test-only JTREG=help` locally, the outputed message seems an error (shown below). Does it work as expected?


Building target 'test-only' in configuration 'linux-x86_64-server-fastdebug'
Valid keywords for JTREG:
RunTests.gmk:205: *** Re-run without 'help' to continue.  Stop.
JOBS TIMEOUT_FACTOR FAILURE_HANDLER_TIMEOUT TEST_MODE ASSERT VERBOSE RETAIN TEST_THREAD_FACTORY MAX_MEM RUN_PROBLEM_LISTS RETRY_COUNT REPEAT_COUNT MAX_OUTPUT REPORT OPTIONS JAVA_OPTIONS VM_OPTIONS KEYWORDS EXTRA_PROBLEM_LISTS LAUNCHER_OPTIONS.
gmake[2]: *** [make/Main.gmk:797: test] Error 2

ERROR: Build failed for target 'test-only' in configuration 'linux-x86_64-server-fastdebug' (exit code 2) 

No indication of failed target found.
HELP: Try searching the build log for '] Error'.
HELP: Run 'make doctor' to diagnose build problems.

make[1]: *** [/home/lgx/source/java/fast-jdk/make/Init.gmk:323: main] Error 2
make: *** [/home/lgx/source/java/fast-jdk/make/Init.gmk:189: test-only] Error 2


The location of the `RunTests.gmk:205: *** Re-run without 'help' to continue.  Stop.` is wrong. But it sometimes works good (Shown below).


Building target 'test-only' in configuration 'linux-x86_64-server-fastdebug'
Valid keywords for JTREG:
JOBS TIMEOUT_FACTOR FAILURE_HANDLER_TIMEOUT TEST_MODE ASSERT VERBOSE RETAIN TEST_THREAD_FACTORY MAX_MEM RUN_PROBLEM_LISTS RETRY_COUNT REPEAT_COUNT MAX_OUTPUT REPORT OPTIONS JAVA_OPTIONS VM_OPTIONS KEYWORDS EXTRA_PROBLEM_LISTS LAUNCHER_OPTIONS.
RunTests.gmk:205: *** Re-run without 'help' to continue.  Stop.
gmake[2]: *** [make/Main.gmk:797: test] Error 2

ERROR: Build failed for target 'test-only' in configuration 'linux-x86_64-server-fastdebug' (exit code 2) 

No indication of failed target found.
HELP: Try searching the build log for '] Error'.
HELP: Run 'make doctor' to diagnose build problems.

make[1]: *** [/home/lgx/source/java/fast-jdk/make/Init.gmk:323: main] Error 2
make: *** [/home/lgx/source/java/fast-jdk/make/Init.gmk:189: test-only] Error 2

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18028#issuecomment-1968862420

From ihse at openjdk.org  Wed Feb 28 12:32:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Feb 2024 12:32:00 GMT
Subject: RFR: 8326953: Possible race in creation of win-exports.def
Message-ID: <GLQrDzGdwdCm-MIbvU68a4Mtu-z1N83YR48IkxbbdK8=.1d0a4333-4057-4a9e-957d-e982bc6e5d8f@github.com>

We have seen a build failure along the lines of:

 /usr/bin/mv: cannot move '.../build/windows-x64-open-debug/hotspot/variant-server/libjvm/win-exports.def.tmp' to '.../build/windows-x64-open-debug/hotspot/variant-server/libjvm/win-exports.def': No such file or directory

on Windows.

My guess is that this is a race between creating the win-export.def file for the gtest jvm and the product jvm.

-------------

Commit messages:
 - 8326953: Possible race in creation of win-exports.def

Changes: https://git.openjdk.org/jdk/pull/18043/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18043&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326953
  Stats: 23 lines in 2 files changed: 15 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/18043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18043/head:pull/18043

PR: https://git.openjdk.org/jdk/pull/18043

From ihse at openjdk.org  Wed Feb 28 12:32:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Feb 2024 12:32:00 GMT
Subject: RFR: 8326953: Possible race in creation of win-exports.def
In-Reply-To: <GLQrDzGdwdCm-MIbvU68a4Mtu-z1N83YR48IkxbbdK8=.1d0a4333-4057-4a9e-957d-e982bc6e5d8f@github.com>
References: <GLQrDzGdwdCm-MIbvU68a4Mtu-z1N83YR48IkxbbdK8=.1d0a4333-4057-4a9e-957d-e982bc6e5d8f@github.com>
Message-ID: <_-nKbVpPWqpfmidEqPgdBOuzzyKg_nvam1f1nRr4jQk=.0cbaf408-64ee-46df-9049-b36c1f32ca93@github.com>

On Wed, 28 Feb 2024 12:26:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We have seen a build failure along the lines of:
> 
>  /usr/bin/mv: cannot move '.../build/windows-x64-open-debug/hotspot/variant-server/libjvm/win-exports.def.tmp' to '.../build/windows-x64-open-debug/hotspot/variant-server/libjvm/win-exports.def': No such file or directory
> 
> on Windows.
> 
> My guess is that this is a race between creating the win-export.def file for the gtest jvm and the product jvm.

I am not 100% confident that this actually identifies the problem, nor that it really provides a fix, nor that this even is the best way to achieve this even if it should be the correct fix.

Intermittent build problems are the worst. :-( They are hard to reproduce or know for sure if they are gone, but when they occur they cause a havoc in the CI pipeline. Hence this opportunistic fix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18043#issuecomment-1968881256

From erikj at openjdk.org  Wed Feb 28 14:05:43 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 28 Feb 2024 14:05:43 GMT
Subject: RFR: 8326947: Minimize MakeBase.gmk
In-Reply-To: <Zacq5On-Rnkhi-uUfL_TDbHbzDtqxe-SQ-eyL7673l8=.c40c1bc0-e490-471b-be98-a553cc51efcf@github.com>
References: <Zacq5On-Rnkhi-uUfL_TDbHbzDtqxe-SQ-eyL7673l8=.c40c1bc0-e490-471b-be98-a553cc51efcf@github.com>
Message-ID: <7kJwZpBaxa-3k2t6n9bXNgvgCq07XuK-9lV2YVnDTPE=.5b00e9ca-a3b5-43ff-bc18-1740233e149a@github.com>

On Wed, 28 Feb 2024 11:24:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is part of a general "spring cleaning" of the build system, addressing old code that has bit-rotted, been subject to lava flow, or just had bad or smelly code that we've never gotten around to fix.
> 
> This particular patch tries to make MakeBase truly minimal; only including the core parts of the build system that all makefiles will need. This is now limited to essential functionality for named parameter functions, variable dependency, tool execution, logging and fixpath functionality. MakeBase still includes Utils.gmk and FileUtils.gmk, and thus "provides" this functionality as well. Separating these out as well will be the subject of a future patch.

The distinction between Utils.gmk and BaseUtils.gmk seems a bit arbitrary at a glance, especially since both are still included from MakeBase.gmk. How would you know in which file to add a new macro?

make/ReleaseFile.gmk line 40:

> 38: # A file containing a way to uniquely identify the source code revision that
> 39: # the build was created from
> 40: SOURCE_REVISION_TRACKER := $(SUPPORT_OUTPUTDIR)/src-rev/source-revision-tracker

Other file locations that need to be shared between different makefiles are defined in spec.gmk.in. Not ideal either, but perhaps better for now than having to define the value twice?

-------------

PR Review: https://git.openjdk.org/jdk/pull/18041#pullrequestreview-1906328783
PR Review Comment: https://git.openjdk.org/jdk/pull/18041#discussion_r1506000674

From jwaters at openjdk.org  Wed Feb 28 14:29:54 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 28 Feb 2024 14:29:54 GMT
Subject: RFR: 8326953: Possible race in creation of win-exports.def
In-Reply-To: <GLQrDzGdwdCm-MIbvU68a4Mtu-z1N83YR48IkxbbdK8=.1d0a4333-4057-4a9e-957d-e982bc6e5d8f@github.com>
References: <GLQrDzGdwdCm-MIbvU68a4Mtu-z1N83YR48IkxbbdK8=.1d0a4333-4057-4a9e-957d-e982bc6e5d8f@github.com>
Message-ID: <bgmxIPqNcd-vKQRkLbFFhq8LN-Sj1o_m2WbJyiji8WY=.2bc4c003-6139-48c9-8ac5-f2f36dd5427f@github.com>

On Wed, 28 Feb 2024 12:26:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We have seen a build failure along the lines of:
> 
>  /usr/bin/mv: cannot move '.../build/windows-x64-open-debug/hotspot/variant-server/libjvm/win-exports.def.tmp' to '.../build/windows-x64-open-debug/hotspot/variant-server/libjvm/win-exports.def': No such file or directory
> 
> on Windows.
> 
> My guess is that this is a race between creating the win-export.def file for the gtest jvm and the product jvm.

Marked as reviewed by jwaters (Committer).

Marked as reviewed by jwaters (Committer).

make/hotspot/lib/CompileJvm.gmk line 151:

> 149:   WIN_EXPORT_FILE := $(JVM_OUTPUTDIR)/win-exports.def
> 150: 
> 151:   JVM_LDFLAGS_NO_GTEST += -def:$(WIN_EXPORT_FILE)

Can't this just be named EXPORT_FILE_FLAG or something along those lines? LDFLAGS_NO_GTEST seems a bit strange

-------------

PR Review: https://git.openjdk.org/jdk/pull/18043#pullrequestreview-1906237581
PR Review: https://git.openjdk.org/jdk/pull/18043#pullrequestreview-1906240849
PR Review Comment: https://git.openjdk.org/jdk/pull/18043#discussion_r1505943413

From ihse at openjdk.org  Wed Feb 28 14:29:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Feb 2024 14:29:55 GMT
Subject: RFR: 8326953: Possible race in creation of win-exports.def
In-Reply-To: <bgmxIPqNcd-vKQRkLbFFhq8LN-Sj1o_m2WbJyiji8WY=.2bc4c003-6139-48c9-8ac5-f2f36dd5427f@github.com>
References: <GLQrDzGdwdCm-MIbvU68a4Mtu-z1N83YR48IkxbbdK8=.1d0a4333-4057-4a9e-957d-e982bc6e5d8f@github.com>
 <bgmxIPqNcd-vKQRkLbFFhq8LN-Sj1o_m2WbJyiji8WY=.2bc4c003-6139-48c9-8ac5-f2f36dd5427f@github.com>
Message-ID: <dhIz8FYwA7JEDNtqtIuEmEWgLf-On9oRySbITfKF9k4=.a6b8f372-b01a-4a37-8248-b3e02af6cc8f@github.com>

On Wed, 28 Feb 2024 13:12:14 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> We have seen a build failure along the lines of:
>> 
>>  /usr/bin/mv: cannot move '.../build/windows-x64-open-debug/hotspot/variant-server/libjvm/win-exports.def.tmp' to '.../build/windows-x64-open-debug/hotspot/variant-server/libjvm/win-exports.def': No such file or directory
>> 
>> on Windows.
>> 
>> My guess is that this is a race between creating the win-export.def file for the gtest jvm and the product jvm.
>
> make/hotspot/lib/CompileJvm.gmk line 151:
> 
>> 149:   WIN_EXPORT_FILE := $(JVM_OUTPUTDIR)/win-exports.def
>> 150: 
>> 151:   JVM_LDFLAGS_NO_GTEST += -def:$(WIN_EXPORT_FILE)
> 
> Can't this just be named EXPORT_FILE_FLAG or something along those lines? LDFLAGS_NO_GTEST seems a bit strange

The thought was to clearly communicate why this must not be included in the gtest LDFLAGS; otherwise they must be exactly identical.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18043#discussion_r1506012594

From ihse at openjdk.org  Wed Feb 28 14:29:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Feb 2024 14:29:55 GMT
Subject: RFR: 8326953: Possible race in creation of win-exports.def
In-Reply-To: <GLQrDzGdwdCm-MIbvU68a4Mtu-z1N83YR48IkxbbdK8=.1d0a4333-4057-4a9e-957d-e982bc6e5d8f@github.com>
References: <GLQrDzGdwdCm-MIbvU68a4Mtu-z1N83YR48IkxbbdK8=.1d0a4333-4057-4a9e-957d-e982bc6e5d8f@github.com>
Message-ID: <1_8G_AoQoFp8yRREC70y0Mtr98633Pp_dxMV6z-eBU0=.9e2dac68-3bd8-4377-8cd8-f561d4189a7f@github.com>

On Wed, 28 Feb 2024 12:26:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We have seen a build failure along the lines of:
> 
>  /usr/bin/mv: cannot move '.../build/windows-x64-open-debug/hotspot/variant-server/libjvm/win-exports.def.tmp' to '.../build/windows-x64-open-debug/hotspot/variant-server/libjvm/win-exports.def': No such file or directory
> 
> on Windows.
> 
> My guess is that this is a race between creating the win-export.def file for the gtest jvm and the product jvm.

This did not help. Either it is fully misdirected, or it is not enough. It seems reasonable that the gtest jvm should depend on the gtest ALL_OBJ; I think this was the case for the old mapfiles (even though the incestuous relationship between the proper jvm and the gtest jvm makes it hard to reason about them), so if that is a correct assumption, this would fix a potential regression.

My next guess is that this is correlated to `hotspot-static-libs`. I have not seen the failure on GHA, but only on the Oracle CI, where we build with static libs. That seems more reasonable to produce a race; the static libs functionality appeared while I was away, but I think it just runs the entire CompileJvm.gmk once more with STATIC_LIBS set to true, with no coordination wrt the normal build, so it can very well end up executing the same rule twice.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18043#issuecomment-1969046252

From lujaniuk at openjdk.org  Wed Feb 28 14:43:43 2024
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Wed, 28 Feb 2024 14:43:43 GMT
Subject: RFR: 8326831 Clarify test harness control variables in make help
In-Reply-To: <fFsKNZyBt9eMjW-6ku43H9fAbWj7WT2QXw4qNFd5Yzw=.c9055542-0c8d-47f4-b085-1f4f03bf9e1b@github.com>
References: <fFsKNZyBt9eMjW-6ku43H9fAbWj7WT2QXw4qNFd5Yzw=.c9055542-0c8d-47f4-b085-1f4f03bf9e1b@github.com>
Message-ID: <pcUJ8rjFnrQclXbjbPHcZulHCf7h7ML81-hvd_5Aw9w=.b4cf72fe-837c-4445-b9f0-8536e186f31e@github.com>

On Tue, 27 Feb 2024 13:55:53 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> Clarifying text in `make help` output on how to list variables for e.g. JTREG='...'.

It's interesting that the order of those two lines can change. I have no idea what causes it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18028#issuecomment-1969132107

From hannesw at openjdk.org  Wed Feb 28 14:49:06 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 28 Feb 2024 14:49:06 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v43]
In-Reply-To: <gwFu9c4-Y_zksoJ1Tu4eJ-rJm0DEf2EYCZj2OVVIrUE=.9e9533b9-751e-4dfd-890e-4dc48c3399ea@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <gwFu9c4-Y_zksoJ1Tu4eJ-rJm0DEf2EYCZj2OVVIrUE=.9e9533b9-751e-4dfd-890e-4dc48c3399ea@github.com>
Message-ID: <cX4hEqIEUFIhx-HUjtmy5yS_-vThVYQLI7fSzsrA7Rg=.5eebc6f6-bea6-477d-a900-069afb732ab5@github.com>

On Fri, 23 Feb 2024 22:27:43 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor most of TestMarkdown.java into separate tests, grouped by functionality

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1380:

> 1378: 
> 1379:         var useMarkdown = trees.stream().anyMatch(t -> t.getKind() == Kind.MARKDOWN);
> 1380:         var markdownHandler = useMarkdown ? new MarkdownHandler(element) : null;

The `MarkdownHandler` and `HeadingNodeRenderer` classes must become aware of the current `TagletWriter.Context`.  That's because headings and other block tags should only be generated if `TagletWriter.Context.isFirstSentence` is `false`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1506084275

From ihse at openjdk.org  Wed Feb 28 14:53:13 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Feb 2024 14:53:13 GMT
Subject: RFR: 8326953: Possible race in creation of win-exports.def [v2]
In-Reply-To: <GLQrDzGdwdCm-MIbvU68a4Mtu-z1N83YR48IkxbbdK8=.1d0a4333-4057-4a9e-957d-e982bc6e5d8f@github.com>
References: <GLQrDzGdwdCm-MIbvU68a4Mtu-z1N83YR48IkxbbdK8=.1d0a4333-4057-4a9e-957d-e982bc6e5d8f@github.com>
Message-ID: <lIh4wp6TEq0LVhP8Jk1_RCUQgWCRmPScINcBOAF41Cg=.eddb9a75-a66b-4d98-aaae-77d98a7987ee@github.com>

> We have seen a build failure along the lines of:
> 
>  /usr/bin/mv: cannot move '.../build/windows-x64-open-debug/hotspot/variant-server/libjvm/win-exports.def.tmp' to '.../build/windows-x64-open-debug/hotspot/variant-server/libjvm/win-exports.def': No such file or directory
> 
> on Windows.
> 
> My guess is that this is a race between creating the win-export.def file for the gtest jvm and the product jvm.

Magnus Ihse Bursie has updated the pull request incrementally with four additional commits since the last revision:

 - Use $(BUILD_LIBJVM_OBJECT_DIR) to work properly with static libs
 - Better attempt with keeping the win-exports file for static libs
 - Disable win-export.def on static libs
 - Make it proper $(eval $(call ...))

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18043/files
  - new: https://git.openjdk.org/jdk/pull/18043/files/2fa57610..f574d063

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18043&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18043&range=00-01

  Stats: 21 lines in 2 files changed: 7 ins; 1 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/18043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18043/head:pull/18043

PR: https://git.openjdk.org/jdk/pull/18043

From ihse at openjdk.org  Wed Feb 28 14:56:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Feb 2024 14:56:54 GMT
Subject: RFR: 8326947: Minimize MakeBase.gmk
In-Reply-To: <Zacq5On-Rnkhi-uUfL_TDbHbzDtqxe-SQ-eyL7673l8=.c40c1bc0-e490-471b-be98-a553cc51efcf@github.com>
References: <Zacq5On-Rnkhi-uUfL_TDbHbzDtqxe-SQ-eyL7673l8=.c40c1bc0-e490-471b-be98-a553cc51efcf@github.com>
Message-ID: <hVivVx20eV1KSl7zJw-mXfU3APXxDZ7CDoISSqAu3nU=.886526bc-9cef-47de-bc4e-91d763b01bab@github.com>

On Wed, 28 Feb 2024 11:24:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is part of a general "spring cleaning" of the build system, addressing old code that has bit-rotted, been subject to lava flow, or just had bad or smelly code that we've never gotten around to fix.
> 
> This particular patch tries to make MakeBase truly minimal; only including the core parts of the build system that all makefiles will need. This is now limited to essential functionality for named parameter functions, variable dependency, tool execution, logging and fixpath functionality. MakeBase still includes Utils.gmk and FileUtils.gmk, and thus "provides" this functionality as well. Separating these out as well will be the subject of a future patch.

The distinction was that BaseUtils.gmk are needed for MakeBase.gmk, Utils.gmk and FileUtils.gmk, but these three are not dependent on anything else. My initial goal was to stop having MakeBase.gmk include Utils.gmk as well, but it required a lot of extra includes and I did not want to do that in this PR. (Maybe it is not a good idea at all; I have not yet really decided).

I agree that the split seems a bit arbitrary. Maybe it was a bad idea. Let me ponder it for a while.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18041#issuecomment-1969158791

From erikj at openjdk.org  Wed Feb 28 15:07:53 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 28 Feb 2024 15:07:53 GMT
Subject: RFR: 8326953: Possible race in creation of win-exports.def [v2]
In-Reply-To: <lIh4wp6TEq0LVhP8Jk1_RCUQgWCRmPScINcBOAF41Cg=.eddb9a75-a66b-4d98-aaae-77d98a7987ee@github.com>
References: <GLQrDzGdwdCm-MIbvU68a4Mtu-z1N83YR48IkxbbdK8=.1d0a4333-4057-4a9e-957d-e982bc6e5d8f@github.com>
 <lIh4wp6TEq0LVhP8Jk1_RCUQgWCRmPScINcBOAF41Cg=.eddb9a75-a66b-4d98-aaae-77d98a7987ee@github.com>
Message-ID: <48KScoMvJa9u-bz-DLhPLODmVgR2inDlh13CgwVoZ_s=.32c7c8ac-ccee-4c39-acde-abb7effcfdd6@github.com>

On Wed, 28 Feb 2024 14:53:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> We have seen a build failure along the lines of:
>> 
>>  /usr/bin/mv: cannot move '.../build/windows-x64-open-debug/hotspot/variant-server/libjvm/win-exports.def.tmp' to '.../build/windows-x64-open-debug/hotspot/variant-server/libjvm/win-exports.def': No such file or directory
>> 
>> on Windows.
>> 
>> My guess is that this is a race between creating the win-export.def file for the gtest jvm and the product jvm.
>
> Magnus Ihse Bursie has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Use $(BUILD_LIBJVM_OBJECT_DIR) to work properly with static libs
>  - Better attempt with keeping the win-exports file for static libs
>  - Disable win-export.def on static libs
>  - Make it proper $(eval $(call ...))

The race was just between the dynamic and static build of libjvm. I don't think we need or should create a separate defs file for gtest, that's just unnecessary complexity.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18043#pullrequestreview-1906513460

From jwaters at openjdk.org  Wed Feb 28 15:12:02 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 28 Feb 2024 15:12:02 GMT
Subject: RFR: 8326964: Remove Eclipse Shared Workspaces
Message-ID: <rOJhLEi2OVRreCl6maVUQXAUG5dF1g_ad2N-_rT2Myk=.8cc1d080-544c-4ced-956c-e62939da1e6a@github.com>

WIP

-------------

Commit messages:
 - 8326964

Changes: https://git.openjdk.org/jdk/pull/18046/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18046&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326964
  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18046.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18046/head:pull/18046

PR: https://git.openjdk.org/jdk/pull/18046

From jwaters at openjdk.org  Wed Feb 28 15:19:58 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 28 Feb 2024 15:19:58 GMT
Subject: RFR: 8326964: Remove Eclipse Shared Workspaces [v2]
In-Reply-To: <rOJhLEi2OVRreCl6maVUQXAUG5dF1g_ad2N-_rT2Myk=.8cc1d080-544c-4ced-956c-e62939da1e6a@github.com>
References: <rOJhLEi2OVRreCl6maVUQXAUG5dF1g_ad2N-_rT2Myk=.8cc1d080-544c-4ced-956c-e62939da1e6a@github.com>
Message-ID: <TgAWzSJQjhuVkzSxqd3VYKrHdpArOO4LvZMU3nwbaws=.25893aac-970c-480c-9339-776f4862a7c0@github.com>

> WIP

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Remove shared targets

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18046/files
  - new: https://git.openjdk.org/jdk/pull/18046/files/aefff3e8..0d29a355

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18046&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18046&range=00-01

  Stats: 20 lines in 1 file changed: 0 ins; 20 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18046.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18046/head:pull/18046

PR: https://git.openjdk.org/jdk/pull/18046

From hannesw at openjdk.org  Wed Feb 28 15:28:04 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 28 Feb 2024 15:28:04 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v43]
In-Reply-To: <gwFu9c4-Y_zksoJ1Tu4eJ-rJm0DEf2EYCZj2OVVIrUE=.9e9533b9-751e-4dfd-890e-4dc48c3399ea@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <gwFu9c4-Y_zksoJ1Tu4eJ-rJm0DEf2EYCZj2OVVIrUE=.9e9533b9-751e-4dfd-890e-4dc48c3399ea@github.com>
Message-ID: <-Nw3xUoSRDHXjRzleG1SaaZjtRcGWAS9Oi9pdhX_GfQ=.63b2610a-f733-4421-a17b-21dd26accd51@github.com>

On Fri, 23 Feb 2024 22:27:43 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor most of TestMarkdown.java into separate tests, grouped by functionality

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1733:

> 1731:             return false;
> 1732:         }
> 1733: 

The two methods below and some other methods in this class have too much indentation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1506145051

From hannesw at openjdk.org  Wed Feb 28 15:58:02 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 28 Feb 2024 15:58:02 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v43]
In-Reply-To: <gwFu9c4-Y_zksoJ1Tu4eJ-rJm0DEf2EYCZj2OVVIrUE=.9e9533b9-751e-4dfd-890e-4dc48c3399ea@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <gwFu9c4-Y_zksoJ1Tu4eJ-rJm0DEf2EYCZj2OVVIrUE=.9e9533b9-751e-4dfd-890e-4dc48c3399ea@github.com>
Message-ID: <x_vvLqu7UsQHMlQCynTzD0ddhHvg2glkHXblCujUCrQ=.62b4b088-e12c-45fc-b974-bd83812d0c9e@github.com>

On Fri, 23 Feb 2024 22:27:43 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor most of TestMarkdown.java into separate tests, grouped by functionality

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1601:

> 1599:                         : eKind != ElementKind.OTHER ? 1   // module, package, class, interface
> 1600:                         : 0; // doc file
> 1601:                 return "h" + Math.min(heading.getLevel() + offset, 6);

I really like that we adapt the heading level to the current context, but I notice that the code kind of expects `h1` headings to be used everywhere, and "punishes" use of contextually correct headings by generating smaller headings. Maybe it would be more educational to only adjust the level if it needs adjusting?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1506190847

From ihse at openjdk.org  Wed Feb 28 17:06:17 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Feb 2024 17:06:17 GMT
Subject: RFR: 8326953: Possible race in creation of win-exports.def [v3]
In-Reply-To: <GLQrDzGdwdCm-MIbvU68a4Mtu-z1N83YR48IkxbbdK8=.1d0a4333-4057-4a9e-957d-e982bc6e5d8f@github.com>
References: <GLQrDzGdwdCm-MIbvU68a4Mtu-z1N83YR48IkxbbdK8=.1d0a4333-4057-4a9e-957d-e982bc6e5d8f@github.com>
Message-ID: <Y6v121N9Z5a6T2fMrBa0eypFDR_5wPzoPbqgIdcXH3Y=.83ca2c49-d2b8-465b-ba24-63ea411455ae@github.com>

> We have seen a build failure along the lines of:
> 
>  /usr/bin/mv: cannot move '.../build/windows-x64-open-debug/hotspot/variant-server/libjvm/win-exports.def.tmp' to '.../build/windows-x64-open-debug/hotspot/variant-server/libjvm/win-exports.def': No such file or directory
> 
> on Windows.
> 
> My guess is that this is a race between creating the win-export.def file for the gtest jvm and the product jvm.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Also restore newline
 - Roll back gtest changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18043/files
  - new: https://git.openjdk.org/jdk/pull/18043/files/f574d063..18e03322

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18043&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18043&range=01-02

  Stats: 33 lines in 2 files changed: 1 ins; 18 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/18043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18043/head:pull/18043

PR: https://git.openjdk.org/jdk/pull/18043

From jjg at openjdk.org  Wed Feb 28 17:15:07 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 28 Feb 2024 17:15:07 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v43]
In-Reply-To: <x_vvLqu7UsQHMlQCynTzD0ddhHvg2glkHXblCujUCrQ=.62b4b088-e12c-45fc-b974-bd83812d0c9e@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <gwFu9c4-Y_zksoJ1Tu4eJ-rJm0DEf2EYCZj2OVVIrUE=.9e9533b9-751e-4dfd-890e-4dc48c3399ea@github.com>
 <x_vvLqu7UsQHMlQCynTzD0ddhHvg2glkHXblCujUCrQ=.62b4b088-e12c-45fc-b974-bd83812d0c9e@github.com>
Message-ID: <k4yPloMAtTmkzn54pzlVhTpBRq6dVGJxmFg1YVgAQVk=.5089ccc6-c675-4933-a8e8-633d6162984d@github.com>

On Wed, 28 Feb 2024 15:54:38 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor most of TestMarkdown.java into separate tests, grouped by functionality
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1601:
> 
>> 1599:                         : eKind != ElementKind.OTHER ? 1   // module, package, class, interface
>> 1600:                         : 0; // doc file
>> 1601:                 return "h" + Math.min(heading.getLevel() + offset, 6);
> 
> I really like that we adapt the heading level to the current context, but I notice that the code kind of expects `h1` headings to be used everywhere, and "punishes" use of contextually correct headings by generating smaller headings. Maybe it would be more educational to only adjust the level if it needs adjusting?

Setext headings only come in "level 1" and "level 2" flavors.
And, at the time the renderer sees the AST, the difference between ATX and setext headings is erased. They're just "headings".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1506307115

From erikj at openjdk.org  Wed Feb 28 17:46:43 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 28 Feb 2024 17:46:43 GMT
Subject: RFR: 8326953: Race in creation of win-exports.def with static-libs
 [v3]
In-Reply-To: <Y6v121N9Z5a6T2fMrBa0eypFDR_5wPzoPbqgIdcXH3Y=.83ca2c49-d2b8-465b-ba24-63ea411455ae@github.com>
References: <GLQrDzGdwdCm-MIbvU68a4Mtu-z1N83YR48IkxbbdK8=.1d0a4333-4057-4a9e-957d-e982bc6e5d8f@github.com>
 <Y6v121N9Z5a6T2fMrBa0eypFDR_5wPzoPbqgIdcXH3Y=.83ca2c49-d2b8-465b-ba24-63ea411455ae@github.com>
Message-ID: <nDVkLAGjlX6KohSImgNResIlNUQyYfXOh3-C-0rqN3I=.7c6f58a5-b15c-4dc4-857b-536ecb5b7e23@github.com>

On Wed, 28 Feb 2024 17:06:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> We have seen a build failure along the lines of:
>> 
>>  /usr/bin/mv: cannot move '.../build/windows-x64-open-debug/hotspot/variant-server/libjvm/win-exports.def.tmp' to '.../build/windows-x64-open-debug/hotspot/variant-server/libjvm/win-exports.def': No such file or directory
>> 
>> on Windows.
>> 
>> My guess is that this is a race between creating the win-export.def file for the gtest jvm and the product jvm.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Also restore newline
>  - Roll back gtest changes

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18043#pullrequestreview-1906887941

From ihse at openjdk.org  Wed Feb 28 17:46:43 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Feb 2024 17:46:43 GMT
Subject: RFR: 8326953: Race in creation of win-exports.def with static-libs
 [v3]
In-Reply-To: <Y6v121N9Z5a6T2fMrBa0eypFDR_5wPzoPbqgIdcXH3Y=.83ca2c49-d2b8-465b-ba24-63ea411455ae@github.com>
References: <GLQrDzGdwdCm-MIbvU68a4Mtu-z1N83YR48IkxbbdK8=.1d0a4333-4057-4a9e-957d-e982bc6e5d8f@github.com>
 <Y6v121N9Z5a6T2fMrBa0eypFDR_5wPzoPbqgIdcXH3Y=.83ca2c49-d2b8-465b-ba24-63ea411455ae@github.com>
Message-ID: <ZBrkmyFABkpokKDzVrf2Wn0jhwLTcOII_dDspudHZaE=.0ad1430f-503e-41ae-9d9b-5135345f56db@github.com>

On Wed, 28 Feb 2024 17:06:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> We have seen a build failure along the lines of:
>> 
>>  /usr/bin/mv: cannot move '.../build/windows-x64-open-debug/hotspot/variant-server/libjvm/win-exports.def.tmp' to '.../build/windows-x64-open-debug/hotspot/variant-server/libjvm/win-exports.def': No such file or directory
>> 
>> on Windows.
>> 
>> My guess is that this is a race between creating the win-export.def file for the gtest jvm and the product jvm.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Also restore newline
>  - Roll back gtest changes

This seem to work fine now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18043#issuecomment-1969516930

From shade at openjdk.org  Wed Feb 28 18:03:52 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 28 Feb 2024 18:03:52 GMT
Subject: RFR: 8325881: Require minimum gcc version 10
In-Reply-To: <M0am_3VbHFaY6j5Ci1-DGeqfU7KOrTJeaymKvQ_EXyc=.c102258b-c728-4718-8061-1346e37e0276@github.com>
References: <M0am_3VbHFaY6j5Ci1-DGeqfU7KOrTJeaymKvQ_EXyc=.c102258b-c728-4718-8061-1346e37e0276@github.com>
Message-ID: <q-dXws5InEfokFDbKZ5aKoUTe4ha4IoleG7pv1Wotb0=.727af5f5-8218-4524-8e98-60a52c3fad7d@github.com>

On Sat, 17 Feb 2024 08:28:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that updates the minimum supported version of gcc
> to be used for building OpenJDK from 6.0 to 10.0.
> 
> This permits enabling C++17 (JDK-8314488), though gcc 9.0 might suffice for
> that. A minimum of gcc 10 also obtains the primitives needed to support a
> work-alick for std::is_constant_evaluated (added in C++20). There are a bunch
> of improvements that would be enabled by that. Having it would also allow the
> elimination of a bit of a mess in the HotSpot assert macros that was needed to
> work around the lack of that feature (JDK-8303805). Either current or proposed
> minimum versions of other supported compilers also provide the needed
> primitives.
> 
> Testing: mach5 tier1 (uses gcc13.2 on gcc-based platforms)
> Locally (linux-x64) built and ran tier1 with gcc10.3.

No problem from our side, thanks!

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17899#pullrequestreview-1906924932

From erikj at openjdk.org  Wed Feb 28 19:34:01 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 28 Feb 2024 19:34:01 GMT
Subject: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal
 JDK binaries
Message-ID: <NdOa4jatnFRBaRrDrrCQU3v-7N4fGRfA8tdRRXuJthM=.02edd694-8eb2-4979-ab31-9b34b862c6db@github.com>

Executables and dynamic libraries on Linux can encode a search path that the dynamic linker will use when looking up library dependencies, generally referred to as an "rpath". In the JDK we use this with the $ORIGIN feature to set search paths relative to the location of the binary itself. Typically executables in the bin/ directory have the rpath "$ORIGIN/../lib" to find libjli.so. Most of the libraries in lib/ have rpath set to just "$ORIGIN" to find each other.

There are two different types of such rpaths, RPATH and RUNPATH. The former is the earlier incantation but RUNPATH has been around since about 2003 and has been default in prominent Linux distros for a long time, and now also seems to be default in the linker directly from binutils. The toolchain used by Oracle defaulted to RPATH until at least JDK 11, but since then with some toolchain upgrade, the default was flipped to RUNPATH.

The main (relevant in this case) difference between the two is that RPATH is considered before the LD_LIBRARY_PATH environment variable, while RUNPATH is only considered after LD_LIBRARY_PATH. For libraries that are part of a Linux distribution, letting users, or the system, control and override builtin rpaths with LD_LIBRARY_PATH seems like a reasonable thing to prefer. However, for the JDK, there really is no usecase for having an externally configured LD_LIBRARY_PATH potentially getting in the way of the JDK libraries finding each other correctly. If a user environment sets LD_LIBRARY_PATH, and there is a library in that path with the same name as a JDK library (e.g. libnet.so or some other generically named library) that external library will be loaded instead of the JDK internal library and that is basically guaranteed to break the JDK. There is no supported usecase that I can think of for injecting other versions of such libraries in a JDK distribution.

I propose that we explicitly configure the JDK build to set RPATH instead of RUNPATH for Linux binaries. This is done with the linker flag "--disable-new-dtags".

-------------

Commit messages:
 - JDK-8326891

Changes: https://git.openjdk.org/jdk/pull/18050/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18050&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326891
  Stats: 9 lines in 2 files changed: 3 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18050.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18050/head:pull/18050

PR: https://git.openjdk.org/jdk/pull/18050

From dholmes at openjdk.org  Wed Feb 28 21:39:44 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 28 Feb 2024 21:39:44 GMT
Subject: RFR: 8326953: Race in creation of win-exports.def with static-libs
 [v3]
In-Reply-To: <Y6v121N9Z5a6T2fMrBa0eypFDR_5wPzoPbqgIdcXH3Y=.83ca2c49-d2b8-465b-ba24-63ea411455ae@github.com>
References: <GLQrDzGdwdCm-MIbvU68a4Mtu-z1N83YR48IkxbbdK8=.1d0a4333-4057-4a9e-957d-e982bc6e5d8f@github.com>
 <Y6v121N9Z5a6T2fMrBa0eypFDR_5wPzoPbqgIdcXH3Y=.83ca2c49-d2b8-465b-ba24-63ea411455ae@github.com>
Message-ID: <SHzwSdAiA2Rz9OjNv1vb9ipPBiVt8Ao2ReJ2I3uePc4=.222af5c0-2d72-42e7-a8c9-b477141f967e@github.com>

On Wed, 28 Feb 2024 17:06:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> We have seen a build failure along the lines of:
>> 
>>  /usr/bin/mv: cannot move '.../build/windows-x64-open-debug/hotspot/variant-server/libjvm/win-exports.def.tmp' to '.../build/windows-x64-open-debug/hotspot/variant-server/libjvm/win-exports.def': No such file or directory
>> 
>> on Windows.
>> 
>> My guess is that this is a race between creating the win-export.def file for the gtest jvm and the product jvm.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Also restore newline
>  - Roll back gtest changes

Seems reasonable. Thanks for jumping on this so quick!

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18043#pullrequestreview-1907474544

From ihse at openjdk.org  Wed Feb 28 22:50:48 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Feb 2024 22:50:48 GMT
Subject: Integrated: 8326953: Race in creation of win-exports.def with
 static-libs
In-Reply-To: <GLQrDzGdwdCm-MIbvU68a4Mtu-z1N83YR48IkxbbdK8=.1d0a4333-4057-4a9e-957d-e982bc6e5d8f@github.com>
References: <GLQrDzGdwdCm-MIbvU68a4Mtu-z1N83YR48IkxbbdK8=.1d0a4333-4057-4a9e-957d-e982bc6e5d8f@github.com>
Message-ID: <BOh11g2vEWzMq-MZTLBZeSCuoys0ODiUbziichnUaGM=.5099a8e4-cbe5-4d3d-b2f5-5b57b207f078@github.com>

On Wed, 28 Feb 2024 12:26:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We have seen a build failure along the lines of:
> 
>  /usr/bin/mv: cannot move '.../build/windows-x64-open-debug/hotspot/variant-server/libjvm/win-exports.def.tmp' to '.../build/windows-x64-open-debug/hotspot/variant-server/libjvm/win-exports.def': No such file or directory
> 
> on Windows.
> 
> My guess is that this is a race between creating the win-export.def file for the gtest jvm and the product jvm.

This pull request has now been integrated.

Changeset: 5fa2bdc6
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5fa2bdc6c76d8f70c8d8582889e96b9c0d2b86b5
Stats:     10 lines in 1 file changed: 5 ins; 2 del; 3 mod

8326953: Race in creation of win-exports.def with static-libs

Reviewed-by: jwaters, erikj, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/18043

From gli at openjdk.org  Thu Feb 29 03:26:54 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 29 Feb 2024 03:26:54 GMT
Subject: RFR: 8326831 Clarify test harness control variables in make help
In-Reply-To: <fFsKNZyBt9eMjW-6ku43H9fAbWj7WT2QXw4qNFd5Yzw=.c9055542-0c8d-47f4-b085-1f4f03bf9e1b@github.com>
References: <fFsKNZyBt9eMjW-6ku43H9fAbWj7WT2QXw4qNFd5Yzw=.c9055542-0c8d-47f4-b085-1f4f03bf9e1b@github.com>
Message-ID: <a97Fkux0FG4PrFpaUE4degnBnXnywqixtODdcZRWFNQ=.164b7a85-8caf-4669-8759-fd0101220496@github.com>

On Tue, 27 Feb 2024 13:55:53 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> Clarifying text in `make help` output on how to list variables for e.g. JTREG='...'.

> I have no idea what causes it.

Nevermind. The patch looks good.

-------------

Marked as reviewed by gli (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18028#pullrequestreview-1907859906

From dholmes at openjdk.org  Thu Feb 29 06:37:51 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 Feb 2024 06:37:51 GMT
Subject: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in
 internal JDK binaries
In-Reply-To: <NdOa4jatnFRBaRrDrrCQU3v-7N4fGRfA8tdRRXuJthM=.02edd694-8eb2-4979-ab31-9b34b862c6db@github.com>
References: <NdOa4jatnFRBaRrDrrCQU3v-7N4fGRfA8tdRRXuJthM=.02edd694-8eb2-4979-ab31-9b34b862c6db@github.com>
Message-ID: <mTJcEpLz2Hlo59STIe2YlnaFHkVTVwt8tguw1qPC4yw=.92df1e51-be0e-4c40-a3c9-232d80aa7914@github.com>

On Wed, 28 Feb 2024 19:29:13 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> There is no supported usecase that I can think of for injecting other versions of such libraries in a JDK distribution.

I can imagine it could be used to allow "hot patching" of the installed JDK/JRE. Whether anyone has ever needed to do so is another matter. I suggest at least adding a Release Note.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18050#issuecomment-1970497315

From hannesw at openjdk.org  Thu Feb 29 11:43:04 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 29 Feb 2024 11:43:04 GMT
Subject: RFR: JDK-8298405: Support Markdown in Documentation Comments [v43]
In-Reply-To: <k4yPloMAtTmkzn54pzlVhTpBRq6dVGJxmFg1YVgAQVk=.5089ccc6-c675-4933-a8e8-633d6162984d@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <gwFu9c4-Y_zksoJ1Tu4eJ-rJm0DEf2EYCZj2OVVIrUE=.9e9533b9-751e-4dfd-890e-4dc48c3399ea@github.com>
 <x_vvLqu7UsQHMlQCynTzD0ddhHvg2glkHXblCujUCrQ=.62b4b088-e12c-45fc-b974-bd83812d0c9e@github.com>
 <k4yPloMAtTmkzn54pzlVhTpBRq6dVGJxmFg1YVgAQVk=.5089ccc6-c675-4933-a8e8-633d6162984d@github.com>
Message-ID: <GBCHPcPnrmMHP5Lv6OmpYTZYNv1mUDoSa_0LL0RNbyg=.1bdb3a33-ed23-470a-8157-a2c142a65712@github.com>

On Wed, 28 Feb 2024 17:12:04 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1601:
>> 
>>> 1599:                         : eKind != ElementKind.OTHER ? 1   // module, package, class, interface
>>> 1600:                         : 0; // doc file
>>> 1601:                 return "h" + Math.min(heading.getLevel() + offset, 6);
>> 
>> I really like that we adapt the heading level to the current context, but I notice that the code kind of expects `h1` headings to be used everywhere, and "punishes" use of contextually correct headings by generating smaller headings. Maybe it would be more educational to only adjust the level if it needs adjusting?
>
> Setext headings only come in "level 1" and "level 2" flavors.
> And, at the time the renderer sees the AST, the difference between ATX and setext headings is erased. They're just "headings".
> 
> I also think it is better to have a simple rule than an "adaptive" rule.  If you start doing a more complex rule, you have to consider the effect on subheadings as well.

I suspected it was about the limited range of Setext headings. Yesterday my proposal was intentionally vague, but thinking about this again I think we should actually do the simplest and least intrusive thing possible:

    // minLevel is 4 for members, 2 for page-level elements, 1 for doc files
    "h" + Math.max(heading.getLevel(), minLevel);

This arguably generates the correct heading for most simple use cases. What it doesn't do is to translate whole hierarchies of headings, but I would argue that few people people need this and those who do should figure out the rules and use the correct ATX headings.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1507439797

From erikj at openjdk.org  Thu Feb 29 14:32:52 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 29 Feb 2024 14:32:52 GMT
Subject: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in
 internal JDK binaries
In-Reply-To: <mTJcEpLz2Hlo59STIe2YlnaFHkVTVwt8tguw1qPC4yw=.92df1e51-be0e-4c40-a3c9-232d80aa7914@github.com>
References: <NdOa4jatnFRBaRrDrrCQU3v-7N4fGRfA8tdRRXuJthM=.02edd694-8eb2-4979-ab31-9b34b862c6db@github.com>
 <mTJcEpLz2Hlo59STIe2YlnaFHkVTVwt8tguw1qPC4yw=.92df1e51-be0e-4c40-a3c9-232d80aa7914@github.com>
Message-ID: <vC5nhncsS8re6msLpYNY50kyj2dI44-vKQgNqFvzl7M=.ed1a0c76-0d48-40ec-8f12-9fe189d1e76a@github.com>

On Thu, 29 Feb 2024 06:34:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I can imagine it could be used to allow "hot patching" of the installed JDK/JRE. Whether anyone has ever needed to do so is another matter. I suggest at least adding a Release Note.

Added release note.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18050#issuecomment-1971267771