Re: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX [v2]
On Fri, 12 Jan 2024 16:15:34 GMT, Julian Waters 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: > > make/autoconf/toolchain.m4 > > Co-authored-by: Magnus Ihse Bursie I was thinking earlier this morning if I could roll a custom AC_PROG_CC for the JDK, since it could solve the issues that the current AC_PROG_CC and AC_PROG_CXX (including the addition of flags that we don't want). This way we could avoid hacks and messing with autoconf internals related to the problems that AC_PROG_CC presents (such as the one present here). Any thoughts on this? - PR Comment: https://git.openjdk.org/jdk/pull/17401#issuecomment-1890336752
Re: RFR: JDK-8320458: Improve structural navigation in API documentation [v4]
On Fri, 12 Jan 2024 18:52:46 GMT, Hannes Wallnöfer wrote: >> This is a rather big change to update the structural navigation in API >> documentation generated by JavaDoc. It adds a table of contents for the >> current page to module, package, and class documentation, and replaces the >> old sub-navigation bar with a breadcrumb-style links in those pages. The >> table of contents is displayed as sidebar on wide/desktop displays and >> integrated into the collapsible menu for narrow/mobile displays. The >> generated docs can be browsed here: >> >> https://cr.openjdk.org/~hannesw/8320458/api.00/ >> >> This change includes improvements in `stylesheet.css` and `script.js` that >> are not strictly related to the navigation changes, but happened as a >> consequence of the necessary restructuring. All these are described together >> with the more on-topic changes in the list below. >> >> - The table of contents is composed as the respective writers generate the >> pages. For this purpose, `HtmlDocletWriter` has a new `tocBuilder` field of >> new type `ListBuilder`. If the field is not `null` it is used to build the >> table of contents as the page is built using either one of the >> new`HtmlDocletWriter.addToTableOfContents` methods or the `ListBuilder` >> directly. >> - Once the TOC is built, `HtmlDocletWriter.getSideBar` is used to generate >> the markup for the sidebar and it is added to the page via the >> `BodyContents.setSideContent` method. >> - Both existing navigation bars (top and sub-navigation) get an additional >> `` container with CSS class `nav-content` that uses a flex layout for >> its content. This also handles vertical positioning, so the old workaround >> for vertical of the language version label in `Docs.gmk` is not necessary >> anymore. >> - Apart from modules, packages, and classes, other pages that were >> converted to obtain a table of contents are the "Constant Field Values" page >> and the Help page. >> - Originally, I used the `` element for the sidebar, but I learned >> that this was the wrong element as it is meant for content that is not >> strictly related to the main content of the page. The prevailing notion >> seems to be that a table of contents is a navigation element and therefore >> should use the `` element, so I used that for the TOC sidebar. The same >> applies for the breadcrumbs sub-navigation, so I left the header `` >> element wrapped around both top and sub-navigation. >> - For the new lists in TOC and breadcrumbs I used ordered list elements >> `` instead of unordered `` we use everywhere else, as that is what >> should be used when... > > Hannes Wallnöfer has updated the pull request incrementally with one > additional commit since the last revision: > > Consolidate TOC functionality into new TableOfContents class The last commit ([70d06e5](https://github.com/openjdk/jdk/pull/17062/commits/70d06e59711f61f732bc64529e26df5282671bfd)) moves the TOC-related methods from `HtmlDocletWriter` to a new `TableOfContents` class. This includes some not totally obvious changes: - `` headings in the main description are now added directly to the TOC/`ListBuilder` instead of collecting them separately and then adding them as a complete sublist. This has a few other consequences: - Method `ListBuilder.addNested(HtmlTree)` is no longer needed and has been removed, all sublists are added via a sequence of `push`-`add`-`pop`. - The stack in `ListBuilder` now stacks both the current list and the current list item as an `HtmlTree[]` array of length 2. This is because a nested list is only added to the parent list item after it is popped to make sure it is not empty. - The constant values page did previously not add `tabindex="0"` attributes. This has been fixed which required the respective test to be updated. - PR Comment: https://git.openjdk.org/jdk/pull/17062#issuecomment-1889842593
Re: RFR: JDK-8320458: Improve structural navigation in API documentation [v4]
> This is a rather big change to update the structural navigation in API > documentation generated by JavaDoc. It adds a table of contents for the > current page to module, package, and class documentation, and replaces the > old sub-navigation bar with a breadcrumb-style links in those pages. The > table of contents is displayed as sidebar on wide/desktop displays and > integrated into the collapsible menu for narrow/mobile displays. The > generated docs can be browsed here: > > https://cr.openjdk.org/~hannesw/8320458/api.00/ > > This change includes improvements in `stylesheet.css` and `script.js` that > are not strictly related to the navigation changes, but happened as a > consequence of the necessary restructuring. All these are described together > with the more on-topic changes in the list below. > > - The table of contents is composed as the respective writers generate the > pages. For this purpose, `HtmlDocletWriter` has a new `tocBuilder` field of > new type `ListBuilder`. If the field is not `null` it is used to build the > table of contents as the page is built using either one of the > new`HtmlDocletWriter.addToTableOfContents` methods or the `ListBuilder` > directly. > - Once the TOC is built, `HtmlDocletWriter.getSideBar` is used to generate > the markup for the sidebar and it is added to the page via the > `BodyContents.setSideContent` method. > - Both existing navigation bars (top and sub-navigation) get an additional > `` container with CSS class `nav-content` that uses a flex layout for > its content. This also handles vertical positioning, so the old workaround > for vertical of the language version label in `Docs.gmk` is not necessary > anymore. > - Apart from modules, packages, and classes, other pages that were converted > to obtain a table of contents are the "Constant Field Values" page and the > Help page. > - Originally, I used the `` element for the sidebar, but I learned > that this was the wrong element as it is meant for content that is not > strictly related to the main content of the page. The prevailing notion seems > to be that a table of contents is a navigation element and therefore should > use the `` element, so I used that for the TOC sidebar. The same applies > for the breadcrumbs sub-navigation, so I left the header `` element > wrapped around both top and sub-navigation. > - For the new lists in TOC and breadcrumbs I used ordered list elements > `` instead of unordered `` we use everywhere else, as that is what > should be used when list order is important... Hannes Wallnöfer has updated the pull request incrementally with one additional commit since the last revision: Consolidate TOC functionality into new TableOfContents class - Changes: - all: https://git.openjdk.org/jdk/pull/17062/files - new: https://git.openjdk.org/jdk/pull/17062/files/17fa1c0e..70d06e59 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17062=03 - incr: https://webrevs.openjdk.org/?repo=jdk=17062=02-03 Stats: 289 lines in 17 files changed: 119 ins; 84 del; 86 mod Patch: https://git.openjdk.org/jdk/pull/17062.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17062/head:pull/17062 PR: https://git.openjdk.org/jdk/pull/17062
Re: RFR: JDK-8323008: filter out harmful -std* flags added by autoconf from CXX [v4]
On Fri, 12 Jan 2024 13:39:33 GMT, Matthias Baesken wrote: > > As I mentioned above, the autoconf inserting of those compiler flags can be > > disabled by setting ac_prog_cc_stdc and >ac_prog_cxx_stdcxx to readonly > > empty values. It's also a workaround, but is slightly less hacky than > > filtering out the CXX values >like this. Maybe a topic for another > > changeset? > > Yes maybe something for another changeset . > [RealCLanger](https://github.com/RealCLanger) did you try this, maybe you > mentioned something like this ? I tried setting this as environment variable in my shell before calling configure and found that it had no effect. But I didn't spend a lot of energy on that approach. - PR Comment: https://git.openjdk.org/jdk/pull/17301#issuecomment-1889774319
Re: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX
On Fri, 12 Jan 2024 16:05:47 GMT, Magnus Ihse Bursie wrote: > I'm kind of on the fence for this one. On one hand filtering out stuff is > really hacky, but so is setting internal undocumented variables. We have done > some meddling with internal variable in a few places before, but I'd really > like to keep that to a minumum. I'm not sure this is an improvement. I'd like > to get input from other build folks on this. I was holding off for Magnus' opinion here. Both solutions are bad, but we are also trying to work around a pretty bad behavior in autoconf that has met quite a bit of opposition from what I've read. I don't see a clear winner, so I'm leaning towards sticking with the solution that is already integrated for now. If we see more related problems crop up we can re-evaluate then. - PR Comment: https://git.openjdk.org/jdk/pull/17401#issuecomment-1889706568
Re: RFR: 8323675: Race in jdk.javadoc-gendata
On Fri, 12 Jan 2024 15:05:46 GMT, Magnus Ihse Bursie wrote:
> In [JDK-8318913](https://bugs.openjdk.org/browse/JDK-8318913), the
> symbolgenerator started to look at current sources as well. This means that
> the gensrc stage needs to be completed before this is run. A dependency was
> added for jdk.compiler-gendata, but unfortunately the same tool is run also
> in jdk.javadoc-gendata, where no such safeguard was created.
>
> The result is that the build can fail intermittently with:
>
> .../module-info.java:77: error: module not found on module source path
> module java.base {
> ^
> error: cannot access module-info
> cannot resolve modules
> Exception in thread "main" java.lang.AssertionError
> at jdk.compiler.interim/com.sun.tools.javac.util.Assert.error(Assert.java:155)
> at
> jdk.compiler.interim/com.sun.tools.javac.util.Assert.checkNonNull(Assert.java:62)
> at
> jdk.compiler.interim/com.sun.tools.javac.comp.Modules.allModules(Modules.java:1225)
> at
> jdk.compiler.interim/com.sun.tools.javac.comp.Modules.getObservableModule(Modules.java:1450)
> at
> jdk.compiler.interim/com.sun.tools.javac.model.JavacElements.getModuleElement(JavacElements.java:144)
> at
> jdk.compiler.interim/com.sun.tools.javac.model.JavacElements.getModuleElement(JavacElements.java:89)
> at
> build.tools.symbolgenerator.JavadocElementList.main(JavadocElementList.java:98)
> Compiling up to 2 files for BUILD_BREAKITERATOR_BASE
> Compiling up to 2 files for BUILD_BREAKITERATOR_LD
> make[3]: *** [.../_element_lists.marker] Error 1
> Gendata.gmk:74: recipe for target '.../_element_lists.marker' failed
make/Main.gmk line 975:
> 973: # It needs all generated java code present.
> 974: jdk.compiler-gendata: $(JAVA_TARGETS)
> 975: jdk.javadoc-gendata: $(JAVA_TARGETS)
The comment talks about source code, but this is adding JAVA_TARGETS which is
all compiled classes. Is the tool operating on source code or on class files?
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17402#discussion_r1450743329
Re: RFR: 8323621: JDK build should exclude snippet class in java.lang.foreign
On Fri, 12 Jan 2024 15:17:42 GMT, Per Minborg wrote: > This PR proposes to remove the snippet files in > `java/lang/foreign/snippet-files` from the build. make/modules/java.base/Java.gmk line 41: > 39: java/lang/classfile/snippet-files \ > 40: java/lang/classfile/components/snippet-files \ > 41: jdk/lang/foreign/snippet-files I can't find this directory in the source tree, but there is a `src/java.base/share/classes/java/lang/foreign/snippet-files`. Is that what you want to exclude? - PR Review Comment: https://git.openjdk.org/jdk/pull/17403#discussion_r1450739475
Re: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX [v2]
On Fri, 12 Jan 2024 16:15:34 GMT, Julian Waters 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: > > make/autoconf/toolchain.m4 > > Co-authored-by: Magnus Ihse Bursie Hmm, wonder what it'd be like if we rolled our own AC_PROG_CC? - PR Comment: https://git.openjdk.org/jdk/pull/17401#issuecomment-1889594675
Re: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX [v2]
On Fri, 12 Jan 2024 16:04:20 GMT, Magnus Ihse Bursie wrote: >> Julian Waters has updated the pull request incrementally with one additional >> commit since the last revision: >> >> make/autoconf/toolchain.m4 >> >> Co-authored-by: Magnus Ihse Bursie > > make/autoconf/toolchain.m4 line 355: > >> 353: OLD_PATH="$PATH" >> 354: >> 355: # autoconf can ass unwanted flags to CC and CXX based on what it >> deems to be > > Suggestion: > > # autoconf can add unwanted flags to CC and CXX based on what it deems to be That has to be the most embarrassing fatfinger I've ever done - PR Review Comment: https://git.openjdk.org/jdk/pull/17401#discussion_r1450657986
Re: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX [v2]
> [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: make/autoconf/toolchain.m4 Co-authored-by: Magnus Ihse Bursie - Changes: - all: https://git.openjdk.org/jdk/pull/17401/files - new: https://git.openjdk.org/jdk/pull/17401/files/b39e0479..0de14523 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17401=01 - incr: https://webrevs.openjdk.org/?repo=jdk=17401=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17401.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17401/head:pull/17401 PR: https://git.openjdk.org/jdk/pull/17401
Re: RFR: JDK-8323008: filter out harmful -std* flags added by autoconf from CXX [v4]
On Fri, 12 Jan 2024 13:33:54 GMT, Julian Waters wrote: > The only downside to that solution on the other hand is the shell will issue > a diagnostic about writing to a readonly var. Not sure if that is an > acceptable tradeoff That definitely sounds worse. - PR Comment: https://git.openjdk.org/jdk/pull/17301#issuecomment-1889576568
Re: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX
On Fri, 12 Jan 2024 14:49:11 GMT, Julian Waters 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 I'm kind of on the fence for this one. On one hand filtering out stuff is really hacky, but so is setting internal undocumented variables. We have done some meddling with internal variable in a few places before, but I'd really like to keep that to a minumum. I'm not sure this is an improvement. I'd like to get input from other build folks on this. make/autoconf/toolchain.m4 line 355: > 353: OLD_PATH="$PATH" > 354: > 355: # autoconf can ass unwanted flags to CC and CXX based on what it deems > to be Suggestion: # autoconf can add unwanted flags to CC and CXX based on what it deems to be - PR Comment: https://git.openjdk.org/jdk/pull/17401#issuecomment-1889569538 PR Review Comment: https://git.openjdk.org/jdk/pull/17401#discussion_r1450647162
RFR: 8323675: Race in jdk.javadoc-gendata
In [JDK-8318913](https://bugs.openjdk.org/browse/JDK-8318913), the
symbolgenerator started to look at current sources as well. This means that the
gensrc stage needs to be completed before this is run. A dependency was added
for jdk.compiler-gendata, but unfortunately the same tool is run also in
jdk.javadoc-gendata, where no such safeguard was created.
The result is that the build can fail intermittently with:
.../module-info.java:77: error: module not found on module source path
module java.base {
^
error: cannot access module-info
cannot resolve modules
Exception in thread "main" java.lang.AssertionError
at jdk.compiler.interim/com.sun.tools.javac.util.Assert.error(Assert.java:155)
at
jdk.compiler.interim/com.sun.tools.javac.util.Assert.checkNonNull(Assert.java:62)
at
jdk.compiler.interim/com.sun.tools.javac.comp.Modules.allModules(Modules.java:1225)
at
jdk.compiler.interim/com.sun.tools.javac.comp.Modules.getObservableModule(Modules.java:1450)
at
jdk.compiler.interim/com.sun.tools.javac.model.JavacElements.getModuleElement(JavacElements.java:144)
at
jdk.compiler.interim/com.sun.tools.javac.model.JavacElements.getModuleElement(JavacElements.java:89)
at
build.tools.symbolgenerator.JavadocElementList.main(JavadocElementList.java:98)
Compiling up to 2 files for BUILD_BREAKITERATOR_BASE
Compiling up to 2 files for BUILD_BREAKITERATOR_LD
make[3]: *** [.../_element_lists.marker] Error 1
Gendata.gmk:74: recipe for target '.../_element_lists.marker' failed
-
Commit messages:
- 8323675: Race in jdk.javadoc-gendata
Changes: https://git.openjdk.org/jdk/pull/17402/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=17402=00
Issue: https://bugs.openjdk.org/browse/JDK-8323675
Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod
Patch: https://git.openjdk.org/jdk/pull/17402.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/17402/head:pull/17402
PR: https://git.openjdk.org/jdk/pull/17402
Re: RFR: 8323637: Capture hotspot replay files in GHA [v3]
> From the bug report: > > jdk/.github/scripts/gen-test-results.sh is capable of capture hs_err_* file > for erroneous and failed tests. They are also exposed under tag > `View HotSpot error log`. > > I think we can do the same thing for replay files. A replay file is > automatically generated when compiler threads encounter a fatal error. > sometimes, we can only trigger the compilation error on GHA. attached replay > file is invaluable. > > --- > > I have not figured out how to provoke a replay file on GHA, so this is > untested, but since it is based on the hs_err logic I'm pretty confident that > it works. If it turns out to be problematic, let's fix it in a follow up. Magnus Ihse Bursie has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains two commits: - Trigger GHA with empty commit - 8323637: Capture hotspot replay files in GHA - Changes: - all: https://git.openjdk.org/jdk/pull/17392/files - new: https://git.openjdk.org/jdk/pull/17392/files/375a2fd1..a19a333d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17392=02 - incr: https://webrevs.openjdk.org/?repo=jdk=17392=01-02 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17392.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17392/head:pull/17392 PR: https://git.openjdk.org/jdk/pull/17392
Re: RFR: 8323637: Capture hotspot replay files in GHA [v2]
On Fri, 12 Jan 2024 15:26:45 GMT, Magnus Ihse Bursie wrote: >> From the bug report: >> >> jdk/.github/scripts/gen-test-results.sh is capable of capture hs_err_* file >> for erroneous and failed tests. They are also exposed under tag >> `View HotSpot error log`. >> >> I think we can do the same thing for replay files. A replay file is >> automatically generated when compiler threads encounter a fatal error. >> sometimes, we can only trigger the compilation error on GHA. attached replay >> file is invaluable. >> >> --- >> >> I have not figured out how to provoke a replay file on GHA, so this is >> untested, but since it is based on the hs_err logic I'm pretty confident >> that it works. If it turns out to be problematic, let's fix it in a follow >> up. > > Magnus Ihse Bursie has updated the pull request incrementally with two > additional commits since the last revision: > > - Add a real change > - Trigger GHA with empty commit (Sorry for the force push, I added a dummy commit locally touching real files, but I never intended to push it to this branch) - PR Comment: https://git.openjdk.org/jdk/pull/17392#issuecomment-1889512559
Re: RFR: 8323637: Capture hotspot replay files in GHA [v2]
> From the bug report: > > jdk/.github/scripts/gen-test-results.sh is capable of capture hs_err_* file > for erroneous and failed tests. They are also exposed under tag > `View HotSpot error log`. > > I think we can do the same thing for replay files. A replay file is > automatically generated when compiler threads encounter a fatal error. > sometimes, we can only trigger the compilation error on GHA. attached replay > file is invaluable. > > --- > > I have not figured out how to provoke a replay file on GHA, so this is > untested, but since it is based on the hs_err logic I'm pretty confident that > it works. If it turns out to be problematic, let's fix it in a follow up. Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: - Add a real change - Trigger GHA with empty commit - Changes: - all: https://git.openjdk.org/jdk/pull/17392/files - new: https://git.openjdk.org/jdk/pull/17392/files/ff8e1589..375a2fd1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17392=01 - incr: https://webrevs.openjdk.org/?repo=jdk=17392=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17392.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17392/head:pull/17392 PR: https://git.openjdk.org/jdk/pull/17392
Re: RFR: 8323637: Capture hotspot replay files in GHA
On Fri, 12 Jan 2024 10:08:57 GMT, Magnus Ihse Bursie wrote: > From the bug report: > > jdk/.github/scripts/gen-test-results.sh is capable of capture hs_err_* file > for erroneous and failed tests. They are also exposed under tag > `View HotSpot error log`. > > I think we can do the same thing for replay files. A replay file is > automatically generated when compiler threads encounter a fatal error. > sometimes, we can only trigger the compilation error on GHA. attached replay > file is invaluable. > > --- > > I have not figured out how to provoke a replay file on GHA, so this is > untested, but since it is based on the hs_err logic I'm pretty confident that > it works. If it turns out to be problematic, let's fix it in a follow up. I agree, we want to see green checks for GHA. I thought it looked like my GHA runs on another branch was working, so maybe it is fixed now. Trying to get GHA to rerun by pushing an empty commit; I have forgotten if this in fact works. :) - PR Comment: https://git.openjdk.org/jdk/pull/17392#issuecomment-1889498743
RFR: 8323621: JDK build should exclude snippet class in java.lang.foreign
This PR proposes to remove the snippet files in `java/lang/foreign/snippet-files` from the build. - Commit messages: - Exclude snipet files Changes: https://git.openjdk.org/jdk/pull/17403/files Webrev: https://webrevs.openjdk.org/?repo=jdk=17403=00 Issue: https://bugs.openjdk.org/browse/JDK-8323621 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17403.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17403/head:pull/17403 PR: https://git.openjdk.org/jdk/pull/17403
Re: RFR: 8323667: Library debug files contain non-reproducible full gcc include paths
On Fri, 12 Jan 2024 14:33:01 GMT, Andrew Leonard wrote: > For gcc toolchains in ALLOW_ABSOLUTE_PATHS_IN_OUTPUT=False builds, this PR > finds the location of the gcc system include paths, and adds > -fdebug-prefix-map flags to map them to a standard location. Thus making the > debuginfo and resulting libraries reproducible when using DevKits in > different path locations. make/autoconf/flags-cflags.m4 line 193: > 191: > 192: # Add gcc system include mapping => /usr/local/gcc_include > 193: # Find location of stddef.h using build C compiler Why use the build compiler here? - PR Review Comment: https://git.openjdk.org/jdk/pull/17399#discussion_r1450586473
Re: RFR: 8323671: DevKit build gcc libraries contain full paths to source location
On Fri, 12 Jan 2024 14:47:55 GMT, Andrew Leonard wrote: > This PR adds --with-debug-prefix-map to the building of gcc in the DevKit > make file to map the top OUTPUT_ROOT folder to a standard "devkit" path, thus > ensuring DevKit builds are reproducible regardless of the folder the DevKit > is built within. Marked as reviewed by erikj (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/17400#pullrequestreview-1818486143
RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX
[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 - Commit messages: - 8323672 Changes: https://git.openjdk.org/jdk/pull/17401/files Webrev: https://webrevs.openjdk.org/?repo=jdk=17401=00 Issue: https://bugs.openjdk.org/browse/JDK-8323672 Stats: 13 lines in 1 file changed: 8 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17401.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17401/head:pull/17401 PR: https://git.openjdk.org/jdk/pull/17401
RFR: 8323671: DevKit build gcc libraries contain full paths to source location
This PR adds --with-debug-prefix-map to the building of gcc in the DevKit make file to map the top OUTPUT_ROOT folder to a standard "devkit" path, thus ensuring DevKit builds are reproducible regardless of the folder the DevKit is built within. - Commit messages: - 8323671: DevKit build gcc libraries contain full paths to source location Changes: https://git.openjdk.org/jdk/pull/17400/files Webrev: https://webrevs.openjdk.org/?repo=jdk=17400=00 Issue: https://bugs.openjdk.org/browse/JDK-8323671 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17400.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17400/head:pull/17400 PR: https://git.openjdk.org/jdk/pull/17400
RFR: 8323667: Library debug files contain non-reproducible full gcc include paths
For gcc toolchains in ALLOW_ABSOLUTE_PATHS_IN_OUTPUT=False builds, this PR finds the location of the gcc system include paths, and adds -fdebug-prefix-map flags to map them to a standard location. Thus making the debuginfo and resulting libraries reproducible when using DevKits in different path locations. - Commit messages: - 8323667: Library debug files contain non-reproducible full gcc include paths Changes: https://git.openjdk.org/jdk/pull/17399/files Webrev: https://webrevs.openjdk.org/?repo=jdk=17399=00 Issue: https://bugs.openjdk.org/browse/JDK-8323667 Stats: 51 lines in 1 file changed: 51 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17399.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17399/head:pull/17399 PR: https://git.openjdk.org/jdk/pull/17399
Re: RFR: JDK-8323008: filter out harmful -std* flags added by autoconf from CXX [v4]
On Fri, 12 Jan 2024 13:32:28 GMT, Julian Waters wrote: >As I mentioned above, the autoconf inserting of those compiler flags can be >disabled by setting ac_prog_cc_stdc and >ac_prog_cxx_stdcxx to readonly empty >values. It's also a workaround, but is slightly less hacky than filtering out >the CXX values >like this. Maybe a topic for another changeset? Yes maybe something for another changeset . [RealCLanger](https://github.com/RealCLanger) did you try this, maybe you mentioned something like this ? - PR Comment: https://git.openjdk.org/jdk/pull/17301#issuecomment-1889234006
Re: RFR: JDK-8323008: filter out harmful -std* flags added by autoconf from CXX [v4]
On Thu, 11 Jan 2024 14:31:47 GMT, Matthias Baesken wrote: >> It was observed, that autoconf 2.72 added on macOS x86_64 the flag >> -std=gnu++11 by default to CXX in the configure process . >> This is not really wanted so better remove / filter out those -std* flags >> added by autoconf from CXX . >> >> Seems we have something similar for some time for CFLAGS and CXXFLAGS ( see >> TOOLCHAIN_POST_DETECTION in make/autoconf/toolchain.m4) that >> dates back to JDK 9. >> >> See the discussion about this issue : >> https://mail.openjdk.org/pipermail/build-dev/2024-January/042551.html > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > adjust GREP, remove unneeded test The only downside to that solution on the other hand is the shell will issue a diagnostic about writing to a readonly var. Not sure if that is an acceptable tradeoff - PR Comment: https://git.openjdk.org/jdk/pull/17301#issuecomment-1889220615
Re: RFR: JDK-8323008: filter out harmful -std* flags added by autoconf from CXX [v4]
On Fri, 12 Jan 2024 11:35:48 GMT, Magnus Ihse Bursie wrote: > The grep fixes are excellent, thank you for those! > > The CXX filtering is a hack, and I'm slightly less happy about that. Otoh, > the entire autoconf compiler detection stuff is so-so, and we're basically > trying to avoid getting entangled in it, so I guess adding yet another > workaround is okay. As I mentioned above, the autoconf inserting of those compiler flags can be disabled by setting ac_prog_cc_stdc and ac_prog_cxx_stdcxx to readonly empty values. It's also a workaround, but is slightly less hacky than filtering out the CXX values like this. Maybe a topic for another changeset? - PR Comment: https://git.openjdk.org/jdk/pull/17301#issuecomment-1889217261
Re: RFR: JDK-8298405: Support Markdown in Documentation Comments [v6]
On Mon, 8 Jan 2024 21:26:50 GMT, Jonathan Gibbons 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 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 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 https://github.com/openjdk/jdk/pull/11936? src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 2: > 1: /* > 2: * Copyright (c) 2005, 2023, Oracle and/or its affiliates. All rights > reserved. It's surprising to see 2005. src/jdk.internal.md/share/classes/module-info.java line 29: > 27: * Internal support for Markdown. > 28: * > 29: * @since 22 Suggestion: * @since 23 - PR Review: https://git.openjdk.org/jdk/pull/16388#pullrequestreview-1818084469 PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1450342017 PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1450347103
Integrated: JDK-8323008: filter out harmful -std* flags added by autoconf from CXX
On Mon, 8 Jan 2024 10:16:21 GMT, Matthias Baesken wrote: > It was observed, that autoconf 2.72 added on macOS x86_64 the flag > -std=gnu++11 by default to CXX in the configure process . > This is not really wanted so better remove / filter out those -std* flags > added by autoconf from CXX . > > Seems we have something similar for some time for CFLAGS and CXXFLAGS ( see > TOOLCHAIN_POST_DETECTION in make/autoconf/toolchain.m4) that > dates back to JDK 9. > > See the discussion about this issue : > https://mail.openjdk.org/pipermail/build-dev/2024-January/042551.html This pull request has now been integrated. Changeset: 68c42860 Author:Matthias Baesken URL: https://git.openjdk.org/jdk/commit/68c4286026bc2c0ec0f594e0b96fe03fe5624d6d Stats: 8 lines in 2 files changed: 4 ins; 0 del; 4 mod 8323008: filter out harmful -std* flags added by autoconf from CXX Reviewed-by: erikj, clanger, ihse - PR: https://git.openjdk.org/jdk/pull/17301
Re: RFR: JDK-8323008: filter out harmful -std* flags added by autoconf from CXX [v4]
On Thu, 11 Jan 2024 14:31:47 GMT, Matthias Baesken wrote: >> It was observed, that autoconf 2.72 added on macOS x86_64 the flag >> -std=gnu++11 by default to CXX in the configure process . >> This is not really wanted so better remove / filter out those -std* flags >> added by autoconf from CXX . >> >> Seems we have something similar for some time for CFLAGS and CXXFLAGS ( see >> TOOLCHAIN_POST_DETECTION in make/autoconf/toolchain.m4) that >> dates back to JDK 9. >> >> See the discussion about this issue : >> https://mail.openjdk.org/pipermail/build-dev/2024-January/042551.html > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > adjust GREP, remove unneeded test Thanks for the reviews ! - PR Comment: https://git.openjdk.org/jdk/pull/17301#issuecomment-1889055298
Re: RFR: 8323637: Capture hotspot replay files in GHA
On Fri, 12 Jan 2024 10:08:57 GMT, Magnus Ihse Bursie wrote: > From the bug report: > > jdk/.github/scripts/gen-test-results.sh is capable of capture hs_err_* file > for erroneous and failed tests. They are also exposed under tag > `View HotSpot error log`. > > I think we can do the same thing for replay files. A replay file is > automatically generated when compiler threads encounter a fatal error. > sometimes, we can only trigger the compilation error on GHA. attached replay > file is invaluable. > > --- > > I have not figured out how to provoke a replay file on GHA, so this is > untested, but since it is based on the hs_err logic I'm pretty confident that > it works. If it turns out to be problematic, let's fix it in a follow up. Looks good. Except that current GHA is broken, and we would want to give it as spin before integrating. I sent a note to ops@ about this yesterday, but got no reply. Maybe you can poke them a bit? The problem is the git.openjdk.java.net forwarder not working... - Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17392#pullrequestreview-1818036218
Re: RFR: JDK-8323008: filter out harmful -std* flags added by autoconf from CXX [v4]
On Thu, 11 Jan 2024 14:31:47 GMT, Matthias Baesken wrote: >> It was observed, that autoconf 2.72 added on macOS x86_64 the flag >> -std=gnu++11 by default to CXX in the configure process . >> This is not really wanted so better remove / filter out those -std* flags >> added by autoconf from CXX . >> >> Seems we have something similar for some time for CFLAGS and CXXFLAGS ( see >> TOOLCHAIN_POST_DETECTION in make/autoconf/toolchain.m4) that >> dates back to JDK 9. >> >> See the discussion about this issue : >> https://mail.openjdk.org/pipermail/build-dev/2024-January/042551.html > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > adjust GREP, remove unneeded test The grep fixes are excellent, thank you for those! The CXX filtering is a hack, and I'm slightly less happy about that. Otoh, the entire autoconf compiler detection stuff is so-so, and we're basically trying to avoid getting entangled in it, so I guess adding yet another workaround is okay. - Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17301#pullrequestreview-1817994834
Re: RFR: 8314488: Compile the JDK as C++17 [v5]
On Thu, 11 Jan 2024 13:04:35 GMT, Julian Waters wrote: > I can't believe I missed something so obvious Don't blame yourself. No-one has noticed for the at least 3 years the code has been present. :) - PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-174780
RFR: 8323637: Capture hotspot replay files in GHA
>From the bug report: jdk/.github/scripts/gen-test-results.sh is capable of capture hs_err_* file for erroneous and failed tests. They are also exposed under tag `View HotSpot error log`. I think we can do the same thing for replay files. A replay file is automatically generated when compiler threads encounter a fatal error. sometimes, we can only trigger the compilation error on GHA. attached replay file is invaluable. --- I have not figured out how to provoke a replay file on GHA, so this is untested, but since it is based on the hs_err logic I'm pretty confident that it works. If it turns out to be problematic, let's fix it in a follow up. - Commit messages: - 8323637: Capture hotspot replay files in GHA Changes: https://git.openjdk.org/jdk/pull/17392/files Webrev: https://webrevs.openjdk.org/?repo=jdk=17392=00 Issue: https://bugs.openjdk.org/browse/JDK-8323637 Stats: 17 lines in 1 file changed: 15 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17392.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17392/head:pull/17392 PR: https://git.openjdk.org/jdk/pull/17392
Integrated: 8323529: Relativize test image dependencies in microbenchmarks
On Wed, 10 Jan 2024 15:10:58 GMT, Claes Redestad wrote: > JMH microbenchmarks may have dependencies on artifacts in the test image > outside of the benchmarks.jar. This includes native libraries (built into > `$TEST_IMAGE/micro/native`) and may soon include other test libraries like > wb.jar (built into `$TEST_IMAGE/lib-test/`) > > By moving execution to the test image root (currently we run out of the > `make` directory) we can make do with relative paths, which means benchmark > can supply a build-time constant flag themselves rather than have the test > runner provide it for you. And needing to be explicit about external > dependencies is good, I think. > > Taken together this makes the benchmarks.jar more self-contained and simpler > to run: all you need is to run `java -jar micro/benchmarks.jar` from the test > image root. > > This patch also drive-by fixes some lang.foreign tests that were printing > warnings due to a missing `--enable-native-access=ALL-UNNAMED` flag. This pull request has now been integrated. Changeset: 3e19bf88 Author:Claes Redestad URL: https://git.openjdk.org/jdk/commit/3e19bf88d5b51fe10c183f930b99bce961a368c1 Stats: 21 lines in 17 files changed: 5 ins; 0 del; 16 mod 8323529: Relativize test image dependencies in microbenchmarks Reviewed-by: mcimadamore, jvernee, erikj - PR: https://git.openjdk.org/jdk/pull/17349
Re: RFR: 8323529: Relativize test image dependencies in microbenchmarks
On Thu, 11 Jan 2024 17:49:42 GMT, Erik Joelsson wrote: > Fair enough. This isn't worse than the current CWD. The test image dir and > the support output dir have no guaranteed relationship relative to each > other, so we can't rely any relative path between them. Thanks! Perhaps we can improve things down the line so that it'd be possible or even easy to run out of test-support. Using the JMH java API is doable to achieve this, but then we'd need to change the way we run micros in some rather convoluted ways. - PR Comment: https://git.openjdk.org/jdk/pull/17349#issuecomment-1888786622
Re: RFR: 8314488: Compile the JDK as C++17 [v6]
On Fri, 12 Jan 2024 07:49:17 GMT, Matthias Baesken wrote: > We at SAP use and document xlC 17.1.1.4 for jdk22 (use the same for jdk23) > https://wiki.openjdk.org/display/Build/Supported+Build+Platforms > > version 17.1.1.4 is already clang15 (at least that's what the compiler output > is telling me) > > /opt/IBM/openxlC/17.1.1/bin/ibm-clang++_r -v IBM Open XL C/C++ for AIX 17.1.1 > (5725-C72, 5765-J18), version 17.1.1.4, clang version 15.0.0 (build ca7115e) > Target: powerpc-ibm-aix7.2.0.0 My mistake, you are correct. 17.1.0 seems to be clang 13, 17.1.1 seems to be clang 15, and 17.1.2 seems to be clang 17. All of those are based on the documented value of the `__VERSION__` macro's string value. - PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1888731423
