Re: fixpath seems to be deleting path separators when paths are read from files
Hi Magnus, > So this is only in @-files? > Sounds like it could be a newline issue then. (CR/LF vs LF) Is this in > cygwin? > Have you checked if "make doctor" finds autocrlf issues? Yes, it only happens when files containing commands are tagged as @; the current builds are tested on MSYS2 (ucrt.exe). make doctor doesn't find any issues oddly enough, apart from the obligatory warning to run "make clean" after the build failed > You can try setting the variable DEBUG_FIXPATH to any non-empty value to > get a bit more debug info out of fixpath. It ended up spamming the console with a lot of output, but the (I think) relevant log was: fixpath: debug: input: /ucrt64/bin/g++.exe -Wl,--warn-unresolved-symbols -Wl,-O1 -m64 -shared -O3 -flto -fuse-linker-plugin -fno-strict-aliasing -m64 -Wl,-version-script=/d/eclipse/workspace/hotspot/jdk/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/mapfile -Wl,-soname=jvm.dll -o /d/eclipse/workspace/hotspot/jdk/build/windows-x86_64-server-release/support/modules_libs/java.base/server/jvm.dll @/d/eclipse/workspace/hotspot/jdk/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objects/_BUILD_LIBJVM_objectfilenames.txt /d/eclipse/workspace/hotspot/jdk/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objects/jvm.dll.res fixpath: debug: output: /ucrt64/bin/g++.exe -Wl,--warn-unresolved-symbols -Wl,-O1 -m64 -shared -O3 -flto -fuse-linker-plugin -fno-strict-aliasing -m64 -Wl,-version-script=d:\eclipse\workspace\hotspot\jdk\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\mapfile -Wl,-soname=jvm.dll -o d:\eclipse\workspace\hotspot\jdk\build\windows-x86_64-server-release\support\modules_libs\java.base\server\jvm.dll @C:\Users\vertig0\Downloads\msys64\tmp\fixpath.UeMmxB\atfile d:\eclipse\workspace\hotspot\jdk\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objects\jvm.dll.res The redirected @file was removed too quickly for me to see its contents though best regards, Julian On Wed, Apr 13, 2022 at 7:04 PM Magnus Ihse Bursie < magnus.ihse.bur...@oracle.com> wrote: > > > On 2022-04-13 05:39, Julian Waters wrote: > > Recently I've been getting build failures on my Windows device that go > > something along the lines of: > > > /msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/.../x86_64-w64-mingw32/bin/ld.exe: > > cannot find > > > d:eclipseworkspacehotspotjdkbuildwindows-x86_64-server-releasehotspotvariant-serverlibjvmobjectsabstractCompiler.o: > > No such file or directory > > > > The issue results from fixpath apparently deleting path separators when > it > > transforms the path styles for Windows; It does add the proper drive name > > but ends up wiping all of the slashes in the path > > > > > /d/eclipse/workspace/hotspot/jdk/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objects/abstractCompiler.o > > > > ends up becoming (As seen above) > > > > > d:eclipseworkspacehotspotjdkbuildwindows-x86_64-server-releasehotspotvariant-serverlibjvmobjectsabstractCompiler.o > > > > Curiously, it works fine only for the last path listed in the @file, so > > given a file containing: > > > > > /d/eclipse/workspace/hotspot/jdk/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objects/zWorkers.o > > > /d/eclipse/workspace/hotspot/jdk/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objects/jvm.dll.res > > > > the latter would properly convert to > > > > > d:\eclipse\workspace\hotspot\jdk\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objects\jvm.dll.res > > > > but the former and everything before it would be affected > > So this is only in @-files? > > Sounds like it could be a newline issue then. (CR/LF vs LF) Is this in > cygwin? > > Have you checked if "make doctor" finds autocrlf issues? > > > > > The full generated build command (with the absolute paths truncated) is > as > > follows > > > > fixpath exec g++.exe -Wl,--warn-unresolved-symbols -Wl,-O1 -m64 -shared > -O3 > > -fuse-linker-plugin -fno-strict-aliasing -m64 > > -Wl,-version-script=/hotspot/variant-server/libjvm/mapfile > > -Wl,-soname=jvm.dll -o /support/modules_libs/java.base/server/jvm.dll > > @/hotspot/variant-server/libjvm/objects/_BUILD_LIBJVM_objectfilenames.txt > > /hotspot/variant-server/libjvm/objects/jvm.dll.res > > > > There aren't any peculiarities between the 2 compilers (I'm currently > > experimenting with the ucrt linking port of gcc) that should be causing > > this from what I can tell, out of curiosity, has this been an issue > > reported elsewhere before? > No. > > > I haven't figured out what's causing this so far > > unfortunately > > :( > > You can try setting the variable DEBUG_FIXPATH to any non-empty value to > get a bit more debug info out of fixpath. > > /Magnus > > > > best regards, > > Julian > >
Re: RFR: 8284853: Fix varios 'expected' typo
On Wed, 13 Apr 2022 20:36:48 GMT, Andrey Turbanov wrote:
> Found various typos of expected: `exepected`, `exept`, `epectedly`,
> `expeced`, `Unexpeted`, etc.
test/jdk/java/lang/StackWalker/StackStreamTest.java line 218:
> 216: private static void equalsOrThrow(String label, List list,
> List expected) {
> 217: System.out.println("List: " + list);
> 218: System.out.println("Expected: " + list);
I think there is a per-existing bug here. Shouldn't the second println print
`expected` instead of `list`?
-
PR: https://git.openjdk.java.net/jdk/pull/8231
Re: RFR: 8284853: Fix varios 'expected' typo
On Wed, 13 Apr 2022 20:36:48 GMT, Andrey Turbanov wrote: > Found various typos of expected: `exepected`, `exept`, `epectedly`, > `expeced`, `Unexpeted`, etc. Expect the Unexpeted. - Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8231
Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v29]
> This PR contains the API and implementation changes for JEP-424 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Remove whitespaces - Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/3a87df5e..8637379e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7888=28 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7888=27-28 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888
Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v28]
> This PR contains the API and implementation changes for JEP-424 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Drop `UnsupportedOperationException` from throws clause in FileChannel/FileChannelImpl - Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/66cebe77..3a87df5e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7888=27 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7888=26-27 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888
Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v27]
On Wed, 13 Apr 2022 16:12:31 GMT, Alan Bateman wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Add @ForceInline annotation on session accessor >> Beef up UnrolledAccess benchmark > > src/java.base/share/classes/java/nio/channels/FileChannel.java line 1052: > >> 1050: public MemorySegment map(MapMode mode, long offset, long size, >> 1051: MemorySession session) >> 1052: throws IOException, UnsupportedOperationException > > Just a minor here is that UOE is a runtime exception so probably shouldn't be > in the throws. whoops - good catch - will fix! - PR: https://git.openjdk.java.net/jdk/pull/7888
RFR: 8284853: Fix varios 'expected' typo
Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc. - Commit messages: - [PATCH] Fix 'expected' typo - [PATCH] Fix 'expected' typo - [PATCH] Fix 'expected' typo Changes: https://git.openjdk.java.net/jdk/pull/8231/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8231=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284853 Stats: 65 lines in 28 files changed: 0 ins; 0 del; 65 mod Patch: https://git.openjdk.java.net/jdk/pull/8231.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8231/head:pull/8231 PR: https://git.openjdk.java.net/jdk/pull/8231
Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v27]
On Tue, 12 Apr 2022 10:24:47 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one > additional commit since the last revision: > > Add @ForceInline annotation on session accessor > Beef up UnrolledAccess benchmark src/java.base/share/classes/java/nio/channels/FileChannel.java line 1052: > 1050: public MemorySegment map(MapMode mode, long offset, long size, > 1051: MemorySession session) > 1052: throws IOException, UnsupportedOperationException Just a minor here is that UOE is a runtime exception so probably shouldn't be in the throws. - PR: https://git.openjdk.java.net/jdk/pull/7888
RE: Why we use specific compiler versions - was: Re: JDK-8284772 - was RE: [jdk17] RFR: 8269148: Update minor GCC version in GitHub Actions pipeline
Hi Magnus, thanks for pointing to the original change that introduced this. Generally I agree that the build environment should be stable and only consciously be updated to newer versions of tools. E.g. the Ubuntu Release and the gcc major version should remain stable. However, this case it is just about changing minor steppings due to vendor packaging in a scenario where pinning to a certain version could fail out of a sudden because the old vendor package is removed. My personal feeling here is that the tradeoff to unpin the package name is the better choice. As for stability of the environment I think that also the ubuntu container that is used is updated from time to time for certain patches and we usually don't recognize it. Best regards Christoph > -Original Message- > From: Magnus Ihse Bursie > Sent: Mittwoch, 13. April 2022 12:58 > To: Langer, Christoph ; Andrew Hughes > ; David Holmes ; > Aleksey Shipilev > Cc: build-dev@openjdk.java.net > Subject: Why we use specific compiler versions - was: Re: JDK-8284772 - was > RE: [jdk17] RFR: 8269148: Update minor GCC version in GitHub Actions > pipeline > > I disagree completely. We had it this way in mainline originally, but it was > fixed > in https://bugs.openjdk.java.net/browse/JDK-8256393. > > As you might know, I'm not too fond of the GHA solution, since we can't debug > issues with Github's hosts. Nevertheless, many users look at the GHA results > as > a way to sanity check their code. Any and all spurious build failures is a > problem > then, since it will present a red marker -- even if the new code in the PR is > okay. > > The less control we have over the build platform, the greater the chance for > odd and non-reproducible build failures. > > Selecting a specific version of the compiler is a way to guarantee > reproducible > build results. If the build succeeds in mainline, and I submit correct code, > chances are higher that the build also succeeds in my PR. In contrast, if the > gcc > version suddenly were changed behind my back, the mainline build might > succeed, and my PR build fail, not due to anything I've done wrong, but just > due > to the fact that the compiler was switched by the Ubuntu team in the > meantime. > > Yes, it means a bit more annoyance when upgrading the compiler, but that also > means it is a conscious (and hopefully well tested) choice. I'll take that > any day > over re-introducing more uncertainty into an already-unstable testing > procedure. > > /Magnus > > On 2022-04-13 08:25, Langer, Christoph wrote: > > Hi Andrew, > > > One dummy question: > Why do we need to specify the real package name here? > If we install gcc-10, I think apt system will pick up the latest gcc-10 > for us. > >>> IIRC the intent is to keep control over the gcc version and not > >>> randomly update whenever the distro updates. Upgrading compiler > >>> versions for the OpenJDK is actually a very involved process when > >>> done properly and we often find code changes need to be made, or > >>> warnings adjusted, when a new version of the compiler is to be used. > >>> This approach forces us to check the new version is okay before > >>> switching over to it. At least that is the theory. :) > >>> > >>> Cheers, > >>> David > >>> > >>> > >> I'm in complete agreement with you as regards major versions of GCC. > >> Fedora's eager adoption of them means we often encounter these early. > >> JDK-8282231 is just the latest example from the introduction of GCC 12. > >> > >> However, the GHA workflow in OpenJDK doesn't just depend on a major > >> version of GCC - which is actually contained in the Ubuntu package > >> name of > >> gcc-9 or gcc-10 itself - but the full revision number, even down to > >> local packaging changes. > >> > >> I believe this is overkill and leads to valuable time being wasted on > >> issues like > >> JDK-8283778 where the GCC version itself didn't even change at all, > >> just the Ubuntu version suffix. > >> > >> Having just encountered this with 8u, I've filed JDK-8284772 there to > >> just use the package name, which includes the major GCC version. > >> That's already how it is depending on the x86_32 GCC, which hasn't > >> suffered broken dependencies in the same way as x86_64. > >> > >> I have yet to see an issue be specific to a minor GCC version bump, > >> whereas the current setup is pretty much guaranteed to mean further > >> fixes to the GitHub workflow every time the Ubuntu packager produces a > new build. > >> > >> I'm happy to submit the change for other JDK versions if there is > >> interest, but I at least don't want to be encountering this in > >> maintaining 8u (and certainly not having to add fixes to a release > >> branch in rampdown, as happened recently with 11u) > > I'm in full agreement with you and can't see any reason for but just > > additional > trouble with hard maintenance of the GCC version suffix. I would love to see > JDK-8284772 be done in
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v4]
On Wed, 13 Apr 2022 11:37:36 GMT, Magnus Ihse Bursie wrote: > The latest version looks much better! Fix the test to check for linux, and > the indentation in the new header file, and I'd say you're good to go! @magicus update ready, with test fix, indentation and remove .file form the linux incubator files. - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v5]
> This PR removes the need for relative object file linking introduced by > JDK-8284437 for linux libraries, by specifying > .file directives in the linux .S source files. The > source files specify a .file ASSEMBLY_SRC_FILE > where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. > > Signed-off-by: Andrew Leonard Andrew Leonard has updated the pull request incrementally with two additional commits since the last revision: - 8284661: Reproducible assembly builds without relative linking Signed-off-by: Andrew Leonard - 8284661: Reproducible assembly builds without relative linking Signed-off-by: Andrew Leonard - Changes: - all: https://git.openjdk.java.net/jdk/pull/8177/files - new: https://git.openjdk.java.net/jdk/pull/8177/files/f9a53868..4245e704 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8177=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8177=03-04 Stats: 79 lines in 39 files changed: 1 ins; 36 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/8177.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8177/head:pull/8177 PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284752: Zero does not build on Mac OS X due to missing os::current_thread_enable_wx implementation
Hi Magnus, On Wed, Apr 13, 2022 at 1:23 PM Magnus Ihse Bursie < magnus.ihse.bur...@oracle.com> wrote: > On 2022-04-12 15:21, David Holmes wrote: > > On Tue, 12 Apr 2022 11:31:03 GMT, Johannes Bechberger < > d...@openjdk.java.net> wrote: > > > >> Adds an implementation of the missing method (guarded with > `defined(AARCH64) && defined(__APPLE__)`) and fixes the compilation issues > on Mac M1. > > Looks good and trivial. > > > > It seems apparent that nobody has been building Zero in this environment. > I'm a bit surprised at this. I thought macos/aarch64 was added to GHA > some time ago? (And also to Oracle's internal CI pipeline) > > GHAs build Linux Zero (hotspot only). I think nobody builds MacOs zero, or? This was a MacOs specific bug (still good to have that fixed though). > /Magnus > > >
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v4]
On Wed, 13 Apr 2022 11:36:41 GMT, Magnus Ihse Bursie wrote: >> Andrew Leonard has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8284661: Reproducible assembly builds without relative linking >> >> Signed-off-by: Andrew Leonard > > make/data/autoheaders/assemblyprefix.h line 24: > >> 22: # >> 23: >> 24: // ASSEMBLY_SRC_FILE gets replaced by relative or absolute file >> path > > While not critical, the indentation here looks surprising and odd. I was keeping it inline with what's in the other .S files - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v4]
On Wed, 13 Apr 2022 11:41:14 GMT, Andrew Leonard wrote: >> make/data/autoheaders/assemblyprefix.h line 24: >> >>> 22: # >>> 23: >>> 24: // ASSEMBLY_SRC_FILE gets replaced by relative or absolute file >>> path >> >> While not critical, the indentation here looks surprising and odd. > > I was keeping it inline with what's in the other .S files i'll change - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v4]
On Wed, 13 Apr 2022 11:30:14 GMT, Andrew Leonard wrote: >> This PR removes the need for relative object file linking introduced by >> JDK-8284437 for linux libraries, by specifying >> .file directives in the linux .S source files. The >> source files specify a .file ASSEMBLY_SRC_FILE >> where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. >> >> Signed-off-by: Andrew Leonard > > Andrew Leonard has updated the pull request incrementally with one additional > commit since the last revision: > > 8284661: Reproducible assembly builds without relative linking > > Signed-off-by: Andrew Leonard The latest version looks much better! Fix the test to check for linux, and the indentation in the new header file, and I'd say you're good to go! make/data/autoheaders/assemblyprefix.h line 24: > 22: # > 23: > 24: // ASSEMBLY_SRC_FILE gets replaced by relative or absolute file > path While not critical, the indentation here looks surprising and odd. - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v4]
> This PR removes the need for relative object file linking introduced by > JDK-8284437 for linux libraries, by specifying > .file directives in the linux .S source files. The > source files specify a .file ASSEMBLY_SRC_FILE > where ASSEMBLY_SRC_FILE is defined by the NativeCompliation.gmk. > > Signed-off-by: Andrew Leonard Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision: 8284661: Reproducible assembly builds without relative linking Signed-off-by: Andrew Leonard - Changes: - all: https://git.openjdk.java.net/jdk/pull/8177/files - new: https://git.openjdk.java.net/jdk/pull/8177/files/748485d7..f9a53868 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8177=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8177=02-03 Stats: 71 lines in 8 files changed: 41 ins; 27 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8177.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8177/head:pull/8177 PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284752: Zero does not build on Mac OS X due to missing os::current_thread_enable_wx implementation
On 2022-04-12 15:21, David Holmes wrote: On Tue, 12 Apr 2022 11:31:03 GMT, Johannes Bechberger wrote: Adds an implementation of the missing method (guarded with `defined(AARCH64) && defined(__APPLE__)`) and fixes the compilation issues on Mac M1. Looks good and trivial. It seems apparent that nobody has been building Zero in this environment. I'm a bit surprised at this. I thought macos/aarch64 was added to GHA some time ago? (And also to Oracle's internal CI pipeline) /Magnus
Re: fixpath seems to be deleting path separators when paths are read from files
On 2022-04-13 05:39, Julian Waters wrote: Recently I've been getting build failures on my Windows device that go something along the lines of: /msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/.../x86_64-w64-mingw32/bin/ld.exe: cannot find d:eclipseworkspacehotspotjdkbuildwindows-x86_64-server-releasehotspotvariant-serverlibjvmobjectsabstractCompiler.o: No such file or directory The issue results from fixpath apparently deleting path separators when it transforms the path styles for Windows; It does add the proper drive name but ends up wiping all of the slashes in the path /d/eclipse/workspace/hotspot/jdk/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objects/abstractCompiler.o ends up becoming (As seen above) d:eclipseworkspacehotspotjdkbuildwindows-x86_64-server-releasehotspotvariant-serverlibjvmobjectsabstractCompiler.o Curiously, it works fine only for the last path listed in the @file, so given a file containing: /d/eclipse/workspace/hotspot/jdk/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objects/zWorkers.o /d/eclipse/workspace/hotspot/jdk/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objects/jvm.dll.res the latter would properly convert to d:\eclipse\workspace\hotspot\jdk\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objects\jvm.dll.res but the former and everything before it would be affected So this is only in @-files? Sounds like it could be a newline issue then. (CR/LF vs LF) Is this in cygwin? Have you checked if "make doctor" finds autocrlf issues? The full generated build command (with the absolute paths truncated) is as follows fixpath exec g++.exe -Wl,--warn-unresolved-symbols -Wl,-O1 -m64 -shared -O3 -fuse-linker-plugin -fno-strict-aliasing -m64 -Wl,-version-script=/hotspot/variant-server/libjvm/mapfile -Wl,-soname=jvm.dll -o /support/modules_libs/java.base/server/jvm.dll @/hotspot/variant-server/libjvm/objects/_BUILD_LIBJVM_objectfilenames.txt /hotspot/variant-server/libjvm/objects/jvm.dll.res There aren't any peculiarities between the 2 compilers (I'm currently experimenting with the ucrt linking port of gcc) that should be causing this from what I can tell, out of curiosity, has this been an issue reported elsewhere before? No. I haven't figured out what's causing this so far unfortunately :( You can try setting the variable DEBUG_FIXPATH to any non-empty value to get a bit more debug info out of fixpath. /Magnus best regards, Julian
Why we use specific compiler versions - was: Re: JDK-8284772 - was RE: [jdk17] RFR: 8269148: Update minor GCC version in GitHub Actions pipeline
I disagree completely. We had it this way in mainline originally, but it was fixed in https://bugs.openjdk.java.net/browse/JDK-8256393. As you might know, I'm not too fond of the GHA solution, since we can't debug issues with Github's hosts. Nevertheless, many users look at the GHA results as a way to sanity check their code. Any and all spurious build failures is a problem then, since it will present a red marker -- even if the new code in the PR is okay. The less control we have over the build platform, the greater the chance for odd and non-reproducible build failures. Selecting a specific version of the compiler is a way to guarantee reproducible build results. If the build succeeds in mainline, and I submit correct code, chances are higher that the build also succeeds in my PR. In contrast, if the gcc version suddenly were changed behind my back, the mainline build might succeed, and my PR build fail, not due to anything I've done wrong, but just due to the fact that the compiler was switched by the Ubuntu team in the meantime. Yes, it means a bit more annoyance when upgrading the compiler, but that also means it is a conscious (and hopefully well tested) choice. I'll take that any day over re-introducing more uncertainty into an already-unstable testing procedure. /Magnus On 2022-04-13 08:25, Langer, Christoph wrote: Hi Andrew, One dummy question: Why do we need to specify the real package name here? If we install gcc-10, I think apt system will pick up the latest gcc-10 for us. IIRC the intent is to keep control over the gcc version and not randomly update whenever the distro updates. Upgrading compiler versions for the OpenJDK is actually a very involved process when done properly and we often find code changes need to be made, or warnings adjusted, when a new version of the compiler is to be used. This approach forces us to check the new version is okay before switching over to it. At least that is the theory. :) Cheers, David I'm in complete agreement with you as regards major versions of GCC. Fedora's eager adoption of them means we often encounter these early. JDK-8282231 is just the latest example from the introduction of GCC 12. However, the GHA workflow in OpenJDK doesn't just depend on a major version of GCC - which is actually contained in the Ubuntu package name of gcc-9 or gcc-10 itself - but the full revision number, even down to local packaging changes. I believe this is overkill and leads to valuable time being wasted on issues like JDK-8283778 where the GCC version itself didn't even change at all, just the Ubuntu version suffix. Having just encountered this with 8u, I've filed JDK-8284772 there to just use the package name, which includes the major GCC version. That's already how it is depending on the x86_32 GCC, which hasn't suffered broken dependencies in the same way as x86_64. I have yet to see an issue be specific to a minor GCC version bump, whereas the current setup is pretty much guaranteed to mean further fixes to the GitHub workflow every time the Ubuntu packager produces a new build. I'm happy to submit the change for other JDK versions if there is interest, but I at least don't want to be encountering this in maintaining 8u (and certainly not having to add fixes to a release branch in rampdown, as happened recently with 11u) I'm in full agreement with you and can't see any reason for but just additional trouble with hard maintenance of the GCC version suffix. I would love to see JDK-8284772 be done in head and backported to all active update releases. I had the same idea when doing JDK-8283778. Best regards Christoph
Integrated: 8284720: IntelliJ: JIRA integration
On Tue, 12 Apr 2022 04:44:15 GMT, Daniel Jeliński wrote: > This patch adds clickable link to commit messages in IntelliJ's git log. > Example result: >  This pull request has now been integrated. Changeset: 507dc41a Author:Daniel Jeliński URL: https://git.openjdk.java.net/jdk/commit/507dc41a53cdbaf60fdf5b198ffc19e767230823 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod 8284720: IntelliJ: JIRA integration Reviewed-by: mcimadamore, ihse - PR: https://git.openjdk.java.net/jdk/pull/8193
Re: RFR: 8284720: IntelliJ: JIRA integration
On Tue, 12 Apr 2022 04:44:15 GMT, Daniel Jeliński wrote: > This patch adds clickable link to commit messages in IntelliJ's git log. > Example result: >  BTW, `\d` in regexps is a bit slower than `[0-9]`. It's because `[0-9]` matches only ASCII digits, while `\d` additional matches by extended unicode digits. - PR: https://git.openjdk.java.net/jdk/pull/8193
Re: RFR: 8284661: Reproducible assembly builds without relative linking [v3]
On Tue, 12 Apr 2022 10:27:30 GMT, Magnus Ihse Bursie wrote: > Actually, a better option might be to let GCC append the `.file` > automatically to all assembly files. I think this can be done by creating a > file like `make/data/autoheaders/assemblyprefix.h` with: > > ``` > // ASSEMBLY_SRC_FILE gets replaced by relative or absolute file path > // in NativeCompilation.gmk, this ensures reproducible .debuginfo > .file ASSEMBLY_SRC_FILE > ``` > > and then add `-include $TOPDIR/make/data/autoheaders/assemblyprefix.h` to the > gcc assembly command line. > > I have not verified this so it needs to be checked. > > I also think we should remove the `.file` keyword from the incubator files. > (Nothing good can come out of having two `.file` attributes.) @magicus this sounds good, i'll give it a try - PR: https://git.openjdk.java.net/jdk/pull/8177
Re: RFR: 8284661: Reproducible assembly builds without relative linking
On Tue, 12 Apr 2022 08:39:54 GMT, Andrew Haley wrote: > > I excluded all kinds of debuginfo files because I didn't know if they could > > be made free of absolute paths, and it was out of scope for what I was > > doing at the time. > > GCC, I believe, uses whatever pathname you give to the compiler in the > debuginfo. If you give GCC relative pathnames, that's what it emits. @theRealAph The current strategy is to retain full paths in cmdlines, so that they can be copy & pasted from logs and just invoked, if relative paths are used then you need to be in the right place. Hence instead to achieve relative paths in the debuginfo, we need to use --debug-prefix-map option. - PR: https://git.openjdk.java.net/jdk/pull/8177
JDK-8284772 - was RE: [jdk17] RFR: 8269148: Update minor GCC version in GitHub Actions pipeline
Hi Andrew, > > > One dummy question: > > > Why do we need to specify the real package name here? > > > If we install gcc-10, I think apt system will pick up the latest gcc-10 > > > for us. > > > > IIRC the intent is to keep control over the gcc version and not > > randomly update whenever the distro updates. Upgrading compiler > > versions for the OpenJDK is actually a very involved process when done > > properly and we often find code changes need to be made, or warnings > > adjusted, when a new version of the compiler is to be used. This > > approach forces us to check the new version is okay before switching > > over to it. At least that is the theory. :) > > > > Cheers, > > David > > > > > > I'm in complete agreement with you as regards major versions of GCC. Fedora's > eager adoption of them means we often encounter these early. JDK-8282231 is > just the latest example from the introduction of GCC 12. > > However, the GHA workflow in OpenJDK doesn't just depend on a major > version of GCC - which is actually contained in the Ubuntu package name of > gcc-9 or gcc-10 itself - but the full revision number, even down to local > packaging changes. > > I believe this is overkill and leads to valuable time being wasted on issues > like > JDK-8283778 where the GCC version itself didn't even change at all, just the > Ubuntu version suffix. > > Having just encountered this with 8u, I've filed JDK-8284772 there to just use > the package name, which includes the major GCC version. That's already how it > is depending on the x86_32 GCC, which hasn't suffered broken dependencies in > the same way as x86_64. > > I have yet to see an issue be specific to a minor GCC version bump, whereas > the > current setup is pretty much guaranteed to mean further fixes to the GitHub > workflow every time the Ubuntu packager produces a new build. > > I'm happy to submit the change for other JDK versions if there is interest, > but I > at least don't want to be encountering this in maintaining 8u (and certainly > not > having to add fixes to a release branch in rampdown, as happened recently > with 11u) I'm in full agreement with you and can't see any reason for but just additional trouble with hard maintenance of the GCC version suffix. I would love to see JDK-8284772 be done in head and backported to all active update releases. I had the same idea when doing JDK-8283778. Best regards Christoph
