Re: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4]
On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is >> used to target a minimum Windows version we want to support. See also for >> more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are >> declared using conditional code. This enables you to use the compiler to >> detect whether your application uses functions that are not supported on its >> target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT >> in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible >> would make sense because we have this setting already at java_props_md.c >> (so targeting older Windows versions at other places is most likely not >> useful). > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup Marked as reviewed by alanb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8428
Re: RFR: 8286429: jpackageapplauncher build fails intermittently in Tier[45]
On Mon, 9 May 2022 23:18:47 GMT, Erik Joelsson wrote: > The way LauncherCommon.gmk is currently written, it's only meant to be > included from "make/module//Launcher.gmk", or at least only from one > single place for each module. This is because the man page generation that > happens in LauncherCommon.gmk is module global. For the jdk.jpackage module, > LauncherCommon.gmk is now called from two separate sub makefiles, both > make/module/jdk.jpackage/Lib.gmk and make/module/jdk.jpackage/Launcher.gmk. > These files are called from the top level targets jdk.jpackage-libs and > jdk.jpackage-launchers respectively. These top level targets are assumed to > be able to run independently of each other, which is normally fine, but now > they define the same rules for the same files. This creates a race where one > may be deleting files that the other one is creating, causing directories to > disappear while files are being written to them. This can fail the build, but > also risks silently corrupting the build. > > This patch fixes this by adding a conditional around the man page generation, > which helps guarantee that man pages are only processed when called from > make/module//Launcher.gmk. It's a bit of a hack, but it's building on > top of the existing design of piggybacking man page generation on the > launchers build. > > Also fixing broken whitespace further down in the file (tabs->space). Marked as reviewed by asemenyuk (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8618
Re: RFR: 8286429: jpackageapplauncher build fails intermittently in Tier[45]
On Mon, 9 May 2022 23:18:47 GMT, Erik Joelsson wrote: > The way LauncherCommon.gmk is currently written, it's only meant to be > included from "make/module//Launcher.gmk", or at least only from one > single place for each module. This is because the man page generation that > happens in LauncherCommon.gmk is module global. For the jdk.jpackage module, > LauncherCommon.gmk is now called from two separate sub makefiles, both > make/module/jdk.jpackage/Lib.gmk and make/module/jdk.jpackage/Launcher.gmk. > These files are called from the top level targets jdk.jpackage-libs and > jdk.jpackage-launchers respectively. These top level targets are assumed to > be able to run independently of each other, which is normally fine, but now > they define the same rules for the same files. This creates a race where one > may be deleting files that the other one is creating, causing directories to > disappear while files are being written to them. This can fail the build, but > also risks silently corrupting the build. > > This patch fixes this by adding a conditional around the man page generation, > which helps guarantee that man pages are only processed when called from > make/module//Launcher.gmk. It's a bit of a hack, but it's building on > top of the existing design of piggybacking man page generation on the > launchers build. > > Also fixing broken whitespace further down in the file (tabs->space). I'm still unclear how `--disable-manpages` is supposed to affect this logic, as they seemed to be the failing configs. - PR: https://git.openjdk.java.net/jdk/pull/8618
RFR: 8286429: jpackageapplauncher build fails intermittently in Tier[45]
The way LauncherCommon.gmk is currently written, it's only meant to be included from "make/module//Launcher.gmk", or at least only from one single place for each module. This is because the man page generation that happens in LauncherCommon.gmk is module global. For the jdk.jpackage module, LauncherCommon.gmk is now called from two separate sub makefiles, both make/module/jdk.jpackage/Lib.gmk and make/module/jdk.jpackage/Launcher.gmk. These files are called from the top level targets jdk.jpackage-libs and jdk.jpackage-launchers respectively. These top level targets are assumed to be able to run independently of each other, which is normally fine, but now they define the same rules for the same files. This creates a race where one may be deleting files that the other one is creating, causing directories to disappear while files are being written to them. This can fail the build, but also risks silently corrupting the build. This patch fixes this by adding a conditional around the man page generation, which helps guarantee that man pages are only processed when called from make/module//Launcher.gmk. It's a bit of a hack, but it's building on top of the existing design of piggybacking man page generation on the launchers build. Also fixing broken whitespace further down in the file (tabs->space). - Commit messages: - JDK-8286429 Changes: https://git.openjdk.java.net/jdk/pull/8618/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8618=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286429 Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8618.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8618/head:pull/8618 PR: https://git.openjdk.java.net/jdk/pull/8618
Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v43]
On Mon, 9 May 2022 18:09:51 GMT, ExE Boss wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix crashes in heap segment benchmarks due to misaligned access > > test/micro/org/openjdk/bench/java/lang/foreign/LoopOverPollutedSegments.java > line 69: > >> 67: static final ValueLayout.OfInt JAVA_INT_UNALIGNED = >> JAVA_INT.withBitAlignment(8); >> 68: static final ValueLayout.OfFloat JAVA_FLOAT_UNALIGNED = >> JAVA_FLOAT.withBitAlignment(8); >> 69: static final VarHandle intHandleUnaligned = >> JAVA_INT_UNALIGNED.arrayElementVarHandle(); > > To match `LoopOverNonConstantHeap`, this should probably be named > `VH_INT_UNALIGNED`. > > > > Maybe these could also be moved into > `org.openjdk.bench.java.lang.foreign.Utils`[^1] > > [^1]: > https://github.com/openjdk/jdk/blob/7b774297b1d04e104a988ea5bd2f2b04c8de3461/test/micro/org/openjdk/bench/java/lang/foreign/Utils.java#L29-L43 I noted other possible cleanups for benchmarks, I'll work on something after we integrate this PR as I'd like to minimize the churn. - PR: https://git.openjdk.java.net/jdk/pull/7888
Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments
On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona wrote: > Please review this patch adding new lint option, **lossy-conversions**, to > javac to warn about type casts in compound assignments with possible lossy > conversions. > > The new lint warning is shown if the type of the right-hand operand of a > compound assignment is not assignment compatible with the type of the > variable. > > The implementation of the warning is based on similar check performed to emit > "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and > negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules > and libraries to allow smooth JDK build. Individual cases to address possibly > lossy conversions warnings in JDK are already addressed in a separate > umbrella issue and its sub-tasks. > > Thanks for your review, > Adam I see there is already a bug filed to address situations found by the new warning in the JDK's libraries (JDK-8286374). As a matter of policy, I recommend the (potential) warnings be addressed in at least the java.base and java.desktop modules before the new warning is enabled. In other words, a priority should be given to keeping java.base and java.desktop compiling successfully with all warnings enabled. - PR: https://git.openjdk.java.net/jdk/pull/8599
RFR: 8286430: make test TEST="gtest:" exits with error when it shouldn't
`make test TEST="gtest:https://git.openjdk.java.net/jdk/pull/8605/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8605=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286430 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8605.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8605/head:pull/8605 PR: https://git.openjdk.java.net/jdk/pull/8605
Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v43]
On Mon, 9 May 2022 17:41:10 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: > > Fix crashes in heap segment benchmarks due to misaligned access test/micro/org/openjdk/bench/java/lang/foreign/LoopOverPollutedSegments.java line 69: > 67: static final ValueLayout.OfInt JAVA_INT_UNALIGNED = > JAVA_INT.withBitAlignment(8); > 68: static final ValueLayout.OfFloat JAVA_FLOAT_UNALIGNED = > JAVA_FLOAT.withBitAlignment(8); > 69: static final VarHandle intHandleUnaligned = > JAVA_INT_UNALIGNED.arrayElementVarHandle(); To match `LoopOverNonConstantHeap`, this should probably be named `VH_INT_UNALIGNED`. Maybe these could also be moved into `org.openjdk.bench.java.lang.foreign.Utils`[^1] [^1]: https://github.com/openjdk/jdk/blob/7b774297b1d04e104a988ea5bd2f2b04c8de3461/test/micro/org/openjdk/bench/java/lang/foreign/Utils.java#L29-L43 - PR: https://git.openjdk.java.net/jdk/pull/7888
Re: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4]
On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is >> used to target a minimum Windows version we want to support. See also for >> more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are >> declared using conditional code. This enables you to use the compiler to >> detect whether your application uses functions that are not supported on its >> target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT >> in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible >> would make sense because we have this setting already at java_props_md.c >> (so targeting older Windows versions at other places is most likely not >> useful). > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup Marked as reviewed by prr (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8428
Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments
On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona wrote:
> Please review this patch adding new lint option, **lossy-conversions**, to
> javac to warn about type casts in compound assignments with possible lossy
> conversions.
>
> The new lint warning is shown if the type of the right-hand operand of a
> compound assignment is not assignment compatible with the type of the
> variable.
>
> The implementation of the warning is based on similar check performed to emit
> "possible lossy conversion" compilation error for simple assignments.
>
> Proposed patch also include complex matrix-style test with positive and
> negative test cases of lossy conversions in compound assignments.
>
> Proposed patch also disables this new lint option in all affected JDK modules
> and libraries to allow smooth JDK build. Individual cases to address possibly
> lossy conversions warnings in JDK are already addressed in a separate
> umbrella issue and its sub-tasks.
>
> Thanks for your review,
> Adam
Marked as reviewed by prr (Reviewer).
test/langtools/tools/javac/lint/LossyConversions.java line 131:
> 129: @SuppressWarnings("lossy-conversions")
> 130: public void supressedLossyConversions() {
> 131: byte a = 0;
you might want to spell suppressed correctly.
-
PR: https://git.openjdk.java.net/jdk/pull/8599
Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v43]
> 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: Fix crashes in heap segment benchmarks due to misaligned access - Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/3c88a2ef..7b774297 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7888=42 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7888=41-42 Stats: 41 lines in 2 files changed: 3 ins; 4 del; 34 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: 8244681: Add a warning for possibly lossy conversion in compound assignments
On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona wrote: > Please review this patch adding new lint option, **lossy-conversions**, to > javac to warn about type casts in compound assignments with possible lossy > conversions. > > The new lint warning is shown if the type of the right-hand operand of a > compound assignment is not assignment compatible with the type of the > variable. > > The implementation of the warning is based on similar check performed to emit > "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and > negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules > and libraries to allow smooth JDK build. Individual cases to address possibly > lossy conversions warnings in JDK are already addressed in a separate > umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Build changes look good. - Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8599
RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments
Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. Thanks for your review, Adam - Commit messages: - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments - 8244681: Add a warning for possibly lossy conversion in compound assignments Changes: https://git.openjdk.java.net/jdk/pull/8599/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8599=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244681 Stats: 449 lines in 26 files changed: 444 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.java.net/jdk/pull/8599
Fwd: JDK 19+21 early-access build is reproducible
Just a FYI: The fix of the last remaining bug towards full reproducibility (on Linux, at least) of the JDK was given attention on the reproducible-builds mailing list. /Magnus Forwarded Message Subject:JDK 19+21 early-access build is reproducible Date: Fri, 6 May 2022 13:48:20 -0700 From: John Neffenger Reply-To: General discussions about reproducible builds Organization: Status Six Communications To: Reproducible Builds List Starting yesterday, for the first time, the JDK can create reproducible builds of the JDK! Pull request 8478 [1] was the last reproducibility bug remaining in my JDK builds on Linux, and it's included in the latest JDK 19+21 early-access build. [2] OpenJDK 19 will be generally available on September 20, 2022. That also means there's nothing in the JDK that's holding back any Java application from having reproducible builds. The link below lists all the "reproducible build" fixes for OpenJDK: https://bugs.openjdk.java.net/issues/?jql=labels+%3D+reproducible-build I tested on six Linux architectures (amd64, arm64, armhf, i386, ppc64el, s390x), and the entire JDK is reproducible including the command-line tools, demos, API documentation, JMOD archives, native libraries, and man pages -- even when using a different build path. Note that I didn't test on macOS or Windows. A big thank you to Magnus Ihse Bursie and Andrew Leonard for doing much of the work to make this possible. John [1]: https://github.com/openjdk/jdk/pull/8478 [2]: https://jdk.java.net/19/
Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v42]
> 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 with a new target base due to a merge or a rebase. The pull request now contains 62 commits: - Merge branch 'master' into foreign-preview - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com> - Add tests for loaderLookup/restricted method corner cases - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI * Tweak restricted method check to work when there's no caller class - Tweak examples in SymbolLookup javadoc - Merge branch 'master' into foreign-preview - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com> - Tweak support for Linker lookup Improve javadoc of SymbolLookup - Tweak Addressable javadoc - Downcall and upcall tests use wrong layout which is missing some trailing padding - ... and 52 more: https://git.openjdk.java.net/jdk/compare/39f4434f...3c88a2ef - Changes: https://git.openjdk.java.net/jdk/pull/7888/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7888=41 Stats: 65712 lines in 373 files changed: 43721 ins; 19432 del; 2559 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
