Re: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version
On Wed, 2 Dec 2020 22:04:17 GMT, Erik Joelsson wrote: >> We are indeed missing the macos-version-min argument when linking >> libjvm.dylib. This is a bug. > > Filed https://bugs.openjdk.java.net/browse/JDK-8257633 Thanks for taking care of those issues. To be clear, there is no real need to bump the version for this PR, 10.9 is fine. This PR just proposes another way to implement the workaround for 10.9. - PR: https://git.openjdk.java.net/jdk/pull/1569
RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction: https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages: sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.) signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17. A CSR request has been filed. Testing: hotspot/jtreg/runtime/signal tests Thanks, David - Commit messages: - 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal Changes: https://git.openjdk.java.net/jdk/pull/1587/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1587=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257572 Stats: 7 lines in 2 files changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1587.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1587/head:pull/1587 PR: https://git.openjdk.java.net/jdk/pull/1587
Re: RFR: JDK-8257547: Handle multiple prereqs on the same line in deps files [v4]
On Wed, 2 Dec 2020 22:48:41 GMT, Erik Joelsson wrote: >> After fixing JDK-8256810 and starting to look into backporting it, I >> discovered more potential failing cases. Certain versions of GCC may >> sometimes output multiple prerequisite files on the same line. I think the >> easiest way to handle this new issue is to split such lines. >> >> When splitting lines, we need to make sure to not just split on any space. >> Some compilers output the : of the rule with a leading space, and already >> split lines will have a space before the backslash. > > Erik Joelsson has updated the pull request incrementally with one additional > commit since the last revision: > > Fixed comment Marked as reviewed by ihse (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1548
Re: RFR: JDK-8257547: Handle multiple prereqs on the same line in deps files [v4]
> After fixing JDK-8256810 and starting to look into backporting it, I > discovered more potential failing cases. Certain versions of GCC may > sometimes output multiple prerequisite files on the same line. I think the > easiest way to handle this new issue is to split such lines. > > When splitting lines, we need to make sure to not just split on any space. > Some compilers output the : of the rule with a leading space, and already > split lines will have a space before the backslash. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Fixed comment - Changes: - all: https://git.openjdk.java.net/jdk/pull/1548/files - new: https://git.openjdk.java.net/jdk/pull/1548/files/0c854066..d0039c3e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=1548=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1548=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1548.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1548/head:pull/1548 PR: https://git.openjdk.java.net/jdk/pull/1548
Re: RFR: JDK-8257547: Handle multiple prereqs on the same line in deps files [v3]
On Wed, 2 Dec 2020 18:54:17 GMT, Erik Joelsson wrote: >> After fixing JDK-8256810 and starting to look into backporting it, I >> discovered more potential failing cases. Certain versions of GCC may >> sometimes output multiple prerequisite files on the same line. I think the >> easiest way to handle this new issue is to split such lines. >> >> When splitting lines, we need to make sure to not just split on any space. >> Some compilers output the : of the rule with a leading space, and already >> split lines will have a space before the backslash. > > Erik Joelsson has updated the pull request incrementally with one additional > commit since the last revision: > > Make newline splitting work with BSD tar to make tests pass on macosx Marked as reviewed by tbell (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1548
Re: RFR: JDK-8257547: Handle multiple prereqs on the same line in deps files [v2]
On Wed, 2 Dec 2020 21:41:26 GMT, Erik Joelsson wrote: >> test/make/TestFixDepsFile.gmk line 60: >> >>> 58: $(ECHO) " $(WORKSPACE_ROOT)/bar/baz \\" >> $(DEPS_FILE).expected >>> 59: $(ECHO) " /foo/baz" >> $(DEPS_FILE).expected >>> 60: $(DIFF) $(DEPS_FILE).expected $(DEPS_FILE) >> >> Does this need to be: >> $(DIFF) $(DEPS_FILE).expected $(DEPS_FILE).tmp > > No, the fix-deps-file macro takes file.tmp as input and outputs into file, so > $(DEPS_FILE) is the output file from the macro in this case. OK - PR: https://git.openjdk.java.net/jdk/pull/1548
Re: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version
On Wed, 2 Dec 2020 22:00:55 GMT, Erik Joelsson wrote: >> The current intention is to be consistent with the min system version and >> it's currently set to 10.9. If libjvm.dylib gets a different value, then >> that would be a bug, but note that this could also vary depending on how the >> build is configured and the compiler version used. >> >> So far, I have only bumped this version once, and that was because the >> toolchain required it when switching to Clang from GCC. Keeping it low is >> nice for backwards compatibility. That said, I don't see a problem with >> increasing this value to 10.10 if it's needed for something. Even 10.10 was >> EOL a long time ago now. The current value is set in make/autoconf/flags.m4. >> >> The discrepancy in Info.plist was fixed in JDK-8252145. > > We are indeed missing the macos-version-min argument when linking > libjvm.dylib. This is a bug. Filed https://bugs.openjdk.java.net/browse/JDK-8257633 - PR: https://git.openjdk.java.net/jdk/pull/1569
Re: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version
On Wed, 2 Dec 2020 21:57:15 GMT, Erik Joelsson wrote: >> Interesting, I still able to run the build after this change on macOS >> 10.9.5. I use jdk image and there is no LC_VERSION_MIN_MACOSX in libjvm. >> libjli, libjava have one, and it's 10.9 > > The current intention is to be consistent with the min system version and > it's currently set to 10.9. If libjvm.dylib gets a different value, then that > would be a bug, but note that this could also vary depending on how the build > is configured and the compiler version used. > > So far, I have only bumped this version once, and that was because the > toolchain required it when switching to Clang from GCC. Keeping it low is > nice for backwards compatibility. That said, I don't see a problem with > increasing this value to 10.10 if it's needed for something. Even 10.10 was > EOL a long time ago now. The current value is set in make/autoconf/flags.m4. > > The discrepancy in Info.plist was fixed in JDK-8252145. We are indeed missing the macos-version-min argument when linking libjvm.dylib. This is a bug. - PR: https://git.openjdk.java.net/jdk/pull/1569
Re: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version
On Wed, 2 Dec 2020 21:32:46 GMT, Anton Kozlov wrote: >> I wonder if we should be "upping" that to something later. >> 10.9 is over 7 years old and has been out of support for what - 4 years ? > > Interesting, I still able to run the build after this change on macOS 10.9.5. > I use jdk image and there is no LC_VERSION_MIN_MACOSX in libjvm. libjli, > libjava have one, and it's 10.9 The current intention is to be consistent with the min system version and it's currently set to 10.9. If libjvm.dylib gets a different value, then that would be a bug, but note that this could also vary depending on how the build is configured and the compiler version used. So far, I have only bumped this version once, and that was because the toolchain required it when switching to Clang from GCC. Keeping it low is nice for backwards compatibility. That said, I don't see a problem with increasing this value to 10.10 if it's needed for something. Even 10.10 was EOL a long time ago now. The current value is set in make/autoconf/flags.m4. The discrepancy in Info.plist was fixed in JDK-8252145. - PR: https://git.openjdk.java.net/jdk/pull/1569
Re: RFR: JDK-8257547: Handle multiple prereqs on the same line in deps files [v2]
On Wed, 2 Dec 2020 20:01:08 GMT, Tim Bell wrote: >> Erik Joelsson has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Added test > > test/make/TestFixDepsFile.gmk line 60: > >> 58: $(ECHO) " $(WORKSPACE_ROOT)/bar/baz \\" >> $(DEPS_FILE).expected >> 59: $(ECHO) " /foo/baz" >> $(DEPS_FILE).expected >> 60: $(DIFF) $(DEPS_FILE).expected $(DEPS_FILE) > > Does this need to be: > $(DIFF) $(DEPS_FILE).expected $(DEPS_FILE).tmp No, the fix-deps-file macro takes file.tmp as input and outputs into file, so $(DEPS_FILE) is the output file from the macro in this case. - PR: https://git.openjdk.java.net/jdk/pull/1548
Re: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version
On Wed, 2 Dec 2020 20:19:54 GMT, Phil Race wrote: >> Unfortunately, no. AFAIK, the minimum target version is 10.9 >> https://github.com/openjdk/jdk/blob/master/make/autoconf/flags.m4#L133, so I >> had to keep indirection. > > I wonder if we should be "upping" that to something later. > 10.9 is over 7 years old and has been out of support for what - 4 years ? Interesting, I still able to run the build after this change on macOS 10.9.5. I use jdk image and there is no LC_VERSION_MIN_MACOSX in libjvm. libjli, libjava have one, and it's 10.9 - PR: https://git.openjdk.java.net/jdk/pull/1569
Re: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version
> On Dec 2, 2020, at 12:22 PM, Phil Race wrote: > > On Wed, 2 Dec 2020 20:04:12 GMT, Anton Kozlov wrote: > >>> Surely these days you can just call [NSProcessInfo operatingSystemVersion] >>> directly ? >>> If I read the doc below it is in the 10.10 SDK and later. >>> https://developer.apple.com/documentation/foundation/nsprocessinfo/1410906-operatingsystemversion?language=occ >> >> Unfortunately, no. AFAIK, the minimum target version is 10.9 >> https://github.com/openjdk/jdk/blob/master/make/autoconf/flags.m4#L133, so I >> had to keep indirection. > > I wonder if we should be "upping" that to something later. > 10.9 is over 7 years old and has been out of support for what - 4 years ? > > - > > PR: https://git.openjdk.java.net/jdk/pull/1569 > I know people running 10.10 and I try to keep my Java code running on 10.10, so I would suggest that. However, my experience is that JDK 14 and later refuse to run on 10.10. The metadata is conflicting: The Info.plist has JVMMinimumSystemVersion 10.6.0 libjli.dylib has LC_VERSION_MIN_MACOSX 10.9 However, libjvm has LC_VERSION_MIN_MACOSX 10.13, and that is enough to prevent it from running.
Re: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version
On Wed, 2 Dec 2020 20:04:12 GMT, Anton Kozlov wrote: >> Surely these days you can just call [NSProcessInfo operatingSystemVersion] >> directly ? >> If I read the doc below it is in the 10.10 SDK and later. >> https://developer.apple.com/documentation/foundation/nsprocessinfo/1410906-operatingsystemversion?language=occ > > Unfortunately, no. AFAIK, the minimum target version is 10.9 > https://github.com/openjdk/jdk/blob/master/make/autoconf/flags.m4#L133, so I > had to keep indirection. I wonder if we should be "upping" that to something later. 10.9 is over 7 years old and has been out of support for what - 4 years ? - PR: https://git.openjdk.java.net/jdk/pull/1569
Re: RFR: JDK-8257547: Handle multiple prereqs on the same line in deps files [v2]
On Wed, 2 Dec 2020 17:55:18 GMT, Erik Joelsson wrote: >> After fixing JDK-8256810 and starting to look into backporting it, I >> discovered more potential failing cases. Certain versions of GCC may >> sometimes output multiple prerequisite files on the same line. I think the >> easiest way to handle this new issue is to split such lines. >> >> When splitting lines, we need to make sure to not just split on any space. >> Some compilers output the : of the rule with a leading space, and already >> split lines will have a space before the backslash. > > Erik Joelsson has updated the pull request incrementally with one additional > commit since the last revision: > > Added test test/make/TestFixDepsFile.gmk line 60: > 58: $(ECHO) " $(WORKSPACE_ROOT)/bar/baz \\" >> $(DEPS_FILE).expected > 59: $(ECHO) " /foo/baz" >> $(DEPS_FILE).expected > 60: $(DIFF) $(DEPS_FILE).expected $(DEPS_FILE) Does this need to be: $(DIFF) $(DEPS_FILE).expected $(DEPS_FILE).tmp - PR: https://git.openjdk.java.net/jdk/pull/1548
Re: RFR: JDK-8257547: Handle multiple prereqs on the same line in deps files [v3]
> After fixing JDK-8256810 and starting to look into backporting it, I > discovered more potential failing cases. Certain versions of GCC may > sometimes output multiple prerequisite files on the same line. I think the > easiest way to handle this new issue is to split such lines. > > When splitting lines, we need to make sure to not just split on any space. > Some compilers output the : of the rule with a leading space, and already > split lines will have a space before the backslash. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Make newline splitting work with BSD tar to make tests pass on macosx - Changes: - all: https://git.openjdk.java.net/jdk/pull/1548/files - new: https://git.openjdk.java.net/jdk/pull/1548/files/9f8a7edb..0c854066 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=1548=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1548=01-02 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1548.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1548/head:pull/1548 PR: https://git.openjdk.java.net/jdk/pull/1548
Re: RFR: JDK-8257547: Handle multiple prereqs on the same line in deps files [v3]
On Wed, 2 Dec 2020 17:41:54 GMT, Tim Bell wrote: >> Erik Joelsson has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Make newline splitting work with BSD tar to make tests pass on macosx > > As @magicus wrote - this is subtle but looks OKAY. I added a test as suggested. This uncovered some portability issues as the test failed on Macosx. I have modified the fix-deps-file macro even more to make it portable for all the versions of sed we are currently using. - PR: https://git.openjdk.java.net/jdk/pull/1548
Re: RFR: JDK-8257547: Handle multiple prereqs on the same line in deps files [v2]
> After fixing JDK-8256810 and starting to look into backporting it, I > discovered more potential failing cases. Certain versions of GCC may > sometimes output multiple prerequisite files on the same line. I think the > easiest way to handle this new issue is to split such lines. > > When splitting lines, we need to make sure to not just split on any space. > Some compilers output the : of the rule with a leading space, and already > split lines will have a space before the backslash. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Added test - Changes: - all: https://git.openjdk.java.net/jdk/pull/1548/files - new: https://git.openjdk.java.net/jdk/pull/1548/files/3164af58..9f8a7edb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=1548=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1548=00-01 Stats: 71 lines in 2 files changed: 70 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1548.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1548/head:pull/1548 PR: https://git.openjdk.java.net/jdk/pull/1548
Re: RFR: JDK-8257547: Handle multiple prereqs on the same line in deps files
On Tue, 1 Dec 2020 22:49:06 GMT, Erik Joelsson wrote: > After fixing JDK-8256810 and starting to look into backporting it, I > discovered more potential failing cases. Certain versions of GCC may > sometimes output multiple prerequisite files on the same line. I think the > easiest way to handle this new issue is to split such lines. > > When splitting lines, we need to make sure to not just split on any space. > Some compilers output the : of the rule with a leading space, and already > split lines will have a space before the backslash. As @magicus wrote - this is subtle but looks OKAY. - Marked as reviewed by tbell (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1548
Re: RFR: JDK-8257547: Handle multiple prereqs on the same line in deps files
On Tue, 1 Dec 2020 22:49:06 GMT, Erik Joelsson wrote: > After fixing JDK-8256810 and starting to look into backporting it, I > discovered more potential failing cases. Certain versions of GCC may > sometimes output multiple prerequisite files on the same line. I think the > easiest way to handle this new issue is to split such lines. > > When splitting lines, we need to make sure to not just split on any space. > Some compilers output the : of the rule with a leading space, and already > split lines will have a space before the backslash. As before, regex is write-only code. :-& But I think this does what you claim it to do. :) I'm not sure how hard it would be to add unit testing of this function (probably quite tricky), but it's starting to get close to the point were it's worth it. - Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1548
Integrated: 8257533: legacy-jre-image includes jpackage and jlink tools
On Wed, 2 Dec 2020 10:16:13 GMT, Magnus Ihse Bursie wrote: > JEP 343 added jdk.jpackage to Module.gmk/JRE_TOOL_MODULES with the result > that the legacy-jre-image builds a run-time image that contains the package > and jlink tools. This seems to be an oversight as these tools should not be > in the equivalent of what we knew in the past as the "JRE". This pull request has now been integrated. Changeset: bff68f1f Author:Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/bff68f1f Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8257533: legacy-jre-image includes jpackage and jlink tools Reviewed-by: alanb, sundar - PR: https://git.openjdk.java.net/jdk/pull/1559
Re: RFR: 8257533: legacy-jre-image includes jpackage and jlink tools
On Wed, 2 Dec 2020 10:16:13 GMT, Magnus Ihse Bursie wrote: > JEP 343 added jdk.jpackage to Module.gmk/JRE_TOOL_MODULES with the result > that the legacy-jre-image builds a run-time image that contains the package > and jlink tools. This seems to be an oversight as these tools should not be > in the equivalent of what we knew in the past as the "JRE". Marked as reviewed by sundar (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1559
Re: RFR: 8257533: legacy-jre-image includes jpackage and jlink tools
On Wed, 2 Dec 2020 10:16:13 GMT, Magnus Ihse Bursie wrote: > JEP 343 added jdk.jpackage to Module.gmk/JRE_TOOL_MODULES with the result > that the legacy-jre-image builds a run-time image that contains the package > and jlink tools. This seems to be an oversight as these tools should not be > in the equivalent of what we knew in the past as the "JRE". Marked as reviewed by alanb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1559
Integrated: 8257224: JDK-8251549 didn't update building.html
On Wed, 2 Dec 2020 10:01:03 GMT, Magnus Ihse Bursie wrote: > JDK-8251549 updated doc/building.md for building with git, but did not > include corresponding updates to doc/building.html. This pull request has now been integrated. Changeset: e7ca0c4a Author:Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/e7ca0c4a Stats: 39 lines in 1 file changed: 4 ins; 23 del; 12 mod 8257224: JDK-8251549 didn't update building.html Reviewed-by: sundar, shade - PR: https://git.openjdk.java.net/jdk/pull/1557
RFR: 8257533: legacy-jre-image includes jpackage and jlink tools
JEP 343 added jdk.jpackage to Module.gmk/JRE_TOOL_MODULES with the result that the legacy-jre-image builds a run-time image that contains the package and jlink tools. This seems to be an oversight as these tools should not be in the equivalent of what we knew in the past as the "JRE". - Commit messages: - 8257533: legacy-jre-image includes jpackage and jlink tools Changes: https://git.openjdk.java.net/jdk/pull/1559/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1559=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257533 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1559.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1559/head:pull/1559 PR: https://git.openjdk.java.net/jdk/pull/1559
Re: RFR: 8257224: JDK-8251549 didn't update building.html
On Wed, 2 Dec 2020 10:01:03 GMT, Magnus Ihse Bursie wrote: > JDK-8251549 updated doc/building.md for building with git, but did not > include corresponding updates to doc/building.html. Looks good! - Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1557
Re: RFR: 8257224: JDK-8251549 didn't update building.html
On Wed, 2 Dec 2020 10:01:03 GMT, Magnus Ihse Bursie wrote: > JDK-8251549 updated doc/building.md for building with git, but did not > include corresponding updates to doc/building.html. Marked as reviewed by sundar (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1557
RFR: 8257224: JDK-8251549 didn't update building.html
JDK-8251549 updated doc/building.md for building with git, but did not include corresponding updates to doc/building.html. - Commit messages: - 8257224: JDK-8251549 didn't update building.html Changes: https://git.openjdk.java.net/jdk/pull/1557/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1557=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257224 Stats: 39 lines in 1 file changed: 4 ins; 23 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/1557.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1557/head:pull/1557 PR: https://git.openjdk.java.net/jdk/pull/1557
