From alanb at openjdk.org Mon May 1 05:52:22 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 May 2023 05:52:22 GMT Subject: RFR: 8303796: Optionally build fully statically linked JDK image In-Reply-To: <-LR0qy8lzfy0N6sksIJNnVxAIesh0yQmRNYrG5pvG2I=.52637aed-bbc2-4ea8-a134-d148c91f2953@github.com> References: <-LR0qy8lzfy0N6sksIJNnVxAIesh0yQmRNYrG5pvG2I=.52637aed-bbc2-4ea8-a134-d148c91f2953@github.com> Message-ID: On Sun, 30 Apr 2023 18:53:40 GMT, Jorn Vernee wrote: > It seems that letting jlink do the linking is also a requirement for user provided modules (.jmods) that contain native libraries (as is the case for instance with jextract). We don't know about those libraries when building the JDK. For now yes, but if there are further steps to have it create a single executable then the classes/resources will also be included. So I think pure Java modules will also be in this picture, eventually. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1529373589 From jlaskey at openjdk.org Mon May 1 12:10:55 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 1 May 2023 12:10:55 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) [v2] In-Reply-To: <5Gfuey8swtt5kH7aGU7aQNwU80KcoCFJ2hZxxGO2tnk=.75eb7117-299b-449a-b3a2-6ef27de44ac0@github.com> References: <5Gfuey8swtt5kH7aGU7aQNwU80KcoCFJ2hZxxGO2tnk=.75eb7117-299b-449a-b3a2-6ef27de44ac0@github.com> Message-ID: On Thu, 27 Apr 2023 18:00:38 GMT, Jim Laskey wrote: >> src/java.base/share/native/libjli/java.c line 590: >> >>> 588: CHECK_EXCEPTION_NULL_LEAVE(mainID); >>> 589: (*env)->CallVoidMethod(env, mainObject, mainID); >>> 590: break; >> >> This calls into LauncherHelper to get the "main type", then calls the static or new/instance method. I'm wondering if you tried have a single entry point in LauncherHelper instead. I think the only downside might be that the trampoline would show up in stack traces but @Hidden could hide that. > > Good idea. If @hidden doesn't work then we can eat the trace entries. Many dependencies (ex. JDI) on main being the first frame. Will set up a separate RFE witch should include using the LauncherHelper in the source code launcher. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1181532559 From jlaskey at openjdk.org Mon May 1 13:06:24 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 1 May 2023 13:06:24 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview) [v8] In-Reply-To: References: Message-ID: > Add flexible main methods and anonymous main classes to the Java language. Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: - Anonymous main classes renamed to unnamed classes - Add test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13689/files - new: https://git.openjdk.org/jdk/pull/13689/files/a09a0a1b..ff7cd4c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=06-07 Stats: 314 lines in 14 files changed: 151 ins; 135 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/13689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689 PR: https://git.openjdk.org/jdk/pull/13689 From erikj at openjdk.org Mon May 1 14:21:23 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 1 May 2023 14:21:23 GMT Subject: RFR: 8303796: Optionally build fully statically linked JDK image In-Reply-To: References: <_gIwWxLooIGNt-PhNASB-dj32BvyljayoyLXOkNLXYA=.e90e720f-5618-4330-a2d3-91a102bd546f@github.com> Message-ID: On Fri, 28 Apr 2023 23:25:17 GMT, Erik Joelsson wrote: >>> I pulled this PR and had a go at building it. For me it failed with errors like this: >>> >>> ``` >>> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::Linux::fast_thread_clock_init(): error: undefined reference to 'clock_getres' >>> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::Linux::fast_thread_cpu_time(int): error: undefined reference to 'clock_gettime' >>> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::current_thread_cpu_time(): error: undefined reference to 'clock_gettime' >>> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::thread_cpu_time(Thread*): error: undefined reference to 'clock_gettime' >>> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::current_thread_cpu_time(bool): error: undefined reference to 'clock_gettime' >>> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::init_2(): error: undefined reference to 'clock_getres' >>> ``` >>> >>> I haven't dug any deeper to try to figure this out. Is this something you recognize? >> >> Erik, could you please share your `support/native/java.base/java/BUILD_LAUNCHER_javastatic_static_link.cmdline`? This generated .cmdline file contains the static linking command. Here is the linking command from my build: >> >> >> /usr/bin/gcc -Wl,-z,defs -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,--hash-style=gnu -m64 -static-libstdc++ -static-libgcc -Wl,-rpath,$ORIGIN/. -Wl,--export-dynamic -o /.../build/linux-x86_64-server-slowdebug/jdk/bin/javastatic /.../linux-x86_64-server-slowdebug/support/native/java.base/java/main.o -Wl,--whole-archive /.../linux-x86_64-server-slowdebug/images/static-libs/lib/libattach.a ... /.../linux-x86_64-server-slowdebug/images/static-libs/lib/libjvm.a -Wl,--no-whole-archive -lpthread -ldl -lm -l:libstdc++.a >> >> >> `clock_getres` and the other related symbols are provided by `libc`. For `libc`, we don't static link with. We still use `libc.so`. >> >> >> $ ldd jdk/bin/javastatic >> linux-vdso.so.1 (0x00007fff8b17a000) >> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0845321000) >> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0845140000) >> /lib64/ld-linux-x86-64.so.2 (0x00007f084888d000) >> >> >> >> $ objdump -Tw /lib/x86_64-linux-gnu/libc.so.6 | grep clock_getres >> 00000000000cf260 g DF .text 0000000000000069 GLIBC_2.17 clock_getres >> 00000000000cf260 g DF .text 0000000000000069 (GLIBC_2.2.5) clock_getres >> >> $ nm jdk/bin/javastatic | grep clock_gettime >> U clock_gettime at GLIBC_2.17 >> $ nm jdk/bin/javastatic | grep clock_getres >> U clock_getres at GLIBC_2.17 > >> Erik, could you please share your `support/native/java.base/java/BUILD_LAUNCHER_javastatic_static_link.cmdline`? This generated .cmdline file contains the static linking command. Here is the linking command from my build: > > I can't see any significant difference. I'm using a devkit created using the devkit makefiles. > > > .../devkit-linux_x64-gcc11.2.0-OL6.4+1.0.tar.gz/x86_64-linux-gnu-to-x86_64-linux-gnu/bin/gcc -Wl,-z,defs -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,--hash-style=gnu -m64 -static-libstdc++ -static-libgcc -Wl,-rpath,$ORIGIN/. -Wl,--export-dynamic -o .../build/linux-x64/jdk/bin/javastatic /home/erik/git/jdk/build/linux-x64/support/native/java.base/java/main.o -Wl,--whole-archive .../build/linux-x64/images/static-libs/lib/libattach.a ... .../build/linux-x64/images/static-libs/lib/libjvm.a -Wl,--no-whole-archive -lpthread -ldl -lm -l:libstdc++.a > Based on the above finding, I pushed a change to use $(JVM_LIBS) for the linking command. @erikj79 could you please see if that resolves the clock_* symbol issues in your environment? Yes, it built cleanly with that change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1529742147 From rriggs at openjdk.org Mon May 1 15:41:24 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 1 May 2023 15:41:24 GMT Subject: Integrated: 8304915: Create jdk.internal.util.Architecture enum and apply In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Wed, 5 Apr 2023 15:58:08 GMT, Roger Riggs wrote: > Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. > The enumeration values are defined to match those used in the build. > The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` > Note that `amd64` and `x86_64` in the build are represented by `X64`. > The value of the system property `os.arch` is unchanged. > > The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). > Uses in `java.base` and a few others are included but other modules will be done in separate PRs. This pull request has now been integrated. Changeset: f00a748b Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/f00a748bc5b708d4f8f277d075859b058f9d575c Stats: 411 lines in 7 files changed: 343 ins; 57 del; 11 mod 8304915: Create jdk.internal.util.Architecture enum and apply Reviewed-by: erikj, mdoerr, amitkumar ------------- PR: https://git.openjdk.org/jdk/pull/13357 From jiangli at openjdk.org Mon May 1 21:57:20 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 1 May 2023 21:57:20 GMT Subject: RFR: 8303796: Optionally build fully statically linked JDK image In-Reply-To: References: Message-ID: <7jnvkVtSNboXfFD3ij19fWwDACENTUbFfBYf4_RCoP8=.21fc70f5-0470-4f4a-8770-b8aee9744e09@github.com> On Sun, 30 Apr 2023 18:34:12 GMT, Alan Bateman wrote: > > The build is already capable of producing .a files and this patch is building on top of that build feature. The current .a file creation is used by the downstream graal build which needs it for nativeimage. > > Also builds on recent changes to remove duplicate symbol names. It's good that the PR demonstrates that these can be linked to create "javastatic" but having it copy into the run-time image created by jlink is probably not the eventual outcome. > > A possible direction on this is for the build to create a set of packaged modules with the .a files, then have an alternative image builder in jlink that integrates with the native linker. Combined with other parts in Jiangli's slides/proposal, it would mean that jlink could produce a single executable that would work for both the JDK or any set of modules. The comment from @AlanBateman helped me realize that I should be more specific (in my earlier comment regarding "withdraw the current PR first and extract the .a part into a new PR") about the needed fixes/enhancements related to .a part: - Create libjvm.a as well when building static-libs-image target, include it in 'images/static-libs/lib' - Filter out "external" .o files (those are the .o files included from different JDK libraries and needed when creating the .so shared library only) from .a libraries - For libjvm.a specifically, exclude operator_new.o - Handle long arguments case for static build in make/common/NativeCompilation.gmk - Ensure zlib and freetype are bundled when building the static-libs-image target, i.e. libzlib.a and libfreetype.a are included in 'images/static-libs/lib' It's probably best to create a separate enhancement/bug for those (will create shortly) and continue using JDK-8303796 for the broader discussion/effort. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1530368068 From jiangli at openjdk.org Mon May 1 21:57:21 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 1 May 2023 21:57:21 GMT Subject: RFR: 8303796: Optionally build fully statically linked JDK image In-Reply-To: References: <_gIwWxLooIGNt-PhNASB-dj32BvyljayoyLXOkNLXYA=.e90e720f-5618-4330-a2d3-91a102bd546f@github.com> Message-ID: On Mon, 1 May 2023 14:03:10 GMT, Erik Joelsson wrote: > > Based on the above finding, I pushed a change to use $(JVM_LIBS) for the linking command. @erikj79 could you please see if that resolves the clock_* symbol issues in your environment? > > Yes, it built cleanly with that change. Thanks for confirm. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1530369506 From jiangli at openjdk.org Mon May 1 22:50:27 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 1 May 2023 22:50:27 GMT Subject: RFR: 8303796: Optionally build fully statically linked JDK image [v2] In-Reply-To: References: Message-ID: On Sat, 29 Apr 2023 03:57:53 GMT, Jiangli Zhou wrote: >> Initial implementation for supporting building a fully statically linked (with a desired set of JDK native libraries and libjvm) Java launcher executable, which is named as 'javastatic'. >> >> In this PR, the support is only added for the linux platform. Both gcc and clang can be supported. For current demo/testing purpose, the bin/javastatic is statically linked with awt headless and other common JDK native libraries. The current PR doesn't fully handle creating the bundle for a static JDK image, which can be supported later. >> >> To build the statically linked executable: >> >> 1. Configure the JDK build with --with-static-java=yes >> 2. Build static-java-image, e.g. 'make jdk-image static-java-image' >> >> The 'javastatic' binary created by the static-java-image target is not runnable. The runtime issues will be handled separately. >> >> Following is a summary of the changes in this PR: >> >> - Add make/autoconf/static-java.m4 for defining STATIC_JAVA_SETUP. Add STATIC_JAVA_SETUP to make/autoconf/configure.ac. >> >> - Changes in make/Main.gmk >> ? - Add HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and DeclareHotspotStaticLibsRecipe for building libjvm static library. >> ? - Add static-java-image for creating the fully statically linked standard Java launcher binary, bin/javastatic. The build process also places libjvm.a into the 'static-libs' image lib/ directory. >> >> - Add make/StaticLink.gmk, which contains the main support for creating the fully statically linked Java launcher binary. >> >> - Setup LDFLAGS_CXX_STATIC_JDK based on $TOOLCHAIN_TYPE in make/autoconf/flags-ldflags.m4. >> >> - Always use bundled libraries for zlib, freetype, etc for static build support. The related changes are in make/autoconf/lib-bundled.m4 and make/autoconf/lib-freetype.m4. Building the bundled zlib, freetype and etc libraries ensures those libraries are included in the JDK binary bundle. It decouples the assumptions/requirements of the static Java image build process from the assumptions/requirements of the JDK build process. A post process that builds the static Java image can use those bundled libraries provided by JDK binary if needed. >> >> - When building a fully statically linked java launcher executable, the --whole-archive linker option is used for the JDK/VM static libraries to make sure it links every object (.o) file provided by those static libraries. As a result, we need to remove any duplicate object files from the different JDK/VM static libraries. To do that, STATIC_LIB_EXCLUDE_OBJS is added and used in make/common/NativeCompilation.gmk. STATIC_LIB_EXCLUDE_OBJS contains the list of object files that need to be filtered out when creating a specific static library. STATIC_LIB_EXCLUDE_OBJS is defined for JDK/VM static libraries that may contain object files from other libraries (those are needed when building shared libraries), and those object files are added to the STATIC_LIB_EXCLUDE_OBJS. See make/hotspot/lib/CompileJvm.gmk, make/modules/java.base/lib/CoreLibraries.gmk and make/modules/java.desktop/lib/Awt2dLibraries.gmk. >> >> - In make/common/NativeCompilation.gmk, move the code handling long arguments so that it can be used for the static build support as well. >> >> - In make/hotspot/lib/CompileJvm.gmk, it specifies to exclude operator_new.o from the libjvm static library. See details in the comment added in CompileJvm.gmk. >> >> Thanks manc for a bug fix for JAVASTATIC_OBJECT_DIR in StaticLink.gmk. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Use $(JVM_LIBS), which includes -lrt on Linux currently. > Created https://bugs.openjdk.org/browse/JDK-8307194 for the need static library (.a handling) enhancements. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1530481290 From duke at openjdk.org Tue May 2 00:07:26 2023 From: duke at openjdk.org (duke) Date: Tue, 2 May 2023 00:07:26 GMT Subject: Withdrawn: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5 only on linux-aarch64 In-Reply-To: References: Message-ID: On Mon, 27 Feb 2023 11:49:27 GMT, Jayathirth D V wrote: > Under https://bugs.openjdk.org/browse/JDK-8264846 we moved to -O3 level of gcc optimizations from -O1 level for libawt build. This improved our J2DBench performance numbers in some options considerably. > > Recent changes done under https://bugs.openjdk.org/browse/JDK-8299337 causes difference in generated code by gcc and this is resulting in performance regression for bimg_misc-* J2DBench options in our performance servers. Under https://bugs.openjdk.org/browse/JDK-8299337 we have just removed unused variables and it is a cleanup task. > > We can force gcc to generate position independent code by using -fpic option.Also i have removed -fgcse-after-reload option for gcc, because this is by default covered under -O3 level of optimization introduced under https://bugs.openjdk.org/browse/JDK-8264846. > > With this change bimg_misc-* J2DBench option performance regression is resolved and there are no regression in other options of J2DBench or SwingMark and it is verified in our performance servers. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/12761 From jiangli at openjdk.org Wed May 3 02:16:08 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 02:16:08 GMT Subject: RFR: 8307194: Enhance static-libs-image Message-ID: This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; - For libjvm.a specifically, exclude operator_new.o; - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; - Handle long arguments case for static build in make/common/NativeCompilation.gmk; - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; ------------- Commit messages: - Remove unused $$($1_EXTRA_ARGS) from DeclareHotspotLibsRecipe. - 8307194: Enhance static-libs-image Changes: https://git.openjdk.org/jdk/pull/13768/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307194 Stats: 146 lines in 6 files changed: 100 ins; 34 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From jiangli at openjdk.org Wed May 3 02:18:17 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 02:18:17 GMT Subject: RFR: 8303796: Optionally build fully statically linked JDK image [v2] In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 19:32:40 GMT, Erik Joelsson wrote: > This is the same list as the LIBJLI_EXTRA_FILES above. Would be good to avoid the duplication. @erikj79 Addressed in the extracted https://github.com/openjdk/jdk/pull/13768, which contains .a related changes only (without linking 'javastatic' part), thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1183188806 From jiangli at openjdk.org Wed May 3 03:03:21 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 03:03:21 GMT Subject: RFR: 8303796: Optionally build fully statically linked JDK image [v2] In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 19:34:40 GMT, Erik Joelsson wrote: >> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: >> >> Use $(JVM_LIBS), which includes -lrt on Linux currently. > > make/modules/java.desktop/lib/Awt2dLibraries.gmk line 228: > >> 226: # static libraries cause linking errors due to duplicate symbols. >> 227: LIBAWT_XAWT_STATIC_EXCLUDE_OBJS := \ >> 228: debug_assert.o debug_util.o debug_trace.o debug_mem.o systemScale.o > > Can this list be derived dynamically in some way? If they are all in the same directory, maybe we could base it on that instead of having to maintain an explicit list? With additional testing, I found 'debug_assert.o debug_util.o debug_trace.o debug_mem.o' are no longer included when building libawt_xawt, using JDK head code base. We no longer need to be filtered out those for libawt_xawt.a. They were needed for JDK 11. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1183201634 From jlahoda at openjdk.org Wed May 3 09:35:03 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 3 May 2023 09:35:03 GMT Subject: RFR: JDK-8306983: Do not invoke external programs when switch terminal to raw mode on selected platforms Message-ID: To support JShell and other usecases, the JDK uses JLine, which provides line-editing functionality inside a terminal. JLine has several ways to work with the terminal, based on various additional libraries and tools. Most of them are not directly usable inside the JDK, so currently, on non-Windows platforms, the JLine inside the JDK will use external programs, like `stty`, to inspect the terminal's properties and to switch the terminal to raw mode. This is slightly problematic, as the external programs might be missing, and while this is not that big problem for JShell, it might be a problem for other potential uses of JLine, like using it inside `System.console()`. So, the proposal here is to call the corresponding native methods directly, on selected platforms for now (Linux and Mac OS/X), instead of invoking the external programs. On Windows, this has always been the case, we are using a custom implementation of the interface that maps native and Java function for JNA there, and the proposal is to do the same here. We take the appropriate mapping interface for JNA, and provide hand-written implementation for it, using JNI. The Windows implementation is mostly unchanged, the changes are mostly non-Windows only. The overview of the changes is: - `LastErrorException` is moved from the Windows-specific code to the platform-neutral code, as it is used by all the native implementations. This is the only change that directly affects the Windows-specific code - `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java` and `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java` are created based on the corresponding files from JLine. In JLine, these files directly call platform-specific implementations, but in this patch, the platform specific code is commented out, and replaced with calls to `JDKNativePty`, which is a new platform-specific class, that delegates to the actual platform-specific implementations. Note the `JnaNativePty.java` and `JnaTerminalProvider.java` already exist in the Windows part, but have different pieces of code commented out, which makes them substantially different. - for Linux and Mac OS/X, there are platform-specific implementations based on the corresponding code from JLine, with the hand-written JNI-based implementation of the JNA-based existing interfaces. They also have an implementation of `JDKNativePty`, which just delegates to the given platform's `"NativePty"` implementation. - the `JdkConsoleProviderImpl.java` has been tweaked to not allow the implementation based on the external programs, and gracefully falling back to the standard implementation. JShell is kept unchanged. The reasons for this organization are: limiting duplication, mostly adhering to the JDK's platform specific build (which is different from the normal JLine's platform-neutral build) and limiting the difference between standard JLine and JLine inside JDK, to help future upgrades. ------------- Commit messages: - Removing tabs - Adding handling of errors in the jni code. - Permit dumb terminals. - Only create JLine-based Console when the direct terminal access passes. - Attempting to minimize the diff between JDK and vanilla JLine on Mac. - Reorganizing the native classes. - mac impl - Using direct native calls instead of stty on Linux. Changes: https://git.openjdk.org/jdk/pull/13687/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13687&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306983 Stats: 2144 lines in 23 files changed: 2096 ins; 40 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/13687.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13687/head:pull/13687 PR: https://git.openjdk.org/jdk/pull/13687 From stefank at openjdk.org Wed May 3 09:58:52 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 3 May 2023 09:58:52 GMT Subject: RFR: 8307058: Implementation of Generational ZGC Message-ID: Hi all, Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention is to give the users time to validate and deploy their workloads with the new GC implementation. Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clear to us how time consuming and complex things end up being when we tried to keep both the original G1 working, and at the same time implemented the ZGC-alike G1. Given this experience, we don't see that as a viable solution to deliver a maintainable and evolving Generational ZGC. Our pragmatic suggestion to these challenges is to let Generational ZGC live under the current gc/z directories and let the legacy, non-generational ZGC be completely separated in its own directories. This way we can continue to move quickly with the continued developme nt of Generational ZGC and let the non-generational ZGC be mostly untouched until it gets deprecated, and eventually removed. The non-generational ZGC directory will be gc/x and all the classes of non-generational have been prefixed with X instead of Z. An alternative to this rename could be to namespace out non-generational ZGC. We experimented with that, but it was too easy to accidentally cross-compile Generational ZGC code into non-generational ZGC, so we didn't like that approach. Most of the stand-alone cleanups and enhancements outside of the ZGC code have already been upstreamed to openjdk/jdk. There are still a few patches that could/should be pushed separately, but they will be easier to understand by also looking at the Generational ZGC code, so they will be sent out after this PR has been published. The patches that could be published separately are: * 59d1e96af6a UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class * ca9edf8aa79 UPSTREAM: RISCV tmp reg cleanup resolve_jobject * 4bec9c69b67 CLEANUP: barrierSetNMethod_aarch64.cpp * b67d03a3f04 UPSTREAM: Add relaxed add&fetch for aarch64 atomics * a2824734d23 UPSTREAM: lir_xchg * 36cd39c0126 UPSTREAM: assembler_ppc CMPLI * 447259cea42 UPSTREAM: assembler_ppc ANDI * 9417323499a UPSTREAM: Add VMErrorCallback infrastructure Regarding all the changesets you see in this PR, they form the history of the development of Generational ZGC. It might look a bit unconventional to what you are used to see in openjdk development. What we have done is to use merges with the 'ours' strategy to ignore the previous Generational ZGC patches, and then rebased and flattened the changes on top of the merge. This effectively gives us the upsides of having a rebased repository and the upsides of retaining the history in the repository. The downside could be that GitHub now lists all those changesets in the PR. Given that this patch is so big, and that you likely only want to see a part of it, I suggest that you pull down the PR branch and then compare it to the openjdk/jdk changeset this PR is based against: git fetch https://github.com/openjdk/zgc zgc_master git diff zgc_master... There have been many contributors of this patch over the years. I'll do my best to poke Skara into listing you all, but if you see that I've missed your name please reach out to me and I'll fix it. Testing: we have been continuously running Generational ZGC through Oracle's tier1-8 testing. ------------- Commit messages: - Whitespace fixes - Copyright fixes - Style, cleanups, and copyright years - Disable ThreadMemoryLeakTest.java for generational ZGC - Fix single gen too early verify_oop - Add vm.opt.final.ZGenerational to JFR event tests - Fix tenuring threshold bounds calculation - Sub code size x86_64 - Stub code size aarch64 - Fix TestStringDeduplicationTools.java for X - ... and 892 more: https://git.openjdk.org/jdk/compare/750bece0...62a4f788 Changes: https://git.openjdk.org/jdk/pull/13771/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13771&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307058 Stats: 67415 lines in 690 files changed: 58209 ins; 4275 del; 4931 mod Patch: https://git.openjdk.org/jdk/pull/13771.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13771/head:pull/13771 PR: https://git.openjdk.org/jdk/pull/13771 From eosterlund at openjdk.org Wed May 3 10:01:28 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 3 May 2023 10:01:28 GMT Subject: RFR: 8307058: Implementation of Generational ZGC In-Reply-To: References: Message-ID: On Wed, 3 May 2023 09:04:50 GMT, Stefan Karlsson wrote: > Hi all, > > Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. > > The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention i s to give the users time to validate and deploy their workloads with the new GC implementation. > > Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clear to us how time consuming and complex things end up being when we tried to keep both the original G1 working, and at the same time implemented the ZGC-alike G1. Given this experience, we don't see that as a viable solution to deliver a maintainable and evolving Generational ZGC. Our pragmatic suggestion to these challenges is to let Generational ZGC live under the current gc/z directories and let the legacy, non-generational ZGC be completely separated in its own directories. This way we can continue to move quickly with the continued develop ment of Generational ZGC and let the non-generational ZGC be mostly untouched until it gets deprecated, and eventually removed. The non-generational ZGC directory will be gc/x and all the classes of non-generational have been prefixed with X instead of Z. An alternative to this rename could be to namespace out non-generational ZGC. We experimented with that, but it was too easy to accidentally cross-compile Generational ZGC code into non-generational ZGC, so we didn't like that approach. > > Most of the stand-alone cleanups and enhancements outside of the ZGC code have already been upstreamed to openjdk/jdk. There are still a few patches that could/should be pushed separately, but they will be easier to understand by also looking at the Generational ZGC code, so they will be sent out after this PR has been published. The patches that could be published separately are: > > * 59d1e96af6a UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class > * ca9edf8aa79 UPSTREAM: RISCV tmp reg cleanup resolve_jobject > * 4bec9c69b67 CLEANUP: barrierSetNMethod_aarch64.cpp > * b67d03a3f04 UPSTREAM: Add relaxed add&fetch for aarch64 atomics > * a2824734d23 UPSTREAM: lir_xchg > * 36cd39c0126 UPSTREAM: assembler_ppc CMPLI > * 447259cea42 UPSTREAM: assembler_ppc ANDI > * 9417323499a UPSTREAM: Add VMErrorCallback infrastructure > > Regarding all the changesets you see in this PR, they form the history of the development of Generational ZGC. It might look a bit unconventional to what you are used to see in openjdk development. What we have done is to use merges with the 'ours' strategy to ignore the previous Generational ZGC patches, and then rebased and flattened the changes on top of the merge. This effectively gives us the upsides of having a rebased repository and the upsides of retaining the history in the repository. The downside could be that GitHub now lists all those changesets in the PR. Given that this patch is so big, and that you likely only want to see a part of it, I suggest that you pull down the PR branch and then compare it to the openjdk/jdk changeset this PR is based against: > > > git fetch https://github.com/openjdk/zgc zgc_master > git diff zgc_master... > > > There have been many contributors of this patch over the years. I'll do my best to poke Skara into listing you all, but if you see that I've missed your name please reach out to me and I'll fix it. > > Testing: we have been continuously running Generational ZGC through Oracle's tier1-8 testing. I have obviously stared at this code since its inception. To me it doesn't just look good, it looks fantastic. ------------- Marked as reviewed by eosterlund (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13771#pullrequestreview-1410554817 From stefank at openjdk.org Wed May 3 10:55:49 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 3 May 2023 10:55:49 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v2] In-Reply-To: References: Message-ID: > Hi all, > > Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. > > The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention i s to give the users time to validate and deploy their workloads with the new GC implementation. > > Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clear to us how time consuming and complex things end up being when we tried to keep both the original G1 working, and at the same time implemented the ZGC-alike G1. Given this experience, we don't see that as a viable solution to deliver a maintainable and evolving Generational ZGC. Our pragmatic suggestion to these challenges is to let Generational ZGC live under the current gc/z directories and let the legacy, non-generational ZGC be completely separated in its own directories. This way we can continue to move quickly with the continued develop ment of Generational ZGC and let the non-generational ZGC be mostly untouched until it gets deprecated, and eventually removed. The non-generational ZGC directory will be gc/x and all the classes of non-generational have been prefixed with X instead of Z. An alternative to this rename could be to namespace out non-generational ZGC. We experimented with that, but it was too easy to accidentally cross-compile Generational ZGC code into non-generational ZGC, so we didn't like that approach. > > Most of the stand-alone cleanups and enhancements outside of the ZGC code have already been upstreamed to openjdk/jdk. There are still a few patches that could/should be pushed separately, but they will be easier to understand by also looking at the Generational ZGC code, so they will be sent out after this PR has been published. The patches that could be published separately are: > > * 59d1e96af6a UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class > * ca9edf8aa79 UPSTREAM: RISCV tmp reg cleanup resolve_jobject > * 4bec9c69b67 CLEANUP: barrierSetNMethod_aarch64.cpp > * b67d03a3f04 UPSTREAM: Add relaxed add&fetch for aarch64 atomics > * a2824734d23 UPSTREAM: lir_xchg > * 36cd39c0126 UPSTREAM: assembler_ppc CMPLI > * 447259cea42 UPSTREAM: assembler_ppc ANDI > * 9417323499a UPSTREAM: Add VMErrorCallback infrastructure > > Regarding all the changesets you see in this PR, they form the history of the development of Generational ZGC. It might look a bit unconventional to what you are used to see in openjdk development. What we have done is to use merges with the 'ours' strategy to ignore the previous Generational ZGC patches, and then rebased and flattened the changes on top of the merge. This effectively gives us the upsides of having a rebased repository and the upsides of retaining the history in the repository. The downside could be that GitHub now lists all those changesets in the PR. Given that this patch is so big, and that you likely only want to see a part of it, I suggest that you pull down the PR branch and then compare it to the openjdk/jdk changeset this PR is based against: > > > git fetch https://github.com/openjdk/zgc zgc_master > git diff zgc_master... > > > There have been many contributors of this patch over the years. I'll do my best to poke Skara into listing you all, but if you see that I've missed your name please reach out to me and I'll fix it. > > Testing: we have been continuously running Generational ZGC through Oracle's tier1-8 testing. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Fix PPC build after 8305668 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13771/files - new: https://git.openjdk.org/jdk/pull/13771/files/62a4f788..da7fdde5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13771&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13771&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13771.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13771/head:pull/13771 PR: https://git.openjdk.org/jdk/pull/13771 From mdoerr at openjdk.org Wed May 3 12:32:31 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 3 May 2023 12:32:31 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v2] In-Reply-To: References: Message-ID: <6A1nfkn9o4N_h6W4aY_0XT_jW5h478GmIF8B-ZNI4wk=.232e8290-55fd-4a7a-9341-ebb1522423e4@github.com> On Wed, 3 May 2023 10:55:49 GMT, Stefan Karlsson wrote: >> Hi all, >> >> Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. >> >> The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention is to give the users time to validate and deploy their workloads with the new GC implementation. >> >> Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clear to us how time consuming and complex things end up being when we tried to keep both the original G1 working, and at the same time implemented the ZGC-alike G1. Given this experience, we don't see that as a viable solution to deliver a maintainable and evolving Generational ZGC. Our pragmatic suggestion to these challenges is to let Generational ZGC live under the current gc/z directories and let the legacy, non-generational ZGC be completely separated in its own directories. This way we can continue to move quickly with the continued develo pment of Generational ZGC and let the non-generational ZGC be mostly untouched until it gets deprecated, and eventually removed. The non-generational ZGC directory will be gc/x and all the classes of non-generational have been prefixed with X instead of Z. An alternative to this rename could be to namespace out non-generational ZGC. We experimented with that, but it was too easy to accidentally cross-compile Generational ZGC code into non-generational ZGC, so we didn't like that approach. >> >> Most of the stand-alone cleanups and enhancements outside of the ZGC code have already been upstreamed to openjdk/jdk. There are still a few patches that could/should be pushed separately, but they will be easier to understand by also looking at the Generational ZGC code, so they will be sent out after this PR has been published. The patches that could be published separately are: >> >> * 59d1e96af6a UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class >> * ca9edf8aa79 UPSTREAM: RISCV tmp reg cleanup resolve_jobject >> * 4bec9c69b67 CLEANUP: barrierSetNMethod_aarch64.cpp >> * b67d03a3f04 UPSTREAM: Add relaxed add&fetch for aarch64 atomics >> * a2824734d23 UPSTREAM: lir_xchg >> * 36cd39c0126 UPSTREAM: assembler_ppc CMPLI >> * 447259cea42 UPSTREAM: assembler_ppc ANDI >> * 9417323499a UPSTREAM: Add VMErrorCallback infrastructure >> >> Regarding all the changesets you see in this PR, they form the history of the development of Generational ZGC. It might look a bit unconventional to what you are used to see in openjdk development. What we have done is to use merges with the 'ours' strategy to ignore the previous Generational ZGC patches, and then rebased and flattened the changes on top of the merge. This effectively gives us the upsides of having a rebased repository and the upsides of retaining the history in the repository. The downside could be that GitHub now lists all those changesets in the PR. Given that this patch is so big, and that you likely only want to see a part of it, I suggest that you pull down the PR branch and then compare it to the openjdk/jdk changeset this PR is based against: >> >> >> git fetch https://github.com/openjdk/zgc zgc_master >> git diff zgc_master... >> >> >> There have been many contributors of this patch over the years. I'll do my best to poke Skara into listing you all, but if you see that I've missed your name please reach out to me and I'll fix it. >> >> Testing: we have been continuously running Generational ZGC through Oracle's tier1-8 testing. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Fix PPC build after 8305668 Thanks for fixing PPC64! With this, the VM compiles and the `test/hotspot/jtreg/gc` tests are passing on linux PPC64le. I'm glad to see this PR for JDK 21 LTS. It's a big step forward for ZGC. Congratulations! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13771#issuecomment-1532942815 From stefank at openjdk.org Wed May 3 12:45:27 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 3 May 2023 12:45:27 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v2] In-Reply-To: <6A1nfkn9o4N_h6W4aY_0XT_jW5h478GmIF8B-ZNI4wk=.232e8290-55fd-4a7a-9341-ebb1522423e4@github.com> References: <6A1nfkn9o4N_h6W4aY_0XT_jW5h478GmIF8B-ZNI4wk=.232e8290-55fd-4a7a-9341-ebb1522423e4@github.com> Message-ID: On Wed, 3 May 2023 12:29:15 GMT, Martin Doerr wrote: > Thanks for fixing PPC64! With this, the VM compiles and the `test/hotspot/jtreg/gc` tests are passing on linux PPC64le. > > I'm glad to see this PR for JDK 21 LTS. It's a big step forward for ZGC. Congratulations! Thanks for porting Generational ZGC to PPC! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13771#issuecomment-1532964490 From erikj at openjdk.org Wed May 3 13:37:15 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 3 May 2023 13:37:15 GMT Subject: RFR: 8307194: Enhance static-libs-image In-Reply-To: References: Message-ID: <-y0ADzT8MTDUDF_cB5Msg5W4OfWnP7GjcCfhcrKtT-I=.6ed57876-309a-4b7f-a23e-e04bf7047755@github.com> On Wed, 3 May 2023 02:09:22 GMT, Jiangli Zhou wrote: > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: > > - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; > - For libjvm.a specifically, exclude operator_new.o; > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; > - Handle long arguments case for static build in make/common/NativeCompilation.gmk; > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; The current target user of the .a libraries is GraalVM, so we should check with them that the changes to the contents of the `.a` files isn't impacting them in a bad way. @dougxc what do you think? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1533040157 From mdoerr at openjdk.org Wed May 3 13:44:29 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 3 May 2023 13:44:29 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v2] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 10:55:49 GMT, Stefan Karlsson wrote: >> Hi all, >> >> Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. >> >> The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention is to give the users time to validate and deploy their workloads with the new GC implementation. >> >> Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clear to us how time consuming and complex things end up being when we tried to keep both the original G1 working, and at the same time implemented the ZGC-alike G1. Given this experience, we don't see that as a viable solution to deliver a maintainable and evolving Generational ZGC. Our pragmatic suggestion to these challenges is to let Generational ZGC live under the current gc/z directories and let the legacy, non-generational ZGC be completely separated in its own directories. This way we can continue to move quickly with the continued develo pment of Generational ZGC and let the non-generational ZGC be mostly untouched until it gets deprecated, and eventually removed. The non-generational ZGC directory will be gc/x and all the classes of non-generational have been prefixed with X instead of Z. An alternative to this rename could be to namespace out non-generational ZGC. We experimented with that, but it was too easy to accidentally cross-compile Generational ZGC code into non-generational ZGC, so we didn't like that approach. >> >> Most of the stand-alone cleanups and enhancements outside of the ZGC code have already been upstreamed to openjdk/jdk. There are still a few patches that could/should be pushed separately, but they will be easier to understand by also looking at the Generational ZGC code, so they will be sent out after this PR has been published. The patches that could be published separately are: >> >> * 59d1e96af6a UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class >> * ca9edf8aa79 UPSTREAM: RISCV tmp reg cleanup resolve_jobject >> * 4bec9c69b67 CLEANUP: barrierSetNMethod_aarch64.cpp >> * b67d03a3f04 UPSTREAM: Add relaxed add&fetch for aarch64 atomics >> * a2824734d23 UPSTREAM: lir_xchg >> * 36cd39c0126 UPSTREAM: assembler_ppc CMPLI >> * 447259cea42 UPSTREAM: assembler_ppc ANDI >> * 9417323499a UPSTREAM: Add VMErrorCallback infrastructure >> >> Regarding all the changesets you see in this PR, they form the history of the development of Generational ZGC. It might look a bit unconventional to what you are used to see in openjdk development. What we have done is to use merges with the 'ours' strategy to ignore the previous Generational ZGC patches, and then rebased and flattened the changes on top of the merge. This effectively gives us the upsides of having a rebased repository and the upsides of retaining the history in the repository. The downside could be that GitHub now lists all those changesets in the PR. Given that this patch is so big, and that you likely only want to see a part of it, I suggest that you pull down the PR branch and then compare it to the openjdk/jdk changeset this PR is based against: >> >> >> git fetch https://github.com/openjdk/zgc zgc_master >> git diff zgc_master... >> >> >> There have been many contributors of this patch over the years. I'll do my best to poke Skara into listing you all, but if you see that I've missed your name please reach out to me and I'll fix it. >> >> Testing: we have been continuously running Generational ZGC through Oracle's tier1-8 testing. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Fix PPC build after 8305668 "test/hotspot/jtreg/gc" and "test/hotspot/jtreg/compiler/gcbarriers" are also passing with JTREG="VM_OPTIONS=-XX:+UseZGC -XX:+ZGenerational" on linux PPC64 le. I've quickly checked Spec JBB 2005 with ZGC performance. Generational mode was about 7% faster on Power10. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13771#issuecomment-1533053221 From erikj at openjdk.org Wed May 3 13:46:17 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 3 May 2023 13:46:17 GMT Subject: RFR: 8307194: Enhance static-libs-image In-Reply-To: References: Message-ID: On Wed, 3 May 2023 02:09:22 GMT, Jiangli Zhou wrote: > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: > > - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; > - For libjvm.a specifically, exclude operator_new.o; > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; > - Handle long arguments case for static build in make/common/NativeCompilation.gmk; > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; make/StaticLibsImage.gmk line 61: > 59: $(eval TARGETS += $$(COPY_STATIC_LIBS_libjvm)) \ > 60: ) > 61: Won't this fail if we were building more than one variant? Perhaps only put `$(JVM_VARIANT_MAIN)` in the static image to avoid problems? make/modules/java.base/lib/CoreLibraries.gmk line 168: > 166: # The duplicate objects in different static libraries cause linking > 167: # errors due to duplicate symbols. > 168: LIBJLI_STATIC_EXCLUDE_OBJS := $(subst .c,.o,$(LIBJLI_EXTRA_FILE_LIST)) Should probably use `$(OBJ_SUFFIX)` instead of `.o`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1183706646 PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1183702610 From erikj at openjdk.org Wed May 3 13:56:16 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 3 May 2023 13:56:16 GMT Subject: RFR: JDK-8306983: Do not invoke external programs when switch terminal to raw mode on selected platforms In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 11:21:04 GMT, Jan Lahoda wrote: > To support JShell and other usecases, the JDK uses JLine, which provides line-editing functionality inside a terminal. > > JLine has several ways to work with the terminal, based on various additional libraries and tools. Most of them are not directly usable inside the JDK, so currently, on non-Windows platforms, the JLine inside the JDK will use external programs, like `stty`, to inspect the terminal's properties and to switch the terminal to raw mode. > > This is slightly problematic, as the external programs might be missing, and while this is not that big problem for JShell, it might be a problem for other potential uses of JLine, like using it inside `System.console()`. > > So, the proposal here is to call the corresponding native methods directly, on selected platforms for now (Linux and Mac OS/X), instead of invoking the external programs. On Windows, this has always been the case, we are using a custom implementation of the interface that maps native and Java function for JNA there, and the proposal is to do the same here. We take the appropriate mapping interface for JNA, and provide hand-written implementation for it, using JNI. > > The Windows implementation is mostly unchanged, the changes are mostly non-Windows only. The overview of the changes is: > - `LastErrorException` is moved from the Windows-specific code to the platform-neutral code, as it is used by all the native implementations. This is the only change that directly affects the Windows-specific code > - `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java` and `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java` are created based on the corresponding files from JLine. In JLine, these files directly call platform-specific implementations, but in this patch, the platform specific code is commented out, and replaced with calls to `JDKNativePty`, which is a new platform-specific class, that delegates to the actual platform-specific implementations. Note the `JnaNativePty.java` and `JnaTerminalProvider.java` already exist in the Windows part, but have different pieces of code commented out, which makes them substantially different. > - for Linux and Mac OS/X, there are platform-specific implementations based on the corresponding code from JLine, with the hand-written JNI-based implementation of the JNA-based existing interfaces. They also have an implementation of `JDKNativePty`, which just delegates to the given platform's `"NativePty"` implementation. > - the `JdkConsoleProviderImpl.java` has been tweaked to not allow the implementation based on the external programs, and gracefully falling back to the standard implementation. JShell is kept unchanged. > > The reasons for this organization are: limiting duplication, mostly adhering to the JDK's platform specific build (which is different from the normal JLine's platform-neutral build) and limiting the difference between standard JLine and JLine inside JDK, to help future upgrades. make/modules/jdk.internal.le/Lib.gmk line 38: > 36: LDFLAGS := $(LDFLAGS_JDKLIB), \ > 37: LIBS_windows := $(JDKLIB_LIBS) user32.lib, \ > 38: LIBS_unix := $(JDKLIB_LIBS) -lstdc++, \ If this is a C++ library, I think it's better to specify `TOOLCHAIN := TOOLCHAIN_LINK_CXX` than adding `-lstdc++`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1183721435 From erikj at openjdk.org Wed May 3 14:01:23 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 3 May 2023 14:01:23 GMT Subject: RFR: JDK-8306983: Do not invoke external programs when switch terminal to raw mode on selected platforms In-Reply-To: References: Message-ID: On Wed, 3 May 2023 13:53:20 GMT, Erik Joelsson wrote: >> To support JShell and other usecases, the JDK uses JLine, which provides line-editing functionality inside a terminal. >> >> JLine has several ways to work with the terminal, based on various additional libraries and tools. Most of them are not directly usable inside the JDK, so currently, on non-Windows platforms, the JLine inside the JDK will use external programs, like `stty`, to inspect the terminal's properties and to switch the terminal to raw mode. >> >> This is slightly problematic, as the external programs might be missing, and while this is not that big problem for JShell, it might be a problem for other potential uses of JLine, like using it inside `System.console()`. >> >> So, the proposal here is to call the corresponding native methods directly, on selected platforms for now (Linux and Mac OS/X), instead of invoking the external programs. On Windows, this has always been the case, we are using a custom implementation of the interface that maps native and Java function for JNA there, and the proposal is to do the same here. We take the appropriate mapping interface for JNA, and provide hand-written implementation for it, using JNI. >> >> The Windows implementation is mostly unchanged, the changes are mostly non-Windows only. The overview of the changes is: >> - `LastErrorException` is moved from the Windows-specific code to the platform-neutral code, as it is used by all the native implementations. This is the only change that directly affects the Windows-specific code >> - `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java` and `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java` are created based on the corresponding files from JLine. In JLine, these files directly call platform-specific implementations, but in this patch, the platform specific code is commented out, and replaced with calls to `JDKNativePty`, which is a new platform-specific class, that delegates to the actual platform-specific implementations. Note the `JnaNativePty.java` and `JnaTerminalProvider.java` already exist in the Windows part, but have different pieces of code commented out, which makes them substantially different. >> - for Linux and Mac OS/X, there are platform-specific implementations based on the corresponding code from JLine, with the hand-written JNI-based implementation of the JNA-based existing interfaces. They also have an implementation of `JDKNativePty`, which just delegates to the given platform's `"NativePty"` implementation. >> - the `JdkConsoleProviderImpl.java` has been tweaked to not allow the implementation based on the external programs, and gracefully falling back to the standard implementation. JShell is kept unchanged. >> >> The reasons for this organization are: limiting duplication, mostly adhering to the JDK's platform specific build (which is different from the normal JLine's platform-neutral build) and limiting the difference between standard JLine and JLine inside JDK, to help future upgrades. > > make/modules/jdk.internal.le/Lib.gmk line 38: > >> 36: LDFLAGS := $(LDFLAGS_JDKLIB), \ >> 37: LIBS_windows := $(JDKLIB_LIBS) user32.lib, \ >> 38: LIBS_unix := $(JDKLIB_LIBS) -lstdc++, \ > > If this is a C++ library, I think it's better to specify `TOOLCHAIN := TOOLCHAIN_LINK_CXX` than adding `-lstdc++`. We may also need `$(LIBCXX)` to force static linking when that is enabled for the build. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1183728006 From dnsimon at openjdk.org Wed May 3 14:01:22 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Wed, 3 May 2023 14:01:22 GMT Subject: RFR: 8307194: Enhance static-libs-image In-Reply-To: <-y0ADzT8MTDUDF_cB5Msg5W4OfWnP7GjcCfhcrKtT-I=.6ed57876-309a-4b7f-a23e-e04bf7047755@github.com> References: <-y0ADzT8MTDUDF_cB5Msg5W4OfWnP7GjcCfhcrKtT-I=.6ed57876-309a-4b7f-a23e-e04bf7047755@github.com> Message-ID: On Wed, 3 May 2023 13:34:12 GMT, Erik Joelsson wrote: > The current target user of the .a libraries is GraalVM, so we should check with them that the changes to the contents of the `.a` files isn't impacting them in a bad way. @dougxc what do you think? Thanks for the heads up - I've asked the GraalVM Native Image team to look at this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1533078913 From sgehwolf at openjdk.org Wed May 3 17:00:26 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 3 May 2023 17:00:26 GMT Subject: RFR: 8307194: Enhance static-libs-image In-Reply-To: References: Message-ID: On Wed, 3 May 2023 02:09:22 GMT, Jiangli Zhou wrote: > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: > > - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; > - For libjvm.a specifically, exclude operator_new.o; > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; > - Handle long arguments case for static build in make/common/NativeCompilation.gmk; > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; @jianglizhou How does the produced image look like after this patch? I.e. what's the contents of `build/*/images/static-libs`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1533385050 From sgehwolf at openjdk.org Wed May 3 17:08:15 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 3 May 2023 17:08:15 GMT Subject: RFR: 8307194: Enhance static-libs-image In-Reply-To: References: Message-ID: On Wed, 3 May 2023 02:09:22 GMT, Jiangli Zhou wrote: > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: > > - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; > - For libjvm.a specifically, exclude operator_new.o; > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; > - Handle long arguments case for static build in make/common/NativeCompilation.gmk; > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; make/Main.gmk line 1060: > 1058: symbols-image: $(LIBS_TARGETS) $(LAUNCHER_TARGETS) > 1059: > 1060: static-libs-image: hotspot-static-libs $(STATIC_LIBS_TARGETS) Could we decouple `hotspot-static-libs` from `static-libs-image` somehow, please? `static-libs-image` is used by the `graal-builder-image` target and it would be good if it didn't include hotspot static libs as they are not needed for it. Would it be sufficient to just use `hotspot-static-libs` directly? Like: `make static-libs-image hotspot-static-libs`? Failing that, could we introduce a new target that produces both? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1183974910 From naoto at openjdk.org Wed May 3 17:51:19 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 3 May 2023 17:51:19 GMT Subject: RFR: JDK-8306983: Do not invoke external programs when switch terminal to raw mode on selected platforms In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 11:21:04 GMT, Jan Lahoda wrote: > To support JShell and other usecases, the JDK uses JLine, which provides line-editing functionality inside a terminal. > > JLine has several ways to work with the terminal, based on various additional libraries and tools. Most of them are not directly usable inside the JDK, so currently, on non-Windows platforms, the JLine inside the JDK will use external programs, like `stty`, to inspect the terminal's properties and to switch the terminal to raw mode. > > This is slightly problematic, as the external programs might be missing, and while this is not that big problem for JShell, it might be a problem for other potential uses of JLine, like using it inside `System.console()`. > > So, the proposal here is to call the corresponding native methods directly, on selected platforms for now (Linux and Mac OS/X), instead of invoking the external programs. On Windows, this has always been the case, we are using a custom implementation of the interface that maps native and Java function for JNA there, and the proposal is to do the same here. We take the appropriate mapping interface for JNA, and provide hand-written implementation for it, using JNI. > > The Windows implementation is mostly unchanged, the changes are mostly non-Windows only. The overview of the changes is: > - `LastErrorException` is moved from the Windows-specific code to the platform-neutral code, as it is used by all the native implementations. This is the only change that directly affects the Windows-specific code > - `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java` and `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java` are created based on the corresponding files from JLine. In JLine, these files directly call platform-specific implementations, but in this patch, the platform specific code is commented out, and replaced with calls to `JDKNativePty`, which is a new platform-specific class, that delegates to the actual platform-specific implementations. Note the `JnaNativePty.java` and `JnaTerminalProvider.java` already exist in the Windows part, but have different pieces of code commented out, which makes them substantially different. > - for Linux and Mac OS/X, there are platform-specific implementations based on the corresponding code from JLine, with the hand-written JNI-based implementation of the JNA-based existing interfaces. They also have an implementation of `JDKNativePty`, which just delegates to the given platform's `"NativePty"` implementation. > - the `JdkConsoleProviderImpl.java` has been tweaked to not allow the implementation based on the external programs, and gracefully falling back to the standard implementation. JShell is kept unchanged. > > The reasons for this organization are: limiting duplication, mostly adhering to the JDK's platform specific build (which is different from the normal JLine's platform-neutral build) and limiting the difference between standard JLine and JLine inside JDK, to help future upgrades. Changes in `JdkConsoleProviderImpl.java` look good to me. Didn't look at other diffs closely, but it seems some other files are missing Oracle copyright text. ------------- PR Review: https://git.openjdk.org/jdk/pull/13687#pullrequestreview-1411449102 From jiangli at openjdk.org Wed May 3 17:58:25 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 17:58:25 GMT Subject: RFR: 8307194: Enhance static-libs-image [v2] In-Reply-To: References: Message-ID: <0T3QYhW2lCL0cut65awn0zF2_xsBu57OhgeBfG13Mbk=.31927d2d-876b-4e8d-8ad1-8642ff0cfb3f@github.com> > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: > > - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; > - For libjvm.a specifically, exclude operator_new.o; > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; > - Handle long arguments case for static build in make/common/NativeCompilation.gmk; > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Update based on @erikj79 review comments and suggestions: - Change to copy libjvm.a for $(JVM_VARIANT_MAIN) only in make/StaticLibsImage.gmk. - Use $(OBJ_SUFFIX) instead of .o in make/modules/java.base/lib/CoreLibraries.gmk. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13768/files - new: https://git.openjdk.org/jdk/pull/13768/files/f8be9e95..f74b576d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=00-01 Stats: 10 lines in 2 files changed: 0 ins; 3 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From jiangli at openjdk.org Wed May 3 17:58:27 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 17:58:27 GMT Subject: RFR: 8307194: Enhance static-libs-image [v2] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 13:42:03 GMT, Erik Joelsson wrote: >> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: >> >> Update based on @erikj79 review comments and suggestions: >> - Change to copy libjvm.a for $(JVM_VARIANT_MAIN) only in make/StaticLibsImage.gmk. >> - Use $(OBJ_SUFFIX) instead of .o in make/modules/java.base/lib/CoreLibraries.gmk. > > make/StaticLibsImage.gmk line 61: > >> 59: $(eval TARGETS += $$(COPY_STATIC_LIBS_libjvm)) \ >> 60: ) >> 61: > > Won't this fail if we were building more than one variant? Perhaps only put `$(JVM_VARIANT_MAIN)` in the static image to avoid problems? Changed to copy for $(JVM_VARIANT_MAIN) only, as suggested. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184061602 From jiangli at openjdk.org Wed May 3 18:15:13 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 18:15:13 GMT Subject: RFR: 8307194: Enhance static-libs-image In-Reply-To: References: Message-ID: <2SPZE-0hNv2CIMD9vVZynRUmk-bw8QCquiDELC2QzDE=.e66960f0-f4ff-4740-99d6-44abe1d8071b@github.com> On Wed, 3 May 2023 16:57:04 GMT, Severin Gehwolf wrote: > @jianglizhou How does the produced image look like after this patch? I.e. what's the contents of `build/*/images/static-libs`? With the changes in this patch, `build/*/images/static-libs` will contain the `libjvm.a` in addition to the JDK `.a` static libraries. For the following JDK static libraries (`.a`), the duplicate `.o` files are excluded to avoid linking failures when the the JDK static libraries are linked with: - For `libjli.a`: Not include `inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o` (compiled from `zlib` sources) if `zlib` is built as JDK bundled. When `zlib` is built as bundled, the extra source files from it are compiled and the produced object files are linked into `libjli`. That's intended for the shared library, `libjli.so`, but that's problematic for `libjli.a`. It's not an issue when `zlib` is not bundled, as the extra sources are not included for `libjli` in that case. - For `libawt_xawt.a` and `libawt_head.a`: Not include `systemScale.o`, since it's provided in `libawt.a`. I'll add these details in the PR description as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1533494769 From erikj at openjdk.org Wed May 3 18:37:16 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 3 May 2023 18:37:16 GMT Subject: RFR: 8307194: Enhance static-libs-image [v2] In-Reply-To: <0T3QYhW2lCL0cut65awn0zF2_xsBu57OhgeBfG13Mbk=.31927d2d-876b-4e8d-8ad1-8642ff0cfb3f@github.com> References: <0T3QYhW2lCL0cut65awn0zF2_xsBu57OhgeBfG13Mbk=.31927d2d-876b-4e8d-8ad1-8642ff0cfb3f@github.com> Message-ID: On Wed, 3 May 2023 17:58:25 GMT, Jiangli Zhou wrote: >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: >> >> - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; >> - For libjvm.a specifically, exclude operator_new.o; >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk; >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Update based on @erikj79 review comments and suggestions: > - Change to copy libjvm.a for $(JVM_VARIANT_MAIN) only in make/StaticLibsImage.gmk. > - Use $(OBJ_SUFFIX) instead of .o in make/modules/java.base/lib/CoreLibraries.gmk. make/Main.gmk line 261: > 259: endef > 260: > 261: $(foreach v, $(JVM_VARIANTS), $(eval $(call DeclareHotspotStaticLibsRecipe,$v))) If we are only using the libjvm.a from the main variant, we don't need to generate top level rules for all variants, or we could at least limit the dependency declaration at line 1109 to only need the main variant. make/StaticLibsImage.gmk line 56: > 54: DEST := $(STATIC_LIBS_IMAGE_DIR)/lib, \ > 55: FILES := $(filter %$(STATIC_LIBRARY_SUFFIX), \ > 56: $(call FindFiles, $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/libjvm/objs/static)))) I would recommend using `wildcard` instead of `FindFiles` as the files are expected to be in a single directory (no recursive directory searching needed). We also try to put the closing double braces on a new line matching the initial eval in indentation. Suggestion: FILES := $(wildcard $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/libjvm/objs/static/*$(STATIC_LIBRARY_SUFFIX)), \ )) make/StaticLibsImage.gmk line 57: > 55: FILES := $(filter %$(STATIC_LIBRARY_SUFFIX), \ > 56: $(call FindFiles, $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/libjvm/objs/static)))) > 57: $(eval TARGETS += $$(COPY_STATIC_LIBS_libjvm)) No need for eval around this assignment. Suggestion: TARGETS += $(COPY_STATIC_LIBS_libjvm) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184105236 PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184103554 PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184099771 From erikj at openjdk.org Wed May 3 18:37:19 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 3 May 2023 18:37:19 GMT Subject: RFR: 8307194: Enhance static-libs-image [v2] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 17:05:29 GMT, Severin Gehwolf wrote: >> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: >> >> Update based on @erikj79 review comments and suggestions: >> - Change to copy libjvm.a for $(JVM_VARIANT_MAIN) only in make/StaticLibsImage.gmk. >> - Use $(OBJ_SUFFIX) instead of .o in make/modules/java.base/lib/CoreLibraries.gmk. > > make/Main.gmk line 1060: > >> 1058: symbols-image: $(LIBS_TARGETS) $(LAUNCHER_TARGETS) >> 1059: >> 1060: static-libs-image: hotspot-static-libs $(STATIC_LIBS_TARGETS) > > Could we decouple `hotspot-static-libs` from `static-libs-image` somehow, please? `static-libs-image` is used by the `graal-builder-image` target and it would be good if it didn't include hotspot static libs as they are not needed for it. > > Would it be sufficient to just use `hotspot-static-libs` directly? Like: `make static-libs-image hotspot-static-libs`? Failing that, could we introduce a new target that produces both? I'm hoping to get input from the graal team on the impact of this change. The exact usage of the new libjvm.a file is still under discussion so I share you concern about changing things for the current static libs usecase before we fully understand where this is going. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184107079 From jiangli at openjdk.org Wed May 3 18:43:16 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 18:43:16 GMT Subject: RFR: 8307194: Enhance static-libs-image [v2] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 18:33:56 GMT, Erik Joelsson wrote: >> make/Main.gmk line 1060: >> >>> 1058: symbols-image: $(LIBS_TARGETS) $(LAUNCHER_TARGETS) >>> 1059: >>> 1060: static-libs-image: hotspot-static-libs $(STATIC_LIBS_TARGETS) >> >> Could we decouple `hotspot-static-libs` from `static-libs-image` somehow, please? `static-libs-image` is used by the `graal-builder-image` target and it would be good if it didn't include hotspot static libs as they are not needed for it. >> >> Would it be sufficient to just use `hotspot-static-libs` directly? Like: `make static-libs-image hotspot-static-libs`? Failing that, could we introduce a new target that produces both? > > I'm hoping to get input from the graal team on the impact of this change. The exact usage of the new libjvm.a file is still under discussion so I share you concern about changing things for the current static libs usecase before we fully understand where this is going. > Could we decouple `hotspot-static-libs` from `static-libs-image` somehow, please? `static-libs-image` is used by the `graal-builder-image` target and it would be good if it didn't include hotspot static libs as they are not needed for it. > > Would it be sufficient to just use `hotspot-static-libs` directly? Like: `make static-libs-image hotspot-static-libs`? Failing that, could we introduce a new target that produces both? Good questions. I had similar thoughts when making the makefile changes. Here's my reasoning with the current approach in this PR: The `images/static-libs/lib` would provide a super set of the JDK/VM static libraries (in a JDK binary/release) for downstream developers to produce their desired final static image. With the addition of the `libjvm.a` and potentially bundled `libzlib.a` and `libfreetype.a` included in `static-libs-image` output, users could select the needed subset of the static libraries for their linking step (e.g. via jlink based on the needed modules) to produce the final image. If these changes are cumbersome for `graal-builder-image` usages, using `hotspot-static-libs` directly for producing `libjvm.a` as you suggested could be doable. Or, we could try using a new make target for producing the `.a` superset. There might be potential concerns/issues with the differences between `graal-builder-image` support and Java static image support, i.e. it might be a good idea to explore unified solution for both if possible. @dougxc and others related to GraalVM Native Image are on this review thread. It's a good idea to collect the thoughts together. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184113709 From sgehwolf at openjdk.org Wed May 3 18:54:15 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 3 May 2023 18:54:15 GMT Subject: RFR: 8307194: Enhance static-libs-image [v2] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 18:40:52 GMT, Jiangli Zhou wrote: >> I'm hoping to get input from the graal team on the impact of this change. The exact usage of the new libjvm.a file is still under discussion so I share you concern about changing things for the current static libs usecase before we fully understand where this is going. > >> Could we decouple `hotspot-static-libs` from `static-libs-image` somehow, please? `static-libs-image` is used by the `graal-builder-image` target and it would be good if it didn't include hotspot static libs as they are not needed for it. >> >> Would it be sufficient to just use `hotspot-static-libs` directly? Like: `make static-libs-image hotspot-static-libs`? Failing that, could we introduce a new target that produces both? > > Good questions. I had similar thoughts when making the makefile changes. Here's my reasoning with the current approach in this PR: > > The `images/static-libs/lib` would provide a super set of the JDK/VM static libraries (in a JDK binary/release) for downstream developers to produce their desired final static image. With the addition of the `libjvm.a` and potentially bundled `libzlib.a` and `libfreetype.a` included in `static-libs-image` output, users could select the needed subset of the static libraries for their linking step (e.g. via jlink based on the needed modules) to produce the final image. > > If these changes are cumbersome for `graal-builder-image` usages, using `hotspot-static-libs` directly for producing `libjvm.a` as you suggested could be doable. Or, we could try using a new make target for producing the `.a` superset. There might be potential concerns/issues with the differences between `graal-builder-image` support and Java static image support, i.e. it might be a good idea to explore unified solution for both if possible. @dougxc and others related to GraalVM Native Image are on this review thread. It's a good idea to collect the thoughts together. GraalVM native-image has it's own `libjvm.a` shim which would likely conflict or produce undesirable results. So I'd prefer the approach where `static-libs-image` wouldn't produce hotspot `libjvm.a` as part of it. For new uses-cases needing that, we could add a new top-level target (like `graal-builder-image`) which would produce such an image. As one of the [Mandrel](https://github.com/graalvm/mandrel) maintainers, I'm not sure any post-build filtering via `jlink` or the like would be ideal for us. I'll see if I can test this on a mandrel build tomorrow... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184123989 From cjplummer at openjdk.org Wed May 3 19:05:30 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 3 May 2023 19:05:30 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v2] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 10:55:49 GMT, Stefan Karlsson wrote: >> Hi all, >> >> Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. >> >> The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention is to give the users time to validate and deploy their workloads with the new GC implementation. >> >> Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clear to us how time consuming and complex things end up being when we tried to keep both the original G1 working, and at the same time implemented the ZGC-alike G1. Given this experience, we don't see that as a viable solution to deliver a maintainable and evolving Generational ZGC. Our pragmatic suggestion to these challenges is to let Generational ZGC live under the current gc/z directories and let the legacy, non-generational ZGC be completely separated in its own directories. This way we can continue to move quickly with the continued develo pment of Generational ZGC and let the non-generational ZGC be mostly untouched until it gets deprecated, and eventually removed. The non-generational ZGC directory will be gc/x and all the classes of non-generational have been prefixed with X instead of Z. An alternative to this rename could be to namespace out non-generational ZGC. We experimented with that, but it was too easy to accidentally cross-compile Generational ZGC code into non-generational ZGC, so we didn't like that approach. >> >> Most of the stand-alone cleanups and enhancements outside of the ZGC code have already been upstreamed to openjdk/jdk. There are still a few patches that could/should be pushed separately, but they will be easier to understand by also looking at the Generational ZGC code, so they will be sent out after this PR has been published. The patches that could be published separately are: >> >> * 59d1e96af6a UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class >> * ca9edf8aa79 UPSTREAM: RISCV tmp reg cleanup resolve_jobject >> * 4bec9c69b67 CLEANUP: barrierSetNMethod_aarch64.cpp >> * b67d03a3f04 UPSTREAM: Add relaxed add&fetch for aarch64 atomics >> * a2824734d23 UPSTREAM: lir_xchg >> * 36cd39c0126 UPSTREAM: assembler_ppc CMPLI >> * 447259cea42 UPSTREAM: assembler_ppc ANDI >> * 9417323499a UPSTREAM: Add VMErrorCallback infrastructure >> >> Regarding all the changesets you see in this PR, they form the history of the development of Generational ZGC. It might look a bit unconventional to what you are used to see in openjdk development. What we have done is to use merges with the 'ours' strategy to ignore the previous Generational ZGC patches, and then rebased and flattened the changes on top of the merge. This effectively gives us the upsides of having a rebased repository and the upsides of retaining the history in the repository. The downside could be that GitHub now lists all those changesets in the PR. Given that this patch is so big, and that you likely only want to see a part of it, I suggest that you pull down the PR branch and then compare it to the openjdk/jdk changeset this PR is based against: >> >> >> git fetch https://github.com/openjdk/zgc zgc_master >> git diff zgc_master... >> >> >> There have been many contributors of this patch over the years. I'll do my best to poke Skara into listing you all, but if you see that I've missed your name please reach out to me and I'll fix it. >> >> Testing: we have been continuously running Generational ZGC through Oracle's tier1-8 testing. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Fix PPC build after 8305668 test/hotspot/jtreg/ProblemList-generational-zgc.txt line 32: > 30: # Quiet all SA tests > 31: > 32: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java 8000000 generic-all I'd suggest filing a bug calling out the lack of SA support for generational ZGC and add a comment that there are no plans to address this. test/jdk/ProblemList-generational-zgc.txt line 27: > 25: # > 26: # List of quarantined tests for testing with Generational ZGC. > 27: # Are the tests in `test/jdk/sun/tools/jhsdb/` not failing? test/jdk/com/sun/jdi/ThreadMemoryLeakTest.java line 30: > 28: * > 29: * @comment Don't allow -Xcomp or -Xint as they impact memory useage and number of iterations > 30: * @requires (vm.compMode == "Xmixed") & !(vm.gc.Z & vm.opt.final.ZGenerational) Seems like a bug should be filed for this failure and then problem listed. This test is a bit finicky w.r.t. the specified max heap size and how much memory ends up actually being used by the test. I can probably get it working without much of a problem. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1184124372 PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1184126199 PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1184128793 From jiangli at openjdk.org Wed May 3 19:11:28 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 19:11:28 GMT Subject: RFR: 8307194: Enhance static-libs-image [v3] In-Reply-To: References: Message-ID: <2F3flYLZ6fDkLmUEgEGjwbFpflTPWHCtBmgFowmXq2o=.c465f39d-d798-4266-8851-867155a64d30@github.com> > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: > > - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; > - For libjvm.a specifically, exclude operator_new.o; > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; > - Handle long arguments case for static build in make/common/NativeCompilation.gmk; > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Update make/StaticLibsImage.gmk Thanks Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13768/files - new: https://git.openjdk.org/jdk/pull/13768/files/f74b576d..1f62842e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From jiangli at openjdk.org Wed May 3 19:19:33 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 19:19:33 GMT Subject: RFR: 8307194: Enhance static-libs-image [v4] In-Reply-To: References: Message-ID: > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: > > - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; > - For libjvm.a specifically, exclude operator_new.o; > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; > - Handle long arguments case for static build in make/common/NativeCompilation.gmk; > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Update make/StaticLibsImage.gmk thanks Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13768/files - new: https://git.openjdk.org/jdk/pull/13768/files/1f62842e..e65aee25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From stefank at openjdk.org Wed May 3 19:36:55 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 3 May 2023 19:36:55 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v3] In-Reply-To: References: Message-ID: > Hi all, > > Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. > > The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention i s to give the users time to validate and deploy their workloads with the new GC implementation. > > Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clear to us how time consuming and complex things end up being when we tried to keep both the original G1 working, and at the same time implemented the ZGC-alike G1. Given this experience, we don't see that as a viable solution to deliver a maintainable and evolving Generational ZGC. Our pragmatic suggestion to these challenges is to let Generational ZGC live under the current gc/z directories and let the legacy, non-generational ZGC be completely separated in its own directories. This way we can continue to move quickly with the continued develop ment of Generational ZGC and let the non-generational ZGC be mostly untouched until it gets deprecated, and eventually removed. The non-generational ZGC directory will be gc/x and all the classes of non-generational have been prefixed with X instead of Z. An alternative to this rename could be to namespace out non-generational ZGC. We experimented with that, but it was too easy to accidentally cross-compile Generational ZGC code into non-generational ZGC, so we didn't like that approach. > > Most of the stand-alone cleanups and enhancements outside of the ZGC code have already been upstreamed to openjdk/jdk. There are still a few patches that could/should be pushed separately, but they will be easier to understand by also looking at the Generational ZGC code, so they will be sent out after this PR has been published. The patches that could be published separately are: > > * 59d1e96af6a UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class > * ca9edf8aa79 UPSTREAM: RISCV tmp reg cleanup resolve_jobject > * 4bec9c69b67 CLEANUP: barrierSetNMethod_aarch64.cpp > * b67d03a3f04 UPSTREAM: Add relaxed add&fetch for aarch64 atomics > * a2824734d23 UPSTREAM: lir_xchg > * 36cd39c0126 UPSTREAM: assembler_ppc CMPLI > * 447259cea42 UPSTREAM: assembler_ppc ANDI > * 9417323499a UPSTREAM: Add VMErrorCallback infrastructure > > Regarding all the changesets you see in this PR, they form the history of the development of Generational ZGC. It might look a bit unconventional to what you are used to see in openjdk development. What we have done is to use merges with the 'ours' strategy to ignore the previous Generational ZGC patches, and then rebased and flattened the changes on top of the merge. This effectively gives us the upsides of having a rebased repository and the upsides of retaining the history in the repository. The downside could be that GitHub now lists all those changesets in the PR. Given that this patch is so big, and that you likely only want to see a part of it, I suggest that you pull down the PR branch and then compare it to the openjdk/jdk changeset this PR is based against: > > > git fetch https://github.com/openjdk/zgc zgc_master > git diff zgc_master... > > > There have been many contributors of this patch over the years. I'll do my best to poke Skara into listing you all, but if you see that I've missed your name please reach out to me and I'll fix it. > > Testing: we have been continuously running Generational ZGC through Oracle's tier1-8 testing. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Update SA ProblemList entries ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13771/files - new: https://git.openjdk.org/jdk/pull/13771/files/da7fdde5..40e8583b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13771&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13771&range=01-02 Stats: 81 lines in 1 file changed: 0 ins; 0 del; 81 mod Patch: https://git.openjdk.org/jdk/pull/13771.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13771/head:pull/13771 PR: https://git.openjdk.org/jdk/pull/13771 From stefank at openjdk.org Wed May 3 19:37:00 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 3 May 2023 19:37:00 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v2] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 18:52:19 GMT, Chris Plummer wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix PPC build after 8305668 > > test/hotspot/jtreg/ProblemList-generational-zgc.txt line 32: > >> 30: # Quiet all SA tests >> 31: >> 32: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java 8000000 generic-all > > I'd suggest filing a bug calling out the lack of SA support for generational ZGC and add a comment that there are no plans to address this. Sounds like a good idea. I've created JDK-8307393 and will update the problem list. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1184167988 From stefank at openjdk.org Wed May 3 19:45:31 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 3 May 2023 19:45:31 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v2] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 18:57:22 GMT, Chris Plummer wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix PPC build after 8305668 > > test/jdk/com/sun/jdi/ThreadMemoryLeakTest.java line 30: > >> 28: * >> 29: * @comment Don't allow -Xcomp or -Xint as they impact memory useage and number of iterations >> 30: * @requires (vm.compMode == "Xmixed") & !(vm.gc.Z & vm.opt.final.ZGenerational) > > Seems like a bug should be filed for this failure and then problem listed. This test is a bit finicky w.r.t. the specified max heap size and how much memory ends up actually being used by the test. I can probably get it working without much of a problem. Yes, the test was finicky with the heap size. Given that the leak it tries to provoke would be provoked by other GCs as well, we didn't think it was that important to run this particular test with Generational ZGC. If you still think that we should create a Bug and ProblemList it, I'll do so. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1184180837 From cjplummer at openjdk.org Wed May 3 20:03:31 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 3 May 2023 20:03:31 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v2] In-Reply-To: References: Message-ID: <6mUJaCFaOVO8V3S6gtr6EZ7uRplgVXXJialmuWqdegM=.e114c23c-28e4-4b12-a99b-15b3a350d4f8@github.com> On Wed, 3 May 2023 19:42:01 GMT, Stefan Karlsson wrote: >> test/jdk/com/sun/jdi/ThreadMemoryLeakTest.java line 30: >> >>> 28: * >>> 29: * @comment Don't allow -Xcomp or -Xint as they impact memory useage and number of iterations >>> 30: * @requires (vm.compMode == "Xmixed") & !(vm.gc.Z & vm.opt.final.ZGenerational) >> >> Seems like a bug should be filed for this failure and then problem listed. This test is a bit finicky w.r.t. the specified max heap size and how much memory ends up actually being used by the test. I can probably get it working without much of a problem. > > Yes, the test was finicky with the heap size. Given that the leak it tries to provoke would be provoked by other GCs as well, we didn't think it was that important to run this particular test with Generational ZGC. If you still think that we should create a Bug and ProblemList it, I'll do so. When I first wrote this test, it ended up failing with ZGC because I hadn't tested it. I considered excluding it for the same reason you've given, but then considered that the test might expose a leak with one GC, but not others, so I decided to fix it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1184197845 From jiangli at openjdk.org Wed May 3 20:25:13 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 20:25:13 GMT Subject: RFR: 8307194: Enhance static-libs-image [v5] In-Reply-To: References: Message-ID: > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: > > - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; > - For libjvm.a specifically, exclude operator_new.o; > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; > - Handle long arguments case for static build in make/common/NativeCompilation.gmk; > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Update to create and use only hotspot-$(JVM_VARIANT_MAIN)-static-libs, based on @erikj79 input. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13768/files - new: https://git.openjdk.org/jdk/pull/13768/files/e65aee25..84861990 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=03-04 Stats: 6 lines in 1 file changed: 2 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From jiangli at openjdk.org Wed May 3 20:25:17 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 20:25:17 GMT Subject: RFR: 8307194: Enhance static-libs-image [v2] In-Reply-To: References: <0T3QYhW2lCL0cut65awn0zF2_xsBu57OhgeBfG13Mbk=.31927d2d-876b-4e8d-8ad1-8642ff0cfb3f@github.com> Message-ID: On Wed, 3 May 2023 18:31:56 GMT, Erik Joelsson wrote: >> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: >> >> Update based on @erikj79 review comments and suggestions: >> - Change to copy libjvm.a for $(JVM_VARIANT_MAIN) only in make/StaticLibsImage.gmk. >> - Use $(OBJ_SUFFIX) instead of .o in make/modules/java.base/lib/CoreLibraries.gmk. > > make/Main.gmk line 261: > >> 259: endef >> 260: >> 261: $(foreach v, $(JVM_VARIANTS), $(eval $(call DeclareHotspotStaticLibsRecipe,$v))) > > If we are only using the libjvm.a from the main variant, we don't need to generate top level rules for all variants, or we could at least limit the dependency declaration at line 1109 to only need the main variant. Changed to define/use the `libjvm.a` rule for the main variant only as suggested, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184217800 From stefank at openjdk.org Wed May 3 21:11:30 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 3 May 2023 21:11:30 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v2] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 18:54:24 GMT, Chris Plummer wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix PPC build after 8305668 > > test/jdk/ProblemList-generational-zgc.txt line 27: > >> 25: # >> 26: # List of quarantined tests for testing with Generational ZGC. >> 27: # > > Are the tests in `test/jdk/sun/tools/jhsdb/` not failing? It seems like these tests are only run with all GCs at the end of the development cycle. I've run them manually and verified that these tests fail as well. I'm going to problem list them. That run also revealed that jstat doesn't like when we report the initial capacity of the old generation as zero. See the calculation in: src/jdk.jcmd/share/classes/sun/tools/jstat/resources/jstat_options column { header "^O^" /* Old Space - Percent Used */ data (1-((sun.gc.generation.1.space.0.capacity - sun.gc.generation.1.space.0.used)/sun.gc.generation.1.space.0.capacity)) * 100 align right scale raw width 6 format "0.00" } I can work around the test problem by faking the capacity to be non-zero, but that's not a pretty solution IMO. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1184285686 From stefank at openjdk.org Wed May 3 21:30:34 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 3 May 2023 21:30:34 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v2] In-Reply-To: <6mUJaCFaOVO8V3S6gtr6EZ7uRplgVXXJialmuWqdegM=.e114c23c-28e4-4b12-a99b-15b3a350d4f8@github.com> References: <6mUJaCFaOVO8V3S6gtr6EZ7uRplgVXXJialmuWqdegM=.e114c23c-28e4-4b12-a99b-15b3a350d4f8@github.com> Message-ID: On Wed, 3 May 2023 20:00:42 GMT, Chris Plummer wrote: >> Yes, the test was finicky with the heap size. Given that the leak it tries to provoke would be provoked by other GCs as well, we didn't think it was that important to run this particular test with Generational ZGC. If you still think that we should create a Bug and ProblemList it, I'll do so. > > When I first wrote this test, it ended up failing with ZGC because I hadn't tested it. I considered excluding it for the same reason you've given, but then considered that the test might expose a leak with one GC, but not others, so I decided to fix it. I've created JDK-8307402. I'll push a problem list entry. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1184308134 From mdoerr at openjdk.org Wed May 3 21:35:28 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 3 May 2023 21:35:28 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v3] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 19:36:55 GMT, Stefan Karlsson wrote: >> Hi all, >> >> Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. >> >> The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention is to give the users time to validate and deploy their workloads with the new GC implementation. >> >> Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clear to us how time consuming and complex things end up being when we tried to keep both the original G1 working, and at the same time implemented the ZGC-alike G1. Given this experience, we don't see that as a viable solution to deliver a maintainable and evolving Generational ZGC. Our pragmatic suggestion to these challenges is to let Generational ZGC live under the current gc/z directories and let the legacy, non-generational ZGC be completely separated in its own directories. This way we can continue to move quickly with the continued develo pment of Generational ZGC and let the non-generational ZGC be mostly untouched until it gets deprecated, and eventually removed. The non-generational ZGC directory will be gc/x and all the classes of non-generational have been prefixed with X instead of Z. An alternative to this rename could be to namespace out non-generational ZGC. We experimented with that, but it was too easy to accidentally cross-compile Generational ZGC code into non-generational ZGC, so we didn't like that approach. >> >> Most of the stand-alone cleanups and enhancements outside of the ZGC code have already been upstreamed to openjdk/jdk. There are still a few patches that could/should be pushed separately, but they will be easier to understand by also looking at the Generational ZGC code, so they will be sent out after this PR has been published. The patches that could be published separately are: >> >> * 59d1e96af6a UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class >> * ca9edf8aa79 UPSTREAM: RISCV tmp reg cleanup resolve_jobject >> * 4bec9c69b67 CLEANUP: barrierSetNMethod_aarch64.cpp >> * b67d03a3f04 UPSTREAM: Add relaxed add&fetch for aarch64 atomics >> * a2824734d23 UPSTREAM: lir_xchg >> * 36cd39c0126 UPSTREAM: assembler_ppc CMPLI >> * 447259cea42 UPSTREAM: assembler_ppc ANDI >> * 9417323499a UPSTREAM: Add VMErrorCallback infrastructure >> >> Regarding all the changesets you see in this PR, they form the history of the development of Generational ZGC. It might look a bit unconventional to what you are used to see in openjdk development. What we have done is to use merges with the 'ours' strategy to ignore the previous Generational ZGC patches, and then rebased and flattened the changes on top of the merge. This effectively gives us the upsides of having a rebased repository and the upsides of retaining the history in the repository. The downside could be that GitHub now lists all those changesets in the PR. Given that this patch is so big, and that you likely only want to see a part of it, I suggest that you pull down the PR branch and then compare it to the openjdk/jdk changeset this PR is based against: >> >> >> git fetch https://github.com/openjdk/zgc zgc_master >> git diff zgc_master... >> >> >> There have been many contributors of this patch over the years. I'll do my best to poke Skara into listing you all, but if you see that I've missed your name please reach out to me and I'll fix it. >> >> Testing: we have been continuously running Generational ZGC through Oracle's tier1-8 testing. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Update SA ProblemList entries I'm getting build warnings on all linux platforms with gcc-11.3.0: ``` src/hotspot/share/gc/z/zDriver.cpp:84:13: error: In the GNU C Library, "minor" is defined by . For historical compatibility, it is currently defined by as well, but we plan to remove this soon. To use "minor", include directly. If you did not intend to use a system-defined macro "minor", you should undefine it after including . [-Werror] 84 | ZDriverMinor* ZDriver::minor() { ------------- PR Comment: https://git.openjdk.org/jdk/pull/13771#issuecomment-1533781342 From jiangli at openjdk.org Wed May 3 21:43:19 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 21:43:19 GMT Subject: RFR: 8307194: Enhance static-libs-image [v5] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 18:51:54 GMT, Severin Gehwolf wrote: >>> Could we decouple `hotspot-static-libs` from `static-libs-image` somehow, please? `static-libs-image` is used by the `graal-builder-image` target and it would be good if it didn't include hotspot static libs as they are not needed for it. >>> >>> Would it be sufficient to just use `hotspot-static-libs` directly? Like: `make static-libs-image hotspot-static-libs`? Failing that, could we introduce a new target that produces both? >> >> Good questions. I had similar thoughts when making the makefile changes. Here's my reasoning with the current approach in this PR: >> >> The `images/static-libs/lib` would provide a super set of the JDK/VM static libraries (in a JDK binary/release) for downstream developers to produce their desired final static image. With the addition of the `libjvm.a` and potentially bundled `libzlib.a` and `libfreetype.a` included in `static-libs-image` output, users could select the needed subset of the static libraries for their linking step (e.g. via jlink based on the needed modules) to produce the final image. >> >> If these changes are cumbersome for `graal-builder-image` usages, using `hotspot-static-libs` directly for producing `libjvm.a` as you suggested could be doable. Or, we could try using a new make target for producing the `.a` superset. There might be potential concerns/issues with the differences between `graal-builder-image` support and Java static image support, i.e. it might be a good idea to explore unified solution for both if possible. @dougxc and others related to GraalVM Native Image are on this review thread. It's a good idea to collect the thoughts together. > > GraalVM native-image has it's own `libjvm.a` shim which would likely conflict or produce undesirable results. So I'd prefer the approach where `static-libs-image` wouldn't produce hotspot `libjvm.a` as part of it. For new uses-cases needing that, we could add a new top-level target (like `graal-builder-image`) which would produce such an image. As one of the [Mandrel](https://github.com/graalvm/mandrel) maintainers, I'm not sure any post-build filtering via `jlink` or the like would be ideal for us. I'll see if I can test this on a mandrel build tomorrow... @jerboaa, thanks for the info. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184317386 From stefank at openjdk.org Wed May 3 21:48:12 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 3 May 2023 21:48:12 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v4] In-Reply-To: References: Message-ID: > Hi all, > > Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. > > The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention i s to give the users time to validate and deploy their workloads with the new GC implementation. > > Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clear to us how time consuming and complex things end up being when we tried to keep both the original G1 working, and at the same time implemented the ZGC-alike G1. Given this experience, we don't see that as a viable solution to deliver a maintainable and evolving Generational ZGC. Our pragmatic suggestion to these challenges is to let Generational ZGC live under the current gc/z directories and let the legacy, non-generational ZGC be completely separated in its own directories. This way we can continue to move quickly with the continued develop ment of Generational ZGC and let the non-generational ZGC be mostly untouched until it gets deprecated, and eventually removed. The non-generational ZGC directory will be gc/x and all the classes of non-generational have been prefixed with X instead of Z. An alternative to this rename could be to namespace out non-generational ZGC. We experimented with that, but it was too easy to accidentally cross-compile Generational ZGC code into non-generational ZGC, so we didn't like that approach. > > Most of the stand-alone cleanups and enhancements outside of the ZGC code have already been upstreamed to openjdk/jdk. There are still a few patches that could/should be pushed separately, but they will be easier to understand by also looking at the Generational ZGC code, so they will be sent out after this PR has been published. The patches that could be published separately are: > > * 59d1e96af6a UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class > * ca9edf8aa79 UPSTREAM: RISCV tmp reg cleanup resolve_jobject > * 4bec9c69b67 CLEANUP: barrierSetNMethod_aarch64.cpp > * b67d03a3f04 UPSTREAM: Add relaxed add&fetch for aarch64 atomics > * a2824734d23 UPSTREAM: lir_xchg > * 36cd39c0126 UPSTREAM: assembler_ppc CMPLI > * 447259cea42 UPSTREAM: assembler_ppc ANDI > * 9417323499a UPSTREAM: Add VMErrorCallback infrastructure > > Regarding all the changesets you see in this PR, they form the history of the development of Generational ZGC. It might look a bit unconventional to what you are used to see in openjdk development. What we have done is to use merges with the 'ours' strategy to ignore the previous Generational ZGC patches, and then rebased and flattened the changes on top of the merge. This effectively gives us the upsides of having a rebased repository and the upsides of retaining the history in the repository. The downside could be that GitHub now lists all those changesets in the PR. Given that this patch is so big, and that you likely only want to see a part of it, I suggest that you pull down the PR branch and then compare it to the openjdk/jdk changeset this PR is based against: > > > git fetch https://github.com/openjdk/zgc zgc_master > git diff zgc_master... > > > There have been many contributors of this patch over the years. I'll do my best to poke Skara into listing you all, but if you see that I've missed your name please reach out to me and I'll fix it. > > Testing: we have been continuously running Generational ZGC through Oracle's tier1-8 testing. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: ProblemList ThreadMemoryLeakTest.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13771/files - new: https://git.openjdk.org/jdk/pull/13771/files/40e8583b..9cb32f4c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13771&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13771&range=02-03 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13771.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13771/head:pull/13771 PR: https://git.openjdk.org/jdk/pull/13771 From stefank at openjdk.org Wed May 3 22:01:10 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 3 May 2023 22:01:10 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v5] In-Reply-To: References: Message-ID: > Hi all, > > Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. > > The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention i s to give the users time to validate and deploy their workloads with the new GC implementation. > > Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clear to us how time consuming and complex things end up being when we tried to keep both the original G1 working, and at the same time implemented the ZGC-alike G1. Given this experience, we don't see that as a viable solution to deliver a maintainable and evolving Generational ZGC. Our pragmatic suggestion to these challenges is to let Generational ZGC live under the current gc/z directories and let the legacy, non-generational ZGC be completely separated in its own directories. This way we can continue to move quickly with the continued develop ment of Generational ZGC and let the non-generational ZGC be mostly untouched until it gets deprecated, and eventually removed. The non-generational ZGC directory will be gc/x and all the classes of non-generational have been prefixed with X instead of Z. An alternative to this rename could be to namespace out non-generational ZGC. We experimented with that, but it was too easy to accidentally cross-compile Generational ZGC code into non-generational ZGC, so we didn't like that approach. > > Most of the stand-alone cleanups and enhancements outside of the ZGC code have already been upstreamed to openjdk/jdk. There are still a few patches that could/should be pushed separately, but they will be easier to understand by also looking at the Generational ZGC code, so they will be sent out after this PR has been published. The patches that could be published separately are: > > * 59d1e96af6a UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class > * ca9edf8aa79 UPSTREAM: RISCV tmp reg cleanup resolve_jobject > * 4bec9c69b67 CLEANUP: barrierSetNMethod_aarch64.cpp > * b67d03a3f04 UPSTREAM: Add relaxed add&fetch for aarch64 atomics > * a2824734d23 UPSTREAM: lir_xchg > * 36cd39c0126 UPSTREAM: assembler_ppc CMPLI > * 447259cea42 UPSTREAM: assembler_ppc ANDI > * 9417323499a UPSTREAM: Add VMErrorCallback infrastructure > > Regarding all the changesets you see in this PR, they form the history of the development of Generational ZGC. It might look a bit unconventional to what you are used to see in openjdk development. What we have done is to use merges with the 'ours' strategy to ignore the previous Generational ZGC patches, and then rebased and flattened the changes on top of the merge. This effectively gives us the upsides of having a rebased repository and the upsides of retaining the history in the repository. The downside could be that GitHub now lists all those changesets in the PR. Given that this patch is so big, and that you likely only want to see a part of it, I suggest that you pull down the PR branch and then compare it to the openjdk/jdk changeset this PR is based against: > > > git fetch https://github.com/openjdk/zgc zgc_master > git diff zgc_master... > > > There have been many contributors of this patch over the years. I'll do my best to poke Skara into listing you all, but if you see that I've missed your name please reach out to me and I'll fix it. > > Testing: we have been continuously running Generational ZGC through Oracle's tier1-8 testing. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: ProblemList jhsdb tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13771/files - new: https://git.openjdk.org/jdk/pull/13771/files/9cb32f4c..d65523f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13771&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13771&range=03-04 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13771.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13771/head:pull/13771 PR: https://git.openjdk.org/jdk/pull/13771 From stefank at openjdk.org Wed May 3 22:01:42 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 3 May 2023 22:01:42 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v3] In-Reply-To: References: Message-ID: <45EiQagy_IO6JBPslCPdMF0_Ab5tGpaPLPr-AtgmleI=.159d0eb4-f759-4d28-8872-407598dec193@github.com> On Wed, 3 May 2023 21:32:54 GMT, Martin Doerr wrote: > I'm getting build warnings on all linux platforms with gcc-11.3.0: > > ``` > src/hotspot/share/gc/z/zDriver.cpp:84:13: error: In the GNU C Library, "minor" is defined > by . For historical compatibility, it is > currently defined by as well, but we plan to > remove this soon. To use "minor", include > directly. If you did not intend to use a system-defined macro > "minor", you should undefine it after including . [-Werror] > 84 | ZDriverMinor* ZDriver::minor() { > ``` That's unfortunate as minor and major are quite central to Generational ZGC and having to rename those functions will make the code look worse. I wonder if we should undef minor and major where needed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13771#issuecomment-1533806231 From stefank at openjdk.org Thu May 4 09:40:33 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 4 May 2023 09:40:33 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v2] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 21:08:39 GMT, Stefan Karlsson wrote: >> test/jdk/ProblemList-generational-zgc.txt line 27: >> >>> 25: # >>> 26: # List of quarantined tests for testing with Generational ZGC. >>> 27: # >> >> Are the tests in `test/jdk/sun/tools/jhsdb/` not failing? > > It seems like these tests are only run with all GCs at the end of the development cycle. I've run them manually and verified that these tests fail as well. I'm going to problem list them. > > That run also revealed that jstat doesn't like when we report the initial capacity of the old generation as zero. See the calculation in: > src/jdk.jcmd/share/classes/sun/tools/jstat/resources/jstat_options > > column { > header "^O^" /* Old Space - Percent Used */ > data (1-((sun.gc.generation.1.space.0.capacity - sun.gc.generation.1.space.0.used)/sun.gc.generation.1.space.0.capacity)) * 100 > align right > scale raw > width 6 > format "0.00" > } > > > I can work around the test problem by faking the capacity to be non-zero, but that's not a pretty solution IMO. The jhsdb tests have been ProblemListed. The jstat test is going to be fixed with #13796. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1184781772 From aboldtch at openjdk.org Thu May 4 09:53:32 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 4 May 2023 09:53:32 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v3] In-Reply-To: <45EiQagy_IO6JBPslCPdMF0_Ab5tGpaPLPr-AtgmleI=.159d0eb4-f759-4d28-8872-407598dec193@github.com> References: <45EiQagy_IO6JBPslCPdMF0_Ab5tGpaPLPr-AtgmleI=.159d0eb4-f759-4d28-8872-407598dec193@github.com> Message-ID: On Wed, 3 May 2023 21:58:25 GMT, Stefan Karlsson wrote: > I'm getting build warnings on all linux platforms with gcc-11.3.0: > > ``` > src/hotspot/share/gc/z/zDriver.cpp:84:13: error: In the GNU C Library, "minor" is defined > by . For historical compatibility, it is > currently defined by as well, but we plan to > remove this soon. To use "minor", include > directly. If you did not intend to use a system-defined macro > "minor", you should undefine it after including . [-Werror] > 84 | ZDriverMinor* ZDriver::minor() { > ``` @TheRealMDoerr I cannot reproduce this with gcc but can see the issue with clangd. Can you check if this patch solves the issue you are seeing? diff --git a/src/hotspot/share/gc/z/zDriver.hpp b/src/hotspot/share/gc/z/zDriver.hpp index 640ea6575ef..7fa650b1fa1 100644 --- a/src/hotspot/share/gc/z/zDriver.hpp +++ b/src/hotspot/share/gc/z/zDriver.hpp @@ -29,6 +29,14 @@ #include "gc/z/zThread.hpp" #include "gc/z/zTracer.hpp" +#ifdef minor +#undef minor +#endif + +#ifdef major +#undef major +#endif + class VM_ZOperation; class ZDriverMinor; class ZDriverMajor; ------------- PR Comment: https://git.openjdk.org/jdk/pull/13771#issuecomment-1534438516 From duke at openjdk.org Thu May 4 10:10:17 2023 From: duke at openjdk.org (Paul Woegerer) Date: Thu, 4 May 2023 10:10:17 GMT Subject: RFR: 8307194: Enhance static-libs-image [v5] In-Reply-To: References: Message-ID: <8PLZSKy3BqQJtO70vyqRrc3uCnbbipqF9Jjv1ILTKyo=.9366d45f-f471-47aa-a59e-88e65cf6e2af@github.com> On Wed, 3 May 2023 18:51:54 GMT, Severin Gehwolf wrote: >>> Could we decouple `hotspot-static-libs` from `static-libs-image` somehow, please? `static-libs-image` is used by the `graal-builder-image` target and it would be good if it didn't include hotspot static libs as they are not needed for it. >>> >>> Would it be sufficient to just use `hotspot-static-libs` directly? Like: `make static-libs-image hotspot-static-libs`? Failing that, could we introduce a new target that produces both? >> >> Good questions. I had similar thoughts when making the makefile changes. Here's my reasoning with the current approach in this PR: >> >> The `images/static-libs/lib` would provide a super set of the JDK/VM static libraries (in a JDK binary/release) for downstream developers to produce their desired final static image. With the addition of the `libjvm.a` and potentially bundled `libzlib.a` and `libfreetype.a` included in `static-libs-image` output, users could select the needed subset of the static libraries for their linking step (e.g. via jlink based on the needed modules) to produce the final image. >> >> If these changes are cumbersome for `graal-builder-image` usages, using `hotspot-static-libs` directly for producing `libjvm.a` as you suggested could be doable. Or, we could try using a new make target for producing the `.a` superset. There might be potential concerns/issues with the differences between `graal-builder-image` support and Java static image support, i.e. it might be a good idea to explore unified solution for both if possible. @dougxc and others related to GraalVM Native Image are on this review thread. It's a good idea to collect the thoughts together. > > GraalVM native-image has it's own `libjvm.a` shim which would likely conflict or produce undesirable results. So I'd prefer the approach where `static-libs-image` wouldn't produce hotspot `libjvm.a` as part of it. For new uses-cases needing that, we could add a new top-level target (like `graal-builder-image`) which would produce such an image. As one of the [Mandrel](https://github.com/graalvm/mandrel) maintainers, I'm not sure any post-build filtering via `jlink` or the like would be ideal for us. I'll see if I can test this on a mandrel build tomorrow... As @jerboaa mentioned, for GraalVM native-image we produce our own `libjvm.a` as part of building GraalVM (every native image gets statically linked to that library). See https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/mx_substratevm.py#L1378 and `com.oracle.svm.native.jvm.{posix,windows}` in https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/suite.py#L736. Having a hot-spot variant of `libjvm.a` next to the other static libraries might complicate things for us. Ideally the output files produced by target `static-libs-image` should remain the same. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184786403 From mdoerr at openjdk.org Thu May 4 11:04:38 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 4 May 2023 11:04:38 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v3] In-Reply-To: References: <45EiQagy_IO6JBPslCPdMF0_Ab5tGpaPLPr-AtgmleI=.159d0eb4-f759-4d28-8872-407598dec193@github.com> Message-ID: On Thu, 4 May 2023 09:50:23 GMT, Axel Boldt-Christmas wrote: >>> I'm getting build warnings on all linux platforms with gcc-11.3.0: >>> >>> ``` >>> src/hotspot/share/gc/z/zDriver.cpp:84:13: error: In the GNU C Library, "minor" is defined >>> by . For historical compatibility, it is >>> currently defined by as well, but we plan to >>> remove this soon. To use "minor", include >>> directly. If you did not intend to use a system-defined macro >>> "minor", you should undefine it after including . [-Werror] >>> 84 | ZDriverMinor* ZDriver::minor() { >>> ``` >> >> That's unfortunate as minor and major are quite central to Generational ZGC and having to rename those functions will make the code look worse. I wonder if we should undef minor and major where needed. > >> I'm getting build warnings on all linux platforms with gcc-11.3.0: >> >> ``` >> src/hotspot/share/gc/z/zDriver.cpp:84:13: error: In the GNU C Library, "minor" is defined >> by . For historical compatibility, it is >> currently defined by as well, but we plan to >> remove this soon. To use "minor", include >> directly. If you did not intend to use a system-defined macro >> "minor", you should undefine it after including . [-Werror] >> 84 | ZDriverMinor* ZDriver::minor() { >> ``` > > @TheRealMDoerr I cannot reproduce this with gcc but can see the issue with clangd. > Can you check if this patch solves the issue you are seeing? > > diff --git a/src/hotspot/share/gc/z/zDriver.hpp b/src/hotspot/share/gc/z/zDriver.hpp > index 640ea6575ef..7fa650b1fa1 100644 > --- a/src/hotspot/share/gc/z/zDriver.hpp > +++ b/src/hotspot/share/gc/z/zDriver.hpp > @@ -29,6 +29,14 @@ > #include "gc/z/zThread.hpp" > #include "gc/z/zTracer.hpp" > > +#ifdef minor > +#undef minor > +#endif > + > +#ifdef major > +#undef major > +#endif > + > class VM_ZOperation; > class ZDriverMinor; > class ZDriverMajor; @xmas92: Thanks for your quick solution. Your patch solves the problem. If you want to integrate it, please also add a comment why this is needed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13771#issuecomment-1534563624 From aboldtch at openjdk.org Thu May 4 11:18:31 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 4 May 2023 11:18:31 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v3] In-Reply-To: References: <45EiQagy_IO6JBPslCPdMF0_Ab5tGpaPLPr-AtgmleI=.159d0eb4-f759-4d28-8872-407598dec193@github.com> Message-ID: On Thu, 4 May 2023 09:50:23 GMT, Axel Boldt-Christmas wrote: >>> I'm getting build warnings on all linux platforms with gcc-11.3.0: >>> >>> ``` >>> src/hotspot/share/gc/z/zDriver.cpp:84:13: error: In the GNU C Library, "minor" is defined >>> by . For historical compatibility, it is >>> currently defined by as well, but we plan to >>> remove this soon. To use "minor", include >>> directly. If you did not intend to use a system-defined macro >>> "minor", you should undefine it after including . [-Werror] >>> 84 | ZDriverMinor* ZDriver::minor() { >>> ``` >> >> That's unfortunate as minor and major are quite central to Generational ZGC and having to rename those functions will make the code look worse. I wonder if we should undef minor and major where needed. > >> I'm getting build warnings on all linux platforms with gcc-11.3.0: >> >> ``` >> src/hotspot/share/gc/z/zDriver.cpp:84:13: error: In the GNU C Library, "minor" is defined >> by . For historical compatibility, it is >> currently defined by as well, but we plan to >> remove this soon. To use "minor", include >> directly. If you did not intend to use a system-defined macro >> "minor", you should undefine it after including . [-Werror] >> 84 | ZDriverMinor* ZDriver::minor() { >> ``` > > @TheRealMDoerr I cannot reproduce this with gcc but can see the issue with clangd. > Can you check if this patch solves the issue you are seeing? > > diff --git a/src/hotspot/share/gc/z/zDriver.hpp b/src/hotspot/share/gc/z/zDriver.hpp > index 640ea6575ef..7fa650b1fa1 100644 > --- a/src/hotspot/share/gc/z/zDriver.hpp > +++ b/src/hotspot/share/gc/z/zDriver.hpp > @@ -29,6 +29,14 @@ > #include "gc/z/zThread.hpp" > #include "gc/z/zTracer.hpp" > > +#ifdef minor > +#undef minor > +#endif > + > +#ifdef major > +#undef major > +#endif > + > class VM_ZOperation; > class ZDriverMinor; > class ZDriverMajor; > @xmas92: Thanks for your quick solution. Your patch solves the problem. If you want to integrate it, please also add a comment why this is needed. Thanks for testing it. Will do. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13771#issuecomment-1534586643 From stefank at openjdk.org Thu May 4 11:44:14 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 4 May 2023 11:44:14 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v6] In-Reply-To: References: Message-ID: > Hi all, > > Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. > > The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention i s to give the users time to validate and deploy their workloads with the new GC implementation. > > Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clear to us how time consuming and complex things end up being when we tried to keep both the original G1 working, and at the same time implemented the ZGC-alike G1. Given this experience, we don't see that as a viable solution to deliver a maintainable and evolving Generational ZGC. Our pragmatic suggestion to these challenges is to let Generational ZGC live under the current gc/z directories and let the legacy, non-generational ZGC be completely separated in its own directories. This way we can continue to move quickly with the continued develop ment of Generational ZGC and let the non-generational ZGC be mostly untouched until it gets deprecated, and eventually removed. The non-generational ZGC directory will be gc/x and all the classes of non-generational have been prefixed with X instead of Z. An alternative to this rename could be to namespace out non-generational ZGC. We experimented with that, but it was too easy to accidentally cross-compile Generational ZGC code into non-generational ZGC, so we didn't like that approach. > > Most of the stand-alone cleanups and enhancements outside of the ZGC code have already been upstreamed to openjdk/jdk. There are still a few patches that could/should be pushed separately, but they will be easier to understand by also looking at the Generational ZGC code, so they will be sent out after this PR has been published. The patches that could be published separately are: > > * 59d1e96af6a UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class > * ca9edf8aa79 UPSTREAM: RISCV tmp reg cleanup resolve_jobject > * 4bec9c69b67 CLEANUP: barrierSetNMethod_aarch64.cpp > * b67d03a3f04 UPSTREAM: Add relaxed add&fetch for aarch64 atomics > * a2824734d23 UPSTREAM: lir_xchg > * 36cd39c0126 UPSTREAM: assembler_ppc CMPLI > * 447259cea42 UPSTREAM: assembler_ppc ANDI > * 9417323499a UPSTREAM: Add VMErrorCallback infrastructure > > Regarding all the changesets you see in this PR, they form the history of the development of Generational ZGC. It might look a bit unconventional to what you are used to see in openjdk development. What we have done is to use merges with the 'ours' strategy to ignore the previous Generational ZGC patches, and then rebased and flattened the changes on top of the merge. This effectively gives us the upsides of having a rebased repository and the upsides of retaining the history in the repository. The downside could be that GitHub now lists all those changesets in the PR. Given that this patch is so big, and that you likely only want to see a part of it, I suggest that you pull down the PR branch and then compare it to the openjdk/jdk changeset this PR is based against: > > > git fetch https://github.com/openjdk/zgc zgc_master > git diff zgc_master... > > > There have been many contributors of this patch over the years. I'll do my best to poke Skara into listing you all, but if you see that I've missed your name please reach out to me and I'll fix it. > > Testing: we have been continuously running Generational ZGC through Oracle's tier1-8 testing. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: undefine glibc major/minor macros ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13771/files - new: https://git.openjdk.org/jdk/pull/13771/files/d65523f5..c9f6257b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13771&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13771&range=04-05 Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13771.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13771/head:pull/13771 PR: https://git.openjdk.org/jdk/pull/13771 From azvegint at openjdk.org Thu May 4 15:34:42 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 4 May 2023 15:34:42 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots Message-ID: Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. This comes with some difficulties, and one of them is the inability to get screenshots from the system. This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) But this functionality is a very important part of automated testing. At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) It has several drawbacks though: + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). + There is no way to disable the visual "screen flash" after screenshot + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. But we still can consider this option as a fallback. 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. + implementation is more complicated comparing to Screenshot API + no intermediate file, screenshot data can be obtained from memory + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. This change also introduces some new behavior for the robot: A system window now appears asking for confirmation from the user to capture the screen. + The user can refuse the screen capture completely. In this case a security exception will be thrown. + The user can allow a screen capture for all screens or some of them. For screens without permission there will be a black image. + If the user wishes to change their mind about the screens allowed to be captured, the user should use the new `Robot#resetScreenCapturePermission` method Also added several system properties: `awt.robot.screencastEnabled` false by default, uses the ScreenCast API if true `awt.robot.screencastDebug` false by default, prints some debug information if true For convenience, this change is divided into two commits: 1. added [pipewire headers](https://gitlab.freedesktop.org/pipewire/pipewire/) that are needed for the build 2. main changes Changes in the documentation are in a separate PR (#13804) also for convenience. At the moment, the planned supported systems are Ubuntu 22.04+, the latest Oracle Linux 9.1 and RHEL 9.1 has some issues with restore_token support. ------------- Commit messages: - replace tabs with spaces - main changes - add pipewire header files Changes: https://git.openjdk.org/jdk/pull/13803/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8280982 Stats: 14277 lines in 107 files changed: 14237 ins; 18 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/13803.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13803/head:pull/13803 PR: https://git.openjdk.org/jdk/pull/13803 From sgehwolf at openjdk.org Thu May 4 19:15:15 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 4 May 2023 19:15:15 GMT Subject: RFR: 8307194: Enhance static-libs-image [v5] In-Reply-To: <8PLZSKy3BqQJtO70vyqRrc3uCnbbipqF9Jjv1ILTKyo=.9366d45f-f471-47aa-a59e-88e65cf6e2af@github.com> References: <8PLZSKy3BqQJtO70vyqRrc3uCnbbipqF9Jjv1ILTKyo=.9366d45f-f471-47aa-a59e-88e65cf6e2af@github.com> Message-ID: On Thu, 4 May 2023 09:40:31 GMT, Paul Woegerer wrote: >> GraalVM native-image has it's own `libjvm.a` shim which would likely conflict or produce undesirable results. So I'd prefer the approach where `static-libs-image` wouldn't produce hotspot `libjvm.a` as part of it. For new uses-cases needing that, we could add a new top-level target (like `graal-builder-image`) which would produce such an image. As one of the [Mandrel](https://github.com/graalvm/mandrel) maintainers, I'm not sure any post-build filtering via `jlink` or the like would be ideal for us. I'll see if I can test this on a mandrel build tomorrow... > > As @jerboaa mentioned, for GraalVM native-image we produce our own `libjvm.a` as part of building GraalVM (every native image gets statically linked to that library). See https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/mx_substratevm.py#L1378 and `com.oracle.svm.native.jvm.{posix,windows}` in https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/suite.py#L736. > > Having a hot-spot variant of `libjvm.a` next to the other static libraries might complicate things for us. Ideally the output files produced by target `static-libs-image` should remain the same. > [...] I'll see if I can test this on a mandrel build tomorrow... @jianglizhou So I've tested this with a mandrel build and it doesn't break terribly, but a graalvm build after this patch has *two* `libjvm.a` which a) doesn't make sense, b) the hotspot version is **very** large (> 1 GB on my system), so unnecessarily bloats the install. I remain of the opinion that the hotspot `libjvm.a` should only get generated for a new make target (not change the old `static-libs-image` target). Do you think that would be a workable solution for you? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1185416553 From jiangli at openjdk.org Thu May 4 19:25:18 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 4 May 2023 19:25:18 GMT Subject: RFR: 8307194: Enhance static-libs-image [v5] In-Reply-To: References: <8PLZSKy3BqQJtO70vyqRrc3uCnbbipqF9Jjv1ILTKyo=.9366d45f-f471-47aa-a59e-88e65cf6e2af@github.com> Message-ID: On Thu, 4 May 2023 19:12:14 GMT, Severin Gehwolf wrote: >> As @jerboaa mentioned, for GraalVM native-image we produce our own `libjvm.a` as part of building GraalVM (every native image gets statically linked to that library). See https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/mx_substratevm.py#L1378 and `com.oracle.svm.native.jvm.{posix,windows}` in https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/suite.py#L736. >> >> Having a hot-spot variant of `libjvm.a` next to the other static libraries might complicate things for us. Ideally the output files produced by target `static-libs-image` should remain the same. > >> [...] I'll see if I can test this on a mandrel build tomorrow... > > @jianglizhou So I've tested this with a mandrel build and it doesn't break terribly, but a graalvm build after this patch has *two* `libjvm.a` which a) doesn't make sense, b) the hotspot version is **very** large (> 1 GB on my system), so unnecessarily bloats the install. I remain of the opinion that the hotspot `libjvm.a` should only get generated for a new make target (not change the old `static-libs-image` target). Do you think that would be a workable solution for you? @jerboaa Thanks very much for testing with mandrel. Based on yours and @olpaw's feedback, I'll refactor this PR to not use the existing `static-libs-image` target for including hotspot `libjvm.a`. I'll also reflect that in the bug & PR titles as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1185426052 From jiangli at openjdk.org Thu May 4 19:35:39 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 4 May 2023 19:35:39 GMT Subject: RFR: 8307194: Enhance static-libs-image [v5] In-Reply-To: References: <8PLZSKy3BqQJtO70vyqRrc3uCnbbipqF9Jjv1ILTKyo=.9366d45f-f471-47aa-a59e-88e65cf6e2af@github.com> Message-ID: On Thu, 4 May 2023 19:12:14 GMT, Severin Gehwolf wrote: >> As @jerboaa mentioned, for GraalVM native-image we produce our own `libjvm.a` as part of building GraalVM (every native image gets statically linked to that library). See https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/mx_substratevm.py#L1378 and `com.oracle.svm.native.jvm.{posix,windows}` in https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/suite.py#L736. >> >> Having a hot-spot variant of `libjvm.a` next to the other static libraries might complicate things for us. Ideally the output files produced by target `static-libs-image` should remain the same. > >> [...] I'll see if I can test this on a mandrel build tomorrow... > > @jianglizhou So I've tested this with a mandrel build and it doesn't break terribly, but a graalvm build after this patch has *two* `libjvm.a` which a) doesn't make sense, b) the hotspot version is **very** large (> 1 GB on my system), so unnecessarily bloats the install. I remain of the opinion that the hotspot `libjvm.a` should only get generated for a new make target (not change the old `static-libs-image` target). Do you think that would be a workable solution for you? > As @jerboaa mentioned, for GraalVM native-image we produce our own `libjvm.a` as part of building GraalVM (every native image gets statically linked to that library). See https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/mx_substratevm.py#L1378 and `com.oracle.svm.native.jvm.{posix,windows}` in https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/suite.py#L736. > > Having a hot-spot variant of `libjvm.a` next to the other static libraries might complicate things for us. Ideally the output files produced by target `static-libs-image` should remain the same. @olpaw Thanks for the input. Could you also please take a look of the changes that excludes the object files from the following static libraries from Graal native image usage perspective? - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled. - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1185436692 From erikj at openjdk.org Thu May 4 19:59:17 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 4 May 2023 19:59:17 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots In-Reply-To: References: Message-ID: <_cTykE_ylL_s6FEZD-whKcVLZHtoca25nQ07DJg3zbc=.9107511d-1770-4259-8465-ae1998e0aba6@github.com> On Thu, 4 May 2023 14:18:44 GMT, Alexander Zvegintsev wrote: > Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. > This comes with some difficulties, and one of them is the inability to get screenshots from the system. > This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) > > But this functionality is a very important part of automated testing. > > > At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): > > 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) > It has several drawbacks though: > + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). > + There is no way to disable the visual "screen flash" after screenshot > + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. > Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. > But we still can consider this option as a fallback. > > > > 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) > It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. > This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. > > + implementation is more complicated comparing to Screenshot API > + no intermediate file, screenshot data can be obtained from memory > + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) > > > So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. > > This change also introduces some new behavior for the robot: > A system window now appears asking for confirmation from the user to capture the screen. > + The user can refuse the screen capture completely. In this case a security exception will be thrown. > + The user can allow a screen capture for all screens or some of them. For screens without permission there will be a black image. > + If the user wishes to change their mind about the screens allowed to be captured, the user should use the new `Robot#resetScreenCapturePermission` method > > Also added several system properties: > `awt.robot.screencastEnabled` false by default, uses the ScreenCast API if true > `awt.robot.screencastDebug` false by default, prints some debug information if true > > For convenience, this change is divided into two commits: > 1. added [pipewire headers](https://gitlab.freedesktop.org/pipewire/pipewire/) that are needed for the build > 2. main changes > > Changes in the documentation are in a separate draft PR (#13809) also for convenience. > > At the moment, the planned supported systems are Ubuntu 22.04+, the latest Oracle Linux 9.1 and RHEL 9.1 has some issues with restore_token support. I would like to understand why we need to add third party headers to our source tree. Are these not generally available on Linux systems? You say that the functionality isn't enabled by default, is that a runtime thing? It loos like it will be built unconditionally. make/modules/java.desktop/lib/Awt2dLibraries.gmk line 194: > 192: LIBAWT_XAWT_EXCLUDES := medialib debug > 193: > 194: BUILD_LIBPIPEWIRE_HEADER_DIRS := \ This variable name indicates that LIBPIPEWIRE is a library that we would build, but it seems to just be headers. I would suggest dropping the `BUILD_` prefix. ------------- PR Review: https://git.openjdk.org/jdk/pull/13803#pullrequestreview-1413812683 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1185452739 From aturbanov at openjdk.org Thu May 4 20:24:29 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 4 May 2023 20:24:29 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v6] In-Reply-To: References: Message-ID: <_UHP565f9Io3v9rWWDf0HGRhhtNoniDhbM_XEM-2w1c=.f7cb7bae-5837-42ff-9491-284093ba4c75@github.com> On Thu, 4 May 2023 11:44:14 GMT, Stefan Karlsson wrote: >> Hi all, >> >> Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. >> >> The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention is to give the users time to validate and deploy their workloads with the new GC implementation. >> >> Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clear to us how time consuming and complex things end up being when we tried to keep both the original G1 working, and at the same time implemented the ZGC-alike G1. Given this experience, we don't see that as a viable solution to deliver a maintainable and evolving Generational ZGC. Our pragmatic suggestion to these challenges is to let Generational ZGC live under the current gc/z directories and let the legacy, non-generational ZGC be completely separated in its own directories. This way we can continue to move quickly with the continued develo pment of Generational ZGC and let the non-generational ZGC be mostly untouched until it gets deprecated, and eventually removed. The non-generational ZGC directory will be gc/x and all the classes of non-generational have been prefixed with X instead of Z. An alternative to this rename could be to namespace out non-generational ZGC. We experimented with that, but it was too easy to accidentally cross-compile Generational ZGC code into non-generational ZGC, so we didn't like that approach. >> >> Most of the stand-alone cleanups and enhancements outside of the ZGC code have already been upstreamed to openjdk/jdk. There are still a few patches that could/should be pushed separately, but they will be easier to understand by also looking at the Generational ZGC code, so they will be sent out after this PR has been published. The patches that could be published separately are: >> >> * 59d1e96af6a UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class >> * ca9edf8aa79 UPSTREAM: RISCV tmp reg cleanup resolve_jobject >> * 4bec9c69b67 CLEANUP: barrierSetNMethod_aarch64.cpp >> * b67d03a3f04 UPSTREAM: Add relaxed add&fetch for aarch64 atomics >> * a2824734d23 UPSTREAM: lir_xchg >> * 36cd39c0126 UPSTREAM: assembler_ppc CMPLI >> * 447259cea42 UPSTREAM: assembler_ppc ANDI >> * 9417323499a UPSTREAM: Add VMErrorCallback infrastructure >> >> Regarding all the changesets you see in this PR, they form the history of the development of Generational ZGC. It might look a bit unconventional to what you are used to see in openjdk development. What we have done is to use merges with the 'ours' strategy to ignore the previous Generational ZGC patches, and then rebased and flattened the changes on top of the merge. This effectively gives us the upsides of having a rebased repository and the upsides of retaining the history in the repository. The downside could be that GitHub now lists all those changesets in the PR. Given that this patch is so big, and that you likely only want to see a part of it, I suggest that you pull down the PR branch and then compare it to the openjdk/jdk changeset this PR is based against: >> >> >> git fetch https://github.com/openjdk/zgc zgc_master >> git diff zgc_master... >> >> >> There have been many contributors of this patch over the years. I'll do my best to poke Skara into listing you all, but if you see that I've missed your name please reach out to me and I'll fix it. >> >> Testing: we have been continuously running Generational ZGC through Oracle's tier1-8 testing. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > undefine glibc major/minor macros test/hotspot/jtreg/runtime/stringtable/StringTableCleaningTest.java line 117: > 115: return gcEndPrefix + g1Suffix; > 116: } else if (GC.Z.isSelected()) { > 117: return gcEndPrefix + "(" + zEndSuffix + ")|(" + xEndSuffix + ")"; nit Suggestion: return gcEndPrefix + "(" + zEndSuffix + ")|(" + xEndSuffix + ")"; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1185476249 From prr at openjdk.org Thu May 4 20:25:18 2023 From: prr at openjdk.org (Phil Race) Date: Thu, 4 May 2023 20:25:18 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots In-Reply-To: <_cTykE_ylL_s6FEZD-whKcVLZHtoca25nQ07DJg3zbc=.9107511d-1770-4259-8465-ae1998e0aba6@github.com> References: <_cTykE_ylL_s6FEZD-whKcVLZHtoca25nQ07DJg3zbc=.9107511d-1770-4259-8465-ae1998e0aba6@github.com> Message-ID: On Thu, 4 May 2023 19:56:21 GMT, Erik Joelsson wrote: > I would like to understand why we need to add third party headers to our source tree. Are these not generally available on Linux systems? They are not available on anything except very new Linux distros. Forget RHEL 6.x / 7.x. I'm fairly sure not 8.x either. RHEL/OL 9.x could an example of the earliest that would work to build without these imports. And that's just for building, even current 9.1 doesn't have sufficiently working runtime libs. There should be a fix for that in 9.2 .. Ubuntu 22.04 is however known to be OK. > You say that the functionality isn't enabled by default, is that a runtime thing? It loos like it will be built unconditionally. Yes, a runtime thing. An implementation System Property needs to be set. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1535363156 From mcimadamore at openjdk.org Thu May 4 20:53:32 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 4 May 2023 20:53:32 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v8] In-Reply-To: References: Message-ID: <2yJRhrPzbNeYBsrEdaC6xv3ng7kv5LI9IEP20zkoUgc=.b38576ed-a819-404b-9cea-b78b65e24b04@github.com> On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey wrote: >> Add flexible main methods and anonymous main classes to the Java language. > > Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: > > - Anonymous main classes renamed to unnamed classes > - Add test The compiler changes look good - I like howthe code got simpler by adding the main class wrapper at parser time. As I suggested elsewhere, do we want to change `Pretty` so that the AST of an unnamed class is rendered like if the unnamed class wasn't there (e.g. so that the output is like the source where the AST comes from) ? ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13689#pullrequestreview-1413902695 From james.laskey at oracle.com Thu May 4 20:56:22 2023 From: james.laskey at oracle.com (Jim Laskey) Date: Thu, 4 May 2023 20:56:22 +0000 Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v8] In-Reply-To: <2yJRhrPzbNeYBsrEdaC6xv3ng7kv5LI9IEP20zkoUgc=.b38576ed-a819-404b-9cea-b78b65e24b04@github.com> References: <2yJRhrPzbNeYBsrEdaC6xv3ng7kv5LI9IEP20zkoUgc=.b38576ed-a819-404b-9cea-b78b65e24b04@github.com> Message-ID: I suppose that?s a possibility. But is it more informative to have the class print with the synthetic flag? ? > On May 4, 2023, at 5:54 PM, Maurizio Cimadamore wrote: > > ?On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey wrote: > >>> Add flexible main methods and anonymous main classes to the Java language. >> >> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: >> >> - Anonymous main classes renamed to unnamed classes >> - Add test > > The compiler changes look good - I like howthe code got simpler by adding the main class wrapper at parser time. As I suggested elsewhere, do we want to change `Pretty` so that the AST of an unnamed class is rendered like if the unnamed class wasn't there (e.g. so that the output is like the source where the AST comes from) ? > > ------------- > > Marked as reviewed by mcimadamore (Reviewer). > > PR Review: https://git.openjdk.org/jdk/pull/13689#pullrequestreview-1413902695 From fyang at openjdk.org Fri May 5 02:00:29 2023 From: fyang at openjdk.org (Fei Yang) Date: Fri, 5 May 2023 02:00:29 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v6] In-Reply-To: References: Message-ID: On Thu, 4 May 2023 11:44:14 GMT, Stefan Karlsson wrote: >> Hi all, >> >> Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. >> >> The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention is to give the users time to validate and deploy their workloads with the new GC implementation. >> >> Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clear to us how time consuming and complex things end up being when we tried to keep both the original G1 working, and at the same time implemented the ZGC-alike G1. Given this experience, we don't see that as a viable solution to deliver a maintainable and evolving Generational ZGC. Our pragmatic suggestion to these challenges is to let Generational ZGC live under the current gc/z directories and let the legacy, non-generational ZGC be completely separated in its own directories. This way we can continue to move quickly with the continued develo pment of Generational ZGC and let the non-generational ZGC be mostly untouched until it gets deprecated, and eventually removed. The non-generational ZGC directory will be gc/x and all the classes of non-generational have been prefixed with X instead of Z. An alternative to this rename could be to namespace out non-generational ZGC. We experimented with that, but it was too easy to accidentally cross-compile Generational ZGC code into non-generational ZGC, so we didn't like that approach. >> >> Most of the stand-alone cleanups and enhancements outside of the ZGC code have already been upstreamed to openjdk/jdk. There are still a few patches that could/should be pushed separately, but they will be easier to understand by also looking at the Generational ZGC code, so they will be sent out after this PR has been published. The patches that could be published separately are: >> >> * 59d1e96af6a UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class >> * ca9edf8aa79 UPSTREAM: RISCV tmp reg cleanup resolve_jobject >> * 4bec9c69b67 CLEANUP: barrierSetNMethod_aarch64.cpp >> * b67d03a3f04 UPSTREAM: Add relaxed add&fetch for aarch64 atomics >> * a2824734d23 UPSTREAM: lir_xchg >> * 36cd39c0126 UPSTREAM: assembler_ppc CMPLI >> * 447259cea42 UPSTREAM: assembler_ppc ANDI >> * 9417323499a UPSTREAM: Add VMErrorCallback infrastructure >> >> Regarding all the changesets you see in this PR, they form the history of the development of Generational ZGC. It might look a bit unconventional to what you are used to see in openjdk development. What we have done is to use merges with the 'ours' strategy to ignore the previous Generational ZGC patches, and then rebased and flattened the changes on top of the merge. This effectively gives us the upsides of having a rebased repository and the upsides of retaining the history in the repository. The downside could be that GitHub now lists all those changesets in the PR. Given that this patch is so big, and that you likely only want to see a part of it, I suggest that you pull down the PR branch and then compare it to the openjdk/jdk changeset this PR is based against: >> >> >> git fetch https://github.com/openjdk/zgc zgc_master >> git diff zgc_master... >> >> >> There have been many contributors of this patch over the years. I'll do my best to poke Skara into listing you all, but if you see that I've missed your name please reach out to me and I'll fix it. >> >> Testing: we have been continuously running Generational ZGC through Oracle's tier1-8 testing. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > undefine glibc major/minor macros test/hotspot/gtest/gc/z/test_zForwarding.cpp line 68: > 66: > 67: bool reserved = os::attempt_reserve_memory_at((char*)ZAddressHeapBase, ZGranuleSize, false /* executable */); > 68: ASSERT_TRUE(reserved); Hi, Thanks for the great work! I have performed some tests on linux-riscv64 Hifive Unmatched board. So far, I only witnessed one gtest failure: $ make test TEST=gtest:ZForwardingTest Building target 'test' in configuration 'linux-riscv64-server-release' Test selection 'gtest:ZForwardingTest', will run: * gtest:ZForwardingTest/server Running test 'gtest:ZForwardingTest/server' Note: Google Test filter = ZForwardingTest* [==========] Running 4 tests from 1 test suite. [----------] Global test environment set-up. [----------] 4 tests from ZForwardingTest [ RUN ] ZForwardingTest.setup_vm test/hotspot/gtest/gc/z/test_zForwarding.cpp:68: Failure Value of: reserved Actual: false Expected: true [ FAILED ] ZForwardingTest.setup_vm (0 ms) [ RUN ] ZForwardingTest.find_empty_vm [ OK ] ZForwardingTest.find_empty_vm (1 ms) [ RUN ] ZForwardingTest.find_full_vm [ OK ] ZForwardingTest.find_full_vm (8 ms) [ RUN ] ZForwardingTest.find_every_other_vm [ OK ] ZForwardingTest.find_every_other_vm (0 ms) [----------] 4 tests from ZForwardingTest (761 ms total) [----------] Global test environment tear-down ERROR: RUN_ALL_TESTS() failed. Error 1 [==========] 4 tests from 1 test suite ran. (762 ms total) [ PASSED ] 3 tests. [ FAILED ] 1 test, listed below: [ FAILED ] ZForwardingTest.setup_vm 1 FAILED TEST Finished running test 'gtest:ZForwardingTest/server' Test report is stored in build/linux-riscv64-server-release/test-results/gtest_ZForwardingTest_server ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR >> gtest:ZForwardingTest/server 4 3 1 0 << ============================== TEST FAILURE The gtest failed this assertion where 'reserved' return by function os::attempt_reserve_memory_at is false. I find the reason is that the mmap call at the bottom returns a different address instead of the requested one (ZAddressHeapBase). I think that is possible since we are not sure if the requested address is available before the mmap call, right? So I guess we might need some changes here for this gtest. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1185645071 From serb at openjdk.org Fri May 5 02:40:12 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 5 May 2023 02:40:12 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots In-Reply-To: References: Message-ID: On Thu, 4 May 2023 14:18:44 GMT, Alexander Zvegintsev wrote: > If the user wishes to change their mind about the screens allowed to be captured, the user should use the new Robot#resetScreenCapturePermission method Do we really need to add this new API? probably we can implement the feature w/o this new method? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1535626183 From stefank at openjdk.org Fri May 5 05:12:59 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 5 May 2023 05:12:59 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v7] In-Reply-To: References: Message-ID: > Hi all, > > Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. > > The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention i s to give the users time to validate and deploy their workloads with the new GC implementation. > > Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clear to us how time consuming and complex things end up being when we tried to keep both the original G1 working, and at the same time implemented the ZGC-alike G1. Given this experience, we don't see that as a viable solution to deliver a maintainable and evolving Generational ZGC. Our pragmatic suggestion to these challenges is to let Generational ZGC live under the current gc/z directories and let the legacy, non-generational ZGC be completely separated in its own directories. This way we can continue to move quickly with the continued develop ment of Generational ZGC and let the non-generational ZGC be mostly untouched until it gets deprecated, and eventually removed. The non-generational ZGC directory will be gc/x and all the classes of non-generational have been prefixed with X instead of Z. An alternative to this rename could be to namespace out non-generational ZGC. We experimented with that, but it was too easy to accidentally cross-compile Generational ZGC code into non-generational ZGC, so we didn't like that approach. > > Most of the stand-alone cleanups and enhancements outside of the ZGC code have already been upstreamed to openjdk/jdk. There are still a few patches that could/should be pushed separately, but they will be easier to understand by also looking at the Generational ZGC code, so they will be sent out after this PR has been published. The patches that could be published separately are: > > * 59d1e96af6a UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class > * ca9edf8aa79 UPSTREAM: RISCV tmp reg cleanup resolve_jobject > * 4bec9c69b67 CLEANUP: barrierSetNMethod_aarch64.cpp > * b67d03a3f04 UPSTREAM: Add relaxed add&fetch for aarch64 atomics > * a2824734d23 UPSTREAM: lir_xchg > * 36cd39c0126 UPSTREAM: assembler_ppc CMPLI > * 447259cea42 UPSTREAM: assembler_ppc ANDI > * 9417323499a UPSTREAM: Add VMErrorCallback infrastructure > > Regarding all the changesets you see in this PR, they form the history of the development of Generational ZGC. It might look a bit unconventional to what you are used to see in openjdk development. What we have done is to use merges with the 'ours' strategy to ignore the previous Generational ZGC patches, and then rebased and flattened the changes on top of the merge. This effectively gives us the upsides of having a rebased repository and the upsides of retaining the history in the repository. The downside could be that GitHub now lists all those changesets in the PR. Given that this patch is so big, and that you likely only want to see a part of it, I suggest that you pull down the PR branch and then compare it to the openjdk/jdk changeset this PR is based against: > > > git fetch https://github.com/openjdk/zgc zgc_master > git diff zgc_master... > > > There have been many contributors of this patch over the years. I'll do my best to poke Skara into listing you all, but if you see that I've missed your name please reach out to me and I'll fix it. > > Testing: we have been continuously running Generational ZGC through Oracle's tier1-8 testing. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Whitespace nit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13771/files - new: https://git.openjdk.org/jdk/pull/13771/files/c9f6257b..c4217280 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13771&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13771&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13771.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13771/head:pull/13771 PR: https://git.openjdk.org/jdk/pull/13771 From stefank at openjdk.org Fri May 5 05:13:04 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 5 May 2023 05:13:04 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v6] In-Reply-To: <_UHP565f9Io3v9rWWDf0HGRhhtNoniDhbM_XEM-2w1c=.f7cb7bae-5837-42ff-9491-284093ba4c75@github.com> References: <_UHP565f9Io3v9rWWDf0HGRhhtNoniDhbM_XEM-2w1c=.f7cb7bae-5837-42ff-9491-284093ba4c75@github.com> Message-ID: On Thu, 4 May 2023 20:21:12 GMT, Andrey Turbanov wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> undefine glibc major/minor macros > > test/hotspot/jtreg/runtime/stringtable/StringTableCleaningTest.java line 117: > >> 115: return gcEndPrefix + g1Suffix; >> 116: } else if (GC.Z.isSelected()) { >> 117: return gcEndPrefix + "(" + zEndSuffix + ")|(" + xEndSuffix + ")"; > > nit > Suggestion: > > return gcEndPrefix + "(" + zEndSuffix + ")|(" + xEndSuffix + ")"; Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1185701989 From stefank at openjdk.org Fri May 5 05:20:30 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 5 May 2023 05:20:30 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v6] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 01:54:48 GMT, Fei Yang wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> undefine glibc major/minor macros > > test/hotspot/gtest/gc/z/test_zForwarding.cpp line 68: > >> 66: >> 67: bool reserved = os::attempt_reserve_memory_at((char*)ZAddressHeapBase, ZGranuleSize, false /* executable */); >> 68: ASSERT_TRUE(reserved); > > Hi, > Thanks for the great work! > I have performed some tests on linux-riscv64 Hifive Unmatched board. So far, I only witnessed one gtest failure: > > > $ make test TEST=gtest:ZForwardingTest > Building target 'test' in configuration 'linux-riscv64-server-release' > Test selection 'gtest:ZForwardingTest', will run: > * gtest:ZForwardingTest/server > > Running test 'gtest:ZForwardingTest/server' > Note: Google Test filter = ZForwardingTest* > [==========] Running 4 tests from 1 test suite. > [----------] Global test environment set-up. > [----------] 4 tests from ZForwardingTest > [ RUN ] ZForwardingTest.setup_vm > test/hotspot/gtest/gc/z/test_zForwarding.cpp:68: Failure > Value of: reserved > Actual: false > Expected: true > [ FAILED ] ZForwardingTest.setup_vm (0 ms) > [ RUN ] ZForwardingTest.find_empty_vm > [ OK ] ZForwardingTest.find_empty_vm (1 ms) > [ RUN ] ZForwardingTest.find_full_vm > [ OK ] ZForwardingTest.find_full_vm (8 ms) > [ RUN ] ZForwardingTest.find_every_other_vm > [ OK ] ZForwardingTest.find_every_other_vm (0 ms) > [----------] 4 tests from ZForwardingTest (761 ms total) > > [----------] Global test environment tear-down > ERROR: RUN_ALL_TESTS() failed. Error 1 > [==========] 4 tests from 1 test suite ran. (762 ms total) > [ PASSED ] 3 tests. > [ FAILED ] 1 test, listed below: > [ FAILED ] ZForwardingTest.setup_vm > > 1 FAILED TEST > Finished running test 'gtest:ZForwardingTest/server' > Test report is stored in build/linux-riscv64-server-release/test-results/gtest_ZForwardingTest_server > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR >>> gtest:ZForwardingTest/server 4 3 1 0 << > ============================== > TEST FAILURE > > > The gtest failed this assertion where 'reserved' return by function os::attempt_reserve_memory_at is false. > I find the reason is that the mmap call at the bottom returns a different address instead of the requested one (ZAddressHeapBase). I think that is possible since we are not sure if the requested address is available before the mmap call, right? So I guess we might need some changes here for this gtest. Thanks for reporting. It would be interesting to see what address you get and compare it to the range [ZAddressHeapBase, ZAddressHeapBase+ZAddressOffsetMax). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1185707639 From david.holmes at oracle.com Fri May 5 05:23:58 2023 From: david.holmes at oracle.com (David Holmes) Date: Fri, 5 May 2023 15:23:58 +1000 Subject: Compiler/aot testing on MacOS In-Reply-To: References: Message-ID: <9687d18b-260c-962f-c8eb-cffc5e5b37cd@oracle.com> Hi Joe, It looks like you were not subscribed to the mailing list and this email only just got cleared and has turned up. is this still an issue? Cheers, David On 24/03/2023 12:20 am, Joe Braley wrote: > Hello, > > Our team publishes Microsoft's build of OpenJDK, and we have observed > some test failures after upgrading our macOS agents from 10.15 to MacOS > 11. We have also seen these failures on macOS 12.x. The tests that are > encountering issues are in compiler/aot category.We are only observing > these issues in our JDK11u builds. The exact command line I used to > reproduce the error locally is: > > /Users/JEG/jdk-11.0.18+10/Contents/Home/bin/java -Xmx512m -jar > /Users/JEG/jtreg/lib/jtreg.jar -agentvm -ignore:quiet -automatic -xml > -vmoption:-Xmx512m -timeoutFactor:4 -concurrency:1 > -testjdk:/Users/JEG/jdk-11.0.18+10/Contents/Home -nativepath:/ > > Users/JEG/jdk-11.0.18+10-test-image/hotspot/jtreg/native > -verbose:fail,error,summary ?-exclude:test/hotspot/jtreg/ProblemList.txt > test/hotspot/jtreg/compiler/aot/TestHeapBase.java > > Which resulted in the following exception: > > Exception in thread "main" java.lang.InternalError: ld: dynamic main > executables must link with libSystem.dylib for architecture x86_64 > > ? ? ? ? at jdk.aot at 11.0.18/jdk.tools.jaotc.Linker.link(Linker.java:142) > > > ? ? ? ? at jdk.aot at 11.0.18/jdk.tools.jaotc.Main.run(Main.java:262) > > > ? ? ? ? at jdk.aot at 11.0.18/jdk.tools.jaotc.Main.run(Main.java:133) > > > ? ? ? ? at jdk.aot at 11.0.18/jdk.tools.jaotc.Main.main(Main.java:89) > > > The version of macOS which I reproduced this error was: > > openjdk-jdk11u % sw_vers > > ProductName: ? ?macOS > > ProductVersion: 11.4 > > BuildVersion: ? 20F71 > > Initial triage on our end suggests that the linker for these tests is > invoked in Linker.java, where we may require additional arguments passed > into the "ld" command. Specifically, including the library path. The > change that may have introduced this behavior is documented here: > https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-release-notes .?The important bit, I think, is: > > * /New in macOS Big Sur 11.0.1, the system ships with a built-in > dynamic linker cache of all system-provided libraries. As part of > this change, copies of dynamic libraries are no longer present on > the filesystem. Code that attempts to check for dynamic library > presence by looking for a file at a path or enumerating a directory > will fail. Instead, check for library presence by attempting to > dlopen() the path, which will correctly check for the library in the > cache. (62986286)/ > > Has anyone encountered this issue before or would be willing to provide > insight to what the root cause may be? > > Thanks! > > *Joe Braley > *Software Engineer > joebraley at microsoft.com > > Microsoft Logo > From yadongwang at openjdk.org Fri May 5 06:31:45 2023 From: yadongwang at openjdk.org (Yadong Wang) Date: Fri, 5 May 2023 06:31:45 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v6] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 05:17:44 GMT, Stefan Karlsson wrote: >> test/hotspot/gtest/gc/z/test_zForwarding.cpp line 68: >> >>> 66: >>> 67: bool reserved = os::attempt_reserve_memory_at((char*)ZAddressHeapBase, ZGranuleSize, false /* executable */); >>> 68: ASSERT_TRUE(reserved); >> >> Hi, >> Thanks for the great work! >> I have performed some tests on linux-riscv64 Hifive Unmatched board. So far, I only witnessed one gtest failure: >> >> >> $ make test TEST=gtest:ZForwardingTest >> Building target 'test' in configuration 'linux-riscv64-server-release' >> Test selection 'gtest:ZForwardingTest', will run: >> * gtest:ZForwardingTest/server >> >> Running test 'gtest:ZForwardingTest/server' >> Note: Google Test filter = ZForwardingTest* >> [==========] Running 4 tests from 1 test suite. >> [----------] Global test environment set-up. >> [----------] 4 tests from ZForwardingTest >> [ RUN ] ZForwardingTest.setup_vm >> test/hotspot/gtest/gc/z/test_zForwarding.cpp:68: Failure >> Value of: reserved >> Actual: false >> Expected: true >> [ FAILED ] ZForwardingTest.setup_vm (0 ms) >> [ RUN ] ZForwardingTest.find_empty_vm >> [ OK ] ZForwardingTest.find_empty_vm (1 ms) >> [ RUN ] ZForwardingTest.find_full_vm >> [ OK ] ZForwardingTest.find_full_vm (8 ms) >> [ RUN ] ZForwardingTest.find_every_other_vm >> [ OK ] ZForwardingTest.find_every_other_vm (0 ms) >> [----------] 4 tests from ZForwardingTest (761 ms total) >> >> [----------] Global test environment tear-down >> ERROR: RUN_ALL_TESTS() failed. Error 1 >> [==========] 4 tests from 1 test suite ran. (762 ms total) >> [ PASSED ] 3 tests. >> [ FAILED ] 1 test, listed below: >> [ FAILED ] ZForwardingTest.setup_vm >> >> 1 FAILED TEST >> Finished running test 'gtest:ZForwardingTest/server' >> Test report is stored in build/linux-riscv64-server-release/test-results/gtest_ZForwardingTest_server >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >>>> gtest:ZForwardingTest/server 4 3 1 0 << >> ============================== >> TEST FAILURE >> >> >> The gtest failed this assertion where 'reserved' return by function os::attempt_reserve_memory_at is false. >> I find the reason is that the mmap call at the bottom returns a different address instead of the requested one (ZAddressHeapBase). I think that is possible since we are not sure if the requested address is available before the mmap call, right? So I guess we might need some changes here for this gtest. > > Thanks for reporting. It would be interesting to see what address you get and compare it to the range [ZAddressHeapBase, ZAddressHeapBase+ZAddressOffsetMax). We emailed to erik to discuss this issue two months ago, and maybe he missed it. ZForwardingTest does not guarantee a successful invoke of os::commit_memory for ZAddressHeapBase, and we saw some conflicts between ZAddressHeapBase and the metadata address space on the RISC-V hardware of 39-bits virtual address. There is no failure in the normal initialization phase of JVM, because the commit order of them is guaranteed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1185738633 From stefank at openjdk.org Fri May 5 06:53:27 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 5 May 2023 06:53:27 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v6] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 06:28:59 GMT, Yadong Wang wrote: >> Thanks for reporting. It would be interesting to see what address you get and compare it to the range [ZAddressHeapBase, ZAddressHeapBase+ZAddressOffsetMax). > > We emailed to erik to discuss this issue two months ago, and maybe he missed it. > ZForwardingTest does not guarantee a successful invoke of os::commit_memory for ZAddressHeapBase, and we saw some conflicts between ZAddressHeapBase and the metadata address space on the RISC-V hardware of 39-bits virtual address. There is no failure in the normal initialization phase of JVM, because the commit order of them is guaranteed. Could you provide the values for `reserved`, `ZAddressHeapBase`, and `ZAddressOffsetMax, when this test is failing. I'd like to know if we can make a workaround for you, or if we have to turn off the test for riscv. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1185751935 From stefank at openjdk.org Fri May 5 07:43:17 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 5 May 2023 07:43:17 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v8] In-Reply-To: References: Message-ID: > Hi all, > > Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. > > The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention i s to give the users time to validate and deploy their workloads with the new GC implementation. > > Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clear to us how time consuming and complex things end up being when we tried to keep both the original G1 working, and at the same time implemented the ZGC-alike G1. Given this experience, we don't see that as a viable solution to deliver a maintainable and evolving Generational ZGC. Our pragmatic suggestion to these challenges is to let Generational ZGC live under the current gc/z directories and let the legacy, non-generational ZGC be completely separated in its own directories. This way we can continue to move quickly with the continued develop ment of Generational ZGC and let the non-generational ZGC be mostly untouched until it gets deprecated, and eventually removed. The non-generational ZGC directory will be gc/x and all the classes of non-generational have been prefixed with X instead of Z. An alternative to this rename could be to namespace out non-generational ZGC. We experimented with that, but it was too easy to accidentally cross-compile Generational ZGC code into non-generational ZGC, so we didn't like that approach. > > Most of the stand-alone cleanups and enhancements outside of the ZGC code have already been upstreamed to openjdk/jdk. There are still a few patches that could/should be pushed separately, but they will be easier to understand by also looking at the Generational ZGC code, so they will be sent out after this PR has been published. The patches that could be published separately are: > > * 59d1e96af6a UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class > * ca9edf8aa79 UPSTREAM: RISCV tmp reg cleanup resolve_jobject > * 4bec9c69b67 CLEANUP: barrierSetNMethod_aarch64.cpp > * b67d03a3f04 UPSTREAM: Add relaxed add&fetch for aarch64 atomics > * a2824734d23 UPSTREAM: lir_xchg > * 36cd39c0126 UPSTREAM: assembler_ppc CMPLI > * 447259cea42 UPSTREAM: assembler_ppc ANDI > * 9417323499a UPSTREAM: Add VMErrorCallback infrastructure > > Regarding all the changesets you see in this PR, they form the history of the development of Generational ZGC. It might look a bit unconventional to what you are used to see in openjdk development. What we have done is to use merges with the 'ours' strategy to ignore the previous Generational ZGC patches, and then rebased and flattened the changes on top of the merge. This effectively gives us the upsides of having a rebased repository and the upsides of retaining the history in the repository. The downside could be that GitHub now lists all those changesets in the PR. Given that this patch is so big, and that you likely only want to see a part of it, I suggest that you pull down the PR branch and then compare it to the openjdk/jdk changeset this PR is based against: > > > git fetch https://github.com/openjdk/zgc zgc_master > git diff zgc_master... > > > There have been many contributors of this patch over the years. I'll do my best to poke Skara into listing you all, but if you see that I've missed your name please reach out to me and I'll fix it. > > Testing: we have been continuously running Generational ZGC through Oracle's tier1-8 testing. Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 917 commits: - ZGC: Generational Co-authored-by: Stefan Karlsson Co-authored-by: Per Liden Co-authored-by: Albert Mingkun Yang Co-authored-by: Erik ?sterlund Co-authored-by: Axel Boldt-Christmas Co-authored-by: Stefan Johansson - UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class - UPSTREAM: RISCV tmp reg cleanup resolve_jobject - CLEANUP: barrierSetNMethod_aarch64.cpp - UPSTREAM: Add relaxed add&fetch for aarch64 atomics - UPSTREAM: assembler_ppc CMPLI Co-authored-by: TheRealMDoerr - UPSTREAM: assembler_ppc ANDI Co-authored-by: TheRealMDoerr - UPSTREAM: Add VMErrorCallback infrastructure - Merge branch 'zgc_generational' into zgc_generational_rebase_target - Whitespace nit - ... and 907 more: https://git.openjdk.org/jdk/compare/705ad7d8...349cf9ae ------------- Changes: https://git.openjdk.org/jdk/pull/13771/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13771&range=07 Stats: 67399 lines in 685 files changed: 58223 ins; 4254 del; 4922 mod Patch: https://git.openjdk.org/jdk/pull/13771.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13771/head:pull/13771 PR: https://git.openjdk.org/jdk/pull/13771 From jpai at openjdk.org Fri May 5 09:33:22 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 5 May 2023 09:33:22 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v8] In-Reply-To: References: Message-ID: On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey wrote: >> Add flexible main methods and anonymous main classes to the Java language. > > Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: > > - Anonymous main classes renamed to unnamed classes > - Add test src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 139: > 137: public static Method findMainMethod(Class mainClass) throws NoSuchMethodException { > 138: try { > 139: Method mainMethod = mainClass.getMethod("main", String[].class); Hello Jim, I think this specific line is trying to find a `public static void main(String[])` method from the launched class. In the current form of this implementation, this has the potential of returning a non-static `public void main(String[])` from here. I think a `isStatic(mainMethod)` would be needed here before returning this method as the found method. src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 142: > 140: > 141: if (mainMethod.getDeclaringClass() != mainClass) { > 142: System.err.println("WARNING: static main in super class will be deprecated."); Similarly, this warning would have to be logged only if the method is `static`. Furthermore, do you think we should include the declaring class in the log message to provide some context on what's causing this warning? Something like: > WARNING: static main(String[]) in super class foo.bar.Parent will be deprecated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185882851 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185885497 From jpai at openjdk.org Fri May 5 09:42:23 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 5 May 2023 09:42:23 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v8] In-Reply-To: References: Message-ID: On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey wrote: >> Add flexible main methods and anonymous main classes to the Java language. > > Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: > > - Anonymous main classes renamed to unnamed classes > - Add test src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 152: > 150: > 151: List mains = new ArrayList<>(); > 152: gatherMains(mainClass, mainClass, mains); The `try` block above is there to find `public static void main(String[])` in the launched class. When it's not found, then we gather the potential main methods (as listed in the JEP). The implementation of `gatherMains(...)`, in its current form starts gathering the main methods from `refc.getSuperclass()`, where `refc` in this case is the `mainClass`, which is the launched class. So if I'm reading this correctly, then I think it's going to completely skip the launched class for looking any potential main methods and instead start looking for them in the launched class' super hierarchy. src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 158: > 156: } > 157: > 158: mains.sort(MainMethodFinder::compareMethods); Perhaps skip the call to `sort` and just return the found main method if `mains.size() == 1`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185890136 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185892782 From jpai at openjdk.org Fri May 5 09:48:24 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 5 May 2023 09:48:24 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v8] In-Reply-To: References: Message-ID: On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey wrote: >> Add flexible main methods and anonymous main classes to the Java language. > > Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: > > - Anonymous main classes renamed to unnamed classes > - Add test src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 70: > 68: correctArgs(method) && > 69: // Only statics in the declaring class > 70: (!isStatic(method) || declc == refc) Should this also exclude `abstract` and `native` methods named `main`? src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 134: > 132: > 133: /** > 134: * {@return priority main method or null if none found} I think this javadoc is perhaps outdated? The current implementation of this method throws a `NoSuchMethodException` when it can't find any eligible main method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185896198 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185898281 From jpai at openjdk.org Fri May 5 09:55:23 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 5 May 2023 09:55:23 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v8] In-Reply-To: References: Message-ID: On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey wrote: >> Add flexible main methods and anonymous main classes to the Java language. > > Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: > > - Anonymous main classes renamed to unnamed classes > - Add test src/java.base/share/classes/sun/launcher/LauncherHelper.java line 872: > 870: Method mainMethod = null; > 871: try { > 872: mainMethod = MainMethodFinder.findMainMethod(mainClass); The `MainMethodFinder.findMainMethod(...)` throws a `NoSuchMethodException` when it can't find the regular `public static void main(String[])` or, when preview is enabled, any other eligible main methods. That will now mean that the next line here which catches a `NoSuchMethodException` can potentially end up aborting with a (very confusing) error message about JavaFX application. We should perhaps change that catch block to something like: } catch (NoSuchMethodException nsme) { if (!PreviewFeatures.isEnabled()) { // invalid main or not FX application, abort with an error abort(null, "java.launcher.cls.error4", mainClass.getName(), JAVAFX_APPLICATION_CLASS_NAME); } else { // abort with something more clear error? } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185905158 From jpai at openjdk.org Fri May 5 10:00:41 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 5 May 2023 10:00:41 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v8] In-Reply-To: References: Message-ID: On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey wrote: >> Add flexible main methods and anonymous main classes to the Java language. > > Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: > > - Anonymous main classes renamed to unnamed classes > - Add test src/java.base/share/classes/sun/launcher/LauncherHelper.java line 893: > 891: * findMainMethod (above) will choose the correct method, based > 892: * on its name and parameter type, however, we still have to > 893: * ensure that the method is static (non-preview) and returns a void. I think it's probably going to be easier to read and maintain if we moved these checks for `static` and `void` return type into the `MainMethodFinder.findMainMethod(...)` itself. What I mean is once we return from the `findMainMethod(...)`, I think the callers, like this code here, shouldn't have to do additional checks to know if this main method is valid and can be used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185908021 From jpai at openjdk.org Fri May 5 10:10:24 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 5 May 2023 10:10:24 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v8] In-Reply-To: References: Message-ID: <0IFuexmcfMhpT8nlQ02H-NNhUWzOvzdyMaklwlMR93k=.c674102a-00f1-4a26-ac87-8cd121ceb10f@github.com> On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey wrote: >> Add flexible main methods and anonymous main classes to the Java language. > > Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: > > - Anonymous main classes renamed to unnamed classes > - Add test src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 419: > 417: private static boolean isStatic(Method method) { > 418: return method != null && Modifier.isStatic(method.getModifiers()); > 419: } It looks like these new methods aren't being used. src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 440: > 438: int mods = mainMethod.getModifiers(); > 439: boolean isStatic = Modifier.isStatic(mods); > 440: boolean isPublic = Modifier.isStatic(mods); This looks like a typo. This should have been `Modifier.isPublic(mods);` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185918190 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185917271 From jpai at openjdk.org Fri May 5 10:18:23 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 5 May 2023 10:18:23 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v8] In-Reply-To: References: Message-ID: On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey wrote: >> Add flexible main methods and anonymous main classes to the Java language. > > Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: > > - Anonymous main classes renamed to unnamed classes > - Add test src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 457: > 455: if (isStatic) { > 456: if (noArgs) { > 457: mainMethod.invoke(appClass); Given that `Method.invoke(...)` on a static method ignores the `obj` param that's passed to it, perhaps pass `null`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185924903 From jpai at openjdk.org Fri May 5 10:25:21 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 5 May 2023 10:25:21 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v8] In-Reply-To: References: Message-ID: <8Q_VdzphUbJgaiyTigSlBztROntOa5lz0oeMhrMcvRU=.2ce70574-d520-49be-91de-e2059c6062ce@github.com> On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey wrote: >> Add flexible main methods and anonymous main classes to the Java language. > > Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: > > - Anonymous main classes renamed to unnamed classes > - Add test test/jdk/tools/launcher/InstanceMainTest.java line 33: > 31: public class InstanceMainTest extends TestHelper { > 32: > 33: @Test Does this compile? I don't see imports for this annotation and this is launched as a `@run main ....` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185930904 From mkartashev at openjdk.org Fri May 5 10:55:21 2023 From: mkartashev at openjdk.org (Maxim Kartashev) Date: Fri, 5 May 2023 10:55:21 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots In-Reply-To: References: Message-ID: <1ZGirSGimyAgLdQ_kmia0mw1qnFaY7_5N5xeDxET4DE=.7d5b9a18-ef76-4078-beeb-756f9afde420@github.com> On Thu, 4 May 2023 14:18:44 GMT, Alexander Zvegintsev wrote: > Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. > This comes with some difficulties, and one of them is the inability to get screenshots from the system. > This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) > > But this functionality is a very important part of automated testing. > > > At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): > > 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) > It has several drawbacks though: > + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). > + There is no way to disable the visual "screen flash" after screenshot > + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. > Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. > But we still can consider this option as a fallback. > > > > 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) > It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. > This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. > > + implementation is more complicated comparing to Screenshot API > + no intermediate file, screenshot data can be obtained from memory > + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) > > > So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. > > This change also introduces some new behavior for the robot: > A system window now appears asking for confirmation from the user to capture the screen. > + The user can refuse the screen capture completely. In this case a security exception will be thrown. > + The user can allow a screen capture for all screens or some of them. For screens without permission there will be a black image. > + If the user wishes to change their mind about the screens allowed to be captured, the user should use the new `Robot#resetScreenCapturePermission` method > > Also added several system properties: > `awt.robot.screencastEnabled` false by default, uses the ScreenCast API if true > `awt.robot.screencastDebug` false by default, prints some debug information if true > > For convenience, this change is divided into two commits: > 1. added [pipewire headers](https://gitlab.freedesktop.org/pipewire/pipewire/) that are needed for the build > 2. main changes > > Changes in the documentation are in a separate draft PR (#13809) also for convenience. > > At the moment, the planned supported systems are Ubuntu 22.04+, the latest Oracle Linux 9.1 and RHEL 9.1 has some issues with restore_token support. src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java line 428: > 426: > 427: @SuppressWarnings("removal") > 428: public static boolean isOnWayland() { It seems that this method doesn't have to part of a public interface of `UNIXToolkit`. src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java line 56: > 54: } > 55: > 56: private static final int DENIED = -11; //defined in native code The comment is confusing as the field is defined right here, not in native code. src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java line 58: > 56: private static final int DENIED = -11; //defined in native code > 57: > 58: private static synchronized native int getRGBPixelsImpl( Is `synchronized` really needed on the declaration of `getRGBPixelsImpl()`? src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 50: > 48: jmethodID storeTokenMethodID = NULL; > 49: > 50: inline void debug_screencast( Does this one need to be externally visible? If not, it can be (also) made `static`. src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 138: > 136: } > 137: > 138: static inline void convertRGBxToBGRx(int* in) { Will this work correctly on little-endian ARM systems? src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 602: > 600: } > 601: > 602: pipewire_libhandle = dlopen("libpipewire-0.3.so.0", There's a useful macro for wrapping library names: `VERSIONED_JNI_LIB_NAME("pipewire-0.3", "0")` src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 722: > 720: > 721: const gchar *token = jtoken > 722: ? token = (*env)->GetStringUTFChars(env, jtoken, NULL) The variable `token` is unnecessarily used in its own initializer here. src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 789: > 787: env, pixelArray, > 788: start, len, > 789: ((jint *) screenProps->captureData) I'm not sure if endianness of `captureData` matches the expected endianness of `pixelArray`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1185887472 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1185891793 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1185894200 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1185907122 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1185917587 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1185942008 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1185946946 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1185951908 From jlaskey at openjdk.org Fri May 5 11:56:23 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 5 May 2023 11:56:23 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v3] In-Reply-To: References: <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com> Message-ID: On Thu, 27 Apr 2023 20:51:53 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: >> >> - Merge branch 'master' into 8306112 >> - PreviewFeatures.isEnabled() >> - Clean up isPreview >> - Missing exception >> - Corrections >> - Update VM.java >> - Clean up testing >> - Update TestJavacTaskScanner.java >> - Merge branch 'master' into 8306112 >> - Clean up >> - ... and 4 more: https://git.openjdk.org/jdk/compare/96cdf93b...53a5321d > > test/jdk/tools/launcher/OnrampMainTest.java line 31: > >> 29: * @run main OnrampMainTest >> 30: */ >> 31: public class OnrampMainTest extends TestHelper { > > Should more tests be added for inherited methods? Test added ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186003544 From jlahoda at openjdk.org Fri May 5 12:34:29 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 5 May 2023 12:34:29 GMT Subject: RFR: JDK-8306983: Do not invoke external programs when switch terminal to raw mode on selected platforms [v2] In-Reply-To: References: Message-ID: > To support JShell and other usecases, the JDK uses JLine, which provides line-editing functionality inside a terminal. > > JLine has several ways to work with the terminal, based on various additional libraries and tools. Most of them are not directly usable inside the JDK, so currently, on non-Windows platforms, the JLine inside the JDK will use external programs, like `stty`, to inspect the terminal's properties and to switch the terminal to raw mode. > > This is slightly problematic, as the external programs might be missing, and while this is not that big problem for JShell, it might be a problem for other potential uses of JLine, like using it inside `System.console()`. > > So, the proposal here is to call the corresponding native methods directly, on selected platforms for now (Linux and Mac OS/X), instead of invoking the external programs. On Windows, this has always been the case, we are using a custom implementation of the interface that maps native and Java function for JNA there, and the proposal is to do the same here. We take the appropriate mapping interface for JNA, and provide hand-written implementation for it, using JNI. > > The Windows implementation is mostly unchanged, the changes are mostly non-Windows only. The overview of the changes is: > - `LastErrorException` is moved from the Windows-specific code to the platform-neutral code, as it is used by all the native implementations. This is the only change that directly affects the Windows-specific code > - `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java` and `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java` are created based on the corresponding files from JLine. In JLine, these files directly call platform-specific implementations, but in this patch, the platform specific code is commented out, and replaced with calls to `JDKNativePty`, which is a new platform-specific class, that delegates to the actual platform-specific implementations. Note the `JnaNativePty.java` and `JnaTerminalProvider.java` already exist in the Windows part, but have different pieces of code commented out, which makes them substantially different. > - for Linux and Mac OS/X, there are platform-specific implementations based on the corresponding code from JLine, with the hand-written JNI-based implementation of the JNA-based existing interfaces. They also have an implementation of `JDKNativePty`, which just delegates to the given platform's `"NativePty"` implementation. > - the `JdkConsoleProviderImpl.java` has been tweaked to not allow the implementation based on the external programs, and gracefully falling back to the standard implementation. JShell is kept unchanged. > > The reasons for this organization are: limiting duplication, mostly adhering to the JDK's platform specific build (which is different from the normal JLine's platform-neutral build) and limiting the difference between standard JLine and JLine inside JDK, to help future upgrades. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Adjusting build script as suggested on the review. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13687/files - new: https://git.openjdk.org/jdk/pull/13687/files/f14e7fb5..4cf8f67e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13687&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13687&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13687.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13687/head:pull/13687 PR: https://git.openjdk.org/jdk/pull/13687 From erikj at openjdk.org Fri May 5 13:24:17 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 5 May 2023 13:24:17 GMT Subject: RFR: JDK-8306983: Do not invoke external programs when switch terminal to raw mode on selected platforms [v2] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 12:34:29 GMT, Jan Lahoda wrote: >> To support JShell and other usecases, the JDK uses JLine, which provides line-editing functionality inside a terminal. >> >> JLine has several ways to work with the terminal, based on various additional libraries and tools. Most of them are not directly usable inside the JDK, so currently, on non-Windows platforms, the JLine inside the JDK will use external programs, like `stty`, to inspect the terminal's properties and to switch the terminal to raw mode. >> >> This is slightly problematic, as the external programs might be missing, and while this is not that big problem for JShell, it might be a problem for other potential uses of JLine, like using it inside `System.console()`. >> >> So, the proposal here is to call the corresponding native methods directly, on selected platforms for now (Linux and Mac OS/X), instead of invoking the external programs. On Windows, this has always been the case, we are using a custom implementation of the interface that maps native and Java function for JNA there, and the proposal is to do the same here. We take the appropriate mapping interface for JNA, and provide hand-written implementation for it, using JNI. >> >> The Windows implementation is mostly unchanged, the changes are mostly non-Windows only. The overview of the changes is: >> - `LastErrorException` is moved from the Windows-specific code to the platform-neutral code, as it is used by all the native implementations. This is the only change that directly affects the Windows-specific code >> - `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java` and `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java` are created based on the corresponding files from JLine. In JLine, these files directly call platform-specific implementations, but in this patch, the platform specific code is commented out, and replaced with calls to `JDKNativePty`, which is a new platform-specific class, that delegates to the actual platform-specific implementations. Note the `JnaNativePty.java` and `JnaTerminalProvider.java` already exist in the Windows part, but have different pieces of code commented out, which makes them substantially different. >> - for Linux and Mac OS/X, there are platform-specific implementations based on the corresponding code from JLine, with the hand-written JNI-based implementation of the JNA-based existing interfaces. They also have an implementation of `JDKNativePty`, which just delegates to the given platform's `"NativePty"` implementation. >> - the `JdkConsoleProviderImpl.java` has been tweaked to not allow the implementation based on the external programs, and gracefully falling back to the standard implementation. JShell is kept unchanged. >> >> The reasons for this organization are: limiting duplication, mostly adhering to the JDK's platform specific build (which is different from the normal JLine's platform-neutral build) and limiting the difference between standard JLine and JLine inside JDK, to help future upgrades. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Adjusting build script as suggested on the review. Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13687#pullrequestreview-1414782534 From alanb at openjdk.org Fri May 5 14:04:23 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 5 May 2023 14:04:23 GMT Subject: RFR: 8307194: Enhance static-libs-image [v5] In-Reply-To: References: <8PLZSKy3BqQJtO70vyqRrc3uCnbbipqF9Jjv1ILTKyo=.9366d45f-f471-47aa-a59e-88e65cf6e2af@github.com> Message-ID: On Thu, 4 May 2023 19:32:45 GMT, Jiangli Zhou wrote: >>> [...] I'll see if I can test this on a mandrel build tomorrow... >> >> @jianglizhou So I've tested this with a mandrel build and it doesn't break terribly, but a graalvm build after this patch has *two* `libjvm.a` which a) doesn't make sense, b) the hotspot version is **very** large (> 1 GB on my system), so unnecessarily bloats the install. I remain of the opinion that the hotspot `libjvm.a` should only get generated for a new make target (not change the old `static-libs-image` target). Do you think that would be a workable solution for you? > >> As @jerboaa mentioned, for GraalVM native-image we produce our own `libjvm.a` as part of building GraalVM (every native image gets statically linked to that library). See https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/mx_substratevm.py#L1378 and `com.oracle.svm.native.jvm.{posix,windows}` in https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/suite.py#L736. >> >> Having a hot-spot variant of `libjvm.a` next to the other static libraries might complicate things for us. Ideally the output files produced by target `static-libs-image` should remain the same. > > @olpaw Thanks for the input. Could you also please take a look of the changes that excludes the object files from the following static libraries from Graal native image usage perspective? > > - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled. > - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a. At first glance, static-libs-image create libjvm.a in the same directory as the other lib .a files make sense but I don't know how that works if --with-jvm-variants is used to create more more than one libjvm. Might have to think whether this combination make sense or not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1186134127 From joebraley at microsoft.com Fri May 5 14:21:41 2023 From: joebraley at microsoft.com (Joe Braley) Date: Fri, 5 May 2023 14:21:41 +0000 Subject: [EXTERNAL] Re: Compiler/aot testing on MacOS In-Reply-To: <9687d18b-260c-962f-c8eb-cffc5e5b37cd@oracle.com> References: <9687d18b-260c-962f-c8eb-cffc5e5b37cd@oracle.com> Message-ID: Hi David, Yes, this is still an issue our team is experiencing. Regards, Joe Braley -----Original Message----- From: David Holmes Sent: Friday, May 5, 2023 12:24 AM To: Joe Braley ; build-dev at openjdk.org Subject: [EXTERNAL] Re: Compiler/aot testing on MacOS [You don't often get email from david.holmes at oracle.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Hi Joe, It looks like you were not subscribed to the mailing list and this email only just got cleared and has turned up. is this still an issue? Cheers, David On 24/03/2023 12:20 am, Joe Braley wrote: > Hello, > > Our team publishes Microsoft's build of OpenJDK, and we have observed > some test failures after upgrading our macOS agents from 10.15 to > MacOS 11. We have also seen these failures on macOS 12.x. The tests > that are encountering issues are in compiler/aot category.We are only > observing these issues in our JDK11u builds. The exact command line I > used to reproduce the error locally is: > > /Users/JEG/jdk-11.0.18+10/Contents/Home/bin/java -Xmx512m -jar > /Users/JEG/jtreg/lib/jtreg.jar -agentvm -ignore:quiet -automatic -xml > -vmoption:-Xmx512m -timeoutFactor:4 -concurrency:1 > -testjdk:/Users/JEG/jdk-11.0.18+10/Contents/Home -nativepath:/ > > Users/JEG/jdk-11.0.18+10-test-image/hotspot/jtreg/native > -verbose:fail,error,summary > -exclude:test/hotspot/jtreg/ProblemList.txt > test/hotspot/jtreg/compiler/aot/TestHeapBase.java > > Which resulted in the following exception: > > Exception in thread "main" java.lang.InternalError: ld: dynamic main > executables must link with libSystem.dylib for architecture x86_64 > > at > jdk.aot at 11.0.18/jdk.tools.jaotc.Linker.link(Linker.java:142) > > > at jdk.aot at 11.0.18/jdk.tools.jaotc.Main.run(Main.java:262) > > > at jdk.aot at 11.0.18/jdk.tools.jaotc.Main.run(Main.java:133) > > > at jdk.aot at 11.0.18/jdk.tools.jaotc.Main.main(Main.java:89) > > > The version of macOS which I reproduced this error was: > > openjdk-jdk11u % sw_vers > > ProductName: macOS > > ProductVersion: 11.4 > > BuildVersion: 20F71 > > Initial triage on our end suggests that the linker for these tests is > invoked in Linker.java, where we may require additional arguments > passed into the "ld" command. Specifically, including the library > path. The change that may have introduced this behavior is documented here: > https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-release-notes . The important bit, I think, is: > > * /New in macOS Big Sur 11.0.1, the system ships with a built-in > dynamic linker cache of all system-provided libraries. As part of > this change, copies of dynamic libraries are no longer present on > the filesystem. Code that attempts to check for dynamic library > presence by looking for a file at a path or enumerating a directory > will fail. Instead, check for library presence by attempting to > dlopen() the path, which will correctly check for the library in the > cache. (62986286)/ > > Has anyone encountered this issue before or would be willing to > provide insight to what the root cause may be? > > Thanks! > > *Joe Braley > *Software Engineer > joebraley at microsoft.com > > Microsoft Logo > From azvegint at openjdk.org Fri May 5 14:35:46 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 5 May 2023 14:35:46 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v2] In-Reply-To: References: Message-ID: > Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. > This comes with some difficulties, and one of them is the inability to get screenshots from the system. > This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) > > But this functionality is a very important part of automated testing. > > > At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): > > 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) > It has several drawbacks though: > + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). > + There is no way to disable the visual "screen flash" after screenshot > + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. > Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. > But we still can consider this option as a fallback. > > > > 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) > It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. > This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. > > + implementation is more complicated comparing to Screenshot API > + no intermediate file, screenshot data can be obtained from memory > + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) > > > So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. > > This change also introduces some new behavior for the robot: > A system window now appears asking for confirmation from the user to capture the screen. > + The user can refuse the screen capture completely. In this case a security exception will be thrown. > + The user can allow a screen capture for all screens or some of them. For screens without permission there will be a black image. > + If the user wishes to change their mind about the screens allowed to be captured, the user should use the new `Robot#resetScreenCapturePermission` method > > Also added several system properties: > `awt.robot.screencastEnabled` false by default, uses the ScreenCast API if true > `awt.robot.screencastDebug` false by default, prints some debug information if true > > For convenience, this change is divided into two commits: > 1. added [pipewire headers](https://gitlab.freedesktop.org/pipewire/pipewire/) that are needed for the build > 2. main changes > > Changes in the documentation are in a separate draft PR (#13809) also for convenience. > > At the moment, the planned supported systems are Ubuntu 22.04+, the latest Oracle Linux 9.1 and RHEL 9.1 has some issues with restore_token support. Alexander Zvegintsev has updated the pull request incrementally with three additional commits since the last revision: - update, based on review comments - remove wayland detection - BUILD_LIBPIPEWIRE_HEADER_DIRS -> LIBPIPEWIRE_HEADER_DIRS ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13803/files - new: https://git.openjdk.org/jdk/pull/13803/files/94fcd916..482471df Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=00-01 Stats: 43 lines in 6 files changed: 0 ins; 37 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13803.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13803/head:pull/13803 PR: https://git.openjdk.org/jdk/pull/13803 From azvegint at openjdk.org Fri May 5 14:35:47 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 5 May 2023 14:35:47 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v2] In-Reply-To: <1ZGirSGimyAgLdQ_kmia0mw1qnFaY7_5N5xeDxET4DE=.7d5b9a18-ef76-4078-beeb-756f9afde420@github.com> References: <1ZGirSGimyAgLdQ_kmia0mw1qnFaY7_5N5xeDxET4DE=.7d5b9a18-ef76-4078-beeb-756f9afde420@github.com> Message-ID: On Fri, 5 May 2023 09:33:00 GMT, Maxim Kartashev wrote: >> Alexander Zvegintsev has updated the pull request incrementally with three additional commits since the last revision: >> >> - update, based on review comments >> - remove wayland detection >> - BUILD_LIBPIPEWIRE_HEADER_DIRS -> LIBPIPEWIRE_HEADER_DIRS > > src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java line 428: > >> 426: >> 427: @SuppressWarnings("removal") >> 428: public static boolean isOnWayland() { > > It seems that this method doesn't have to part of a public interface of `UNIXToolkit`. You're right. Furthermore, Wayland detection is no longer used in this change, so I am removing it. It is now in #13830, where it belongs. > src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java line 56: > >> 54: } >> 55: >> 56: private static final int DENIED = -11; //defined in native code > > The comment is confusing as the field is defined right here, not in native code. removed. > src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java line 58: > >> 56: private static final int DENIED = -11; //defined in native code >> 57: >> 58: private static synchronized native int getRGBPixelsImpl( > > Is `synchronized` really needed on the declaration of `getRGBPixelsImpl()`? This code was written with the understanding that it will not run in parallel, so the `synchronized` is used. Moreover, we will get a significant benefit from removing `synchronized` only if `getRGBPixelsImpl` is called frequently from different threads. If it is called from a single thread(which seems to me to be the main use case), the results of my quick tests with JMH show that the difference between synchronized and not synchronized is within the margin of error. Removing the `synchronized` keyword would require additional testing, which at this point I want to avoid. And since this is not a public API we have no problem revisiting it later. P.S. I removed `synchronized` modifier from `getRGBPixels` > src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 50: > >> 48: jmethodID storeTokenMethodID = NULL; >> 49: >> 50: inline void debug_screencast( > > Does this one need to be externally visible? If not, it can be (also) made `static`. It is used by `screencast_portal.c` and `screencast_pipewire.c`. > src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 138: > >> 136: } >> 137: >> 138: static inline void convertRGBxToBGRx(int* in) { > > Will this work correctly on little-endian ARM systems? I haven't tested it, but I'll try to find a machine to test it on. > src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 602: > >> 600: } >> 601: >> 602: pipewire_libhandle = dlopen("libpipewire-0.3.so.0", > > There's a useful macro for wrapping library names: `VERSIONED_JNI_LIB_NAME("pipewire-0.3", "0")` Updated. > src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 722: > >> 720: >> 721: const gchar *token = jtoken >> 722: ? token = (*env)->GetStringUTFChars(env, jtoken, NULL) > > The variable `token` is unnecessarily used in its own initializer here. Fixed. > src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 789: > >> 787: env, pixelArray, >> 788: start, len, >> 789: ((jint *) screenProps->captureData) > > I'm not sure if endianness of `captureData` matches the expected endianness of `pixelArray`. For now, it is going to be supported on x86-64 only, but it is a good candidate for investigation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1186164127 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1186163925 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1186163799 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1186163601 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1186163575 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1186163520 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1186163465 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1186163401 From azvegint at openjdk.org Fri May 5 14:38:19 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 5 May 2023 14:38:19 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v2] In-Reply-To: <_cTykE_ylL_s6FEZD-whKcVLZHtoca25nQ07DJg3zbc=.9107511d-1770-4259-8465-ae1998e0aba6@github.com> References: <_cTykE_ylL_s6FEZD-whKcVLZHtoca25nQ07DJg3zbc=.9107511d-1770-4259-8465-ae1998e0aba6@github.com> Message-ID: On Thu, 4 May 2023 19:52:22 GMT, Erik Joelsson wrote: >> Alexander Zvegintsev has updated the pull request incrementally with three additional commits since the last revision: >> >> - update, based on review comments >> - remove wayland detection >> - BUILD_LIBPIPEWIRE_HEADER_DIRS -> LIBPIPEWIRE_HEADER_DIRS > > make/modules/java.desktop/lib/Awt2dLibraries.gmk line 194: > >> 192: LIBAWT_XAWT_EXCLUDES := medialib debug >> 193: >> 194: BUILD_LIBPIPEWIRE_HEADER_DIRS := \ > > This variable name indicates that LIBPIPEWIRE is a library that we would build, but it seems to just be headers. I would suggest dropping the `BUILD_` prefix. Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1186173916 From mkartashev at openjdk.org Fri May 5 14:47:22 2023 From: mkartashev at openjdk.org (Maxim Kartashev) Date: Fri, 5 May 2023 14:47:22 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v2] In-Reply-To: References: <1ZGirSGimyAgLdQ_kmia0mw1qnFaY7_5N5xeDxET4DE=.7d5b9a18-ef76-4078-beeb-756f9afde420@github.com> Message-ID: On Fri, 5 May 2023 14:26:49 GMT, Alexander Zvegintsev wrote: > P.S. I removed synchronized modifier from getRGBPixels My main point was that you don't seem to need to have both, and while I picked one you picked the other ;-) So it's OK. >> src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 50: >> >>> 48: jmethodID storeTokenMethodID = NULL; >>> 49: >>> 50: inline void debug_screencast( >> >> Does this one need to be externally visible? If not, it can be (also) made `static`. > > It is used by `screencast_portal.c` and `screencast_pipewire.c`. OK, then it actually does need to be externally visible. Thanks! >> src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 789: >> >>> 787: env, pixelArray, >>> 788: start, len, >>> 789: ((jint *) screenProps->captureData) >> >> I'm not sure if endianness of `captureData` matches the expected endianness of `pixelArray`. > > For now, it is going to be supported on x86-64 only, but it is a good candidate for investigation. Is this enforced somehow? I mean what happens if this code is built on risc-v or arm? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1186179577 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1186180467 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1186184024 From azvegint at openjdk.org Fri May 5 15:01:51 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 5 May 2023 15:01:51 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots In-Reply-To: References: Message-ID: On Fri, 5 May 2023 02:37:28 GMT, Sergey Bylokhov wrote: > > If the user wishes to change their mind about the screens allowed to be captured, the user should use the new Robot#resetScreenCapturePermission method > > Do we really need to add this new API? probably we can implement the feature w/o this new method? I couldn't think of anything better. We need to somehow let the robot know that the saved `restore_token` no longer meets the user's expectations. It seems that the current robot API is not suitable for this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1536387259 From jlaskey at openjdk.org Fri May 5 15:17:23 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 5 May 2023 15:17:23 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v8] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 09:28:04 GMT, Jaikiran Pai wrote: >> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: >> >> - Anonymous main classes renamed to unnamed classes >> - Add test > > src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 139: > >> 137: public static Method findMainMethod(Class mainClass) throws NoSuchMethodException { >> 138: try { >> 139: Method mainMethod = mainClass.getMethod("main", String[].class); > > Hello Jim, I think this specific line is trying to find a `public static void main(String[])` method from the launched class. In the current form of this implementation, this has the potential of returning a non-static `public void main(String[])` from here. I think a `isStatic(mainMethod)` would be needed here before returning this method as the found method. The problem with modifying behaviour that has existed since JDK 1.0 is that it has to be compatible in unexpected ways. If you look at the code modification: - mainMethod = mainClass.getMethod("main", String[].class); + mainMethod = MainMethodFinder.findMainMethod(mainClass); you can see that nothing has really changed. The mainMethod was always possibly non-static and the caller produced an appropriate error message if that was the case. There is the rub. If I didn't do it the way I have, I would also have to modify 130+ tests that expect to fail with a "method is not static" message as oppose to a "method not found" error message (there are other related issues to args and return types). After spending several days wading through a handful of these ancient tests, I realized I did not have time to complete the modifications necessary before targeting. And, there is also the issue of what happens to tests and expectations downstream. For a preview feature, behaviour has to remain the same when preview is not enabled. I was also hopeful to be able to unify the _java launcher_ and the _source code launcher_. Similar problem with error messaging, though the tests for the source code launcher are fewer and newer. Unifying the launchers would also introduce another downstream issue. Since launching would occur from Java code, addition frames appear on the stack. Seems there are a several tests, tools and debuggers that rely on "main" being the first frame (even if hidden by printStackTrace). Ugh. Before the next cycle, I hope to unify the messaging, have someone clean up the tests and figure out a scheme that unifies the launching. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186216248 From jlaskey at openjdk.org Fri May 5 15:24:50 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 5 May 2023 15:24:50 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v8] In-Reply-To: References: Message-ID: <6Rr-jSur-o5l60DNHYg-1GoZS7LO9Fc8S9d83Zs4Q7g=.58c21be6-a3b0-48be-9fff-74ad1c1f43dd@github.com> On Fri, 5 May 2023 09:30:54 GMT, Jaikiran Pai wrote: >> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: >> >> - Anonymous main classes renamed to unnamed classes >> - Add test > > src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 142: > >> 140: >> 141: if (mainMethod.getDeclaringClass() != mainClass) { >> 142: System.err.println("WARNING: static main in super class will be deprecated."); > > Similarly, this warning would have to be logged only if the method is `static`. Furthermore, do you think we should include the declaring class in the log message to provide some context on what's causing this warning? Something like: >> WARNING: static main(String[]) in super class foo.bar.Parent will be deprecated. Yes this is an oversight on my part. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186223626 From jlaskey at openjdk.org Fri May 5 15:28:23 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 5 May 2023 15:28:23 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v8] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 09:39:07 GMT, Jaikiran Pai wrote: >> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: >> >> - Anonymous main classes renamed to unnamed classes >> - Add test > > src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 158: > >> 156: } >> 157: >> 158: mains.sort(MainMethodFinder::compareMethods); > > Perhaps skip the call to `sort` and just return the found main method if `mains.size() == 1`? Likely negligible difference since it's interpreted code, but what the hey. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186227774 From jlaskey at openjdk.org Fri May 5 15:50:26 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 5 May 2023 15:50:26 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v8] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 09:43:04 GMT, Jaikiran Pai wrote: >> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: >> >> - Anonymous main classes renamed to unnamed classes >> - Add test > > src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 70: > >> 68: correctArgs(method) && >> 69: // Only statics in the declaring class >> 70: (!isStatic(method) || declc == refc) > > Should this also exclude `abstract` and `native` methods named `main`? abstract would be overshadowed by its implementation and native is fair game. > src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 134: > >> 132: >> 133: /** >> 134: * {@return priority main method or null if none found} > > I think this javadoc is perhaps outdated? The current implementation of this method throws a `NoSuchMethodException` when it can't find any eligible main method. Changing > src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 152: > >> 150: >> 151: List mains = new ArrayList<>(); >> 152: gatherMains(mainClass, mainClass, mains); > > The `try` block above is there to find `public static void main(String[])` in the launched class. When it's not found, then we gather the potential main methods (as listed in the JEP). The implementation of `gatherMains(...)`, in its current form starts gathering the main methods from `refc.getSuperclass()`, where `refc` in this case is the `mainClass`, which is the launched class. > > So if I'm reading this correctly, then I think it's going to completely skip the launched class for looking any potential main methods and instead start looking for them in the launched class' super hierarchy. It doesn't skip, it just adds the super members first. However, I should move the `gatherMains` to the end since the sort pushes the best candidate to the top and (was originally taking the last one with an opposite sort order). The sort order is - static trumps non-static - public trumps protected/package-protected - arguments trumps no arguments - depth in hierarchy Let's say we have a hierarchy of `B` inherits from `A`. If `B` contains `public void main()` and `A` contains `public void main(String... args)`, `A`'s `main` trumps `B` `main` since it has arguments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186247702 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186249703 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186245072 From jlaskey at openjdk.org Fri May 5 16:02:39 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 5 May 2023 16:02:39 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v8] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 09:52:37 GMT, Jaikiran Pai wrote: >> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: >> >> - Anonymous main classes renamed to unnamed classes >> - Add test > > src/java.base/share/classes/sun/launcher/LauncherHelper.java line 872: > >> 870: Method mainMethod = null; >> 871: try { >> 872: mainMethod = MainMethodFinder.findMainMethod(mainClass); > > The `MainMethodFinder.findMainMethod(...)` throws a `NoSuchMethodException` when it can't find the regular `public static void main(String[])` or, when preview is enabled, any other eligible main methods. That will now mean that the next line here which catches a `NoSuchMethodException` can potentially end up aborting with a (very confusing) error message about JavaFX application. We should perhaps change that catch block to something like: > > } catch (NoSuchMethodException nsme) { > if (!PreviewFeatures.isEnabled()) { > // invalid main or not FX application, abort with an error > abort(null, "java.launcher.cls.error4", mainClass.getName(), > JAVAFX_APPLICATION_CLASS_NAME); > } else { > // abort with something more clear error? > } Not convinced that anything has changed or that the message is confusing. > src/java.base/share/classes/sun/launcher/LauncherHelper.java line 893: > >> 891: * findMainMethod (above) will choose the correct method, based >> 892: * on its name and parameter type, however, we still have to >> 893: * ensure that the method is static (non-preview) and returns a void. > > I think it's probably going to be easier to read and maintain if we moved these checks for `static` and `void` return type into the `MainMethodFinder.findMainMethod(...)` itself. > What I mean is once we return from the `findMainMethod(...)`, I think the callers, like this code here, shouldn't have to do additional checks to know if this main method is valid and can be used. I agree, but from my early commentary we have to hold off until later. > src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 419: > >> 417: private static boolean isStatic(Method method) { >> 418: return method != null && Modifier.isStatic(method.getModifiers()); >> 419: } > > It looks like these new methods aren't being used. Remnants - removing > src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 440: > >> 438: int mods = mainMethod.getModifiers(); >> 439: boolean isStatic = Modifier.isStatic(mods); >> 440: boolean isPublic = Modifier.isStatic(mods); > > This looks like a typo. This should have been `Modifier.isPublic(mods);` Changing ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186258290 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186259446 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186261107 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186259830 From jlaskey at openjdk.org Fri May 5 16:08:22 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 5 May 2023 16:08:22 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v8] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 10:15:02 GMT, Jaikiran Pai wrote: >> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: >> >> - Anonymous main classes renamed to unnamed classes >> - Add test > > src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 457: > >> 455: if (isStatic) { >> 456: if (noArgs) { >> 457: mainMethod.invoke(appClass); > > Given that `Method.invoke(...)` on a static method ignores the `obj` param that's passed to it, perhaps pass `null`? Nostalgia and a useful reminder. > test/jdk/tools/launcher/InstanceMainTest.java line 33: > >> 31: public class InstanceMainTest extends TestHelper { >> 32: >> 33: @Test > > Does this compile? I don't see imports for this annotation and this is launched as a `@run main ....` Same package ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186263733 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186265984 From jlaskey at openjdk.org Fri May 5 16:18:42 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 5 May 2023 16:18:42 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v9] In-Reply-To: References: Message-ID: > Add flexible main methods and anonymous main classes to the Java language. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Recommended changes #2 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13689/files - new: https://git.openjdk.org/jdk/pull/13689/files/ff7cd4c7..788b4e5a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=07-08 Stats: 22 lines in 2 files changed: 9 ins; 10 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689 PR: https://git.openjdk.org/jdk/pull/13689 From jiangli at openjdk.org Fri May 5 16:45:35 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 5 May 2023 16:45:35 GMT Subject: RFR: 8307194: Enhance static-libs-image [v6] In-Reply-To: References: Message-ID: > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: > > - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; > - For libjvm.a specifically, exclude operator_new.o; > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; > - Handle long arguments case for static build in make/common/NativeCompilation.gmk; > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: - Separate building libjvm.a from static-libs-image target, based on input from @jerboaa and @olpaw: - Add a new java-static-libs-image target in Main.gmk for creating the JDK .a static libraries and libjvm.a super set. The static libraries are placed in images/static-libs/lib. The existing static-libs-image target is not affected and will not include hotspot libjvm.a. - Add java-static-libs-bundles target in Bundles.gmk. The created .tar.gz bundle contains JDK .a static libraries and hotspot libjvm.a. - Add StaticJvmLibsImage.gmk for placing libjvm.a into images/static-libs/lib. - Further cleanup after incorporating erikj79's suggestion to only build libjvm.a for $(JVM_VARIANT_MAIN) for now: - Change HOTSPOT_VARIANT_STATIC_LIBS_TARGETS to HOTSPOT_VARIANT_MAIN_STATIC_LIBS_TARGETS in Main.gmk. - Change hotspot-$v-static-libs to hotspot-$(JVM_VARIANT_MAIN)-static-libs in Main.gmk. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13768/files - new: https://git.openjdk.org/jdk/pull/13768/files/84861990..e49d7b4e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=04-05 Stats: 78 lines in 4 files changed: 64 ins; 8 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From jiangli at openjdk.org Fri May 5 16:48:12 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 5 May 2023 16:48:12 GMT Subject: RFR: 8307194: Enhance static-libs-image [v6] In-Reply-To: References: Message-ID: > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: > > - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; > - For libjvm.a specifically, exclude operator_new.o; > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; > - Handle long arguments case for static build in make/common/NativeCompilation.gmk; > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: - Separate building libjvm.a from static-libs-image target, based on input from @jerboaa and @olpaw: - Add a new java-static-libs-image target in Main.gmk for creating the JDK .a static libraries and libjvm.a super set. The static libraries are placed in images/static-libs/lib. The existing static-libs-image target is not affected and will not include hotspot libjvm.a. - Add java-static-libs-bundles target in Bundles.gmk. The created .tar.gz bundle contains JDK .a static libraries and hotspot libjvm.a. - Add StaticJvmLibsImage.gmk for placing libjvm.a into images/static-libs/lib. - Further cleanup after incorporating erikj79's suggestion to only build libjvm.a for $(JVM_VARIANT_MAIN) for now: - Change HOTSPOT_VARIANT_STATIC_LIBS_TARGETS to HOTSPOT_VARIANT_MAIN_STATIC_LIBS_TARGETS in Main.gmk. - Change hotspot-$v-static-libs to hotspot-$(JVM_VARIANT_MAIN)-static-libs in Main.gmk. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13768/files - new: https://git.openjdk.org/jdk/pull/13768/files/84861990..e49d7b4e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=04-05 Stats: 78 lines in 4 files changed: 64 ins; 8 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From jiangli at openjdk.org Fri May 5 16:48:13 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 5 May 2023 16:48:13 GMT Subject: RFR: 8307194: Enhance static-libs-image [v6] In-Reply-To: References: <8PLZSKy3BqQJtO70vyqRrc3uCnbbipqF9Jjv1ILTKyo=.9366d45f-f471-47aa-a59e-88e65cf6e2af@github.com> Message-ID: On Thu, 4 May 2023 19:12:14 GMT, Severin Gehwolf wrote: >> As @jerboaa mentioned, for GraalVM native-image we produce our own `libjvm.a` as part of building GraalVM (every native image gets statically linked to that library). See https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/mx_substratevm.py#L1378 and `com.oracle.svm.native.jvm.{posix,windows}` in https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/suite.py#L736. >> >> Having a hot-spot variant of `libjvm.a` next to the other static libraries might complicate things for us. Ideally the output files produced by target `static-libs-image` should remain the same. > >> [...] I'll see if I can test this on a mandrel build tomorrow... > > @jianglizhou So I've tested this with a mandrel build and it doesn't break terribly, but a graalvm build after this patch has *two* `libjvm.a` which a) doesn't make sense, b) the hotspot version is **very** large (> 1 GB on my system), so unnecessarily bloats the install. I remain of the opinion that the hotspot `libjvm.a` should only get generated for a new make target (not change the old `static-libs-image` target). Do you think that would be a workable solution for you? > @jerboaa Thanks very much for testing with mandrel. Based on yours and @olpaw's feedback, I'll refactor this PR to not use the existing `static-libs-image` target for including hotspot `libjvm.a`. Updated PR to decouple building libjvm.a from static-libs-image target. Add a java-static-libs-image target for building the static library super set, which includes JDK .a static libraries and hotspot libjvm.a. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1186300461 From jiangli at openjdk.org Fri May 5 16:52:22 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 5 May 2023 16:52:22 GMT Subject: RFR: 8307194: Enhance static-libs-image [v7] In-Reply-To: References: Message-ID: <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com> > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: > > - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; > - For libjvm.a specifically, exclude operator_new.o; > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; > - Handle long arguments case for static build in make/common/NativeCompilation.gmk; > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Fix whitespace error in make/StaticJvmLibsImage.gmk. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13768/files - new: https://git.openjdk.org/jdk/pull/13768/files/e49d7b4e..2cb786ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From jiangli at openjdk.org Fri May 5 16:53:35 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 5 May 2023 16:53:35 GMT Subject: RFR: 8307194: Enhance static-libs-image [v7] In-Reply-To: References: <8PLZSKy3BqQJtO70vyqRrc3uCnbbipqF9Jjv1ILTKyo=.9366d45f-f471-47aa-a59e-88e65cf6e2af@github.com> Message-ID: On Fri, 5 May 2023 16:43:46 GMT, Jiangli Zhou wrote: >>> [...] I'll see if I can test this on a mandrel build tomorrow... >> >> @jianglizhou So I've tested this with a mandrel build and it doesn't break terribly, but a graalvm build after this patch has *two* `libjvm.a` which a) doesn't make sense, b) the hotspot version is **very** large (> 1 GB on my system), so unnecessarily bloats the install. I remain of the opinion that the hotspot `libjvm.a` should only get generated for a new make target (not change the old `static-libs-image` target). Do you think that would be a workable solution for you? > >> @jerboaa Thanks very much for testing with mandrel. Based on yours and @olpaw's feedback, I'll refactor this PR to not use the existing `static-libs-image` target for including hotspot `libjvm.a`. > > Updated PR to decouple building libjvm.a from static-libs-image target. Add a java-static-libs-image target for building the static library super set, which includes JDK .a static libraries and hotspot libjvm.a. > At first glance, static-libs-image create libjvm.a in the same directory as the other lib .a files make sense but I don't know how that works if --with-jvm-variants is used to create more more than one libjvm. Might have to think whether this combination make sense or not. We now use a java-static-libs-image target for building all JDK and hotspot .a static libraries. @erikj79 Suggested building libjvm.a for $(JVM_VARIANT_MAIN) for now. I think that's a good starting point. The PR has been updated accordingly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1186308007 From vromero at openjdk.org Fri May 5 17:11:28 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 5 May 2023 17:11:28 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v9] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 16:18:42 GMT, Jim Laskey wrote: >> Add flexible main methods and anonymous main classes to the Java language. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Recommended changes #2 src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 138: > 136: * @param mainClass main class > 137: * > 138: * @throws NoSuchMethodException when not and preview and no method found wording here? `when not and preview`? src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3999: > 3997: Name name = names.fromString(simplename); > 3998: JCModifiers anonMods = F.at(primaryPos) > 3999: .Modifiers(Flags.FINAL|Flags.MANDATED|Flags.SYNTHETIC|Flags.UNNAMED_CLASS, List.nil()); I wonder if testing if a class has flags: `Flags.FINAL|Flags.MANDATED|Flags.SYNTHETIC` should be enough to know if it is unnamed or not and we don't need to use the new `UNNAMED_CLASS` flag ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186299301 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186323116 From jlaskey at openjdk.org Fri May 5 17:31:27 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 5 May 2023 17:31:27 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v10] In-Reply-To: References: Message-ID: > Add flexible main methods and anonymous main classes to the Java language. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13689/files - new: https://git.openjdk.org/jdk/pull/13689/files/788b4e5a..0c8add65 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689 PR: https://git.openjdk.org/jdk/pull/13689 From jlaskey at openjdk.org Fri May 5 17:31:30 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 5 May 2023 17:31:30 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v9] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 16:42:43 GMT, Vicente Romero wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Recommended changes #2 > > src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 138: > >> 136: * @param mainClass main class >> 137: * >> 138: * @throws NoSuchMethodException when not and preview and no method found > > wording here? `when not and preview`? oops - never on a Friday ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186337652 From forax at openjdk.org Fri May 5 17:31:31 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 5 May 2023 17:31:31 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v9] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 17:08:35 GMT, Vicente Romero wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Recommended changes #2 > > src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3999: > >> 3997: Name name = names.fromString(simplename); >> 3998: JCModifiers anonMods = F.at(primaryPos) >> 3999: .Modifiers(Flags.FINAL|Flags.MANDATED|Flags.SYNTHETIC|Flags.UNNAMED_CLASS, List.nil()); > > I wonder if testing if a class has flags: `Flags.FINAL|Flags.MANDATED|Flags.SYNTHETIC` should be enough to know if it is unnamed or not and we don't need to use the new `UNNAMED_CLASS` flag `Flags.MANDATED` on a class is currently enough to know if it's a unnamed class or not, but it's not enough for classes not produced by javac. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186335538 From vromero at openjdk.org Fri May 5 17:38:25 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 5 May 2023 17:38:25 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v9] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 17:22:03 GMT, R?mi Forax wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3999: >> >>> 3997: Name name = names.fromString(simplename); >>> 3998: JCModifiers anonMods = F.at(primaryPos) >>> 3999: .Modifiers(Flags.FINAL|Flags.MANDATED|Flags.SYNTHETIC|Flags.UNNAMED_CLASS, List.nil()); >> >> I wonder if testing if a class has flags: `Flags.FINAL|Flags.MANDATED|Flags.SYNTHETIC` should be enough to know if it is unnamed or not and we don't need to use the new `UNNAMED_CLASS` flag > > `Flags.MANDATED` on a class is currently enough to know if it's a unnamed class or not, but it's not enough for classes not produced by javac. good point ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186346149 From forax at openjdk.org Fri May 5 17:50:21 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 5 May 2023 17:50:21 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v9] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 17:35:33 GMT, Vicente Romero wrote: >> `Flags.MANDATED` on a class is currently enough to know if it's a unnamed class or not, but it's not enough for classes not produced by javac. > > good point Just to be clear, here, Flags.UNNAMED_CLASS is needed because an an unnamed class must have a main(), which is tested later. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186357338 From vromero at openjdk.org Fri May 5 18:18:24 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 5 May 2023 18:18:24 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v10] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 17:31:27 GMT, Jim Laskey wrote: >> Add flexible main methods and anonymous main classes to the Java language. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Typo src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 466: > 464: } catch (ClassNotFoundException e) { > 465: throw new Fault(Errors.CantFindClass(mainClassName)); > 466: } catch (NoSuchMethodException e) { `getDeclaredConstructor` can also throw a NSME but this error message would still say that the main method couldn't be found unless at this point we are sure that the class must have a no-args constructor ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186379230 From jlaskey at openjdk.org Fri May 5 18:32:30 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 5 May 2023 18:32:30 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v10] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 18:15:20 GMT, Vicente Romero wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Typo > > src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 466: > >> 464: } catch (ClassNotFoundException e) { >> 465: throw new Fault(Errors.CantFindClass(mainClassName)); >> 466: } catch (NoSuchMethodException e) { > > `getDeclaredConstructor` can also throw a NSME but this error message would still say that the main method couldn't be found unless at this point we are sure that the class must have a no-args constructor I was avoiding moving things so not to change behaviour when not in preview, but I think I really need to break it down into separate try blocks; get method, get constructor, execute method. Let me attempt. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186390633 From jlaskey at openjdk.org Fri May 5 19:17:53 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 5 May 2023 19:17:53 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v11] In-Reply-To: References: Message-ID: > Add flexible main methods and anonymous main classes to the Java language. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Refactor source code launcher ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13689/files - new: https://git.openjdk.org/jdk/pull/13689/files/0c8add65..b91e75aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=09-10 Stats: 76 lines in 2 files changed: 43 ins; 22 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/13689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689 PR: https://git.openjdk.org/jdk/pull/13689 From vromero at openjdk.org Fri May 5 20:16:26 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 5 May 2023 20:16:26 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v11] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 19:17:53 GMT, Jim Laskey wrote: >> Add flexible main methods and anonymous main classes to the Java language. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Refactor source code launcher looks good ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13689#pullrequestreview-1415400703 From erikj at openjdk.org Fri May 5 20:46:22 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 5 May 2023 20:46:22 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v7] In-Reply-To: <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com> References: <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com> Message-ID: On Fri, 5 May 2023 16:52:22 GMT, Jiangli Zhou wrote: >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: >> >> - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a >> >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk >> >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Fix whitespace error in make/StaticJvmLibsImage.gmk. With this solution, the build will produce a different static-libs bundle and image depending on the make target called, but the output name is exactly the same. That isn't ok. If you run one target after the other, the behavior becomes strange and unpredictable. If these are different deliverables, they need to be that all the way through, with a separate image and bundle with their own make targets. If we go with two separate deliverables, then to me it makes more sense that "static-libs-image" is the complete image with all the static libs and if graal needs a specialized subset of this, then that's something graal specific. The graal-builder-image is already meant just for their consumption (which is a combination of the jdk-image and the current static-libs-image). Having graal builds having to change the target they call is inconvenient for them, but for us to be forced to maintain unintuitive build targets is also bad. All of that said, I think we can get away with a smaller subset of targets and deliverables. AFAIK, graal needs the combined `graal-builder-image` as input to their build anyway, so they should not have any dependency on what the target `static-libs-image` produces. Given that I propose the following behavior: `make static-libs-image` produces `images/static-libs` with all .a (including libjvm.a). `make static-libs-graal-image` produces `images/static-libs-graal` with all .a except libjvm.a. `make graal-builder-image` produces `images/graal-builder-image` like today, but depends on and uses `static-libs-graal-image` instead of `static-libs-image`. `make static-libs-bundles` depends on and uses `static-libs-image` like today, so will contain libjvm.a, which is new behavior. Further I would like to suggest that libjvm.a gets put in the variant subdir under lib, just like libjvm.so does today (e.g. lib/server/libjvm.a). That way you can support building libjvm.a for all variants without worry. It will also get libjvm.a out of the way to cause less trouble for a graal build that uses the static-libs-bundles as input. This goes against what I suggested before, to just use JVM_VARIANT_MAIN, but I think this makes for a cleaner long term solution given the goals of the hermetic java effort. ------------- PR Review: https://git.openjdk.org/jdk/pull/13768#pullrequestreview-1415436469 From tsteele at openjdk.org Fri May 5 23:25:16 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Fri, 5 May 2023 23:25:16 GMT Subject: RFR: 8304434: [AIX] Update minimum xlclang version [v2] In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 01:49:09 GMT, Tyler Steele wrote: >> Minor changes to the build system to recognize and warn that an incompatible toolchain is detected. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > Change min xlx FP level to 11 Thanks for the reviews :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/13086#issuecomment-1536897137 From tsteele at openjdk.org Fri May 5 23:28:27 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Fri, 5 May 2023 23:28:27 GMT Subject: RFR: 8304434: [AIX] Update minimum xlclang version [v2] In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 01:49:09 GMT, Tyler Steele wrote: >> Minor changes to the build system to recognize and warn that an incompatible toolchain is detected. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > Change min xlx FP level to 11 Curious. Trying again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13086#issuecomment-1536899515 From tsteele at openjdk.org Fri May 5 23:33:17 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Fri, 5 May 2023 23:33:17 GMT Subject: RFR: 8304434: [AIX] Update minimum xlclang version [v2] In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 01:49:09 GMT, Tyler Steele wrote: >> Minor changes to the build system to recognize and warn that an incompatible toolchain is detected. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > Change min xlx FP level to 11 Curious-er. I am tired too openjdk bots. I will call upon you again next week. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13086#issuecomment-1536902419 From jiefu at openjdk.org Sat May 6 01:27:41 2023 From: jiefu at openjdk.org (Jie Fu) Date: Sat, 6 May 2023 01:27:41 GMT Subject: RFR: 8307569: Build with gcc8 is broken after JDK-8307301 Message-ID: <4Q1rajZAC5iFfiSOvXZvftLEliJc4nkVA_OStjQV-P4=.78709cff-a5c7-4fb7-adf9-603a7aac9db4@github.com> The fix disables expansion-to-defined warning for gcc. Thanks. ------------- Commit messages: - 8307569: Build with gcc8 is broken after JDK-8307301 Changes: https://git.openjdk.org/jdk/pull/13850/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13850&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307569 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13850.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13850/head:pull/13850 PR: https://git.openjdk.org/jdk/pull/13850 From jiefu at openjdk.org Sat May 6 01:41:11 2023 From: jiefu at openjdk.org (Jie Fu) Date: Sat, 6 May 2023 01:41:11 GMT Subject: RFR: 8307569: Build with gcc8 is broken after JDK-8307301 [v2] In-Reply-To: <4Q1rajZAC5iFfiSOvXZvftLEliJc4nkVA_OStjQV-P4=.78709cff-a5c7-4fb7-adf9-603a7aac9db4@github.com> References: <4Q1rajZAC5iFfiSOvXZvftLEliJc4nkVA_OStjQV-P4=.78709cff-a5c7-4fb7-adf9-603a7aac9db4@github.com> Message-ID: > The fix disables expansion-to-defined warning for gcc. > Thanks. Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Add comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13850/files - new: https://git.openjdk.org/jdk/pull/13850/files/99d77204..064271e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13850&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13850&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13850.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13850/head:pull/13850 PR: https://git.openjdk.org/jdk/pull/13850 From jiefu at openjdk.org Sat May 6 01:45:12 2023 From: jiefu at openjdk.org (Jie Fu) Date: Sat, 6 May 2023 01:45:12 GMT Subject: RFR: 8307569: Build with gcc8 is broken after JDK-8307301 [v2] In-Reply-To: References: <4Q1rajZAC5iFfiSOvXZvftLEliJc4nkVA_OStjQV-P4=.78709cff-a5c7-4fb7-adf9-603a7aac9db4@github.com> Message-ID: On Sat, 6 May 2023 01:41:11 GMT, Jie Fu wrote: >> The fix disables expansion-to-defined warning for gcc. >> Thanks. > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Add comment It failed with gcc8 & gcc9, but passed with gcc10+. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13850#issuecomment-1536971053 From qamai at openjdk.org Sat May 6 05:35:32 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Sat, 6 May 2023 05:35:32 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v8] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 07:43:17 GMT, Stefan Karlsson wrote: >> Hi all, >> >> Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. >> >> The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention is to give the users time to validate and deploy their workloads with the new GC implementation. >> >> Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clear to us how time consuming and complex things end up being when we tried to keep both the original G1 working, and at the same time implemented the ZGC-alike G1. Given this experience, we don't see that as a viable solution to deliver a maintainable and evolving Generational ZGC. Our pragmatic suggestion to these challenges is to let Generational ZGC live under the current gc/z directories and let the legacy, non-generational ZGC be completely separated in its own directories. This way we can continue to move quickly with the continued develo pment of Generational ZGC and let the non-generational ZGC be mostly untouched until it gets deprecated, and eventually removed. The non-generational ZGC directory will be gc/x and all the classes of non-generational have been prefixed with X instead of Z. An alternative to this rename could be to namespace out non-generational ZGC. We experimented with that, but it was too easy to accidentally cross-compile Generational ZGC code into non-generational ZGC, so we didn't like that approach. >> >> Most of the stand-alone cleanups and enhancements outside of the ZGC code have already been upstreamed to openjdk/jdk. There are still a few patches that could/should be pushed separately, but they will be easier to understand by also looking at the Generational ZGC code, so they will be sent out after this PR has been published. The patches that could be published separately are: >> >> * 59d1e96af6a UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class >> * ca9edf8aa79 UPSTREAM: RISCV tmp reg cleanup resolve_jobject >> * 4bec9c69b67 CLEANUP: barrierSetNMethod_aarch64.cpp >> * b67d03a3f04 UPSTREAM: Add relaxed add&fetch for aarch64 atomics >> * a2824734d23 UPSTREAM: lir_xchg >> * 36cd39c0126 UPSTREAM: assembler_ppc CMPLI >> * 447259cea42 UPSTREAM: assembler_ppc ANDI >> * 9417323499a UPSTREAM: Add VMErrorCallback infrastructure >> >> Regarding all the changesets you see in this PR, they form the history of the development of Generational ZGC. It might look a bit unconventional to what you are used to see in openjdk development. What we have done is to use merges with the 'ours' strategy to ignore the previous Generational ZGC patches, and then rebased and flattened the changes on top of the merge. This effectively gives us the upsides of having a rebased repository and the upsides of retaining the history in the repository. The downside could be that GitHub now lists all those changesets in the PR. Given that this patch is so big, and that you likely only want to see a part of it, I suggest that you pull down the PR branch and then compare it to the openjdk/jdk changeset this PR is based against: >> >> >> git fetch https://github.com/openjdk/zgc zgc_master >> git diff zgc_master... >> >> >> There have been many contributors of this patch over the years. I'll do my best to poke Skara into listing you all, but if you see that I've missed your name please reach out to me and I'll fix it. >> >> Testing: we have been continuously running Generational ZGC through Oracle's tier1-8 testing. > > Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 917 commits: > > - ZGC: Generational > > Co-authored-by: Stefan Karlsson > Co-authored-by: Per Liden > Co-authored-by: Albert Mingkun Yang > Co-authored-by: Erik ?sterlund > Co-authored-by: Axel Boldt-Christmas > Co-authored-by: Stefan Johansson > - UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class > - UPSTREAM: RISCV tmp reg cleanup resolve_jobject > - CLEANUP: barrierSetNMethod_aarch64.cpp > - UPSTREAM: Add relaxed add&fetch for aarch64 atomics > - UPSTREAM: assembler_ppc CMPLI > > Co-authored-by: TheRealMDoerr > - UPSTREAM: assembler_ppc ANDI > > Co-authored-by: TheRealMDoerr > - UPSTREAM: Add VMErrorCallback infrastructure > - Merge branch 'zgc_generational' into zgc_generational_rebase_target > - Whitespace nit > - ... and 907 more: https://git.openjdk.org/jdk/compare/705ad7d8...349cf9ae src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp line 310: > 308: // A not relocatable object could have spurious raw null pointers in its fields after > 309: // getting promoted to the old generation. > 310: __ cmpw(ref_addr, barrier_Relocation::unpatched); `cmpw` with immediates stalls the predecoder, it may be better to `movzwl` to a spare register and `cmpl` there. src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp line 483: > 481: > 482: __ lock(); > 483: __ cmpxchgq(rbx, Address(rcx, 0)); `ref_addr` is not necessarily materialised here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1186614250 PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1186640115 From liangchenblue at gmail.com Sat May 6 05:42:32 2023 From: liangchenblue at gmail.com (-) Date: Sat, 6 May 2023 00:42:32 -0500 Subject: WSL building performance and questions Message-ID: Hello, While I was trying to diagnose the problem that JMH benchmarks can't be run on a fresh cygwin or WSL environment, https://bugs.openjdk.org/browse/JDK-8305669 I found myself troubled with path issues and slow building speed with a Windows target. Meanwhile the linux target is totally fine. 1. When I pass --with-jmh=build/jmh/jars in WSL configuration, it always fails to find the relative directories (not present on linux configuration). C:\\...\\jdk\\build\\jmh\\jars doesn't work. Only /mnt/c/.../jdk/build/jmh/jars work. Is this a bug? 2. My Windows WSL build is extremely slow. My windows target has almost stalled that it stuck on creating benchmark jar without even progressing to indify. And it seems WSL (Ubuntu) itself is only using 400MB of RAM with almost no CPU usage. However, these problems don't happen for my Linux target builds; meanwhile my cygwin builds are blazingly fast. What could be the cause of this slowness? Curious, Chen Liang -------------- next part -------------- An HTML attachment was scrubbed... URL: From qamai at openjdk.org Sat May 6 08:17:31 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Sat, 6 May 2023 08:17:31 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v8] In-Reply-To: References: Message-ID: <6SAAbnqbNXzGj7LtOU1fhkg9y87ZR2dKYeRM2RyxO1E=.12002ace-4616-4b73-9306-25da93948b2d@github.com> On Sat, 6 May 2023 04:08:42 GMT, Quan Anh Mai wrote: >> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 917 commits: >> >> - ZGC: Generational >> >> Co-authored-by: Stefan Karlsson >> Co-authored-by: Per Liden >> Co-authored-by: Albert Mingkun Yang >> Co-authored-by: Erik ?sterlund >> Co-authored-by: Axel Boldt-Christmas >> Co-authored-by: Stefan Johansson >> - UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class >> - UPSTREAM: RISCV tmp reg cleanup resolve_jobject >> - CLEANUP: barrierSetNMethod_aarch64.cpp >> - UPSTREAM: Add relaxed add&fetch for aarch64 atomics >> - UPSTREAM: assembler_ppc CMPLI >> >> Co-authored-by: TheRealMDoerr >> - UPSTREAM: assembler_ppc ANDI >> >> Co-authored-by: TheRealMDoerr >> - UPSTREAM: Add VMErrorCallback infrastructure >> - Merge branch 'zgc_generational' into zgc_generational_rebase_target >> - Whitespace nit >> - ... and 907 more: https://git.openjdk.org/jdk/compare/705ad7d8...349cf9ae > > src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp line 310: > >> 308: // A not relocatable object could have spurious raw null pointers in its fields after >> 309: // getting promoted to the old generation. >> 310: __ cmpw(ref_addr, barrier_Relocation::unpatched); > > `cmpw` with immediates stalls the predecoder, it may be better to `movzwl` to a spare register and `cmpl` there. I think we use the flag `UseStoreImmI16` for these kinds of situations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1186662246 From gdams at openjdk.org Sat May 6 09:46:55 2023 From: gdams at openjdk.org (George Adams) Date: Sat, 6 May 2023 09:46:55 GMT Subject: RFR: 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal Message-ID: Deprecate the Windows x86-32 port, with the intent to remove it in a future release. ------------- Commit messages: - 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal Changes: https://git.openjdk.org/jdk/pull/13852/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13852&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307573 Stats: 22 lines in 3 files changed: 22 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13852.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13852/head:pull/13852 PR: https://git.openjdk.org/jdk/pull/13852 From gdams at openjdk.org Sat May 6 10:00:10 2023 From: gdams at openjdk.org (George Adams) Date: Sat, 6 May 2023 10:00:10 GMT Subject: RFR: 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal [v2] In-Reply-To: References: Message-ID: > Deprecate the Windows x86-32 port, with the intent to remove it in a future release. George Adams has updated the pull request incrementally with one additional commit since the last revision: fix wording ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13852/files - new: https://git.openjdk.org/jdk/pull/13852/files/671fe9fe..20315f6f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13852&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13852&range=00-01 Stats: 7 lines in 3 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/13852.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13852/head:pull/13852 PR: https://git.openjdk.org/jdk/pull/13852 From djelinski at openjdk.org Sat May 6 12:31:16 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Sat, 6 May 2023 12:31:16 GMT Subject: RFR: 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal [v2] In-Reply-To: References: Message-ID: <0siN7qFOHHjdmcH37HrsvJr6dATKxrB3lP0iMLNan8I=.37671830-07e4-40b8-9ec3-fd35d5465c38@github.com> On Sat, 6 May 2023 10:00:10 GMT, George Adams wrote: >> Deprecate the Windows x86-32 port, with the intent to remove it in a future release. > > George Adams has updated the pull request incrementally with one additional commit since the last revision: > > fix wording doc/building.md line 129: > 127: instead create a 32-bit target using `--with-target-bits=32`. > 128: > 129: Note: The Widows 32-bit x86 port is deprecated. Suggestion: Note: The Windows 32-bit x86 port is deprecated. doc/building.md line 204: > 202: on [Fixpath](#fixpath). > 203: > 204: Note: The Widows x32-bit x86 port is deprecated. Suggestion: Note: The Windows 32-bit x86 port is deprecated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13852#discussion_r1186690212 PR Review Comment: https://git.openjdk.org/jdk/pull/13852#discussion_r1186690258 From gdams at openjdk.org Sat May 6 12:42:23 2023 From: gdams at openjdk.org (George Adams) Date: Sat, 6 May 2023 12:42:23 GMT Subject: RFR: 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal [v3] In-Reply-To: References: Message-ID: <1E6ZU_haLOvT9Br8S8ytnhw6CH3BZj2IaglTd17YYqA=.5bfa0dd8-88df-49be-a2e4-69e318dd3d84@github.com> > Deprecate the Windows x86-32 port, with the intent to remove it in a future release. George Adams has updated the pull request incrementally with one additional commit since the last revision: typo fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13852/files - new: https://git.openjdk.org/jdk/pull/13852/files/20315f6f..8c090a71 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13852&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13852&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13852.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13852/head:pull/13852 PR: https://git.openjdk.org/jdk/pull/13852 From gdams at openjdk.org Sat May 6 12:42:24 2023 From: gdams at openjdk.org (George Adams) Date: Sat, 6 May 2023 12:42:24 GMT Subject: RFR: 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal [v2] In-Reply-To: <0siN7qFOHHjdmcH37HrsvJr6dATKxrB3lP0iMLNan8I=.37671830-07e4-40b8-9ec3-fd35d5465c38@github.com> References: <0siN7qFOHHjdmcH37HrsvJr6dATKxrB3lP0iMLNan8I=.37671830-07e4-40b8-9ec3-fd35d5465c38@github.com> Message-ID: On Sat, 6 May 2023 12:27:40 GMT, Daniel Jeli?ski wrote: >> George Adams has updated the pull request incrementally with one additional commit since the last revision: >> >> fix wording > > doc/building.md line 129: > >> 127: instead create a 32-bit target using `--with-target-bits=32`. >> 128: >> 129: Note: The Widows 32-bit x86 port is deprecated. > > Suggestion: > > Note: The Windows 32-bit x86 port is deprecated. updated PTAL ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13852#discussion_r1186691185 From david.holmes at oracle.com Mon May 8 00:51:08 2023 From: david.holmes at oracle.com (David Holmes) Date: Mon, 8 May 2023 10:51:08 +1000 Subject: [EXTERNAL] Re: Compiler/aot testing on MacOS In-Reply-To: References: <9687d18b-260c-962f-c8eb-cffc5e5b37cd@oracle.com> Message-ID: <3c7ef64d-19ef-c7eb-377d-7fa2a44d7bc5@oracle.com> Hi Joe, On 6/05/2023 12:21 am, Joe Braley wrote: > Hi David, > > Yes, this is still an issue our team is experiencing. Okay I'm asking around but I'm not sure anyone actively uses jaotc any more. David > Regards, > Joe Braley > > -----Original Message----- > From: David Holmes > Sent: Friday, May 5, 2023 12:24 AM > To: Joe Braley ; build-dev at openjdk.org > Subject: [EXTERNAL] Re: Compiler/aot testing on MacOS > > [You don't often get email from david.holmes at oracle.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > Hi Joe, > > It looks like you were not subscribed to the mailing list and this email only just got cleared and has turned up. is this still an issue? > > Cheers, > David > > On 24/03/2023 12:20 am, Joe Braley wrote: >> Hello, >> >> Our team publishes Microsoft's build of OpenJDK, and we have observed >> some test failures after upgrading our macOS agents from 10.15 to >> MacOS 11. We have also seen these failures on macOS 12.x. The tests >> that are encountering issues are in compiler/aot category.We are only >> observing these issues in our JDK11u builds. The exact command line I >> used to reproduce the error locally is: >> >> /Users/JEG/jdk-11.0.18+10/Contents/Home/bin/java -Xmx512m -jar >> /Users/JEG/jtreg/lib/jtreg.jar -agentvm -ignore:quiet -automatic -xml >> -vmoption:-Xmx512m -timeoutFactor:4 -concurrency:1 >> -testjdk:/Users/JEG/jdk-11.0.18+10/Contents/Home -nativepath:/ >> >> Users/JEG/jdk-11.0.18+10-test-image/hotspot/jtreg/native >> -verbose:fail,error,summary >> -exclude:test/hotspot/jtreg/ProblemList.txt >> test/hotspot/jtreg/compiler/aot/TestHeapBase.java >> >> Which resulted in the following exception: >> >> Exception in thread "main" java.lang.InternalError: ld: dynamic main >> executables must link with libSystem.dylib for architecture x86_64 >> >> at >> jdk.aot at 11.0.18/jdk.tools.jaotc.Linker.link(Linker.java:142) >> >> >> at jdk.aot at 11.0.18/jdk.tools.jaotc.Main.run(Main.java:262) >> >> >> at jdk.aot at 11.0.18/jdk.tools.jaotc.Main.run(Main.java:133) >> >> >> at jdk.aot at 11.0.18/jdk.tools.jaotc.Main.main(Main.java:89) >> >> >> The version of macOS which I reproduced this error was: >> >> openjdk-jdk11u % sw_vers >> >> ProductName: macOS >> >> ProductVersion: 11.4 >> >> BuildVersion: 20F71 >> >> Initial triage on our end suggests that the linker for these tests is >> invoked in Linker.java, where we may require additional arguments >> passed into the "ld" command. Specifically, including the library >> path. The change that may have introduced this behavior is documented here: >> https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-release-notes . The important bit, I think, is: >> >> * /New in macOS Big Sur 11.0.1, the system ships with a built-in >> dynamic linker cache of all system-provided libraries. As part of >> this change, copies of dynamic libraries are no longer present on >> the filesystem. Code that attempts to check for dynamic library >> presence by looking for a file at a path or enumerating a directory >> will fail. Instead, check for library presence by attempting to >> dlopen() the path, which will correctly check for the library in the >> cache. (62986286)/ >> >> Has anyone encountered this issue before or would be willing to >> provide insight to what the root cause may be? >> >> Thanks! >> >> *Joe Braley >> *Software Engineer >> joebraley at microsoft.com >> >> Microsoft Logo >> From dholmes at openjdk.org Mon May 8 06:36:27 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 8 May 2023 06:36:27 GMT Subject: RFR: 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal [v3] In-Reply-To: <1E6ZU_haLOvT9Br8S8ytnhw6CH3BZj2IaglTd17YYqA=.5bfa0dd8-88df-49be-a2e4-69e318dd3d84@github.com> References: <1E6ZU_haLOvT9Br8S8ytnhw6CH3BZj2IaglTd17YYqA=.5bfa0dd8-88df-49be-a2e4-69e318dd3d84@github.com> Message-ID: On Sat, 6 May 2023 12:42:23 GMT, George Adams wrote: >> Deprecate the Windows x86-32 port, with the intent to remove it in a future release. > > George Adams has updated the pull request incrementally with one additional commit since the last revision: > > typo fix doc/building.html line 326: > 324: machine, and instead create a 32-bit target using > 325: --with-target-bits=32.

> 326:

Note: The Windows 32-bit x86 port is deprecated.

Suggestion: > The Windows 32-bit x86 port is deprecated and may be removed in a future release. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13852#discussion_r1187073820 From sgehwolf at openjdk.org Mon May 8 08:52:27 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 8 May 2023 08:52:27 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v7] In-Reply-To: <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com> References: <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com> Message-ID: On Fri, 5 May 2023 16:52:22 GMT, Jiangli Zhou wrote: >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: >> >> - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a >> >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk >> >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Fix whitespace error in make/StaticJvmLibsImage.gmk. Seems fine to me, but I'm not an expert in on the build files. Thanks for the implementing the suggestion. ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13768#pullrequestreview-1416396939 From sgehwolf at openjdk.org Mon May 8 09:00:22 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 8 May 2023 09:00:22 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v7] In-Reply-To: References: <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com> Message-ID: <2BVvV9m8bI-UzZXpX1GEPwoStZ6pHZBn4JuAMRQk978=.54246fe4-57b8-4372-bfc4-6b63823fa9a2@github.com> On Fri, 5 May 2023 20:43:41 GMT, Erik Joelsson wrote: > All of that said, I think we can get away with a smaller subset of targets and deliverables. AFAIK, graal needs the combined `graal-builder-image` as input to their build anyway, so they should not have any dependency on what the target `static-libs-image` produces. Given that I propose the following behavior: > > `make static-libs-image` produces `images/static-libs` with all .a (including libjvm.a). `make static-libs-graal-image` produces `images/static-libs-graal` with all .a except libjvm.a. `make graal-builder-image` produces `images/graal-builder-image` like today, but depends on and uses `static-libs-graal-image` instead of `static-libs-image`. `make static-libs-bundles` depends on and uses `static-libs-image` like today, so will contain libjvm.a, which is new behavior. Sure, that should work too as long as there is a way to a) build the static libs only needed for graal some way b) keep `graal-builder-image` working as it does today. FWIW, we use `a)` at adoptium so as to be able to have a combination to build mandrel from. Not all users will want to have JDK + static libs so only the ones needing them should need to download them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1538008209 From eosterlund at openjdk.org Mon May 8 09:04:39 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 8 May 2023 09:04:39 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v8] In-Reply-To: <6SAAbnqbNXzGj7LtOU1fhkg9y87ZR2dKYeRM2RyxO1E=.12002ace-4616-4b73-9306-25da93948b2d@github.com> References: <6SAAbnqbNXzGj7LtOU1fhkg9y87ZR2dKYeRM2RyxO1E=.12002ace-4616-4b73-9306-25da93948b2d@github.com> Message-ID: On Sat, 6 May 2023 08:14:24 GMT, Quan Anh Mai wrote: >> src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp line 310: >> >>> 308: // A not relocatable object could have spurious raw null pointers in its fields after >>> 309: // getting promoted to the old generation. >>> 310: __ cmpw(ref_addr, barrier_Relocation::unpatched); >> >> `cmpw` with immediates stalls the predecoder, it may be better to `movzwl` to a spare register and `cmpl` there. > > I think we use the flag `UseStoreImmI16` for these kinds of situations. We did indeed run into the predecoder issue when we used testw for normal store barriers, so I changed to testl. However, this cmpw is only taken when we use atomics. I felt less motivated to optimize every bit in this path as the ratio of atomic accesses compared to normal stores/loads is typically really small, when I have profiled it. That's why I haven't optimized this path further. However, we can fix it too. It will however require some changes to the assembler, as it currently tries to be too smart about encoding cmpl with register + immediate operands with varying sizes. I'd like to postpone that until after we integrate, as it seems mostly like a micro optimization. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1187207769 From eosterlund at openjdk.org Mon May 8 09:13:39 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 8 May 2023 09:13:39 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v8] In-Reply-To: References: Message-ID: <3biazHwRxoAOqw2VA_W48jB5IUe_asslAOFbTyIpCIg=.fa235ecf-6139-44e4-bb6c-d98ae7188841@github.com> On Sat, 6 May 2023 05:22:48 GMT, Quan Anh Mai wrote: >> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 917 commits: >> >> - ZGC: Generational >> >> Co-authored-by: Stefan Karlsson >> Co-authored-by: Per Liden >> Co-authored-by: Albert Mingkun Yang >> Co-authored-by: Erik ?sterlund >> Co-authored-by: Axel Boldt-Christmas >> Co-authored-by: Stefan Johansson >> - UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class >> - UPSTREAM: RISCV tmp reg cleanup resolve_jobject >> - CLEANUP: barrierSetNMethod_aarch64.cpp >> - UPSTREAM: Add relaxed add&fetch for aarch64 atomics >> - UPSTREAM: assembler_ppc CMPLI >> >> Co-authored-by: TheRealMDoerr >> - UPSTREAM: assembler_ppc ANDI >> >> Co-authored-by: TheRealMDoerr >> - UPSTREAM: Add VMErrorCallback infrastructure >> - Merge branch 'zgc_generational' into zgc_generational_rebase_target >> - Whitespace nit >> - ... and 907 more: https://git.openjdk.org/jdk/compare/705ad7d8...349cf9ae > > src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp line 483: > >> 481: >> 482: __ lock(); >> 483: __ cmpxchgq(rbx, Address(rcx, 0)); > > `ref_addr` is not necessarily materialised here? I think it is, yes. But we want to ensure it's in a register that isn't rbx or rax. So I figured I'd just force materialize it in rcx and call it a day. It might be possible to micro optimize this further and even use the live information we have gathered to eliminate some of the spilling, but I'd like to hold off on that until we integrate. It's again only for atomics, and also happens at most once per field. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1187216401 From dzhang at openjdk.org Mon May 8 09:40:26 2023 From: dzhang at openjdk.org (Dingli Zhang) Date: Mon, 8 May 2023 09:40:26 GMT Subject: RFR: 8306408: Fix the format of several tables in building.md [v4] In-Reply-To: <16mRdq0k89i1Zil8kF5J6x96HzAGgv1-Ja3w5fioepA=.5e4c6f7e-6572-461b-a04c-95e15b64650f@github.com> References: <16mRdq0k89i1Zil8kF5J6x96HzAGgv1-Ja3w5fioepA=.5e4c6f7e-6572-461b-a04c-95e15b64650f@github.com> Message-ID: On Thu, 20 Apr 2023 00:23:34 GMT, Dingli Zhang wrote: >> Hi all, >> >> Currently, the format of several tables in building.md looks a little >> problematic and will incorrectly display the split line. In contrast, the >> corresponding building.html will display the tables correctly. >> >> This patch will only change building.md and the format of the tables >> will display correctly. >> >> Please take a look and have some reviews. Thanks a lot. > > Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: > > Updated html May I ask if anyone can sponsor for me? Thanks a lot! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13523#issuecomment-1538063108 From fyang at openjdk.org Mon May 8 10:22:53 2023 From: fyang at openjdk.org (Fei Yang) Date: Mon, 8 May 2023 10:22:53 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v6] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 06:50:55 GMT, Stefan Karlsson wrote: >> We emailed to erik to discuss this issue two months ago, and maybe he missed it. >> ZForwardingTest does not guarantee a successful invoke of os::commit_memory for ZAddressHeapBase, and we saw some conflicts between ZAddressHeapBase and the metadata address space on the RISC-V hardware of 39-bits virtual address. There is no failure in the normal initialization phase of JVM, because the commit order of them is guaranteed. > > Could you provide the values for `reserved`, `ZAddressHeapBase`, and `ZAddressOffsetMax`, when this test is failing. I'd like to know if we can make a workaround for you, or if we have to turn off the test for riscv. @stefank : I ran this gtest for 5 times and here is what I got. ZAddressHeapBase : 0x800000000 ZAddressOffsetMax: 0x800000000 ZGranuleSize : 0x200000 In os::pd_attempt_reserve_memory_at() which is called by os::attempt_reserve_memory_at(), return value by anon_mmap() [1] is one of: ```0x3f8d5ff000, 0x3f649fe000, 0x3f5d3ff000, 0x3f68077000 and 0x3f555ff000``` So seems that those values are not in the range [ZAddressHeapBase, ZAddressHeapBase+ZAddressOffsetMax). [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/os_linux.cpp#L3334 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1187278971 From shade at openjdk.org Mon May 8 10:33:28 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 8 May 2023 10:33:28 GMT Subject: RFR: 8307527: MacOS Zero builds fail with undefined FFI_GO_CLOSURES after JDK-8304265 In-Reply-To: References: Message-ID: On Fri, 5 May 2023 13:23:21 GMT, Jorn Vernee wrote: > And then remove the workaround from the source code. (`LIBFFI_CFLAGS` is used to build both relevant libraries, and should also be used when a new library is added that needs libffi. So this would avoid a repeat of this issue) Yes, I added a variant of that fix that explicitly checks for `FFI_GO_CLOSURES` definition during configure. (Now I have to find a system which actually supports recent FFI to test it... ------------- PR Comment: https://git.openjdk.org/jdk/pull/13827#issuecomment-1538144683 From mbaesken at openjdk.org Mon May 8 10:38:27 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 8 May 2023 10:38:27 GMT Subject: RFR: JDK-8307604: gcc12 based Alpine build broken build after JDK-8307301 Message-ID: After the harfbuzz 7.2 update we run into /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8: error: offset '4' outside bounds of constant string [-Werror=array-bounds] 281 | bool get_points (hb_font_t *font, const accelerator_t &glyf_accelerator, | ^~~~~~~~~~ /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/hb-static.cc:45:16: note: '_hb_NullPool' declared here 45 | uint64_t const _hb_NullPool[(HB_NULL_POOL_SIZE + sizeof (uint64_t) - 1) / sizeof (uint64_t)] = {}; | ^~~~~~~~~~~~ /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8: error: offset '4' outside bounds of constant string [-Werror=array-bounds] 281 | bool get_points (hb_font_t *font, const accelerator_t &glyf_accelerator, | ^~~~~~~~~~ /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/hb-static.cc:45:16: note: '_hb_NullPool' declared here 45 | uint64_t const _hb_NullPool[(HB_NULL_POOL_SIZE + sizeof (uint64_t) - 1) / sizeof (uint64_t)] = {}; We use gcc12 on Alpine. Switching off this 'warning as error' fixes the issue. ------------- Commit messages: - JDK-8307604 Changes: https://git.openjdk.org/jdk/pull/13859/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13859&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307604 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13859.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13859/head:pull/13859 PR: https://git.openjdk.org/jdk/pull/13859 From qamai at openjdk.org Mon May 8 10:52:38 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 8 May 2023 10:52:38 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v8] In-Reply-To: References: <6SAAbnqbNXzGj7LtOU1fhkg9y87ZR2dKYeRM2RyxO1E=.12002ace-4616-4b73-9306-25da93948b2d@github.com> Message-ID: On Mon, 8 May 2023 09:01:07 GMT, Erik ?sterlund wrote: >> I think we use the flag `UseStoreImmI16` for these kinds of situations. > > We did indeed run into the predecoder issue when we used testw for normal store barriers, so I changed to testl. However, this cmpw is only taken when we use atomics. I felt less motivated to optimize every bit in this path as the ratio of atomic accesses compared to normal stores/loads is typically really small, when I have profiled it. That's why I haven't optimized this path further. However, we can fix it too. It will however require some changes to the assembler, as it currently tries to be too smart about encoding cmpl with register + immediate operands with varying sizes. I'd like to postpone that until after we integrate, as it seems mostly like a micro optimization. @fisk Thanks a lot for your explanations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1187303107 From lucy at openjdk.org Mon May 8 11:38:14 2023 From: lucy at openjdk.org (Lutz Schmidt) Date: Mon, 8 May 2023 11:38:14 GMT Subject: RFR: JDK-8307604: gcc12 based Alpine build broken build after JDK-8307301 In-Reply-To: References: Message-ID: <12Hjj2DVxLGHSB-LcyczzLrqrD3gvH1RyTM3A-JPAvg=.da0c013c-cdd8-4399-9c08-186aa9e10b06@github.com> On Mon, 8 May 2023 10:29:56 GMT, Matthias Baesken wrote: > After the harfbuzz 7.2 update we run into > > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8: error: offset '4' outside bounds of constant string [-Werror=array-bounds] > 281 | bool get_points (hb_font_t *font, const accelerator_t &glyf_accelerator, > | ^~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/hb-static.cc:45:16: note: '_hb_NullPool' declared here > 45 | uint64_t const _hb_NullPool[(HB_NULL_POOL_SIZE + sizeof (uint64_t) - 1) / sizeof (uint64_t)] = {}; > | ^~~~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8: error: offset '4' outside bounds of constant string [-Werror=array-bounds] > 281 | bool get_points (hb_font_t *font, const accelerator_t &glyf_accelerator, > | ^~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/hb-static.cc:45:16: note: '_hb_NullPool' declared here > 45 | uint64_t const _hb_NullPool[(HB_NULL_POOL_SIZE + sizeof (uint64_t) - 1) / sizeof (uint64_t)] = {}; > > We use gcc12 on Alpine. > Switching off this 'warning as error' fixes the issue. LGTM. Disabling the warning is OK for now. Issue should be fixed by HarfBuzz. ------------- Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13859#pullrequestreview-1416631184 From jvernee at openjdk.org Mon May 8 12:16:28 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 8 May 2023 12:16:28 GMT Subject: RFR: 8307527: MacOS Zero builds fail with undefined FFI_GO_CLOSURES after JDK-8304265 [v2] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 10:18:35 GMT, Aleksey Shipilev wrote: >> See the bug. Actually, I am not sure why JDK-8304265 changed the `#ifndef FFI_GO_CLOSURES` to `#ifdef _APPLE_`. That seems too intrusive if `FFI_GO_CLOSURES` *is* enabled. So I rewrote the block to something more safe. >> >> Additional testing: >> - [x] macos-aarch64-zero-fastdebug `make images` passes > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Use a build system fix Thanks! This looks like a good solution, but I'll leave the Review to one of the build people. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13827#issuecomment-1538260265 From stefank at openjdk.org Mon May 8 12:51:13 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 8 May 2023 12:51:13 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v6] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 10:19:44 GMT, Fei Yang wrote: >> Could you provide the values for `reserved`, `ZAddressHeapBase`, and `ZAddressOffsetMax`, when this test is failing. I'd like to know if we can make a workaround for you, or if we have to turn off the test for riscv. > > @stefank : I ran this gtest for 5 times on linux-riscv64 board and here is what I got. > > ZAddressHeapBase : 0x800000000 > ZAddressOffsetMax: 0x800000000 > ZGranuleSize : 0x200000 > > In os::pd_attempt_reserve_memory_at() which is called by os::attempt_reserve_memory_at(), return value by anon_mmap() [1] is one of: ```0x3f8d5ff000, 0x3f649fe000, 0x3f5d3ff000, 0x3f68077000 and 0x3f555ff000``` > > So seems that those values are not in the range [ZAddressHeapBase, ZAddressHeapBase+ZAddressOffsetMax). > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/os_linux.cpp#L3334 That's unfortunate. Could you try this patch, which probes the address range to see if it can reserve the memory somewhere else within `[ZAddressHeapBase, ZAddressHeapBase+ZAddressOffsetMax)`: https://github.com/stefank/jdk/tree/zgc_generational_review_test_zforwarding ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1187406599 From mdoerr at openjdk.org Mon May 8 13:26:16 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 8 May 2023 13:26:16 GMT Subject: RFR: JDK-8307604: gcc12 based Alpine build broken build after JDK-8307301 In-Reply-To: References: Message-ID: On Mon, 8 May 2023 10:29:56 GMT, Matthias Baesken wrote: > After the harfbuzz 7.2 update we run into > > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8: error: offset '4' outside bounds of constant string [-Werror=array-bounds] > 281 | bool get_points (hb_font_t *font, const accelerator_t &glyf_accelerator, > | ^~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/hb-static.cc:45:16: note: '_hb_NullPool' declared here > 45 | uint64_t const _hb_NullPool[(HB_NULL_POOL_SIZE + sizeof (uint64_t) - 1) / sizeof (uint64_t)] = {}; > | ^~~~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8: error: offset '4' outside bounds of constant string [-Werror=array-bounds] > 281 | bool get_points (hb_font_t *font, const accelerator_t &glyf_accelerator, > | ^~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/hb-static.cc:45:16: note: '_hb_NullPool' declared here > 45 | uint64_t const _hb_NullPool[(HB_NULL_POOL_SIZE + sizeof (uint64_t) - 1) / sizeof (uint64_t)] = {}; > > We use gcc12 on Alpine. > Switching off this 'warning as error' fixes the issue. It's always unfortunate if we have to disable warnings, but I'm not aware of a better solution. Changing the harfbuzz code should be done upstream (in the harfbuzz repo). ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13859#pullrequestreview-1416794665 From erikj at openjdk.org Mon May 8 13:32:14 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 8 May 2023 13:32:14 GMT Subject: RFR: 8307569: Build with gcc8 is broken after JDK-8307301 [v2] In-Reply-To: References: <4Q1rajZAC5iFfiSOvXZvftLEliJc4nkVA_OStjQV-P4=.78709cff-a5c7-4fb7-adf9-603a7aac9db4@github.com> Message-ID: On Sat, 6 May 2023 01:41:11 GMT, Jie Fu wrote: >> The fix disables expansion-to-defined warning for gcc. >> Thanks. > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Add comment Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13850#pullrequestreview-1416808334 From erik.joelsson at oracle.com Mon May 8 13:36:35 2023 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 8 May 2023 06:36:35 -0700 Subject: WSL building performance and questions In-Reply-To: References: Message-ID: <82c742ef-e4a8-30ff-f073-974aec1de81a@oracle.com> Hello Chen, On 5/5/23 22:42, - wrote: > Hello, > While I was trying to diagnose the problem that JMH benchmarks can't > be run on a fresh cygwin or WSL environment, > https://bugs.openjdk.org/browse/JDK-8305669 I found myself troubled > with path issues and slow building speed with a Windows target. > Meanwhile the linux target is totally fine. > > 1. When I pass --with-jmh=build/jmh/jars in WSL configuration, it > always fails to find the relative directories (not present on linux > configuration). C:\\...\\jdk\\build\\jmh\\jars doesn't work. Only > /mnt/c/.../jdk/build/jmh/jars work. Is this a bug? I would say it's a bug. > > 2. My Windows WSL build is extremely slow. My windows target has > almost stalled that it stuck on creating benchmark jar without even > progressing to indify. And it seems WSL (Ubuntu) itself is only using > 400MB of RAM with almost no CPU usage. However, these problems don't > happen for my Linux target builds; meanwhile my cygwin builds are > blazingly fast. What could be the cause of this slowness? > Are you running WSL 1 or 2? From what I've heard, WSL 2 doesn't work well when having to interact with native Windows tools (which the windows build has to do). Most reports I've heard about WSL 1 say it's slightly faster than Cygwin, but different people and different environments have different results. /Erik From jiefu at openjdk.org Mon May 8 13:41:16 2023 From: jiefu at openjdk.org (Jie Fu) Date: Mon, 8 May 2023 13:41:16 GMT Subject: RFR: 8307569: Build with gcc8 is broken after JDK-8307301 [v2] In-Reply-To: References: <4Q1rajZAC5iFfiSOvXZvftLEliJc4nkVA_OStjQV-P4=.78709cff-a5c7-4fb7-adf9-603a7aac9db4@github.com> Message-ID: <2Ogud9_skvVWZMLtBHwOhycSrV5PINikC0pJ3qI7X58=.13d0fc69-8f19-4519-9daa-1941aacc2a7e@github.com> On Mon, 8 May 2023 13:29:26 GMT, Erik Joelsson wrote: >> Jie Fu has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comment > > Marked as reviewed by erikj (Reviewer). Thanks @erikj79 for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13850#issuecomment-1538378087 From erikj at openjdk.org Mon May 8 13:43:18 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 8 May 2023 13:43:18 GMT Subject: RFR: 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal [v3] In-Reply-To: <1E6ZU_haLOvT9Br8S8ytnhw6CH3BZj2IaglTd17YYqA=.5bfa0dd8-88df-49be-a2e4-69e318dd3d84@github.com> References: <1E6ZU_haLOvT9Br8S8ytnhw6CH3BZj2IaglTd17YYqA=.5bfa0dd8-88df-49be-a2e4-69e318dd3d84@github.com> Message-ID: On Sat, 6 May 2023 12:42:23 GMT, George Adams wrote: >> Deprecate the Windows x86-32 port, with the intent to remove it in a future release. > > George Adams has updated the pull request incrementally with one additional commit since the last revision: > > typo fix Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13852#pullrequestreview-1416826542 From erikj at openjdk.org Mon May 8 13:52:25 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 8 May 2023 13:52:25 GMT Subject: RFR: 8307527: MacOS Zero builds fail with undefined FFI_GO_CLOSURES after JDK-8304265 [v2] In-Reply-To: References: Message-ID: <1cvvumeMiLuc08Hl58XHjPvLr803TpnepkO5RSdTPyY=.5b2f1346-b8a5-4272-a38a-5e5240889f52@github.com> On Mon, 8 May 2023 10:18:35 GMT, Aleksey Shipilev wrote: >> See the bug. Actually, I am not sure why JDK-8304265 changed the `#ifndef FFI_GO_CLOSURES` to `#ifdef _APPLE_`. That seems too intrusive if `FFI_GO_CLOSURES` *is* enabled. So I rewrote the block to something more safe. >> >> Additional testing: >> - [x] macos-aarch64-zero-fastdebug `make images` passes > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Use a build system fix Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13827#pullrequestreview-1416842813 From erikj at openjdk.org Mon May 8 13:56:22 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 8 May 2023 13:56:22 GMT Subject: RFR: JDK-8307604: gcc12 based Alpine build broken build after JDK-8307301 In-Reply-To: References: Message-ID: On Mon, 8 May 2023 10:29:56 GMT, Matthias Baesken wrote: > After the harfbuzz 7.2 update we run into > > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8: error: offset '4' outside bounds of constant string [-Werror=array-bounds] > 281 | bool get_points (hb_font_t *font, const accelerator_t &glyf_accelerator, > | ^~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/hb-static.cc:45:16: note: '_hb_NullPool' declared here > 45 | uint64_t const _hb_NullPool[(HB_NULL_POOL_SIZE + sizeof (uint64_t) - 1) / sizeof (uint64_t)] = {}; > | ^~~~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8: error: offset '4' outside bounds of constant string [-Werror=array-bounds] > 281 | bool get_points (hb_font_t *font, const accelerator_t &glyf_accelerator, > | ^~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/hb-static.cc:45:16: note: '_hb_NullPool' declared here > 45 | uint64_t const _hb_NullPool[(HB_NULL_POOL_SIZE + sizeof (uint64_t) - 1) / sizeof (uint64_t)] = {}; > > We use gcc12 on Alpine. > Switching off this 'warning as error' fixes the issue. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13859#pullrequestreview-1416851881 From jiefu at openjdk.org Mon May 8 14:02:34 2023 From: jiefu at openjdk.org (Jie Fu) Date: Mon, 8 May 2023 14:02:34 GMT Subject: Integrated: 8307569: Build with gcc8 is broken after JDK-8307301 In-Reply-To: <4Q1rajZAC5iFfiSOvXZvftLEliJc4nkVA_OStjQV-P4=.78709cff-a5c7-4fb7-adf9-603a7aac9db4@github.com> References: <4Q1rajZAC5iFfiSOvXZvftLEliJc4nkVA_OStjQV-P4=.78709cff-a5c7-4fb7-adf9-603a7aac9db4@github.com> Message-ID: On Sat, 6 May 2023 01:14:50 GMT, Jie Fu wrote: > The fix disables expansion-to-defined warning for gcc. > Thanks. This pull request has now been integrated. Changeset: 64c09628 Author: Jie Fu URL: https://git.openjdk.org/jdk/commit/64c09628664fd19c281723f15bf677c52e360acd Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8307569: Build with gcc8 is broken after JDK-8307301 Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/13850 From dzhang at openjdk.org Mon May 8 14:04:33 2023 From: dzhang at openjdk.org (Dingli Zhang) Date: Mon, 8 May 2023 14:04:33 GMT Subject: Integrated: 8306408: Fix the format of several tables in building.md In-Reply-To: References: Message-ID: On Wed, 19 Apr 2023 02:49:55 GMT, Dingli Zhang wrote: > Hi all, > > Currently, the format of several tables in building.md looks a little > problematic and will incorrectly display the split line. In contrast, the > corresponding building.html will display the tables correctly. > > This patch will only change building.md and the format of the tables > will display correctly. > > Please take a look and have some reviews. Thanks a lot. This pull request has now been integrated. Changeset: 26755a96 Author: Dingli Zhang Committer: Erik Joelsson URL: https://git.openjdk.org/jdk/commit/26755a968665545a151adce79a5227c79724bb6b Stats: 111 lines in 2 files changed: 7 ins; 0 del; 104 mod 8306408: Fix the format of several tables in building.md Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/13523 From mbaesken at openjdk.org Mon May 8 14:07:15 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 8 May 2023 14:07:15 GMT Subject: RFR: JDK-8307604: gcc12 based Alpine build broken build after JDK-8307301 In-Reply-To: References: Message-ID: On Mon, 8 May 2023 10:29:56 GMT, Matthias Baesken wrote: > After the harfbuzz 7.2 update we run into > > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8: error: offset '4' outside bounds of constant string [-Werror=array-bounds] > 281 | bool get_points (hb_font_t *font, const accelerator_t &glyf_accelerator, > | ^~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/hb-static.cc:45:16: note: '_hb_NullPool' declared here > 45 | uint64_t const _hb_NullPool[(HB_NULL_POOL_SIZE + sizeof (uint64_t) - 1) / sizeof (uint64_t)] = {}; > | ^~~~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8: error: offset '4' outside bounds of constant string [-Werror=array-bounds] > 281 | bool get_points (hb_font_t *font, const accelerator_t &glyf_accelerator, > | ^~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/hb-static.cc:45:16: note: '_hb_NullPool' declared here > 45 | uint64_t const _hb_NullPool[(HB_NULL_POOL_SIZE + sizeof (uint64_t) - 1) / sizeof (uint64_t)] = {}; > > We use gcc12 on Alpine. > Switching off this 'warning as error' fixes the issue. Hi Erik, Lucy and Martin , thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13859#issuecomment-1538417029 From mbaesken at openjdk.org Mon May 8 14:19:30 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 8 May 2023 14:19:30 GMT Subject: Integrated: JDK-8307604: gcc12 based Alpine build broken build after JDK-8307301 In-Reply-To: References: Message-ID: On Mon, 8 May 2023 10:29:56 GMT, Matthias Baesken wrote: > After the harfbuzz 7.2 update we run into > > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8: error: offset '4' outside bounds of constant string [-Werror=array-bounds] > 281 | bool get_points (hb_font_t *font, const accelerator_t &glyf_accelerator, > | ^~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/hb-static.cc:45:16: note: '_hb_NullPool' declared here > 45 | uint64_t const _hb_NullPool[(HB_NULL_POOL_SIZE + sizeof (uint64_t) - 1) / sizeof (uint64_t)] = {}; > | ^~~~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8: error: offset '4' outside bounds of constant string [-Werror=array-bounds] > 281 | bool get_points (hb_font_t *font, const accelerator_t &glyf_accelerator, > | ^~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/hb-static.cc:45:16: note: '_hb_NullPool' declared here > 45 | uint64_t const _hb_NullPool[(HB_NULL_POOL_SIZE + sizeof (uint64_t) - 1) / sizeof (uint64_t)] = {}; > > We use gcc12 on Alpine. > Switching off this 'warning as error' fixes the issue. This pull request has now been integrated. Changeset: d2e0e534 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/d2e0e534d7e391dd633fb9ff671900f8060b6d49 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8307604: gcc12 based Alpine build broken build after JDK-8307301 Reviewed-by: lucy, mdoerr, erikj ------------- PR: https://git.openjdk.org/jdk/pull/13859 From stefank at openjdk.org Mon May 8 14:29:47 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 8 May 2023 14:29:47 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v9] In-Reply-To: References: Message-ID: > Hi all, > > Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. > > The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention i s to give the users time to validate and deploy their workloads with the new GC implementation. > > Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clear to us how time consuming and complex things end up being when we tried to keep both the original G1 working, and at the same time implemented the ZGC-alike G1. Given this experience, we don't see that as a viable solution to deliver a maintainable and evolving Generational ZGC. Our pragmatic suggestion to these challenges is to let Generational ZGC live under the current gc/z directories and let the legacy, non-generational ZGC be completely separated in its own directories. This way we can continue to move quickly with the continued develop ment of Generational ZGC and let the non-generational ZGC be mostly untouched until it gets deprecated, and eventually removed. The non-generational ZGC directory will be gc/x and all the classes of non-generational have been prefixed with X instead of Z. An alternative to this rename could be to namespace out non-generational ZGC. We experimented with that, but it was too easy to accidentally cross-compile Generational ZGC code into non-generational ZGC, so we didn't like that approach. > > Most of the stand-alone cleanups and enhancements outside of the ZGC code have already been upstreamed to openjdk/jdk. There are still a few patches that could/should be pushed separately, but they will be easier to understand by also looking at the Generational ZGC code, so they will be sent out after this PR has been published. The patches that could be published separately are: > > * 59d1e96af6a UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class > * ca9edf8aa79 UPSTREAM: RISCV tmp reg cleanup resolve_jobject > * 4bec9c69b67 CLEANUP: barrierSetNMethod_aarch64.cpp > * b67d03a3f04 UPSTREAM: Add relaxed add&fetch for aarch64 atomics > * a2824734d23 UPSTREAM: lir_xchg > * 36cd39c0126 UPSTREAM: assembler_ppc CMPLI > * 447259cea42 UPSTREAM: assembler_ppc ANDI > * 9417323499a UPSTREAM: Add VMErrorCallback infrastructure > > Regarding all the changesets you see in this PR, they form the history of the development of Generational ZGC. It might look a bit unconventional to what you are used to see in openjdk development. What we have done is to use merges with the 'ours' strategy to ignore the previous Generational ZGC patches, and then rebased and flattened the changes on top of the merge. This effectively gives us the upsides of having a rebased repository and the upsides of retaining the history in the repository. The downside could be that GitHub now lists all those changesets in the PR. Given that this patch is so big, and that you likely only want to see a part of it, I suggest that you pull down the PR branch and then compare it to the openjdk/jdk changeset this PR is based against: > > > git fetch https://github.com/openjdk/zgc zgc_master > git diff zgc_master... > > > There have been many contributors of this patch over the years. I'll do my best to poke Skara into listing you all, but if you see that I've missed your name please reach out to me and I'll fix it. > > Testing: we have been continuously running Generational ZGC through Oracle's tier1-8 testing. Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 923 commits: - ZGC: Generational Co-authored-by: Stefan Karlsson Co-authored-by: Per Liden Co-authored-by: Albert Mingkun Yang Co-authored-by: Erik ?sterlund Co-authored-by: Axel Boldt-Christmas Co-authored-by: Stefan Johansson - UPSTREAM: RISCV tmp reg cleanup resolve_jobject - CLEANUP: barrierSetNMethod_aarch64.cpp - UPSTREAM: assembler_ppc CMPLI Co-authored-by: TheRealMDoerr - UPSTREAM: assembler_ppc ANDI Co-authored-by: TheRealMDoerr - Merge branch 'zgc_generational' into zgc_generational_rebase_target - ZGC: Generational Co-authored-by: Stefan Karlsson Co-authored-by: Per Liden Co-authored-by: Albert Mingkun Yang Co-authored-by: Erik ?sterlund Co-authored-by: Axel Boldt-Christmas Co-authored-by: Stefan Johansson - UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class - UPSTREAM: RISCV tmp reg cleanup resolve_jobject - CLEANUP: barrierSetNMethod_aarch64.cpp - ... and 913 more: https://git.openjdk.org/jdk/compare/5c7ede94...34312e0c ------------- Changes: https://git.openjdk.org/jdk/pull/13771/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13771&range=08 Stats: 67315 lines in 682 files changed: 58157 ins; 4252 del; 4906 mod Patch: https://git.openjdk.org/jdk/pull/13771.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13771/head:pull/13771 PR: https://git.openjdk.org/jdk/pull/13771 From stefank at openjdk.org Mon May 8 14:32:34 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 8 May 2023 14:32:34 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v9] In-Reply-To: References: Message-ID: > Hi all, > > Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. > > The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention i s to give the users time to validate and deploy their workloads with the new GC implementation. > > Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clear to us how time consuming and complex things end up being when we tried to keep both the original G1 working, and at the same time implemented the ZGC-alike G1. Given this experience, we don't see that as a viable solution to deliver a maintainable and evolving Generational ZGC. Our pragmatic suggestion to these challenges is to let Generational ZGC live under the current gc/z directories and let the legacy, non-generational ZGC be completely separated in its own directories. This way we can continue to move quickly with the continued develop ment of Generational ZGC and let the non-generational ZGC be mostly untouched until it gets deprecated, and eventually removed. The non-generational ZGC directory will be gc/x and all the classes of non-generational have been prefixed with X instead of Z. An alternative to this rename could be to namespace out non-generational ZGC. We experimented with that, but it was too easy to accidentally cross-compile Generational ZGC code into non-generational ZGC, so we didn't like that approach. > > Most of the stand-alone cleanups and enhancements outside of the ZGC code have already been upstreamed to openjdk/jdk. There are still a few patches that could/should be pushed separately, but they will be easier to understand by also looking at the Generational ZGC code, so they will be sent out after this PR has been published. The patches that could be published separately are: > > * 59d1e96af6a UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class > * ca9edf8aa79 UPSTREAM: RISCV tmp reg cleanup resolve_jobject > * 4bec9c69b67 CLEANUP: barrierSetNMethod_aarch64.cpp > * b67d03a3f04 UPSTREAM: Add relaxed add&fetch for aarch64 atomics > * a2824734d23 UPSTREAM: lir_xchg > * 36cd39c0126 UPSTREAM: assembler_ppc CMPLI > * 447259cea42 UPSTREAM: assembler_ppc ANDI > * 9417323499a UPSTREAM: Add VMErrorCallback infrastructure > > Regarding all the changesets you see in this PR, they form the history of the development of Generational ZGC. It might look a bit unconventional to what you are used to see in openjdk development. What we have done is to use merges with the 'ours' strategy to ignore the previous Generational ZGC patches, and then rebased and flattened the changes on top of the merge. This effectively gives us the upsides of having a rebased repository and the upsides of retaining the history in the repository. The downside could be that GitHub now lists all those changesets in the PR. Given that this patch is so big, and that you likely only want to see a part of it, I suggest that you pull down the PR branch and then compare it to the openjdk/jdk changeset this PR is based against: > > > git fetch https://github.com/openjdk/zgc zgc_master > git diff zgc_master... > > > There have been many contributors of this patch over the years. I'll do my best to poke Skara into listing you all, but if you see that I've missed your name please reach out to me and I'll fix it. > > Testing: we have been continuously running Generational ZGC through Oracle's tier1-8 testing. Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 923 commits: - ZGC: Generational Co-authored-by: Stefan Karlsson Co-authored-by: Per Liden Co-authored-by: Albert Mingkun Yang Co-authored-by: Erik ?sterlund Co-authored-by: Axel Boldt-Christmas Co-authored-by: Stefan Johansson - UPSTREAM: RISCV tmp reg cleanup resolve_jobject - CLEANUP: barrierSetNMethod_aarch64.cpp - UPSTREAM: assembler_ppc CMPLI Co-authored-by: TheRealMDoerr - UPSTREAM: assembler_ppc ANDI Co-authored-by: TheRealMDoerr - Merge branch 'zgc_generational' into zgc_generational_rebase_target - ZGC: Generational Co-authored-by: Stefan Karlsson Co-authored-by: Per Liden Co-authored-by: Albert Mingkun Yang Co-authored-by: Erik ?sterlund Co-authored-by: Axel Boldt-Christmas Co-authored-by: Stefan Johansson - UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class - UPSTREAM: RISCV tmp reg cleanup resolve_jobject - CLEANUP: barrierSetNMethod_aarch64.cpp - ... and 913 more: https://git.openjdk.org/jdk/compare/5c7ede94...34312e0c ------------- Changes: https://git.openjdk.org/jdk/pull/13771/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13771&range=08 Stats: 67315 lines in 682 files changed: 58157 ins; 4252 del; 4906 mod Patch: https://git.openjdk.org/jdk/pull/13771.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13771/head:pull/13771 PR: https://git.openjdk.org/jdk/pull/13771 From tsteele at openjdk.org Mon May 8 14:35:45 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Mon, 8 May 2023 14:35:45 GMT Subject: RFR: 8304434: [AIX] Update minimum xlclang version [v3] In-Reply-To: References: Message-ID: > Minor changes to the build system to recognize and warn that an incompatible toolchain is detected. Tyler Steele has updated the pull request incrementally with two additional commits since the last revision: - Trivial II - Trivial I ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13086/files - new: https://git.openjdk.org/jdk/pull/13086/files/030f2283..d5ed186a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13086&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13086&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13086.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13086/head:pull/13086 PR: https://git.openjdk.org/jdk/pull/13086 From tsteele at openjdk.org Mon May 8 14:35:46 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Mon, 8 May 2023 14:35:46 GMT Subject: Integrated: 8304434: [AIX] Update minimum xlclang version In-Reply-To: References: Message-ID: <6U6jO3YCHkkeLpDT1f3my_7XqhZzfYVzYtAVhfN0XcQ=.5101d355-e192-488f-a9ad-757860e51b5e@github.com> On Fri, 17 Mar 2023 22:36:24 GMT, Tyler Steele wrote: > Minor changes to the build system to recognize and warn that an incompatible toolchain is detected. This pull request has now been integrated. Changeset: 9f34e4f8 Author: Tyler Steele URL: https://git.openjdk.org/jdk/commit/9f34e4f8d9144751b63243713e4d9247c21d64cd Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8304434: [AIX] Update minimum xlclang version Reviewed-by: erikj, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/13086 From jvernee at openjdk.org Mon May 8 15:27:28 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 8 May 2023 15:27:28 GMT Subject: RFR: 8307527: MacOS Zero builds fail with undefined FFI_GO_CLOSURES after JDK-8304265 In-Reply-To: References: Message-ID: On Mon, 8 May 2023 10:31:20 GMT, Aleksey Shipilev wrote: >> After thinking a bit, I think I'd prefer this to be addressed in the build system instead. e.g. something like: >> >> >> diff --git a/make/autoconf/lib-ffi.m4 b/make/autoconf/lib-ffi.m4 >> index 0905c3cd225..83de5a4abf7 100644 >> --- a/make/autoconf/lib-ffi.m4 >> +++ b/make/autoconf/lib-ffi.m4 >> @@ -106,6 +106,13 @@ AC_DEFUN_ONCE([LIB_SETUP_LIBFFI], >> AC_MSG_ERROR([Could not find libffi! $HELP_MSG]) >> fi >> >> + if test "x${OPENJDK_TARGET_CPU}" = "xaarch64" && test "x${OPENJDK_TARGET_OS}" = xmacosx; then >> + # ffi.h checks '#if FFI_GO_CLOSURES' which throws a warning in xcode on aarch64 because the aarch64 >> + # ffitarget.h (included from ffi.h) doesn't explicitly define FFI_GO_CLOSURES (like it does on e.g. x64). >> + # define it explicitly here to avoid compilation errors >> + LIBFFI_CFLAGS="$LIBFFI_CFLAGS -DFFI_GO_CLOSURES=0" >> + fi >> + >> AC_MSG_CHECKING([if libffi works]) >> AC_LANG_PUSH(C) >> OLD_CFLAGS="$CFLAGS" >> >> >> And then remove the workaround from the source code. (`LIBFFI_CFLAGS` is used to build both relevant libraries, and should also be used when a new library is added that needs libffi. So this would avoid a repeat of this issue) >> >> Either way, let's thoroughly document the issue this time around, so future editors won't have to guess why this is needed. > >> And then remove the workaround from the source code. (`LIBFFI_CFLAGS` is used to build both relevant libraries, and should also be used when a new library is added that needs libffi. So this would avoid a repeat of this issue) > > Yes, I added a variant of that fix that explicitly checks for `FFI_GO_CLOSURES` definition during configure. (Now I have to find a system which actually supports recent FFI to test it... @shipilev Ran this through our CI again, but it's failing there (`linux-x64-zero` and `linux-aarch64-zero`). It seems like the check in the configuration is erroneously failing (`checking for FFI_GO_CLOSURES definition... no, defining`) and then the compilation of hotspot fails because `FFI_GO_CLOSURES` is already defined, when `ffitarget.h` tries to define it again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13827#issuecomment-1538564604 From liangchenblue at gmail.com Mon May 8 17:42:09 2023 From: liangchenblue at gmail.com (-) Date: Mon, 8 May 2023 12:42:09 -0500 Subject: WSL building performance and questions In-Reply-To: <82c742ef-e4a8-30ff-f073-974aec1de81a@oracle.com> References: <82c742ef-e4a8-30ff-f073-974aec1de81a@oracle.com> Message-ID: Thank you for your quick response! I just took a few hours and successfully set up and built from WSL 1. It indeed is even faster than cygwin. Meanwhile, it's fascinating that the relative directory problem doesn't exist on WSL 1, that passing build/jmh/jars allows configure to locate JMH just fine. Since WSL 1 and WSL 2 have such dramatic differences, should we briefly mention in building documentation that building with WSL should be primarily done with WSL 1, given now the default WSL installed from Microsoft Store only supports WSL 2? Gratefully, Chen Liang On Mon, May 8, 2023 at 8:36?AM wrote: > > Hello Chen, > > On 5/5/23 22:42, - wrote: > > Hello, > > While I was trying to diagnose the problem that JMH benchmarks can't > > be run on a fresh cygwin or WSL environment, > > https://bugs.openjdk.org/browse/JDK-8305669 I found myself troubled > > with path issues and slow building speed with a Windows target. > > Meanwhile the linux target is totally fine. > > > > 1. When I pass --with-jmh=build/jmh/jars in WSL configuration, it > > always fails to find the relative directories (not present on linux > > configuration). C:\\...\\jdk\\build\\jmh\\jars doesn't work. Only > > /mnt/c/.../jdk/build/jmh/jars work. Is this a bug? > I would say it's a bug. > > > > 2. My Windows WSL build is extremely slow. My windows target has > > almost stalled that it stuck on creating benchmark jar without even > > progressing to indify. And it seems WSL (Ubuntu) itself is only using > > 400MB of RAM with almost no CPU usage. However, these problems don't > > happen for my Linux target builds; meanwhile my cygwin builds are > > blazingly fast. What could be the cause of this slowness? > > > Are you running WSL 1 or 2? From what I've heard, WSL 2 doesn't work > well when having to interact with native Windows tools (which the > windows build has to do). Most reports I've heard about WSL 1 say it's > slightly faster than Cygwin, but different people and different > environments have different results. > > /Erik > > From erik.joelsson at oracle.com Mon May 8 17:57:03 2023 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 8 May 2023 10:57:03 -0700 Subject: [External] : Re: WSL building performance and questions In-Reply-To: References: <82c742ef-e4a8-30ff-f073-974aec1de81a@oracle.com> Message-ID: On 5/8/23 10:42, - wrote: > Thank you for your quick response! > I just took a few hours and successfully set up and built from WSL 1. > It indeed is even faster than cygwin. > Meanwhile, it's fascinating that the relative directory problem > doesn't exist on WSL 1, that passing build/jmh/jars allows configure > to locate JMH just fine. > > Since WSL 1 and WSL 2 have such dramatic differences, should we > briefly mention in building documentation that building with WSL > should be primarily done with WSL 1, given now the default WSL > installed from Microsoft Store only supports WSL 2? I assumed the documentation had been updated to reflect that already back when the problems with WSL 2 were discovered, but looking now, there is nothing there. I suppose WSL 1 was still default at that time. Yes, I think we should update the documentation, especially if the default has changed to WSL 2. /Erik > Gratefully, > Chen Liang > > On Mon, May 8, 2023 at 8:36?AM wrote: >> Hello Chen, >> >> On 5/5/23 22:42, - wrote: >>> Hello, >>> While I was trying to diagnose the problem that JMH benchmarks can't >>> be run on a fresh cygwin or WSL environment, >>> https://bugs.openjdk.org/browse/JDK-8305669 I found myself troubled >>> with path issues and slow building speed with a Windows target. >>> Meanwhile the linux target is totally fine. >>> >>> 1. When I pass --with-jmh=build/jmh/jars in WSL configuration, it >>> always fails to find the relative directories (not present on linux >>> configuration). C:\\...\\jdk\\build\\jmh\\jars doesn't work. Only >>> /mnt/c/.../jdk/build/jmh/jars work. Is this a bug? >> I would say it's a bug. >>> 2. My Windows WSL build is extremely slow. My windows target has >>> almost stalled that it stuck on creating benchmark jar without even >>> progressing to indify. And it seems WSL (Ubuntu) itself is only using >>> 400MB of RAM with almost no CPU usage. However, these problems don't >>> happen for my Linux target builds; meanwhile my cygwin builds are >>> blazingly fast. What could be the cause of this slowness? >>> >> Are you running WSL 1 or 2? From what I've heard, WSL 2 doesn't work >> well when having to interact with native Windows tools (which the >> windows build has to do). Most reports I've heard about WSL 1 say it's >> slightly faster than Cygwin, but different people and different >> environments have different results. >> >> /Erik >> >> From serb at openjdk.org Mon May 8 18:45:22 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 8 May 2023 18:45:22 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots In-Reply-To: References: Message-ID: On Fri, 5 May 2023 14:58:15 GMT, Alexander Zvegintsev wrote: > It seems that the current robot API is not suitable for this. Can we just reset the token when we create a new instance of Robot? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1538859204 From jiangli at openjdk.org Mon May 8 19:48:23 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 8 May 2023 19:48:23 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v7] In-Reply-To: <2BVvV9m8bI-UzZXpX1GEPwoStZ6pHZBn4JuAMRQk978=.54246fe4-57b8-4372-bfc4-6b63823fa9a2@github.com> References: <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com> <2BVvV9m8bI-UzZXpX1GEPwoStZ6pHZBn4JuAMRQk978=.54246fe4-57b8-4372-bfc4-6b63823fa9a2@github.com> Message-ID: On Mon, 8 May 2023 08:57:37 GMT, Severin Gehwolf wrote: > > All of that said, I think we can get away with a smaller subset of targets and deliverables. AFAIK, graal needs the combined `graal-builder-image` as input to their build anyway, so they should not have any dependency on what the target `static-libs-image` produces. Given that I propose the following behavior: > > `make static-libs-image` produces `images/static-libs` with all .a (including libjvm.a). `make static-libs-graal-image` produces `images/static-libs-graal` with all .a except libjvm.a. `make graal-builder-image` produces `images/graal-builder-image` like today, but depends on and uses `static-libs-graal-image` instead of `static-libs-image`. `make static-libs-bundles` depends on and uses `static-libs-image` like today, so will contain libjvm.a, which is new behavior. > > Sure, that should work too as long as there is a way to a) build the static libs only needed for graal some way b) keep `graal-builder-image` working as it does today. FWIW, we use `a)` at adoptium so as to be able to have a combination to build mandrel from. Not all users will want to have JDK + static libs so only the ones needing them should need to download them. Thanks @erikj79 @jerboaa. We can go with what @erikj79 suggested then. I'll revise the PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1538945606 From liach at openjdk.org Mon May 8 20:05:50 2023 From: liach at openjdk.org (Chen Liang) Date: Mon, 8 May 2023 20:05:50 GMT Subject: RFR: 8305669: RuntimeException when running benchmarks through make on Windows/WSL [v2] In-Reply-To: References: Message-ID: > This patch replaces `FIXPATH` with `FixPath` on individual path argumenets. The root cause might be that JMH requires passing VM args to benchmarks in quotes, which might have triggered incorrect detections in `FIXPATH` (as in comparison, `$1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED` right above this patch seems to work fine) > Also removed a useless and wrong Java flag to the java running javac, originally intended to enable running `make test TEST="loom.obsolete"` benchmarks. > > Since I only have a windows cygwin environment, I am not quite sure if this works elsewhere. Chen Liang 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 six additional commits since the last revision: - Comment about the fix logic We have a mix and match of spaces and tabs, might need to fix it later - Is this the right way instead? - space fails linux - Expose fixpath import and let jmh run use it - Merge branch 'master' into jmh-windows - 8305669: RuntimeException when running benchmarks through make on Windows/WSL ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13550/files - new: https://git.openjdk.org/jdk/pull/13550/files/11df4e9c..0866ee3c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13550&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13550&range=00-01 Stats: 80515 lines in 1424 files changed: 55854 ins; 14773 del; 9888 mod Patch: https://git.openjdk.org/jdk/pull/13550.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13550/head:pull/13550 PR: https://git.openjdk.org/jdk/pull/13550 From liach at openjdk.org Mon May 8 20:05:51 2023 From: liach at openjdk.org (Chen Liang) Date: Mon, 8 May 2023 20:05:51 GMT Subject: RFR: 8305669: RuntimeException when running benchmarks through make on Windows/WSL In-Reply-To: References: Message-ID: <9-ker50WXopb3KQzl3gvkESWCHOg0GYagdVZC6eGZFY=.03777287-a4c8-4acf-ad7b-074aab8694f7@github.com> On Thu, 20 Apr 2023 02:32:37 GMT, Chen Liang wrote: > This patch replaces `FIXPATH` with `FixPath` on individual path argumenets. The root cause might be that JMH requires passing VM args to benchmarks in quotes, which might have triggered incorrect detections in `FIXPATH` (as in comparison, `$1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED` right above this patch seems to work fine) > Also removed a useless and wrong Java flag to the java running javac, originally intended to enable running `make test TEST="loom.obsolete"` benchmarks. > > Since I only have a windows cygwin environment, I am not quite sure if this works elsewhere. Since I have WSL setup [fixed](https://mail.openjdk.org/pipermail/build-dev/2023-May/039249.html), I have tested this patch in cygwin, wsl 1, and a linux target wsl 2 environments. All three runs normally. This patch is indeed ugly, but I don't think we have reliable ways to tell FixPath to only consider a space part of a Windows directory name when it's quoted, especially quotes can be further complicated by escapes. Thus I just did the simple, by exporting the needed functionalities and replace the needed parts for jmh invocation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13550#issuecomment-1538964852 From erikj at openjdk.org Mon May 8 20:22:27 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 8 May 2023 20:22:27 GMT Subject: RFR: 8305669: RuntimeException when running benchmarks through make on Windows/WSL [v2] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 20:05:50 GMT, Chen Liang wrote: >> This patch replaces `FIXPATH` with `FixPath` on individual path argumenets. The root cause might be that JMH requires passing VM args to benchmarks in quotes, which might have triggered incorrect detections in `FIXPATH` (as in comparison, `$1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED` right above this patch seems to work fine) >> Also removed a useless and wrong Java flag to the java running javac, originally intended to enable running `make test TEST="loom.obsolete"` benchmarks. >> >> Since I only have a windows cygwin environment, I am not quite sure if this works elsewhere. > > Chen Liang 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 six additional commits since the last revision: > > - Comment about the fix logic > We have a mix and match of spaces and tabs, might need to fix it later > - Is this the right way instead? > - space fails linux > - Expose fixpath import and let jmh run use it > - Merge branch 'master' into jmh-windows > - 8305669: RuntimeException when running benchmarks through make on Windows/WSL Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13550#pullrequestreview-1417456269 From jiangli at openjdk.org Mon May 8 21:00:24 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 8 May 2023 21:00:24 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v7] In-Reply-To: References: <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com> Message-ID: <0wRYu-_MAO2LH1Xgl-icgILa9rL6PnDEsZv4sjCpY6c=.54e81c63-ccd8-43ad-88cf-e16ba0452cdd@github.com> On Fri, 5 May 2023 20:43:41 GMT, Erik Joelsson wrote: > Further I would like to suggest that libjvm.a gets put in the variant subdir under lib, just like libjvm.so does today (e.g. `lib/server/libjvm.a`). That way you can support building libjvm.a for all variants without worry. It will also get libjvm.a out of the way to cause less trouble for a graal build that uses the static-libs-bundles as input. This goes against what I suggested before, to just use `JVM_VARIANT_MAIN`, but I think this makes for a cleaner long term solution given the goals of the hermetic java effort. There are some complications related to `jvm.cfg` and `libjvm.so` path runtime handling for JVM variants support, with the JDK traditional/dynamic build. With JDK static support, the usage of `libjvm` is fully determined at build time, runtime can avoid the complications and associated overhead with accessing `jvm.cfg` and determining `libjvm` path. At the final static image build time users need to know the sub-directory containing `libjvm.a`, if we go with the suggestion. That adds a small complication. However, from broader point of view there are probably more benefits to do so. I'll change the PR, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1539037862 From fyang at openjdk.org Tue May 9 00:54:43 2023 From: fyang at openjdk.org (Fei Yang) Date: Tue, 9 May 2023 00:54:43 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v6] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 12:47:51 GMT, Stefan Karlsson wrote: > That's unfortunate. Could you try this patch, which probes the address range to see if it can reserve the memory somewhere else within `[ZAddressHeapBase, ZAddressHeapBase+ZAddressOffsetMax)`: https://github.com/stefank/jdk/tree/zgc_generational_review_test_zforwarding @stefank : Good news is that this gtest case can now pass on linux-riscv64 with this patch. I tried several times and it seems we could always reserve a space of ZGranuleSize(0x200000) bytes at address 0x852000000. Thanks for fixing this! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1188015373 From liach at openjdk.org Tue May 9 03:17:13 2023 From: liach at openjdk.org (Chen Liang) Date: Tue, 9 May 2023 03:17:13 GMT Subject: RFR: 8300204: Sealed-class hierarchy graph missing nodes Message-ID: Please review this simple patch that fixes the package determination for nested classes in the `@sealedGraph` taglet. Current JDK 21: https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/foreign/MemoryLayout.html https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/foreign/ValueLayout.html ![image](https://user-images.githubusercontent.com/7806504/236984282-f4361510-6208-4469-92d6-b9ce143204c3.png) This patch: https://cr.openjdk.org/~liach/8300204/java.base/java/lang/foreign/MemoryLayout.html https://cr.openjdk.org/~liach/8300204/java.base/java/lang/foreign/ValueLayout.html ![image](https://user-images.githubusercontent.com/7806504/236984331-a877a493-487a-444a-984c-9175393cbb92.png) ------------- Commit messages: - 8300204: Sealed-class hierarchy graph missing nodes Changes: https://git.openjdk.org/jdk/pull/13875/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13875&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300204 Stats: 9 lines in 1 file changed: 1 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/13875.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13875/head:pull/13875 PR: https://git.openjdk.org/jdk/pull/13875 From liach at openjdk.org Tue May 9 04:18:38 2023 From: liach at openjdk.org (Chen Liang) Date: Tue, 9 May 2023 04:18:38 GMT Subject: RFR: 8307652: sealed class hierarchy graph doesn't distinguish non-sealed classes Message-ID: `@sealedGraph` had a mechanism to render non-sealed classes differently, but it's useless because the graph nodes are not bordered. This patch converts the non-sealed classes to be rendered in italics instead. An example of `ConstantDesc`, which has a sealed hierarchy except `DynamicConstantDesc`: JDK 20: ![image](https://user-images.githubusercontent.com/7806504/236991678-e30c181a-cb1f-407a-b3e0-f648fe2df788.png) This patch: ![image](https://user-images.githubusercontent.com/7806504/236991592-affcb128-9721-45cf-860c-6292ee6a8bb6.png) ------------- Commit messages: - 8307652: sealed class hierarchy graph doesn't distinguish non-sealed classes Changes: https://git.openjdk.org/jdk/pull/13877/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13877&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307652 Stats: 30 lines in 1 file changed: 22 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13877.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13877/head:pull/13877 PR: https://git.openjdk.org/jdk/pull/13877 From stefank at openjdk.org Tue May 9 06:06:11 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 9 May 2023 06:06:11 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v10] In-Reply-To: References: Message-ID: > Hi all, > > Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. > > The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention i s to give the users time to validate and deploy their workloads with the new GC implementation. > > Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clear to us how time consuming and complex things end up being when we tried to keep both the original G1 working, and at the same time implemented the ZGC-alike G1. Given this experience, we don't see that as a viable solution to deliver a maintainable and evolving Generational ZGC. Our pragmatic suggestion to these challenges is to let Generational ZGC live under the current gc/z directories and let the legacy, non-generational ZGC be completely separated in its own directories. This way we can continue to move quickly with the continued develop ment of Generational ZGC and let the non-generational ZGC be mostly untouched until it gets deprecated, and eventually removed. The non-generational ZGC directory will be gc/x and all the classes of non-generational have been prefixed with X instead of Z. An alternative to this rename could be to namespace out non-generational ZGC. We experimented with that, but it was too easy to accidentally cross-compile Generational ZGC code into non-generational ZGC, so we didn't like that approach. > > Most of the stand-alone cleanups and enhancements outside of the ZGC code have already been upstreamed to openjdk/jdk. There are still a few patches that could/should be pushed separately, but they will be easier to understand by also looking at the Generational ZGC code, so they will be sent out after this PR has been published. The patches that could be published separately are: > > * 59d1e96af6a UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class > * ca9edf8aa79 UPSTREAM: RISCV tmp reg cleanup resolve_jobject > * 4bec9c69b67 CLEANUP: barrierSetNMethod_aarch64.cpp > * b67d03a3f04 UPSTREAM: Add relaxed add&fetch for aarch64 atomics > * a2824734d23 UPSTREAM: lir_xchg > * 36cd39c0126 UPSTREAM: assembler_ppc CMPLI > * 447259cea42 UPSTREAM: assembler_ppc ANDI > * 9417323499a UPSTREAM: Add VMErrorCallback infrastructure > > Regarding all the changesets you see in this PR, they form the history of the development of Generational ZGC. It might look a bit unconventional to what you are used to see in openjdk development. What we have done is to use merges with the 'ours' strategy to ignore the previous Generational ZGC patches, and then rebased and flattened the changes on top of the merge. This effectively gives us the upsides of having a rebased repository and the upsides of retaining the history in the repository. The downside could be that GitHub now lists all those changesets in the PR. Given that this patch is so big, and that you likely only want to see a part of it, I suggest that you pull down the PR branch and then compare it to the openjdk/jdk changeset this PR is based against: > > > git fetch https://github.com/openjdk/zgc zgc_master > git diff zgc_master... > > > There have been many contributors of this patch over the years. I'll do my best to poke Skara into listing you all, but if you see that I've missed your name please reach out to me and I'll fix it. > > Testing: we have been continuously running Generational ZGC through Oracle's tier1-8 testing. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Workaround failed reservation in ZForwardingTest ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13771/files - new: https://git.openjdk.org/jdk/pull/13771/files/34312e0c..de34a122 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13771&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13771&range=08-09 Stats: 48 lines in 1 file changed: 40 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/13771.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13771/head:pull/13771 PR: https://git.openjdk.org/jdk/pull/13771 From stefank at openjdk.org Tue May 9 06:06:13 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 9 May 2023 06:06:13 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v6] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 00:50:56 GMT, Fei Yang wrote: >> That's unfortunate. Could you try this patch, which probes the address range to see if it can reserve the memory somewhere else within `[ZAddressHeapBase, ZAddressHeapBase+ZAddressOffsetMax)`: >> https://github.com/stefank/jdk/tree/zgc_generational_review_test_zforwarding > >> That's unfortunate. Could you try this patch, which probes the address range to see if it can reserve the memory somewhere else within `[ZAddressHeapBase, ZAddressHeapBase+ZAddressOffsetMax)`: https://github.com/stefank/jdk/tree/zgc_generational_review_test_zforwarding > > @stefank : Good news is that this gtest case can now pass on linux-riscv64 with this patch. I tried several times and it seems we could always reserve a space of ZGranuleSize(0x200000) bytes at address 0x852000000. Thanks for fixing this! Thanks for helping out with this. I've now pushed the proposed patch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1188168418 From pminborg at openjdk.org Tue May 9 06:38:23 2023 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 9 May 2023 06:38:23 GMT Subject: RFR: 8300204: Sealed-class hierarchy graph missing nodes In-Reply-To: References: Message-ID: On Tue, 9 May 2023 03:11:10 GMT, Chen Liang wrote: > Please review this simple patch that fixes the package determination for nested classes in the `@sealedGraph` taglet. > > Current JDK 21: > https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/foreign/MemoryLayout.html > https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/foreign/ValueLayout.html > ![image](https://user-images.githubusercontent.com/7806504/236984282-f4361510-6208-4469-92d6-b9ce143204c3.png) > > This patch: > https://cr.openjdk.org/~liach/8300204/java.base/java/lang/foreign/MemoryLayout.html > https://cr.openjdk.org/~liach/8300204/java.base/java/lang/foreign/ValueLayout.html > ![image](https://user-images.githubusercontent.com/7806504/236984331-a877a493-487a-444a-984c-9175393cbb92.png) Looks good to me! Thanks for providing this patch. Unfortunately, I am not a reviewer so we have to get someone else to review it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13875#issuecomment-1539537777 From kbarrett at openjdk.org Tue May 9 08:48:43 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 9 May 2023 08:48:43 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v10] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 06:06:11 GMT, Stefan Karlsson wrote: >> Hi all, >> >> Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. >> >> The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention is to give the users time to validate and deploy their workloads with the new GC implementation. >> >> Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clear to us how time consuming and complex things end up being when we tried to keep both the original G1 working, and at the same time implemented the ZGC-alike G1. Given this experience, we don't see that as a viable solution to deliver a maintainable and evolving Generational ZGC. Our pragmatic suggestion to these challenges is to let Generational ZGC live under the current gc/z directories and let the legacy, non-generational ZGC be completely separated in its own directories. This way we can continue to move quickly with the continued develo pment of Generational ZGC and let the non-generational ZGC be mostly untouched until it gets deprecated, and eventually removed. The non-generational ZGC directory will be gc/x and all the classes of non-generational have been prefixed with X instead of Z. An alternative to this rename could be to namespace out non-generational ZGC. We experimented with that, but it was too easy to accidentally cross-compile Generational ZGC code into non-generational ZGC, so we didn't like that approach. >> >> Most of the stand-alone cleanups and enhancements outside of the ZGC code have already been upstreamed to openjdk/jdk. There are still a few patches that could/should be pushed separately, but they will be easier to understand by also looking at the Generational ZGC code, so they will be sent out after this PR has been published. The patches that could be published separately are: >> >> * 59d1e96af6a UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class >> * ca9edf8aa79 UPSTREAM: RISCV tmp reg cleanup resolve_jobject >> * 4bec9c69b67 CLEANUP: barrierSetNMethod_aarch64.cpp >> * b67d03a3f04 UPSTREAM: Add relaxed add&fetch for aarch64 atomics >> * a2824734d23 UPSTREAM: lir_xchg >> * 36cd39c0126 UPSTREAM: assembler_ppc CMPLI >> * 447259cea42 UPSTREAM: assembler_ppc ANDI >> * 9417323499a UPSTREAM: Add VMErrorCallback infrastructure >> >> Regarding all the changesets you see in this PR, they form the history of the development of Generational ZGC. It might look a bit unconventional to what you are used to see in openjdk development. What we have done is to use merges with the 'ours' strategy to ignore the previous Generational ZGC patches, and then rebased and flattened the changes on top of the merge. This effectively gives us the upsides of having a rebased repository and the upsides of retaining the history in the repository. The downside could be that GitHub now lists all those changesets in the PR. Given that this patch is so big, and that you likely only want to see a part of it, I suggest that you pull down the PR branch and then compare it to the openjdk/jdk changeset this PR is based against: >> >> >> git fetch https://github.com/openjdk/zgc zgc_master >> git diff zgc_master... >> >> >> There have been many contributors of this patch over the years. I'll do my best to poke Skara into listing you all, but if you see that I've missed your name please reach out to me and I'll fix it. >> >> Testing: we have been continuously running Generational ZGC through Oracle's tier1-8 testing. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Workaround failed reservation in ZForwardingTest src/hotspot/share/code/relocInfo.hpp line 1105: > 1103: int offset() override { ShouldNotReachHere(); return 0; } > 1104: address value() override { ShouldNotReachHere(); return nullptr; } > 1105: void set_value(address value) override { ShouldNotReachHere(); } Why is barrier_Relocation derived from DataRelocation? It seems to be overriding the entire virtual API associated with DataRelocation with ShouldNotReachHere implementations? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1188241722 From eosterlund at openjdk.org Tue May 9 09:52:38 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 9 May 2023 09:52:38 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v10] In-Reply-To: References: Message-ID: <3bqD7LsrwaorrF0Jyk3NdJJH1h4XCjthQnuC6z9Uv7c=.a3e98d86-3cbb-4802-9b1d-14c29711ab6f@github.com> On Tue, 9 May 2023 07:27:46 GMT, Kim Barrett wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Workaround failed reservation in ZForwardingTest > > src/hotspot/share/code/relocInfo.hpp line 1105: > >> 1103: int offset() override { ShouldNotReachHere(); return 0; } >> 1104: address value() override { ShouldNotReachHere(); return nullptr; } >> 1105: void set_value(address value) override { ShouldNotReachHere(); } > > Why is barrier_Relocation derived from DataRelocation? It seems to be overriding the entire virtual > API associated with DataRelocation with ShouldNotReachHere implementations? That is a good question. I think we used to use Relocation:: pd_address_in_code, which on x86 asserts that it has to be a DataRelocation. But it seems like we are not using that any more and it just looks weird. I will remove this and inherit from Relocation instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13771#discussion_r1188403500 From jbechberger at openjdk.org Tue May 9 10:47:33 2023 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Tue, 9 May 2023 10:47:33 GMT Subject: RFR: 8307732: build-test-lib is broken Message-ID: Fixes the issue by adding `--add-exports` for the required modules and making the `HttpHeaderParser` final (fixing an issue with calling overridable methods in a constructor). ------------- Commit messages: - Fix make build-test-lib Changes: https://git.openjdk.org/jdk/pull/13885/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13885&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307732 Stats: 9 lines in 2 files changed: 6 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13885.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13885/head:pull/13885 PR: https://git.openjdk.org/jdk/pull/13885 From djelinski at openjdk.org Tue May 9 11:48:22 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 9 May 2023 11:48:22 GMT Subject: RFR: 8307732: build-test-lib is broken In-Reply-To: References: Message-ID: On Tue, 9 May 2023 10:38:54 GMT, Johannes Bechberger wrote: > Fixes the issue by adding `--add-exports` for the required modules and making the `HttpHeaderParser` final (fixing an issue with calling overridable methods in a constructor). That's interesting. How did you find this? Is the result of this target used anywhere? As far as I could tell, the `build-test-lib` target itself is not used anywhere. The classes that fail to compile here are used by tests without any problems - each test specifies the necessary imports individually. Should we remove this make target instead? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13885#issuecomment-1540007948 From jbechberger at openjdk.org Tue May 9 11:55:22 2023 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Tue, 9 May 2023 11:55:22 GMT Subject: RFR: 8307732: build-test-lib is broken In-Reply-To: References: Message-ID: On Tue, 9 May 2023 10:38:54 GMT, Johannes Bechberger wrote: > Fixes the issue by adding `--add-exports` for the required modules and making the `HttpHeaderParser` final (fixing an issue with calling overridable methods in a constructor). Well, I wanted to use the WhiteBox testing API for my ASGST related tests (see https://github.com/parttimenerd/trace_tester) and found in the wiki https://wiki.openjdk.org/display/HotSpot/The+WhiteBox+testing+API, but the build instructions didn't work for me, so I fixed them. I need the WhiteBox API methods to ensure that a specific method is compiled, inlined, ..., when testing whether my API implementation gets it correct. The tests will later be partially included in the JTREG tests, but the external project makes prototyping easier. > Should we remove this make target instead? No, this would make writing extensive tests harder. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13885#issuecomment-1540010987 From stefank at openjdk.org Tue May 9 12:44:13 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 9 May 2023 12:44:13 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v11] In-Reply-To: References: Message-ID: > Hi all, > > Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. > > The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention i s to give the users time to validate and deploy their workloads with the new GC implementation. > > Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clear to us how time consuming and complex things end up being when we tried to keep both the original G1 working, and at the same time implemented the ZGC-alike G1. Given this experience, we don't see that as a viable solution to deliver a maintainable and evolving Generational ZGC. Our pragmatic suggestion to these challenges is to let Generational ZGC live under the current gc/z directories and let the legacy, non-generational ZGC be completely separated in its own directories. This way we can continue to move quickly with the continued develop ment of Generational ZGC and let the non-generational ZGC be mostly untouched until it gets deprecated, and eventually removed. The non-generational ZGC directory will be gc/x and all the classes of non-generational have been prefixed with X instead of Z. An alternative to this rename could be to namespace out non-generational ZGC. We experimented with that, but it was too easy to accidentally cross-compile Generational ZGC code into non-generational ZGC, so we didn't like that approach. > > Most of the stand-alone cleanups and enhancements outside of the ZGC code have already been upstreamed to openjdk/jdk. There are still a few patches that could/should be pushed separately, but they will be easier to understand by also looking at the Generational ZGC code, so they will be sent out after this PR has been published. The patches that could be published separately are: > > * 59d1e96af6a UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class > * ca9edf8aa79 UPSTREAM: RISCV tmp reg cleanup resolve_jobject > * 4bec9c69b67 CLEANUP: barrierSetNMethod_aarch64.cpp > * b67d03a3f04 UPSTREAM: Add relaxed add&fetch for aarch64 atomics > * a2824734d23 UPSTREAM: lir_xchg > * 36cd39c0126 UPSTREAM: assembler_ppc CMPLI > * 447259cea42 UPSTREAM: assembler_ppc ANDI > * 9417323499a UPSTREAM: Add VMErrorCallback infrastructure > > Regarding all the changesets you see in this PR, they form the history of the development of Generational ZGC. It might look a bit unconventional to what you are used to see in openjdk development. What we have done is to use merges with the 'ours' strategy to ignore the previous Generational ZGC patches, and then rebased and flattened the changes on top of the merge. This effectively gives us the upsides of having a rebased repository and the upsides of retaining the history in the repository. The downside could be that GitHub now lists all those changesets in the PR. Given that this patch is so big, and that you likely only want to see a part of it, I suggest that you pull down the PR branch and then compare it to the openjdk/jdk changeset this PR is based against: > > > git fetch https://github.com/openjdk/zgc zgc_master > git diff zgc_master... > > > There have been many contributors of this patch over the years. I'll do my best to poke Skara into listing you all, but if you see that I've missed your name please reach out to me and I'll fix it. > > Testing: we have been continuously running Generational ZGC through Oracle's tier1-8 testing. Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 930 commits: - ZGC: Generational Co-authored-by: Stefan Karlsson Co-authored-by: Per Liden Co-authored-by: Albert Mingkun Yang Co-authored-by: Erik ?sterlund Co-authored-by: Axel Boldt-Christmas Co-authored-by: Stefan Johansson - UPSTREAM: RISCV tmp reg cleanup resolve_jobject - CLEANUP: barrierSetNMethod_aarch64.cpp - UPSTREAM: assembler_ppc CMPLI Co-authored-by: TheRealMDoerr - UPSTREAM: assembler_ppc ANDI Co-authored-by: TheRealMDoerr - Merge branch 'zgc_generational' into zgc_generational_rebase_target - Workaround failed reservation in ZForwardingTest - ZGC: Generational Co-authored-by: Stefan Karlsson Co-authored-by: Per Liden Co-authored-by: Albert Mingkun Yang Co-authored-by: Erik ?sterlund Co-authored-by: Axel Boldt-Christmas Co-authored-by: Stefan Johansson - UPSTREAM: RISCV tmp reg cleanup resolve_jobject - CLEANUP: barrierSetNMethod_aarch64.cpp - ... and 920 more: https://git.openjdk.org/jdk/compare/07f55c5e...217c648d ------------- Changes: https://git.openjdk.org/jdk/pull/13771/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13771&range=10 Stats: 67364 lines in 684 files changed: 58197 ins; 4252 del; 4915 mod Patch: https://git.openjdk.org/jdk/pull/13771.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13771/head:pull/13771 PR: https://git.openjdk.org/jdk/pull/13771 From erikj at openjdk.org Tue May 9 12:44:30 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 9 May 2023 12:44:30 GMT Subject: RFR: 8307732: build-test-lib is broken In-Reply-To: References: Message-ID: On Tue, 9 May 2023 10:38:54 GMT, Johannes Bechberger wrote: > Fixes the issue by adding `--add-exports` for the required modules and making the `HttpHeaderParser` final (fixing an issue with calling overridable methods in a constructor). Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13885#pullrequestreview-1418536278 From stefank at openjdk.org Tue May 9 12:55:42 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 9 May 2023 12:55:42 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v12] In-Reply-To: References: Message-ID: > Hi all, > > Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. > > The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention i s to give the users time to validate and deploy their workloads with the new GC implementation. > > Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clear to us how time consuming and complex things end up being when we tried to keep both the original G1 working, and at the same time implemented the ZGC-alike G1. Given this experience, we don't see that as a viable solution to deliver a maintainable and evolving Generational ZGC. Our pragmatic suggestion to these challenges is to let Generational ZGC live under the current gc/z directories and let the legacy, non-generational ZGC be completely separated in its own directories. This way we can continue to move quickly with the continued develop ment of Generational ZGC and let the non-generational ZGC be mostly untouched until it gets deprecated, and eventually removed. The non-generational ZGC directory will be gc/x and all the classes of non-generational have been prefixed with X instead of Z. An alternative to this rename could be to namespace out non-generational ZGC. We experimented with that, but it was too easy to accidentally cross-compile Generational ZGC code into non-generational ZGC, so we didn't like that approach. > > Most of the stand-alone cleanups and enhancements outside of the ZGC code have already been upstreamed to openjdk/jdk. There are still a few patches that could/should be pushed separately, but they will be easier to understand by also looking at the Generational ZGC code, so they will be sent out after this PR has been published. The patches that could be published separately are: > > * 59d1e96af6a UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class > * ca9edf8aa79 UPSTREAM: RISCV tmp reg cleanup resolve_jobject > * 4bec9c69b67 CLEANUP: barrierSetNMethod_aarch64.cpp > * b67d03a3f04 UPSTREAM: Add relaxed add&fetch for aarch64 atomics > * a2824734d23 UPSTREAM: lir_xchg > * 36cd39c0126 UPSTREAM: assembler_ppc CMPLI > * 447259cea42 UPSTREAM: assembler_ppc ANDI > * 9417323499a UPSTREAM: Add VMErrorCallback infrastructure > > Regarding all the changesets you see in this PR, they form the history of the development of Generational ZGC. It might look a bit unconventional to what you are used to see in openjdk development. What we have done is to use merges with the 'ours' strategy to ignore the previous Generational ZGC patches, and then rebased and flattened the changes on top of the merge. This effectively gives us the upsides of having a rebased repository and the upsides of retaining the history in the repository. The downside could be that GitHub now lists all those changesets in the PR. Given that this patch is so big, and that you likely only want to see a part of it, I suggest that you pull down the PR branch and then compare it to the openjdk/jdk changeset this PR is based against: > > > git fetch https://github.com/openjdk/zgc zgc_master > git diff zgc_master... > > > There have been many contributors of this patch over the years. I'll do my best to poke Skara into listing you all, but if you see that I've missed your name please reach out to me and I'll fix it. > > Testing: we have been continuously running Generational ZGC through Oracle's tier1-8 testing. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Make barrier_Relocation inherit from Relocation instead of DataRelocation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13771/files - new: https://git.openjdk.org/jdk/pull/13771/files/217c648d..0fccc81b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13771&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13771&range=10-11 Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13771.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13771/head:pull/13771 PR: https://git.openjdk.org/jdk/pull/13771 From djelinski at openjdk.org Tue May 9 13:29:24 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 9 May 2023 13:29:24 GMT Subject: RFR: 8307732: build-test-lib is broken In-Reply-To: References: Message-ID: <96PPtoUC3C26Ox6ABVtF9S64fZYi0HFRcHI8o_L4iAs=.950cfee3-ddb5-41ef-b2ca-6802c731a8a5@github.com> On Tue, 9 May 2023 10:38:54 GMT, Johannes Bechberger wrote: > Fixes the issue by adding `--add-exports` for the required modules and making the `HttpHeaderParser` final (fixing an issue with calling overridable methods in a constructor). Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13885#pullrequestreview-1418633035 From azvegint at openjdk.org Tue May 9 14:40:18 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 9 May 2023 14:40:18 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots In-Reply-To: References: Message-ID: On Mon, 8 May 2023 18:41:56 GMT, Sergey Bylokhov wrote: > > It seems that the current robot API is not suitable for this. > > Can we just reset the token when we create a new instance of Robot? This will be a big problem for automated testing, as each test with the robot will require user confirmation(or even more than one, as some tests instantiate it several times). This is exactly what we are trying to avoid. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1540255849 From stefank at openjdk.org Tue May 9 15:32:38 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 9 May 2023 15:32:38 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v12] In-Reply-To: References: Message-ID: <48C_1iKnxNHpS_EqySRFI91zVoFag-tBJ5Nf2nwsFHE=.7c5f09a5-abe1-4f2e-ba6a-b33f8900b29f@github.com> On Tue, 9 May 2023 12:55:42 GMT, Stefan Karlsson wrote: >> Hi all, >> >> Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. >> >> The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention is to give the users time to validate and deploy their workloads with the new GC implementation. >> >> Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clear to us how time consuming and complex things end up being when we tried to keep both the original G1 working, and at the same time implemented the ZGC-alike G1. Given this experience, we don't see that as a viable solution to deliver a maintainable and evolving Generational ZGC. Our pragmatic suggestion to these challenges is to let Generational ZGC live under the current gc/z directories and let the legacy, non-generational ZGC be completely separated in its own directories. This way we can continue to move quickly with the continued develo pment of Generational ZGC and let the non-generational ZGC be mostly untouched until it gets deprecated, and eventually removed. The non-generational ZGC directory will be gc/x and all the classes of non-generational have been prefixed with X instead of Z. An alternative to this rename could be to namespace out non-generational ZGC. We experimented with that, but it was too easy to accidentally cross-compile Generational ZGC code into non-generational ZGC, so we didn't like that approach. >> >> Most of the stand-alone cleanups and enhancements outside of the ZGC code have already been upstreamed to openjdk/jdk. There are still a few patches that could/should be pushed separately, but they will be easier to understand by also looking at the Generational ZGC code, so they will be sent out after this PR has been published. The patches that could be published separately are: >> >> * 59d1e96af6a UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class >> * ca9edf8aa79 UPSTREAM: RISCV tmp reg cleanup resolve_jobject >> * 4bec9c69b67 CLEANUP: barrierSetNMethod_aarch64.cpp >> * b67d03a3f04 UPSTREAM: Add relaxed add&fetch for aarch64 atomics >> * a2824734d23 UPSTREAM: lir_xchg >> * 36cd39c0126 UPSTREAM: assembler_ppc CMPLI >> * 447259cea42 UPSTREAM: assembler_ppc ANDI >> * 9417323499a UPSTREAM: Add VMErrorCallback infrastructure >> >> Regarding all the changesets you see in this PR, they form the history of the development of Generational ZGC. It might look a bit unconventional to what you are used to see in openjdk development. What we have done is to use merges with the 'ours' strategy to ignore the previous Generational ZGC patches, and then rebased and flattened the changes on top of the merge. This effectively gives us the upsides of having a rebased repository and the upsides of retaining the history in the repository. The downside could be that GitHub now lists all those changesets in the PR. Given that this patch is so big, and that you likely only want to see a part of it, I suggest that you pull down the PR branch and then compare it to the openjdk/jdk changeset this PR is based against: >> >> >> git fetch https://github.com/openjdk/zgc zgc_master >> git diff zgc_master... >> >> >> There have been many contributors of this patch over the years. I'll do my best to poke Skara into listing you all, but if you see that I've missed your name please reach out to me and I'll fix it. >> >> Testing: we have been continuously running Generational ZGC through Oracle's tier1-8 testing. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Make barrier_Relocation inherit from Relocation instead of DataRelocation FYI: GitHub doesn't seem to handle our new merges correctly and lists changes that we have recently merged in from openjdk/jdk. Make sure to look at the patches locally or use the webrevs above. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13771#issuecomment-1540395015 From liach at openjdk.org Tue May 9 16:28:08 2023 From: liach at openjdk.org (Chen Liang) Date: Tue, 9 May 2023 16:28:08 GMT Subject: RFR: 8305669: RuntimeException when running benchmarks through make on Windows/WSL [v2] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 20:05:50 GMT, Chen Liang wrote: >> This patch replaces `FIXPATH` with `FixPath` on individual path argumenets. The root cause might be that JMH requires passing VM args to benchmarks in quotes, which might have triggered incorrect detections in `FIXPATH` (as in comparison, `$1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED` right above this patch seems to work fine) >> Also removed a useless and wrong Java flag to the java running javac, originally intended to enable running `make test TEST="loom.obsolete"` benchmarks. >> >> Since I only have a windows cygwin environment, I am not quite sure if this works elsewhere. > > Chen Liang 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 six additional commits since the last revision: > > - Comment about the fix logic > We have a mix and match of spaces and tabs, might need to fix it later > - Is this the right way instead? > - space fails linux > - Expose fixpath import and let jmh run use it > - Merge branch 'master' into jmh-windows > - 8305669: RuntimeException when running benchmarks through make on Windows/WSL Per Claes https://github.com/openjdk/jdk/pull/13671#discussion_r1188840349 we should move the open and export additions to the individual tests instead of adding them during building of the microbenchmark suite. I will wait for others opinions before deciding the way to go. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13550#issuecomment-1540493754 From erikj at openjdk.org Tue May 9 17:27:56 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 9 May 2023 17:27:56 GMT Subject: RFR: 8305669: RuntimeException when running benchmarks through make on Windows/WSL [v2] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 20:05:50 GMT, Chen Liang wrote: >> This patch replaces `FIXPATH` with `FixPath` on individual path argumenets. The root cause might be that JMH requires passing VM args to benchmarks in quotes, which might have triggered incorrect detections in `FIXPATH` (as in comparison, `$1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED` right above this patch seems to work fine) >> Also removed a useless and wrong Java flag to the java running javac, originally intended to enable running `make test TEST="loom.obsolete"` benchmarks. >> >> Since I only have a windows cygwin environment, I am not quite sure if this works elsewhere. > > Chen Liang 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 six additional commits since the last revision: > > - Comment about the fix logic > We have a mix and match of spaces and tabs, might need to fix it later > - Is this the right way instead? > - space fails linux > - Expose fixpath import and let jmh run use it > - Merge branch 'master' into jmh-windows > - 8305669: RuntimeException when running benchmarks through make on Windows/WSL > Per Claes [#13671 (comment)](https://github.com/openjdk/jdk/pull/13671#discussion_r1188840349) we should move the open and export additions to the individual tests instead of adding them during building of the microbenchmark suite. I will wait for others opinions before deciding the way to go. If there is a way to supply them in the tests themselves (similar to how we do for jtreg tests), then I agree that is a better idea than adding them globally for the whole test run. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13550#issuecomment-1540575605 From jjg at openjdk.org Tue May 9 17:43:47 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 9 May 2023 17:43:47 GMT Subject: RFR: 8300204: Sealed-class hierarchy graph missing nodes In-Reply-To: References: Message-ID: On Tue, 9 May 2023 03:11:10 GMT, Chen Liang wrote: > Please review this simple patch that fixes the package determination for nested classes in the `@sealedGraph` taglet. > > Current JDK 21: > https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/foreign/MemoryLayout.html > https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/foreign/ValueLayout.html > ![image](https://user-images.githubusercontent.com/7806504/236984282-f4361510-6208-4469-92d6-b9ce143204c3.png) > > This patch: > https://cr.openjdk.org/~liach/8300204/java.base/java/lang/foreign/MemoryLayout.html > https://cr.openjdk.org/~liach/8300204/java.base/java/lang/foreign/ValueLayout.html > ![image](https://user-images.githubusercontent.com/7806504/236984331-a877a493-487a-444a-984c-9175393cbb92.png) Marked as reviewed by jjg (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13875#pullrequestreview-1419153267 From rriggs at openjdk.org Tue May 9 18:37:25 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 9 May 2023 18:37:25 GMT Subject: RFR: 8305669: RuntimeException when running benchmarks through make on Windows/WSL [v2] In-Reply-To: References: Message-ID: <0178Bli6mDUC7cJsTSF1jfNjKaL9iO-k_5GB3oJFeCY=.97ee0221-20a6-463c-9712-826f54bc43fb@github.com> On Mon, 8 May 2023 20:05:50 GMT, Chen Liang wrote: >> This patch replaces `FIXPATH` with `FixPath` on individual path argumenets. The root cause might be that JMH requires passing VM args to benchmarks in quotes, which might have triggered incorrect detections in `FIXPATH` (as in comparison, `$1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED` right above this patch seems to work fine) >> Also removed a useless and wrong Java flag to the java running javac, originally intended to enable running `make test TEST="loom.obsolete"` benchmarks. >> >> Since I only have a windows cygwin environment, I am not quite sure if this works elsewhere. > > Chen Liang 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 six additional commits since the last revision: > > - Comment about the fix logic > We have a mix and match of spaces and tabs, might need to fix it later > - Is this the right way instead? > - space fails linux > - Expose fixpath import and let jmh run use it > - Merge branch 'master' into jmh-windows > - 8305669: RuntimeException when running benchmarks through make on Windows/WSL The JMH tests should be runnable standalone and be self contained. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13550#issuecomment-1540683767 From liach at openjdk.org Tue May 9 18:56:25 2023 From: liach at openjdk.org (Chen Liang) Date: Tue, 9 May 2023 18:56:25 GMT Subject: RFR: 8305669: RuntimeException when running benchmarks through make on Windows/WSL [v2] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 20:05:50 GMT, Chen Liang wrote: >> This patch replaces `FIXPATH` with `FixPath` on individual path argumenets. The root cause might be that JMH requires passing VM args to benchmarks in quotes, which might have triggered incorrect detections in `FIXPATH` (as in comparison, `$1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED` right above this patch seems to work fine) >> Also removed a useless and wrong Java flag to the java running javac, originally intended to enable running `make test TEST="loom.obsolete"` benchmarks. >> >> Since I only have a windows cygwin environment, I am not quite sure if this works elsewhere. > > Chen Liang 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 six additional commits since the last revision: > > - Comment about the fix logic > We have a mix and match of spaces and tabs, might need to fix it later > - Is this the right way instead? > - space fails linux > - Expose fixpath import and let jmh run use it > - Merge branch 'master' into jmh-windows > - 8305669: RuntimeException when running benchmarks through make on Windows/WSL Thanks for the conclusions. A quick peek into the benchmarks show there are currently three types of exports/opens: 1. java.io opens, present since the beginning of the benchmark suite 2. classfile and asm opens for the Class-File API benchmarks 3. jdk.internal.vm for a few loom benchmarks, added incorrectly to javac's vm args upon loom integration The latter two cases are easy to take care of; loom one is used by some of those deprecated benchmarks. I don't know where the first java.io opens is required and might need others help to investigate that. In addition, I think users can still pass in `--add-exports` and `--add-opens` with `MICRO_JAVA_OPTIONS` from test arguments, which may still get FixPath'd and break. If that is the case, this patch would still have some value. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13550#issuecomment-1540723084 From prr at openjdk.org Tue May 9 20:46:31 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 9 May 2023 20:46:31 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v2] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 14:35:46 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow a screen capture for all screens or some of them. For screens without permission there will be a black image. >> + If the user wishes to change their mind about the screens allowed to be captured, the user should use the new `Robot#resetScreenCapturePermission` method >> >> Also added several system properties: >> `awt.robot.screencastEnabled` false by default, uses the ScreenCast API if true >> `awt.robot.screencastDebug` false by default, prints some debug information if true >> >> For convenience, this change is divided into two commits: >> 1. added [pipewire headers](https://gitlab.freedesktop.org/pipewire/pipewire/) that are needed for the build >> 2. main changes >> >> Changes in the documentation are in a separate draft PR (#13809) also for convenience. >> >> At the moment, the planned supported systems are Ubuntu 22.04+, the latest Oracle Linux 9.1 and RHEL 9.1 has some issues with restore_token support. > > Alexander Zvegintsev has updated the pull request incrementally with three additional commits since the last revision: > > - update, based on review comments > - remove wayland detection > - BUILD_LIBPIPEWIRE_HEADER_DIRS -> LIBPIPEWIRE_HEADER_DIRS I'm thinking about the re-set API "If the user wishes to change their mind about the screens allowed to be captured, the user should use the new Robot#resetScreenCapturePermission method" Well the "user" is hosed unless the app calls this every time ... or provides UI for it .. I want to work through the scenarios and how much of it is specific to the behaviours of the API you are using and so forth. Since you use the Preferences API for saving the token, if you keyed it off the Robot class rather than the internal API class then anyone using the Preferences API could delete the token, couldn't they ? And we presumably can store alongside the token, info about the screens attached at the time we obtained the token ? Can you point (here in the implementation review) to the exact native functions that popup up the dialog ? I'm still trying to find my way through that code. Is it opaque to the caller (us) what the user actually approved ? I can't imagine why we would need to reset "we have all permissions" to "we have no permissions" so I'm supposing the issue is when they didn't grant permissions .. but if they "deny" permissions that's surely different than "this token is no longer valid" ? The first time we need a permission for the screencast API there is a dialog. The user makes some choices and we then choose to save a token so that the user isn't prompted again. We must at least know though that they approved SOMETHING but we don't know what ? Or do we ? If they DENY, would we save that ? Interesting question because if we don't save something we'll keep spamming them until they approve :-) Next time, what happens if for some reaon the token is no longer valid ? And what might make it invalid ? If the user denied screen 2, or added screen 2 later, would that not result in an invalid token and we'd know to ask again ? No reset needed ? Also I can't figure out if "validating" the token can cause the dialog as a side effect or if there's some API we explicitly call to request a new token. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1540864851 From bpb at openjdk.org Tue May 9 20:59:35 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 9 May 2023 20:59:35 GMT Subject: RFR: JDK-8306983: Do not invoke external programs when switch terminal to raw mode on selected platforms [v2] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 12:34:29 GMT, Jan Lahoda wrote: >> To support JShell and other usecases, the JDK uses JLine, which provides line-editing functionality inside a terminal. >> >> JLine has several ways to work with the terminal, based on various additional libraries and tools. Most of them are not directly usable inside the JDK, so currently, on non-Windows platforms, the JLine inside the JDK will use external programs, like `stty`, to inspect the terminal's properties and to switch the terminal to raw mode. >> >> This is slightly problematic, as the external programs might be missing, and while this is not that big problem for JShell, it might be a problem for other potential uses of JLine, like using it inside `System.console()`. >> >> So, the proposal here is to call the corresponding native methods directly, on selected platforms for now (Linux and Mac OS/X), instead of invoking the external programs. On Windows, this has always been the case, we are using a custom implementation of the interface that maps native and Java function for JNA there, and the proposal is to do the same here. We take the appropriate mapping interface for JNA, and provide hand-written implementation for it, using JNI. >> >> The Windows implementation is mostly unchanged, the changes are mostly non-Windows only. The overview of the changes is: >> - `LastErrorException` is moved from the Windows-specific code to the platform-neutral code, as it is used by all the native implementations. This is the only change that directly affects the Windows-specific code >> - `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java` and `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java` are created based on the corresponding files from JLine. In JLine, these files directly call platform-specific implementations, but in this patch, the platform specific code is commented out, and replaced with calls to `JDKNativePty`, which is a new platform-specific class, that delegates to the actual platform-specific implementations. Note the `JnaNativePty.java` and `JnaTerminalProvider.java` already exist in the Windows part, but have different pieces of code commented out, which makes them substantially different. >> - for Linux and Mac OS/X, there are platform-specific implementations based on the corresponding code from JLine, with the hand-written JNI-based implementation of the JNA-based existing interfaces. They also have an implementation of `JDKNativePty`, which just delegates to the given platform's `"NativePty"` implementation. >> - the `JdkConsoleProviderImpl.java` has been tweaked to not allow the implementation based on the external programs, and gracefully falling back to the standard implementation. JShell is kept unchanged. >> >> The reasons for this organization are: limiting duplication, mostly adhering to the JDK's platform specific build (which is different from the normal JLine's platform-neutral build) and limiting the difference between standard JLine and JLine inside JDK, to help future upgrades. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Adjusting build script as suggested on the review. src/jdk.internal.le/linux/native/lible/CLibrary.cpp line 2: > 1: /* > 2: * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved. Copyright year 2023 only if this is new. src/jdk.internal.le/linux/native/lible/CLibrary.cpp line 103: > 101: > 102: if (tcgetattr(fd, &data) != 0) { > 103: jobject exc = env->NewObject(lastErrorExceptionClass, Could lines 103-106 be converted to a utility function which would then be invoked at current lines 103, 141, 163, and 197? src/jdk.internal.le/linux/native/lible/CLibrary.cpp line 116: > 114: env->SetIntField(result, c_line, data.c_line); > 115: jbyteArray c_ccValue = (jbyteArray) env->GetObjectField(result, c_cc); > 116: env->SetByteArrayRegion(c_ccValue, 0, NCCS, (signed char *) data.c_cc);//TODO: cast? Cast instead to `(jbyte*)` here and at lines 136 and 204? src/jdk.internal.le/linux/native/lible/CLibrary.cpp line 183: > 181: JNIEXPORT jint JNICALL Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_isatty > 182: (JNIEnv *, jobject, jint fd) { > 183: return isatty(fd); Do we care if the native `isatty()` returns zero? Or is this dealt with somewhere else? src/jdk.internal.le/macosx/native/lible/CLibrary.cpp line 2: > 1: /* > 2: * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved. Copyright year 2023 only? src/jdk.internal.le/macosx/native/lible/CLibrary.cpp line 59: > 57: > 58: JNIEXPORT void JNICALL Java_jdk_internal_org_jline_terminal_impl_jna_osx_CLibraryImpl_initIDs > 59: (JNIEnv *env, jclass) { Missing parameter for `jclass`? Maybe add `clazz` or `unused` or something? src/jdk.internal.le/macosx/native/lible/CLibrary.cpp line 109: > 107: > 108: if (tcgetattr(fd, &data) != 0) { > 109: jobject exc = env->NewObject(lastErrorExceptionClass, Could lines 109-112 be converted to a utility function which would then be invoked at current lines 109, 145, 167, and 197? src/jdk.internal.le/macosx/native/lible/CLibrary.cpp line 121: > 119: env->SetLongField(env->GetObjectField(result, c_lflag), nativelong_value, data.c_lflag); > 120: jbyteArray c_ccValue = (jbyteArray) env->GetObjectField(result, c_cc); > 121: env->SetByteArrayRegion(c_ccValue, 0, NCCS, (signed char *) data.c_cc); Cast instead to `(jbyte*)` here and at lines 140 and 208? src/jdk.internal.le/macosx/native/lible/CLibrary.cpp line 187: > 185: JNIEXPORT jint JNICALL Java_jdk_internal_org_jline_terminal_impl_jna_osx_CLibraryImpl_isatty > 186: (JNIEnv *, jobject, jint fd) { > 187: return isatty(fd); Do we care if the native `isatty()` returns zero? Or is this dealt with somewhere else? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1189114958 PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1189116097 PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1189116683 PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1189117836 PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1189123411 PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1189118782 PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1189120027 PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1189121218 PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1189121521 From jiangli at openjdk.org Tue May 9 21:34:43 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 9 May 2023 21:34:43 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v8] In-Reply-To: References: Message-ID: > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: > > - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries > > - For libjvm.a specifically, exclude operator_new.o > > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols > - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled > - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a > > - Handle long arguments case for static build in make/common/NativeCompilation.gmk > > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Reflect on @erikj79 suggestions/input on static-libs-image/graal-builder-image and supporting libjvm.a for different JVM_VARIANTS: - Remove the new java-static-libs and java-static-libs-bundles targets. Delete the new make/StaticJvmLibsImage.gmk. - Restore HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and related definitions from previous revision for different $(JVM_VARIANTS). - Change the existing static-libs-image target to build libjvm.a in addition to JDK static libraries. The libjvm.a is placed under images/static-libs/lib/. When building multiple JVM variants, each variant contains its own libjvm.a under images/static-libs/lib/ directory. - Add a new static-libs-graal-image target, which is used by graal-builder-image. Hotspot libjvm.a is not created when building static-libs-graal-image and graal-builder-image targets. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13768/files - new: https://git.openjdk.org/jdk/pull/13768/files/2cb786ab..cf317d36 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=06-07 Stats: 107 lines in 5 files changed: 32 ins; 60 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From jiangli at openjdk.org Tue May 9 21:46:42 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 9 May 2023 21:46:42 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v9] In-Reply-To: References: Message-ID: > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: > > - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries > > - For libjvm.a specifically, exclude operator_new.o > > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols > - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled > - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a > > - Handle long arguments case for static build in make/common/NativeCompilation.gmk > > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Fix whitspace errors. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13768/files - new: https://git.openjdk.org/jdk/pull/13768/files/cf317d36..d30b3e34 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From jiangli at openjdk.org Tue May 9 21:47:32 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 9 May 2023 21:47:32 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v7] In-Reply-To: References: <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com> <2BVvV9m8bI-UzZXpX1GEPwoStZ6pHZBn4JuAMRQk978=.54246fe4-57b8-4372-bfc4-6b63823fa9a2@github.com> Message-ID: On Mon, 8 May 2023 19:45:18 GMT, Jiangli Zhou wrote: > > > All of that said, I think we can get away with a smaller subset of targets and deliverables. AFAIK, graal needs the combined `graal-builder-image` as input to their build anyway, so they should not have any dependency on what the target `static-libs-image` produces. Given that I propose the following behavior: > > > `make static-libs-image` produces `images/static-libs` with all .a (including libjvm.a). `make static-libs-graal-image` produces `images/static-libs-graal` with all .a except libjvm.a. `make graal-builder-image` produces `images/graal-builder-image` like today, but depends on and uses `static-libs-graal-image` instead of `static-libs-image`. `make static-libs-bundles` depends on and uses `static-libs-image` like today, so will contain libjvm.a, which is new behavior. > > > > > > Sure, that should work too as long as there is a way to a) build the static libs only needed for graal some way b) keep `graal-builder-image` working as it does today. FWIW, we use `a)` at adoptium so as to be able to have a combination to build mandrel from. Not all users will want to have JDK + static libs so only the ones needing them should need to download them. > > Thanks @erikj79 @jerboaa. We can go with what @erikj79 suggested then. I'll revise the PR. @erikj79 and @jerboaa please please review the updated version, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1540931243 From azvegint at openjdk.org Tue May 9 22:12:15 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 9 May 2023 22:12:15 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v2] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 20:43:13 GMT, Phil Race wrote: > I want to work through the scenarios and how much of it is specific to the behaviours of the API you are using and so forth. Since you use the Preferences API for saving the token, if you keyed it off the Robot class rather than the internal API class then anyone using the Preferences API could delete the token, couldn't they ? Right now it can be read with a simple call: `System.out.println(Preferences.userRoot().node("/sun/awt/screencast").get("restoreToken", ""));` (modification is also simple). Moving to Robot doesn't change anything in this regard. So anyone can delete it. > And we presumably can store alongside the token, info about the screens attached at the time we obtained the token ? We can try to do that and switch it depending on the area requested, but I tried to keep it simple. > Can you point (here in the implementation review) to the exact native functions that popup up the dialog ? I'm still trying to find my way through that code. Is it opaque to the caller (us) what the user actually approved ? (It is collapsed by the github in the review, so links are to the branch) basically if you [didn't provide a correct token or no token at all](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L530-L537) to [SelectSources call](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L539-L546) it will prompt with dialog right after [the Start call](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L677-L685) > I can't imagine why we would need to reset "we have all permissions" to "we have no permissions" so I'm supposing the issue is when they didn't grant permissions .. but if they "deny" permissions that's surely different than "this token is no longer valid" ? It is not for the "we have all permissions" case, it is for the case when we only have a permission to some screens. So it won't hurt. > The first time we need a permission for the screencast API there is a dialog. The user makes some choices and we then choose to save a token so that the user isn't prompted again. We must at least know though that they approved SOMETHING but we don't know what ? Or do we ? No we don't. We receive the response [callbackScreenCastStart](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L586-L591) as a separate streams for each allowed display. Based on this response we [building a list of **available** displays](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L73). So denied screens will not be there. At this point we can compare this result with the screens got from X11 API(won't be compatible with Wayland, where we also want to reuse it later) or with Wayland(+1 dependency at this point). > If they DENY, would we save that ? Interesting question because if we don't save something we'll keep spamming them until they approve :-) The [DENY case](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L586-L591) propagated to java and we are throwing the security exception. > Next time, what happens if for some reaon the token is no longer valid ? It just prompts a permission request again. > And what might make it invalid ? Adding or removing a display for example. > If the user denied screen 2, or added screen 2 later, would that not result in an invalid token and we'd know to ask again ? No reset needed ? Also I can't figure out if "validating" the token can cause the dialog as a side effect or if there's some API we explicitly call to request a new token. Let me elaborate how this `restore_token` works: We may or may not provide the `restore_token` while calling `SelectSources`. If the token provided is not valid (we have no control over this, it's checked on the system side), the permission prompt will appear. Later, after granting permissions, the `restore_token` is returned by [Start](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.Start) callback. We should [update](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L593-L611) it, as it may not be the same as we provided before. When we are calling the `resetScreenCapturePermission` we are not actually revoking the token from the system, we are just doesn't add it to the `SelectSources` call. (but, if needed, we can provide it later and it should work). So whenever we don't provide a valid token, we get a confirmation prompt. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1540951957 From erikj at openjdk.org Tue May 9 22:17:18 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 9 May 2023 22:17:18 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v9] In-Reply-To: References: Message-ID: <8-kD9iBw0LboYiC_RJnaHZdxySrxXG15ENceHPSt2qo=.8d0beed0-409d-4ba9-9b3e-bbb1cedceb6b@github.com> On Tue, 9 May 2023 21:46:42 GMT, Jiangli Zhou wrote: >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: >> >> - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a >> >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk >> >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Fix whitspace errors. I think you also need to make a change to `GraalBuilderImage.gmk` and the target in `Main.gmk` that calls it. Otherwise this looks pretty good to me. make/Main.gmk line 1281: > 1279: all-bundles: product-bundles test-bundles docs-bundles static-libs-bundles > 1280: > 1281: ALL_TARGETS += buildtools hotspot hotspot-libs hotspot-static-libs hotspot-gensrc gensrc gendata \ Can you add a newline to try to keep line length in check here. No need to reformat the whole block, just don't let random lines shoot way over 80. ------------- PR Review: https://git.openjdk.org/jdk/pull/13768#pullrequestreview-1419519027 PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1189176422 From jiangli at openjdk.org Tue May 9 23:06:23 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 9 May 2023 23:06:23 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v10] In-Reply-To: References: Message-ID: <0viE6l2gzDCF4VBwgJcR_rAbXRApsFP4JL8RPcyRrIU=.00d04ba3-63c6-4f0f-aeef-718c0f388369@github.com> > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: > > - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries > > - For libjvm.a specifically, exclude operator_new.o > > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols > - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled > - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a > > - Handle long arguments case for static build in make/common/NativeCompilation.gmk > > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Address comments from @erikj79: - Fix to use $(STATIC_LIBS_GRAAL_IMAGE_DIR) in GraalBuilderImage.gmk. - Split the long line at 1281 in Main.gmk. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13768/files - new: https://git.openjdk.org/jdk/pull/13768/files/d30b3e34..45dd2a00 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=08-09 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From jiangli at openjdk.org Tue May 9 23:08:27 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 9 May 2023 23:08:27 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v9] In-Reply-To: <8-kD9iBw0LboYiC_RJnaHZdxySrxXG15ENceHPSt2qo=.8d0beed0-409d-4ba9-9b3e-bbb1cedceb6b@github.com> References: <8-kD9iBw0LboYiC_RJnaHZdxySrxXG15ENceHPSt2qo=.8d0beed0-409d-4ba9-9b3e-bbb1cedceb6b@github.com> Message-ID: On Tue, 9 May 2023 22:14:04 GMT, Erik Joelsson wrote: > I think you also need to make a change to `GraalBuilderImage.gmk` and the target in `Main.gmk` that calls it. Good catch! Fixed `GraalBuilderImage.gmk`, thanks! For the `graal-builder-image` target that uses `GraalBuilderImage.gmk`, it's already changed to use `static-libs-graal-image` as one of the DEPS. Please let me know if anything additional that I missed. > make/Main.gmk line 1281: > >> 1279: all-bundles: product-bundles test-bundles docs-bundles static-libs-bundles >> 1280: >> 1281: ALL_TARGETS += buildtools hotspot hotspot-libs hotspot-static-libs hotspot-gensrc gensrc gendata \ > > Can you add a newline to try to keep line length in check here. No need to reformat the whole block, just don't let random lines shoot way over 80. Done, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1540998009 PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1189206701 From sgehwolf at openjdk.org Wed May 10 09:08:21 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 10 May 2023 09:08:21 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v10] In-Reply-To: <0viE6l2gzDCF4VBwgJcR_rAbXRApsFP4JL8RPcyRrIU=.00d04ba3-63c6-4f0f-aeef-718c0f388369@github.com> References: <0viE6l2gzDCF4VBwgJcR_rAbXRApsFP4JL8RPcyRrIU=.00d04ba3-63c6-4f0f-aeef-718c0f388369@github.com> Message-ID: On Tue, 9 May 2023 23:06:23 GMT, Jiangli Zhou wrote: >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: >> >> - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a >> >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk >> >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Address comments from @erikj79: > - Fix to use $(STATIC_LIBS_GRAAL_IMAGE_DIR) in GraalBuilderImage.gmk. > - Split the long line at 1281 in Main.gmk. Looks fine to me. ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13768#pullrequestreview-1420136948 From aboldtch at openjdk.org Wed May 10 09:10:45 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 10 May 2023 09:10:45 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v12] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 12:55:42 GMT, Stefan Karlsson wrote: >> Hi all, >> >> Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. >> >> The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention is to give the users time to validate and deploy their workloads with the new GC implementation. >> >> Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clear to us how time consuming and complex things end up being when we tried to keep both the original G1 working, and at the same time implemented the ZGC-alike G1. Given this experience, we don't see that as a viable solution to deliver a maintainable and evolving Generational ZGC. Our pragmatic suggestion to these challenges is to let Generational ZGC live under the current gc/z directories and let the legacy, non-generational ZGC be completely separated in its own directories. This way we can continue to move quickly with the continued develo pment of Generational ZGC and let the non-generational ZGC be mostly untouched until it gets deprecated, and eventually removed. The non-generational ZGC directory will be gc/x and all the classes of non-generational have been prefixed with X instead of Z. An alternative to this rename could be to namespace out non-generational ZGC. We experimented with that, but it was too easy to accidentally cross-compile Generational ZGC code into non-generational ZGC, so we didn't like that approach. >> >> Most of the stand-alone cleanups and enhancements outside of the ZGC code have already been upstreamed to openjdk/jdk. There are still a few patches that could/should be pushed separately, but they will be easier to understand by also looking at the Generational ZGC code, so they will be sent out after this PR has been published. The patches that could be published separately are: >> >> * 59d1e96af6a UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class >> * ca9edf8aa79 UPSTREAM: RISCV tmp reg cleanup resolve_jobject >> * 4bec9c69b67 CLEANUP: barrierSetNMethod_aarch64.cpp >> * b67d03a3f04 UPSTREAM: Add relaxed add&fetch for aarch64 atomics >> * a2824734d23 UPSTREAM: lir_xchg >> * 36cd39c0126 UPSTREAM: assembler_ppc CMPLI >> * 447259cea42 UPSTREAM: assembler_ppc ANDI >> * 9417323499a UPSTREAM: Add VMErrorCallback infrastructure >> >> Regarding all the changesets you see in this PR, they form the history of the development of Generational ZGC. It might look a bit unconventional to what you are used to see in openjdk development. What we have done is to use merges with the 'ours' strategy to ignore the previous Generational ZGC patches, and then rebased and flattened the changes on top of the merge. This effectively gives us the upsides of having a rebased repository and the upsides of retaining the history in the repository. The downside could be that GitHub now lists all those changesets in the PR. Given that this patch is so big, and that you likely only want to see a part of it, I suggest that you pull down the PR branch and then compare it to the openjdk/jdk changeset this PR is based against: >> >> >> git fetch https://github.com/openjdk/zgc zgc_master >> git diff zgc_master... >> >> >> There have been many contributors of this patch over the years. I'll do my best to poke Skara into listing you all, but if you see that I've missed your name please reach out to me and I'll fix it. >> >> Testing: we have been continuously running Generational ZGC through Oracle's tier1-8 testing. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Make barrier_Relocation inherit from Relocation instead of DataRelocation Having been able to contribute to generational ZGC over the last year has been a privilege. The code is well structured and the preparatory upstreaming work has made the integration with other subcomponents of hotspot rather minimal. The X/Z split feels like a pragmatic solution for having the two ZGC codebases coexisting. Just like Erik, I am a little biased. I approve of this PR! ------------- Marked as reviewed by aboldtch (Committer). PR Review: https://git.openjdk.org/jdk/pull/13771#pullrequestreview-1420141836 From jbechberger at openjdk.org Wed May 10 11:05:29 2023 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 10 May 2023 11:05:29 GMT Subject: RFR: 8307732: build-test-lib is broken In-Reply-To: References: Message-ID: On Tue, 9 May 2023 10:38:54 GMT, Johannes Bechberger wrote: > Fixes the issue by adding `--add-exports` for the required modules and making the `HttpHeaderParser` final (fixing an issue with calling overridable methods in a constructor). What is preventing this PR from being merged? The CI errors have nothing todo with my change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13885#issuecomment-1541950649 From duke at openjdk.org Wed May 10 11:08:27 2023 From: duke at openjdk.org (JoKern65) Date: Wed, 10 May 2023 11:08:27 GMT Subject: RFR: JDK-8307349: Support xlc17 clang toolchain on AIX Message-ID: The new xlc17 compiler should be supported to build OpenJDK on AIX. This compiler, compared to the currently supported xlc16, has a significantly more recent clang (xlc 17.1.1 uses clang 15) included. 1. Because the frontend interface of the new compiler (c-flags, Ld-Flags) has changed from an xlc to a clang interface we decided to use the clang toolchain for the new xlc17 compiler. 2. Unfortunately, the system headers are mainly unchanged, so they do not harmonize with the src/hotspot/share/utilities/globalDefinitions_gcc.hpp which would be used if we totally switch to clang toolchain. So we keep the HOTSPOT_TOOLCHAIN_TYPE=xlc 3. In src/hotspot/share/utilities/globalDefinitions_xlc.hpp we introduce a new define AIX_XLC_GE_17 which is set if we build with the new xlc17 on AIX. This define will be used in following PRs. ------------- Commit messages: - JDK-8307349 Changes: https://git.openjdk.org/jdk/pull/13898/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13898&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307349 Stats: 117 lines in 6 files changed: 97 ins; 1 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/13898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13898/head:pull/13898 PR: https://git.openjdk.org/jdk/pull/13898 From mbaesken at openjdk.org Wed May 10 11:17:24 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 10 May 2023 11:17:24 GMT Subject: RFR: JDK-8307349: Support xlc17 clang toolchain on AIX In-Reply-To: References: Message-ID: On Wed, 10 May 2023 11:01:24 GMT, JoKern65 wrote: > The new xlc17 compiler should be supported to build OpenJDK on AIX. This compiler, compared to the currently supported xlc16, has a significantly more recent clang (xlc 17.1.1 uses clang 15) included. > 1. Because the frontend interface of the new compiler (c-flags, Ld-Flags) has changed from an xlc to a clang interface we decided to use the clang toolchain for the new xlc17 compiler. > 2. Unfortunately, the system headers are mainly unchanged, so they do not harmonize with the src/hotspot/share/utilities/globalDefinitions_gcc.hpp which would be used if we totally switch to clang toolchain. So we keep the HOTSPOT_TOOLCHAIN_TYPE=xlc > 3. In src/hotspot/share/utilities/globalDefinitions_xlc.hpp we introduce a new define AIX_XLC_GE_17 which is set if we build with the new xlc17 on AIX. This define will be used in following PRs. The copyright year info needs updating to 2023 in some files (please look at the start of the files). e.g. make/autoconf/flags-ldflags.m4 ------------- PR Comment: https://git.openjdk.org/jdk/pull/13898#issuecomment-1541980514 From djelinski at openjdk.org Wed May 10 12:16:35 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 10 May 2023 12:16:35 GMT Subject: RFR: 8307732: build-test-lib is broken In-Reply-To: References: Message-ID: On Tue, 9 May 2023 10:38:54 GMT, Johannes Bechberger wrote: > Fixes the issue by adding `--add-exports` for the required modules and making the `HttpHeaderParser` final (fixing an issue with calling overridable methods in a constructor). Just making sure everyone had a chance to take a look. I'll sponsor this now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13885#issuecomment-1542098317 From jbechberger at openjdk.org Wed May 10 12:16:36 2023 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 10 May 2023 12:16:36 GMT Subject: Integrated: 8307732: build-test-lib is broken In-Reply-To: References: Message-ID: <-ks9idC-Yt78xRIjwDfEfe2TEo6WCG96_HP16peuqwM=.638f9539-d827-4851-beb3-f2dfd013300e@github.com> On Tue, 9 May 2023 10:38:54 GMT, Johannes Bechberger wrote: > Fixes the issue by adding `--add-exports` for the required modules and making the `HttpHeaderParser` final (fixing an issue with calling overridable methods in a constructor). This pull request has now been integrated. Changeset: 0da48f19 Author: Johannes Bechberger Committer: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/0da48f19cbebe0730d689cb966b886f6f73fb3f1 Stats: 9 lines in 2 files changed: 6 ins; 0 del; 3 mod 8307732: build-test-lib is broken Reviewed-by: erikj, djelinski ------------- PR: https://git.openjdk.org/jdk/pull/13885 From erikj at openjdk.org Wed May 10 12:49:19 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 10 May 2023 12:49:19 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v10] In-Reply-To: <0viE6l2gzDCF4VBwgJcR_rAbXRApsFP4JL8RPcyRrIU=.00d04ba3-63c6-4f0f-aeef-718c0f388369@github.com> References: <0viE6l2gzDCF4VBwgJcR_rAbXRApsFP4JL8RPcyRrIU=.00d04ba3-63c6-4f0f-aeef-718c0f388369@github.com> Message-ID: <6FRecbkoJikA25hk24eO8JA_kIG2c1ie9DZ9-GYwMC4=.607ca420-7788-4574-aec4-5a47ae614238@github.com> On Tue, 9 May 2023 23:06:23 GMT, Jiangli Zhou wrote: >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: >> >> - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a >> >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk >> >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Address comments from @erikj79: > - Fix to use $(STATIC_LIBS_GRAAL_IMAGE_DIR) in GraalBuilderImage.gmk. > - Split the long line at 1281 in Main.gmk. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13768#pullrequestreview-1420562567 From erikj at openjdk.org Wed May 10 13:03:27 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 10 May 2023 13:03:27 GMT Subject: RFR: JDK-8307349: Support xlc17 clang toolchain on AIX In-Reply-To: References: Message-ID: <9LnzYtRgLFFJLEJSKXC6xk3JPxB6AHHKNOnQAAANNOY=.7d5a2eab-7552-4892-96ef-e5acd770df97@github.com> On Wed, 10 May 2023 11:01:24 GMT, JoKern65 wrote: > The new xlc17 compiler should be supported to build OpenJDK on AIX. This compiler, compared to the currently supported xlc16, has a significantly more recent clang (xlc 17.1.1 uses clang 15) included. > 1. Because the frontend interface of the new compiler (c-flags, Ld-Flags) has changed from an xlc to a clang interface we decided to use the clang toolchain for the new xlc17 compiler. > 2. Unfortunately, the system headers are mainly unchanged, so they do not harmonize with the src/hotspot/share/utilities/globalDefinitions_gcc.hpp which would be used if we totally switch to clang toolchain. So we keep the HOTSPOT_TOOLCHAIN_TYPE=xlc > 3. In src/hotspot/share/utilities/globalDefinitions_xlc.hpp we introduce a new define AIX_XLC_GE_17 which is set if we build with the new xlc17 on AIX. This define will be used in following PRs. Looks ok, just some whitespace suggestions. make/autoconf/flags-ldflags.m4 line 95: > 93: fi > 94: > 95: if (test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang) && test "x$OPENJDK_TARGET_OS" != xaix; then Suggestion: if (test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang) \ && test "x$OPENJDK_TARGET_OS" != xaix; then make/hotspot/lib/JvmOverrideFiles.gmk line 116: > 114: else > 115: BUILD_LIBJVM_synchronizer.cpp_CXXFLAGS := -qnoinline > 116: endif Suggestion: ifeq ($(TOOLCHAIN_TYPE), clang) BUILD_LIBJVM_synchronizer.cpp_CXXFLAGS := -fno-inline else BUILD_LIBJVM_synchronizer.cpp_CXXFLAGS := -qnoinline endif ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13898#pullrequestreview-1420576356 PR Review Comment: https://git.openjdk.org/jdk/pull/13898#discussion_r1189867146 PR Review Comment: https://git.openjdk.org/jdk/pull/13898#discussion_r1189874551 From rcastanedalo at openjdk.org Wed May 10 13:04:44 2023 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Wed, 10 May 2023 13:04:44 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v12] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 12:55:42 GMT, Stefan Karlsson wrote: >> Hi all, >> >> Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. >> >> The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention is to give the users time to validate and deploy their workloads with the new GC implementation. >> >> Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clear to us how time consuming and complex things end up being when we tried to keep both the original G1 working, and at the same time implemented the ZGC-alike G1. Given this experience, we don't see that as a viable solution to deliver a maintainable and evolving Generational ZGC. Our pragmatic suggestion to these challenges is to let Generational ZGC live under the current gc/z directories and let the legacy, non-generational ZGC be completely separated in its own directories. This way we can continue to move quickly with the continued develo pment of Generational ZGC and let the non-generational ZGC be mostly untouched until it gets deprecated, and eventually removed. The non-generational ZGC directory will be gc/x and all the classes of non-generational have been prefixed with X instead of Z. An alternative to this rename could be to namespace out non-generational ZGC. We experimented with that, but it was too easy to accidentally cross-compile Generational ZGC code into non-generational ZGC, so we didn't like that approach. >> >> Most of the stand-alone cleanups and enhancements outside of the ZGC code have already been upstreamed to openjdk/jdk. There are still a few patches that could/should be pushed separately, but they will be easier to understand by also looking at the Generational ZGC code, so they will be sent out after this PR has been published. The patches that could be published separately are: >> >> * 59d1e96af6a UPSTREAM: Introduce check_oop infrastructure to check oops in the oop class >> * ca9edf8aa79 UPSTREAM: RISCV tmp reg cleanup resolve_jobject >> * 4bec9c69b67 CLEANUP: barrierSetNMethod_aarch64.cpp >> * b67d03a3f04 UPSTREAM: Add relaxed add&fetch for aarch64 atomics >> * a2824734d23 UPSTREAM: lir_xchg >> * 36cd39c0126 UPSTREAM: assembler_ppc CMPLI >> * 447259cea42 UPSTREAM: assembler_ppc ANDI >> * 9417323499a UPSTREAM: Add VMErrorCallback infrastructure >> >> Regarding all the changesets you see in this PR, they form the history of the development of Generational ZGC. It might look a bit unconventional to what you are used to see in openjdk development. What we have done is to use merges with the 'ours' strategy to ignore the previous Generational ZGC patches, and then rebased and flattened the changes on top of the merge. This effectively gives us the upsides of having a rebased repository and the upsides of retaining the history in the repository. The downside could be that GitHub now lists all those changesets in the PR. Given that this patch is so big, and that you likely only want to see a part of it, I suggest that you pull down the PR branch and then compare it to the openjdk/jdk changeset this PR is based against: >> >> >> git fetch https://github.com/openjdk/zgc zgc_master >> git diff zgc_master... >> >> >> There have been many contributors of this patch over the years. I'll do my best to poke Skara into listing you all, but if you see that I've missed your name please reach out to me and I'll fix it. >> >> Testing: we have been continuously running Generational ZGC through Oracle's tier1-8 testing. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Make barrier_Relocation inherit from Relocation instead of DataRelocation Compiler-related changes look good! ------------- Marked as reviewed by rcastanedalo (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13771#pullrequestreview-1420591971 From mbaesken at openjdk.org Wed May 10 13:12:23 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 10 May 2023 13:12:23 GMT Subject: RFR: JDK-8307349: Support xlc17 clang toolchain on AIX In-Reply-To: References: Message-ID: On Wed, 10 May 2023 11:01:24 GMT, JoKern65 wrote: > The new xlc17 compiler should be supported to build OpenJDK on AIX. This compiler, compared to the currently supported xlc16, has a significantly more recent clang (xlc 17.1.1 uses clang 15) included. > 1. Because the frontend interface of the new compiler (c-flags, Ld-Flags) has changed from an xlc to a clang interface we decided to use the clang toolchain for the new xlc17 compiler. > 2. Unfortunately, the system headers are mainly unchanged, so they do not harmonize with the src/hotspot/share/utilities/globalDefinitions_gcc.hpp which would be used if we totally switch to clang toolchain. So we keep the HOTSPOT_TOOLCHAIN_TYPE=xlc > 3. In src/hotspot/share/utilities/globalDefinitions_xlc.hpp we introduce a new define AIX_XLC_GE_17 which is set if we build with the new xlc17 on AIX. This define will be used in following PRs. src/hotspot/share/utilities/globalDefinitions_xlc.hpp line 1: > 1: /* #if __open_xl_version__ < 17 #error "xlc < 16 not supported" #endif Should this be xlc < 17 in the error ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13898#discussion_r1189887724 From duke at openjdk.org Wed May 10 13:59:15 2023 From: duke at openjdk.org (JoKern65) Date: Wed, 10 May 2023 13:59:15 GMT Subject: RFR: JDK-8307349: Support xlc17 clang toolchain on AIX [v2] In-Reply-To: References: Message-ID: > The new xlc17 compiler should be supported to build OpenJDK on AIX. This compiler, compared to the currently supported xlc16, has a significantly more recent clang (xlc 17.1.1 uses clang 15) included. > 1. Because the frontend interface of the new compiler (c-flags, Ld-Flags) has changed from an xlc to a clang interface we decided to use the clang toolchain for the new xlc17 compiler. > 2. Unfortunately, the system headers are mainly unchanged, so they do not harmonize with the src/hotspot/share/utilities/globalDefinitions_gcc.hpp which would be used if we totally switch to clang toolchain. So we keep the HOTSPOT_TOOLCHAIN_TYPE=xlc > 3. In src/hotspot/share/utilities/globalDefinitions_xlc.hpp we introduce a new define AIX_XLC_GE_17 which is set if we build with the new xlc17 on AIX. This define will be used in following PRs. JoKern65 has updated the pull request incrementally with two additional commits since the last revision: - revert accidantially changed mode bits - I followed the proposals ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13898/files - new: https://git.openjdk.org/jdk/pull/13898/files/a94aa615..74331b8f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13898&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13898&range=00-01 Stats: 12 lines in 5 files changed: 1 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/13898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13898/head:pull/13898 PR: https://git.openjdk.org/jdk/pull/13898 From duke at openjdk.org Wed May 10 13:59:15 2023 From: duke at openjdk.org (JoKern65) Date: Wed, 10 May 2023 13:59:15 GMT Subject: RFR: JDK-8307349: Support xlc17 clang toolchain on AIX In-Reply-To: References: Message-ID: On Wed, 10 May 2023 11:01:24 GMT, JoKern65 wrote: > The new xlc17 compiler should be supported to build OpenJDK on AIX. This compiler, compared to the currently supported xlc16, has a significantly more recent clang (xlc 17.1.1 uses clang 15) included. > 1. Because the frontend interface of the new compiler (c-flags, Ld-Flags) has changed from an xlc to a clang interface we decided to use the clang toolchain for the new xlc17 compiler. > 2. Unfortunately, the system headers are mainly unchanged, so they do not harmonize with the src/hotspot/share/utilities/globalDefinitions_gcc.hpp which would be used if we totally switch to clang toolchain. So we keep the HOTSPOT_TOOLCHAIN_TYPE=xlc > 3. In src/hotspot/share/utilities/globalDefinitions_xlc.hpp we introduce a new define AIX_XLC_GE_17 which is set if we build with the new xlc17 on AIX. This define will be used in following PRs. I followed your suggested corrections. Thanks a lot. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13898#issuecomment-1542257220 From mbaesken at openjdk.org Wed May 10 14:10:25 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 10 May 2023 14:10:25 GMT Subject: RFR: JDK-8307349: Support xlc17 clang toolchain on AIX [v2] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 13:59:15 GMT, JoKern65 wrote: >> The new xlc17 compiler should be supported to build OpenJDK on AIX. This compiler, compared to the currently supported xlc16, has a significantly more recent clang (xlc 17.1.1 uses clang 15) included. >> 1. Because the frontend interface of the new compiler (c-flags, Ld-Flags) has changed from an xlc to a clang interface we decided to use the clang toolchain for the new xlc17 compiler. >> 2. Unfortunately, the system headers are mainly unchanged, so they do not harmonize with the src/hotspot/share/utilities/globalDefinitions_gcc.hpp which would be used if we totally switch to clang toolchain. So we keep the HOTSPOT_TOOLCHAIN_TYPE=xlc >> 3. In src/hotspot/share/utilities/globalDefinitions_xlc.hpp we introduce a new define AIX_XLC_GE_17 which is set if we build with the new xlc17 on AIX. This define will be used in following PRs. > > JoKern65 has updated the pull request incrementally with two additional commits since the last revision: > > - revert accidantially changed mode bits > - I followed the proposals Marked as reviewed by mbaesken (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13898#pullrequestreview-1420735558 From jiangli at openjdk.org Wed May 10 15:15:29 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 10 May 2023 15:15:29 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries In-Reply-To: <-y0ADzT8MTDUDF_cB5Msg5W4OfWnP7GjcCfhcrKtT-I=.6ed57876-309a-4b7f-a23e-e04bf7047755@github.com> References: <-y0ADzT8MTDUDF_cB5Msg5W4OfWnP7GjcCfhcrKtT-I=.6ed57876-309a-4b7f-a23e-e04bf7047755@github.com> Message-ID: On Wed, 3 May 2023 13:34:12 GMT, Erik Joelsson wrote: >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: >> >> - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a >> >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk >> >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > > The current target user of the .a libraries is GraalVM, so we should check with them that the changes to the contents of the `.a` files isn't impacting them in a bad way. @dougxc what do you think? Thanks a lot for the multiple iterations of the discussions and reviews in this PR thread. All the input, especially https://github.com/openjdk/jdk/pull/13768#pullrequestreview-1415436469 from @erikj79 helped shaped this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1542387929 From liach at openjdk.org Wed May 10 15:40:38 2023 From: liach at openjdk.org (Chen Liang) Date: Wed, 10 May 2023 15:40:38 GMT Subject: RFR: 8305669: RuntimeException when running benchmarks through make on Windows/WSL [v2] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 20:05:50 GMT, Chen Liang wrote: >> This patch replaces `FIXPATH` with `FixPath` on individual path argumenets. The root cause might be that JMH requires passing VM args to benchmarks in quotes, which might have triggered incorrect detections in `FIXPATH` (as in comparison, `$1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED` right above this patch seems to work fine) >> Also removed a useless and wrong Java flag to the java running javac, originally intended to enable running `make test TEST="loom.obsolete"` benchmarks. >> >> Since I only have a windows cygwin environment, I am not quite sure if this works elsewhere. > > Chen Liang 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 six additional commits since the last revision: > > - Comment about the fix logic > We have a mix and match of spaces and tabs, might need to fix it later > - Is this the right way instead? > - space fails linux > - Expose fixpath import and let jmh run use it > - Merge branch 'master' into jmh-windows > - 8305669: RuntimeException when running benchmarks through make on Windows/WSL Withdrawing this patch, as #13671 fixes benchmark running. The one for loom can be fixed in a separate rfe. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13550#issuecomment-1542421334 From liach at openjdk.org Wed May 10 15:40:39 2023 From: liach at openjdk.org (Chen Liang) Date: Wed, 10 May 2023 15:40:39 GMT Subject: Withdrawn: 8305669: RuntimeException when running benchmarks through make on Windows/WSL In-Reply-To: References: Message-ID: On Thu, 20 Apr 2023 02:32:37 GMT, Chen Liang wrote: > This patch replaces `FIXPATH` with `FixPath` on individual path argumenets. The root cause might be that JMH requires passing VM args to benchmarks in quotes, which might have triggered incorrect detections in `FIXPATH` (as in comparison, `$1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED` right above this patch seems to work fine) > Also removed a useless and wrong Java flag to the java running javac, originally intended to enable running `make test TEST="loom.obsolete"` benchmarks. > > Since I only have a windows cygwin environment, I am not quite sure if this works elsewhere. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/13550 From jiangli at openjdk.org Wed May 10 16:23:06 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 10 May 2023 16:23:06 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v11] In-Reply-To: References: Message-ID: <8XdK5PaDhcdKRH67l1erHK0jLMDfo6Gz5qJxN53pGXg=.db58f51d-b5c0-4744-827b-9c74dd6cd9ec@github.com> > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: > > - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target > > - For libjvm.a specifically, exclude operator_new.o > > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols > - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled > - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a > > - Handle long arguments case for static build in make/common/NativeCompilation.gmk > > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS Jiangli Zhou 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 12 additional commits since the last revision: - Merge branch 'master' into JDK-8307194 - Address comments from @erikj79: - Fix to use $(STATIC_LIBS_GRAAL_IMAGE_DIR) in GraalBuilderImage.gmk. - Split the long line at 1281 in Main.gmk. - Fix whitspace errors. - Reflect on @erikj79 suggestions/input on static-libs-image/graal-builder-image and supporting libjvm.a for different JVM_VARIANTS: - Remove the new java-static-libs and java-static-libs-bundles targets. Delete the new make/StaticJvmLibsImage.gmk. - Restore HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and related definitions from previous revision for different $(JVM_VARIANTS). - Change the existing static-libs-image target to build libjvm.a in addition to JDK static libraries. The libjvm.a is placed under images/static-libs/lib/. When building multiple JVM variants, each variant contains its own libjvm.a under images/static-libs/lib/ directory. - Add a new static-libs-graal-image target, which is used by graal-builder-image. Hotspot libjvm.a is not created when building static-libs-graal-image and graal-builder-image targets. - Fix whitespace error in make/StaticJvmLibsImage.gmk. - - Separate building libjvm.a from static-libs-image target, based on input from @jerboaa and @olpaw: - Add a new java-static-libs-image target in Main.gmk for creating the JDK .a static libraries and libjvm.a super set. The static libraries are placed in images/static-libs/lib. The existing static-libs-image target is not affected and will not include hotspot libjvm.a. - Add java-static-libs-bundles target in Bundles.gmk. The created .tar.gz bundle contains JDK .a static libraries and hotspot libjvm.a. - Add StaticJvmLibsImage.gmk for placing libjvm.a into images/static-libs/lib. - Further cleanup after incorporating erikj79's suggestion to only build libjvm.a for $(JVM_VARIANT_MAIN) for now: - Change HOTSPOT_VARIANT_STATIC_LIBS_TARGETS to HOTSPOT_VARIANT_MAIN_STATIC_LIBS_TARGETS in Main.gmk. - Change hotspot-$v-static-libs to hotspot-$(JVM_VARIANT_MAIN)-static-libs in Main.gmk. - Update to create and use only hotspot-$(JVM_VARIANT_MAIN)-static-libs, based on @erikj79 input. - Update make/StaticLibsImage.gmk thanks Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> - Update make/StaticLibsImage.gmk Thanks Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> - Update based on @erikj79 review comments and suggestions: - Change to copy libjvm.a for $(JVM_VARIANT_MAIN) only in make/StaticLibsImage.gmk. - Use $(OBJ_SUFFIX) instead of .o in make/modules/java.base/lib/CoreLibraries.gmk. - ... and 2 more: https://git.openjdk.org/jdk/compare/84938550...36526d4f ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13768/files - new: https://git.openjdk.org/jdk/pull/13768/files/45dd2a00..36526d4f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=09-10 Stats: 44134 lines in 1102 files changed: 31678 ins; 5168 del; 7288 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From jiangli at openjdk.org Wed May 10 17:13:13 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 10 May 2023 17:13:13 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v12] In-Reply-To: References: Message-ID: > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: > > - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target > > - For libjvm.a specifically, exclude operator_new.o > > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols > - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled > - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a > > - Handle long arguments case for static build in make/common/NativeCompilation.gmk > > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS Jiangli Zhou 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 13 additional commits since the last revision: - Merge branch 'master' into JDK-8307194 - Merge branch 'master' into JDK-8307194 - Address comments from @erikj79: - Fix to use $(STATIC_LIBS_GRAAL_IMAGE_DIR) in GraalBuilderImage.gmk. - Split the long line at 1281 in Main.gmk. - Fix whitspace errors. - Reflect on @erikj79 suggestions/input on static-libs-image/graal-builder-image and supporting libjvm.a for different JVM_VARIANTS: - Remove the new java-static-libs and java-static-libs-bundles targets. Delete the new make/StaticJvmLibsImage.gmk. - Restore HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and related definitions from previous revision for different $(JVM_VARIANTS). - Change the existing static-libs-image target to build libjvm.a in addition to JDK static libraries. The libjvm.a is placed under images/static-libs/lib/. When building multiple JVM variants, each variant contains its own libjvm.a under images/static-libs/lib/ directory. - Add a new static-libs-graal-image target, which is used by graal-builder-image. Hotspot libjvm.a is not created when building static-libs-graal-image and graal-builder-image targets. - Fix whitespace error in make/StaticJvmLibsImage.gmk. - - Separate building libjvm.a from static-libs-image target, based on input from @jerboaa and @olpaw: - Add a new java-static-libs-image target in Main.gmk for creating the JDK .a static libraries and libjvm.a super set. The static libraries are placed in images/static-libs/lib. The existing static-libs-image target is not affected and will not include hotspot libjvm.a. - Add java-static-libs-bundles target in Bundles.gmk. The created .tar.gz bundle contains JDK .a static libraries and hotspot libjvm.a. - Add StaticJvmLibsImage.gmk for placing libjvm.a into images/static-libs/lib. - Further cleanup after incorporating erikj79's suggestion to only build libjvm.a for $(JVM_VARIANT_MAIN) for now: - Change HOTSPOT_VARIANT_STATIC_LIBS_TARGETS to HOTSPOT_VARIANT_MAIN_STATIC_LIBS_TARGETS in Main.gmk. - Change hotspot-$v-static-libs to hotspot-$(JVM_VARIANT_MAIN)-static-libs in Main.gmk. - Update to create and use only hotspot-$(JVM_VARIANT_MAIN)-static-libs, based on @erikj79 input. - Update make/StaticLibsImage.gmk thanks Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> - Update make/StaticLibsImage.gmk Thanks Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> - ... and 3 more: https://git.openjdk.org/jdk/compare/54e2bacc...ba2e9ce6 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13768/files - new: https://git.openjdk.org/jdk/pull/13768/files/36526d4f..ba2e9ce6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=10-11 Stats: 125 lines in 7 files changed: 26 ins; 96 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From jiangli at openjdk.org Wed May 10 17:29:32 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 10 May 2023 17:29:32 GMT Subject: Integrated: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries In-Reply-To: References: Message-ID: On Wed, 3 May 2023 02:09:22 GMT, Jiangli Zhou wrote: > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: > > - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target > > - For libjvm.a specifically, exclude operator_new.o > > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols > - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled > - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a > > - Handle long arguments case for static build in make/common/NativeCompilation.gmk > > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS This pull request has now been integrated. Changeset: 1964954d Author: Jiangli Zhou URL: https://git.openjdk.org/jdk/commit/1964954da9ac1d020e0b5ba35893f475d86ec909 Stats: 178 lines in 8 files changed: 127 ins; 34 del; 17 mod 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries Reviewed-by: erikj, sgehwolf ------------- PR: https://git.openjdk.org/jdk/pull/13768 From erikj at openjdk.org Wed May 10 20:28:06 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 10 May 2023 20:28:06 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v12] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 17:13:13 GMT, Jiangli Zhou wrote: >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: >> >> - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a >> >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk >> >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > > Jiangli Zhou 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 13 additional commits since the last revision: > > - Merge branch 'master' into JDK-8307194 > - Merge branch 'master' into JDK-8307194 > - Address comments from @erikj79: > - Fix to use $(STATIC_LIBS_GRAAL_IMAGE_DIR) in GraalBuilderImage.gmk. > - Split the long line at 1281 in Main.gmk. > - Fix whitspace errors. > - Reflect on @erikj79 suggestions/input on static-libs-image/graal-builder-image and supporting libjvm.a for different JVM_VARIANTS: > > - Remove the new java-static-libs and java-static-libs-bundles targets. Delete the new make/StaticJvmLibsImage.gmk. > > - Restore HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and related definitions from previous revision for different $(JVM_VARIANTS). > - Change the existing static-libs-image target to build libjvm.a in addition to JDK static libraries. The libjvm.a is placed under images/static-libs/lib/. When building multiple JVM variants, each variant contains its own libjvm.a under images/static-libs/lib/ directory. > > - Add a new static-libs-graal-image target, which is used by graal-builder-image. Hotspot libjvm.a is not created when building static-libs-graal-image and graal-builder-image targets. > - Fix whitespace error in make/StaticJvmLibsImage.gmk. > - - Separate building libjvm.a from static-libs-image target, based on input from @jerboaa and @olpaw: > - Add a new java-static-libs-image target in Main.gmk for creating the JDK .a static libraries and libjvm.a super set. The static libraries are placed in images/static-libs/lib. The existing static-libs-image target is not affected and will not include hotspot libjvm.a. > - Add java-static-libs-bundles target in Bundles.gmk. The created .tar.gz bundle contains JDK .a static libraries and hotspot libjvm.a. > - Add StaticJvmLibsImage.gmk for placing libjvm.a into images/static-libs/lib. > - Further cleanup after incorporating erikj79's suggestion to only build libjvm.a for $(JVM_VARIANT_MAIN) for now: > - Change HOTSPOT_VARIANT_STATIC_LIBS_TARGETS to HOTSPOT_VARIANT_MAIN_STATIC_LIBS_TARGETS in Main.gmk. > - Change hotspot-$v-static-libs to hotspot-$(JVM_VARIANT_MAIN)-static-libs in Main.gmk. > - Update to create and use only hotspot-$(JVM_VARIANT_MAIN)-static-libs, based on @erikj79 input. > - Update make/StaticLibsIm... This change caused all our builds but Linux to fail. Did you verify on other platforms than Linux at all? I see you have GHA turned off. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1542764704 From jiangli at openjdk.org Wed May 10 20:41:56 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 10 May 2023 20:41:56 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v12] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 20:24:30 GMT, Erik Joelsson wrote: > This change caused all our builds but Linux to fail. Did you verify on other platforms than Linux at all? I see you have GHA turned off. Sorry about the issue. There were failed workflows after I merged with the latest JDK master this morning. I canceled the workflow and tried a rerun, which didn't work. I retried with a new commit with merging again. And noticed the GHA was off after merging with the latest master, but didn't know what caused it. The last night tests in the workflow (before merging with the master) were successful. So I proceeded with integration. Please let me know if we should back out or fix forward ... ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1542779168 From dcubed at openjdk.org Wed May 10 20:53:44 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 10 May 2023 20:53:44 GMT Subject: RFR: 8307860: [BACKOUT] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries Message-ID: <6OEYWLAHe0n6aBbuYYGh_8YH0ONMPbRDF_lifL_Bfyg=.b4d7e647-f9df-428f-af72-ed6fc2937668@github.com> This reverts commit 1964954da9ac1d020e0b5ba35893f475d86ec909. ------------- Commit messages: - Revert "8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries" - 8307857: validate-source fails after JDK-8306758 Changes: https://git.openjdk.org/jdk/pull/13918/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13918&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307860 Stats: 179 lines in 9 files changed: 34 ins; 127 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/13918.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13918/head:pull/13918 PR: https://git.openjdk.org/jdk/pull/13918 From dcubed at openjdk.org Wed May 10 20:53:45 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 10 May 2023 20:53:45 GMT Subject: RFR: 8307860: [BACKOUT] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries In-Reply-To: <6OEYWLAHe0n6aBbuYYGh_8YH0ONMPbRDF_lifL_Bfyg=.b4d7e647-f9df-428f-af72-ed6fc2937668@github.com> References: <6OEYWLAHe0n6aBbuYYGh_8YH0ONMPbRDF_lifL_Bfyg=.b4d7e647-f9df-428f-af72-ed6fc2937668@github.com> Message-ID: On Wed, 10 May 2023 20:44:45 GMT, Daniel D. Daugherty wrote: > This reverts commit 1964954da9ac1d020e0b5ba35893f475d86ec909. This [BACKOUT] is being tested with a Mach5 Tier1 job set. All build tasks except for macosx-x64-debug have run and PASSED at this point. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13918#issuecomment-1542790853 From xuelei at openjdk.org Wed May 10 20:53:56 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 10 May 2023 20:53:56 GMT Subject: RFR: 8307855: update for deprecated sprintf for src/utils Message-ID: <_y76ehEcXfM8bS00DzlNsVoOL3MUIp83ReGFdxsFlDA=.f0fc3530-3e27-49b5-a4f7-4082f2d7d06c@github.com> Hi, May I have this update reviewed? The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the src/utils directory. Thanks, Xuelei ------------- Commit messages: - 8307855: update for deprecated sprintf for src/utils Changes: https://git.openjdk.org/jdk/pull/13915/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13915&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307855 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13915.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13915/head:pull/13915 PR: https://git.openjdk.org/jdk/pull/13915 From erikj at openjdk.org Wed May 10 20:56:49 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 10 May 2023 20:56:49 GMT Subject: RFR: 8307860: [BACKOUT] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries In-Reply-To: <6OEYWLAHe0n6aBbuYYGh_8YH0ONMPbRDF_lifL_Bfyg=.b4d7e647-f9df-428f-af72-ed6fc2937668@github.com> References: <6OEYWLAHe0n6aBbuYYGh_8YH0ONMPbRDF_lifL_Bfyg=.b4d7e647-f9df-428f-af72-ed6fc2937668@github.com> Message-ID: On Wed, 10 May 2023 20:44:45 GMT, Daniel D. Daugherty wrote: > This reverts commit 1964954da9ac1d020e0b5ba35893f475d86ec909. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13918#pullrequestreview-1421364204 From dcubed at openjdk.org Wed May 10 21:04:43 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 10 May 2023 21:04:43 GMT Subject: RFR: 8307860: [BACKOUT] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries In-Reply-To: References: <6OEYWLAHe0n6aBbuYYGh_8YH0ONMPbRDF_lifL_Bfyg=.b4d7e647-f9df-428f-af72-ed6fc2937668@github.com> Message-ID: On Wed, 10 May 2023 20:54:04 GMT, Erik Joelsson wrote: >> This reverts commit 1964954da9ac1d020e0b5ba35893f475d86ec909. > > Marked as reviewed by erikj (Reviewer). @erikj79 - Thanks for the review! I'm still waiting for the macosx-x64-debug build to finish. The workdir logs show that the build is chugging along... ------------- PR Comment: https://git.openjdk.org/jdk/pull/13918#issuecomment-1542805804 From erikj at openjdk.org Wed May 10 21:04:54 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 10 May 2023 21:04:54 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v12] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 20:38:50 GMT, Jiangli Zhou wrote: > > This change caused all our builds but Linux to fail. Did you verify on other platforms than Linux at all? I see you have GHA turned off. > > Sorry about the issue. There were failed workflows after I merged with the latest JDK master this morning. I canceled the workflow and tried a rerun, which didn't work. I retried with a new commit with merging again. And noticed the GHA was off after merging with the latest master, but didn't know what caused it. The last night tests in the workflow (before merging with the master) were successful. So I proceeded with integration. > > Please let me know if we should back out or fix forward ... Dan is already backing out in https://github.com/openjdk/jdk/pull/13918, so we have plenty of time to figure out the issues. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1542805621 From dcubed at openjdk.org Wed May 10 21:11:47 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 10 May 2023 21:11:47 GMT Subject: RFR: 8307860: [BACKOUT] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries In-Reply-To: <6OEYWLAHe0n6aBbuYYGh_8YH0ONMPbRDF_lifL_Bfyg=.b4d7e647-f9df-428f-af72-ed6fc2937668@github.com> References: <6OEYWLAHe0n6aBbuYYGh_8YH0ONMPbRDF_lifL_Bfyg=.b4d7e647-f9df-428f-af72-ed6fc2937668@github.com> Message-ID: On Wed, 10 May 2023 20:44:45 GMT, Daniel D. Daugherty wrote: > This reverts commit 1964954da9ac1d020e0b5ba35893f475d86ec909. All builds have passed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13918#issuecomment-1542811200 From dcubed at openjdk.org Wed May 10 21:11:48 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 10 May 2023 21:11:48 GMT Subject: Integrated: 8307860: [BACKOUT] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries In-Reply-To: <6OEYWLAHe0n6aBbuYYGh_8YH0ONMPbRDF_lifL_Bfyg=.b4d7e647-f9df-428f-af72-ed6fc2937668@github.com> References: <6OEYWLAHe0n6aBbuYYGh_8YH0ONMPbRDF_lifL_Bfyg=.b4d7e647-f9df-428f-af72-ed6fc2937668@github.com> Message-ID: On Wed, 10 May 2023 20:44:45 GMT, Daniel D. Daugherty wrote: > This reverts commit 1964954da9ac1d020e0b5ba35893f475d86ec909. This pull request has now been integrated. Changeset: edc4adb7 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/edc4adb77e755b8076c0ab85acab313384397428 Stats: 178 lines in 8 files changed: 34 ins; 127 del; 17 mod 8307860: [BACKOUT] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/13918 From jiangli at openjdk.org Wed May 10 21:16:57 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 10 May 2023 21:16:57 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v12] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 17:13:13 GMT, Jiangli Zhou wrote: >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: >> >> - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a >> >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk >> >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > > Jiangli Zhou 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 13 additional commits since the last revision: > > - Merge branch 'master' into JDK-8307194 > - Merge branch 'master' into JDK-8307194 > - Address comments from @erikj79: > - Fix to use $(STATIC_LIBS_GRAAL_IMAGE_DIR) in GraalBuilderImage.gmk. > - Split the long line at 1281 in Main.gmk. > - Fix whitspace errors. > - Reflect on @erikj79 suggestions/input on static-libs-image/graal-builder-image and supporting libjvm.a for different JVM_VARIANTS: > > - Remove the new java-static-libs and java-static-libs-bundles targets. Delete the new make/StaticJvmLibsImage.gmk. > > - Restore HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and related definitions from previous revision for different $(JVM_VARIANTS). > - Change the existing static-libs-image target to build libjvm.a in addition to JDK static libraries. The libjvm.a is placed under images/static-libs/lib/. When building multiple JVM variants, each variant contains its own libjvm.a under images/static-libs/lib/ directory. > > - Add a new static-libs-graal-image target, which is used by graal-builder-image. Hotspot libjvm.a is not created when building static-libs-graal-image and graal-builder-image targets. > - Fix whitespace error in make/StaticJvmLibsImage.gmk. > - - Separate building libjvm.a from static-libs-image target, based on input from @jerboaa and @olpaw: > - Add a new java-static-libs-image target in Main.gmk for creating the JDK .a static libraries and libjvm.a super set. The static libraries are placed in images/static-libs/lib. The existing static-libs-image target is not affected and will not include hotspot libjvm.a. > - Add java-static-libs-bundles target in Bundles.gmk. The created .tar.gz bundle contains JDK .a static libraries and hotspot libjvm.a. > - Add StaticJvmLibsImage.gmk for placing libjvm.a into images/static-libs/lib. > - Further cleanup after incorporating erikj79's suggestion to only build libjvm.a for $(JVM_VARIANT_MAIN) for now: > - Change HOTSPOT_VARIANT_STATIC_LIBS_TARGETS to HOTSPOT_VARIANT_MAIN_STATIC_LIBS_TARGETS in Main.gmk. > - Change hotspot-$v-static-libs to hotspot-$(JVM_VARIANT_MAIN)-static-libs in Main.gmk. > - Update to create and use only hotspot-$(JVM_VARIANT_MAIN)-static-libs, based on @erikj79 input. > - Update make/StaticLibsIm... > > > This change caused all our builds but Linux to fail. Did you verify on other platforms than Linux at all? I see you have GHA turned off. > > > > > > Sorry about the issue. There were failed workflows after I merged with the latest JDK master this morning. I canceled the workflow and tried a rerun, which didn't work. I retried with a new commit with merging again. And noticed the GHA was off after merging with the latest master, but didn't know what caused it. The last night tests in the workflow (before merging with the master) were successful. So I proceeded with integration. > > Please let me know if we should back out or fix forward ... > > Dan is already backing out in #13918, so we have plenty of time to figure out the issues. Ok, thanks! Sorry about the build failure again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1542817870 From jiangli at openjdk.org Wed May 10 21:19:50 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 10 May 2023 21:19:50 GMT Subject: RFR: 8307860: [BACKOUT] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries In-Reply-To: References: <6OEYWLAHe0n6aBbuYYGh_8YH0ONMPbRDF_lifL_Bfyg=.b4d7e647-f9df-428f-af72-ed6fc2937668@github.com> Message-ID: On Wed, 10 May 2023 21:07:23 GMT, Daniel D. Daugherty wrote: >> This reverts commit 1964954da9ac1d020e0b5ba35893f475d86ec909. > > All builds have passed. Thank you, @dcubed-ojdk! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13918#issuecomment-1542821136 From prr at openjdk.org Wed May 10 22:02:42 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 10 May 2023 22:02:42 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v2] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 22:09:26 GMT, Alexander Zvegintsev wrote: > > I want to work through the scenarios and how much of it is specific to the behaviours of the API you are using and so forth. Since you use the Preferences API for saving the token, if you keyed it off the Robot class rather than the internal API class then anyone using the Preferences API could delete the token, couldn't they ? > > Right now it can be read with a simple call: `System.out.println(Preferences.userRoot().node("/sun/awt/screencast").get("restoreToken", ""));` (modification is also simple). > > Moving to Robot doesn't change anything in this regard. So anyone can delete it. I was thinking it better to make it an API class, but we can discuss later when we are sure we want the API at all. > > And we presumably can store alongside the token, info about the screens attached at the time we obtained the token ? > > We can try to do that and switch it depending on the area requested, but I tried to keep it simple. If it can avoid the need for dialogs in some additional cases, its worth it, but we can add this later, correct ? But it may be worth doing now - see comments below. > > > Can you point (here in the implementation review) to the exact native functions that popup up the dialog ? I'm still trying to find my way through that code. Is it opaque to the caller (us) what the user actually approved ? > > (It is collapsed by the github in the review, so links are to the branch) > > basically if you [didn't provide a correct token or no token at all](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L530-L537) to [SelectSources call](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L539-L546) it will prompt with dialog right after [the Start call](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L677-L685) > > > I can't imagine why we would need to reset "we have all permissions" to "we have no permissions" so I'm supposing the issue is when they didn't grant permissions .. but if they "deny" permissions that's surely different than "this token is no longer valid" ? > > It is not for the "we have all permissions" case, it is for the case when we only have a permission to some screens. So it won't hurt. But how does the app know when to call it ? > > > The first time we need a permission for the screencast API there is a dialog. The user makes some choices and we then choose to save a token so that the user isn't prompted again. We must at least know though that they approved SOMETHING but we don't know what ? Or do we ? > > No we don't. > > We receive the response [callbackScreenCastStart](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L586-L591) as a separate streams for each allowed display. > > Based on this response we [building a list of **available** displays](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L73). So denied screens will not be there. OK, so to make sure I understand, you use the token to see if you can obtain a stream for all connected displays. If any "fail" you know the user didn't approve that. So we can do this every time right ? And in conjunction with knowing which screen[s] were connected when we captured the token we know the situation changed and so we know it is appropriate to ignore the stored token - causing the user to be re-prompted. And even if the screens have changed if we already have the token we need for THIS screen capture we know whether we already have the permission we need. And if we do then we just use it and don't cause a user re-prompt. At this point I think we've done everything that "revoke" was needed for. Then [if I have everything right] the only open question is whether when permissions to the required screen or screens was previously denied, do we re-prompt ? My take is that we do not "store" a token that denies access. So next time the app is run they will be re-prompted. But we *probably* don't want to keep re-prompting within this running instance of the JDK. BTW "the app" means "any app that can find this token, doesn't it" ? This is probably what we want, and this is also how the Apple permissions work .. but maybe non-intuitive to users who don't know that both App A and App B are written in Java. I don't propose doing anything here, since if we tied it to a specific "class" then it would not work very well for 500 individual regression tests that each need robot :-) > > At this point we can compare this result with the screens got from X11 API(won't be compatible with Wayland, where we also want to reuse it later) or with Wayland(+1 dependency at this point). > > > If they DENY, would we save that ? Interesting question because if we don't save something we'll keep spamming them until they approve :-) > > The [DENY case](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L586-L591) propagated to java and we are throwing the security exception. > > > Next time, what happens if for some reaon the token is no longer valid ? > > It just prompts a permission request again. > > > And what might make it invalid ? > > Adding or removing a display for example. > > > If the user denied screen 2, or added screen 2 later, would that not result in an invalid token and we'd know to ask again ? No reset needed ? Also I can't figure out if "validating" the token can cause the dialog as a side effect or if there's some API we explicitly call to request a new token. > > Let me elaborate how this `restore_token` works: > > We may or may not provide the `restore_token` while calling `SelectSources`. > > If the token provided is not valid (we have no control over this, it's checked on the system side), the permission prompt will appear. > > Later, after granting permissions, the `restore_token` is returned by [Start](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.Start) callback. We should [update](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L593-L611) it, as it may not be the same as we provided before. > > When we are calling the `resetScreenCapturePermission` we are not actually revoking the token from the system, we are just doesn't add it to the `SelectSources` call. (but, if needed, we can provide it later and it should work). I think most people reading the API would interpret it as "rm , not "don't use the token". And since its not tied to a particular invocation of Robot screen capture APIs it means that if you then call System.exit(0) right afterwards, so no new token is captured, it didn't do what you thought it did. Also if we follow the suggested policy of not storing tokens which don't grant permission then we'd also not over-write it in that case. > > So whenever we don't provide a valid token, we get a confirmation prompt. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1542866062 From jlahoda at openjdk.org Thu May 11 07:26:47 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 11 May 2023 07:26:47 GMT Subject: RFR: JDK-8306983: Do not invoke external programs when switch terminal to raw mode on selected platforms [v2] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 20:49:16 GMT, Brian Burkhalter wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjusting build script as suggested on the review. > > src/jdk.internal.le/linux/native/lible/CLibrary.cpp line 183: > >> 181: JNIEXPORT jint JNICALL Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_isatty >> 182: (JNIEnv *, jobject, jint fd) { >> 183: return isatty(fd); > > Do we care if the native `isatty()` returns zero? Or is this dealt with somewhere else? This method is only used to determine with the fd is attached to a terminal (returns 1) or not (return 0). The reasons why it is not attached to a terminal are not really important. The value is used here: https://github.com/lahodaj/jdk/blob/4cf8f67e43f442a5c48cd30349740ac2cb638d6e/src/jdk.internal.le/unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java#L186 > src/jdk.internal.le/macosx/native/lible/CLibrary.cpp line 187: > >> 185: JNIEXPORT jint JNICALL Java_jdk_internal_org_jline_terminal_impl_jna_osx_CLibraryImpl_isatty >> 186: (JNIEnv *, jobject, jint fd) { >> 187: return isatty(fd); > > Do we care if the native `isatty()` returns zero? Or is this dealt with somewhere else? This method is only used to determine with the fd is attached to a terminal (returns 1) or not (return 0). The reasons why it is not attached to a terminal are not really important. The value is used here: https://github.com/lahodaj/jdk/blob/4cf8f67e43f442a5c48cd30349740ac2cb638d6e/src/jdk.internal.le/unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java#L186 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1190739079 PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1190741351 From duke at openjdk.org Thu May 11 07:43:51 2023 From: duke at openjdk.org (JoKern65) Date: Thu, 11 May 2023 07:43:51 GMT Subject: Integrated: JDK-8307349: Support xlc17 clang toolchain on AIX In-Reply-To: References: Message-ID: <9mB_pPmwJVhF3gFCGYHf1ArzthSyaqFhhnbg0TOnMMU=.26027334-56b2-4863-b166-33e064b947cd@github.com> On Wed, 10 May 2023 11:01:24 GMT, JoKern65 wrote: > The new xlc17 compiler should be supported to build OpenJDK on AIX. This compiler, compared to the currently supported xlc16, has a significantly more recent clang (xlc 17.1.1 uses clang 15) included. > 1. Because the frontend interface of the new compiler (c-flags, Ld-Flags) has changed from an xlc to a clang interface we decided to use the clang toolchain for the new xlc17 compiler. > 2. Unfortunately, the system headers are mainly unchanged, so they do not harmonize with the src/hotspot/share/utilities/globalDefinitions_gcc.hpp which would be used if we totally switch to clang toolchain. So we keep the HOTSPOT_TOOLCHAIN_TYPE=xlc > 3. In src/hotspot/share/utilities/globalDefinitions_xlc.hpp we introduce a new define AIX_XLC_GE_17 which is set if we build with the new xlc17 on AIX. This define will be used in following PRs. This pull request has now been integrated. Changeset: 08fa2698 Author: JoKern65 Committer: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/08fa269886467e6d468d00158a601c3143c32790 Stats: 124 lines in 6 files changed: 98 ins; 1 del; 25 mod 8307349: Support xlc17 clang toolchain on AIX Reviewed-by: erikj, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/13898 From jlaskey at openjdk.org Thu May 11 10:54:12 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 11 May 2023 10:54:12 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v12] In-Reply-To: References: Message-ID: <2hfZpzvDkrICXlLe0Dl09tcVut4zF8ahGixTc8I3yHo=.0b0786e1-d364-4b44-b815-a29ecb2d304a@github.com> > Add flexible main methods and anonymous main classes to the Java language. Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: - Merge branch 'master' into 8306112 - Refactor source code launcher - Typo - Recommended changes #2 - Anonymous main classes renamed to unnamed classes - Add test - Move AnonymousMainClass to parser - Revert java launch - Leave exception alone - Unused variables - ... and 16 more: https://git.openjdk.org/jdk/compare/cc396895...c3cfa837 ------------- Changes: https://git.openjdk.org/jdk/pull/13689/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=11 Stats: 1234 lines in 28 files changed: 1068 ins; 77 del; 89 mod Patch: https://git.openjdk.org/jdk/pull/13689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689 PR: https://git.openjdk.org/jdk/pull/13689 From jlaskey at openjdk.org Thu May 11 11:25:51 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 11 May 2023 11:25:51 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v13] In-Reply-To: References: Message-ID: <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com> > Add flexible main methods and anonymous main classes to the Java language. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Update VirtualParser.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13689/files - new: https://git.openjdk.org/jdk/pull/13689/files/c3cfa837..90b1e981 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=11-12 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689 PR: https://git.openjdk.org/jdk/pull/13689 From stefank at openjdk.org Thu May 11 12:10:39 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 11 May 2023 12:10:39 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v13] In-Reply-To: References: Message-ID: > Hi all, > > Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. > > The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention i s to give the users time to validate and deploy their workloads with the new GC implementation. > > Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clea... Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 932 commits: - Merge remote-tracking branch 'upstream/master' into zgc_generational_review - Make barrier_Relocation inherit from Relocation instead of DataRelocation - ZGC: Generational Co-authored-by: Stefan Karlsson Co-authored-by: Per Liden Co-authored-by: Albert Mingkun Yang Co-authored-by: Erik ?sterlund Co-authored-by: Axel Boldt-Christmas Co-authored-by: Stefan Johansson - UPSTREAM: RISCV tmp reg cleanup resolve_jobject - CLEANUP: barrierSetNMethod_aarch64.cpp - UPSTREAM: assembler_ppc CMPLI Co-authored-by: TheRealMDoerr - UPSTREAM: assembler_ppc ANDI Co-authored-by: TheRealMDoerr - Merge branch 'zgc_generational' into zgc_generational_rebase_target - Workaround failed reservation in ZForwardingTest - ZGC: Generational Co-authored-by: Stefan Karlsson Co-authored-by: Per Liden Co-authored-by: Albert Mingkun Yang Co-authored-by: Erik ?sterlund Co-authored-by: Axel Boldt-Christmas Co-authored-by: Stefan Johansson - ... and 922 more: https://git.openjdk.org/jdk/compare/0cbfbc40...9dd9681b ------------- Changes: https://git.openjdk.org/jdk/pull/13771/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13771&range=12 Stats: 67359 lines in 684 files changed: 58192 ins; 4252 del; 4915 mod Patch: https://git.openjdk.org/jdk/pull/13771.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13771/head:pull/13771 PR: https://git.openjdk.org/jdk/pull/13771 From stefank at openjdk.org Thu May 11 12:12:56 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 11 May 2023 12:12:56 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v13] In-Reply-To: References: Message-ID: > Hi all, > > Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. > > The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention i s to give the users time to validate and deploy their workloads with the new GC implementation. > > Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clea... Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 932 commits: - Merge remote-tracking branch 'upstream/master' into zgc_generational_review - Make barrier_Relocation inherit from Relocation instead of DataRelocation - ZGC: Generational Co-authored-by: Stefan Karlsson Co-authored-by: Per Liden Co-authored-by: Albert Mingkun Yang Co-authored-by: Erik ?sterlund Co-authored-by: Axel Boldt-Christmas Co-authored-by: Stefan Johansson - UPSTREAM: RISCV tmp reg cleanup resolve_jobject - CLEANUP: barrierSetNMethod_aarch64.cpp - UPSTREAM: assembler_ppc CMPLI Co-authored-by: TheRealMDoerr - UPSTREAM: assembler_ppc ANDI Co-authored-by: TheRealMDoerr - Merge branch 'zgc_generational' into zgc_generational_rebase_target - Workaround failed reservation in ZForwardingTest - ZGC: Generational Co-authored-by: Stefan Karlsson Co-authored-by: Per Liden Co-authored-by: Albert Mingkun Yang Co-authored-by: Erik ?sterlund Co-authored-by: Axel Boldt-Christmas Co-authored-by: Stefan Johansson - ... and 922 more: https://git.openjdk.org/jdk/compare/0cbfbc40...9dd9681b ------------- Changes: https://git.openjdk.org/jdk/pull/13771/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13771&range=12 Stats: 67359 lines in 684 files changed: 58192 ins; 4252 del; 4915 mod Patch: https://git.openjdk.org/jdk/pull/13771.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13771/head:pull/13771 PR: https://git.openjdk.org/jdk/pull/13771 From duke at openjdk.org Thu May 11 13:58:39 2023 From: duke at openjdk.org (JoKern65) Date: Thu, 11 May 2023 13:58:39 GMT Subject: RFR: JDK-8307520: set minimum supported CPU architecture to Power8 on AIX Message-ID: In the compile flags, set the minimum supported CPU architecture to Power8 on AIX, because we do not want to support pwr7 architecture any more. ------------- Commit messages: - accidentially changed mode bits - JDK-8307520 Changes: https://git.openjdk.org/jdk/pull/13933/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13933&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307520 Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13933.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13933/head:pull/13933 PR: https://git.openjdk.org/jdk/pull/13933 From mbaesken at openjdk.org Thu May 11 13:58:40 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 11 May 2023 13:58:40 GMT Subject: RFR: JDK-8307520: set minimum supported CPU architecture to Power8 on AIX In-Reply-To: References: Message-ID: On Thu, 11 May 2023 13:27:44 GMT, JoKern65 wrote: > In the compile flags, set the minimum supported CPU architecture to Power8 on AIX, because we do not want to support pwr7 architecture any more. LGTM I would recommend to enable the PR also for our nightly makes to check the flag in the build logs. ------------- Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13933#pullrequestreview-1422645048 From duke at openjdk.org Thu May 11 13:58:41 2023 From: duke at openjdk.org (JoKern65) Date: Thu, 11 May 2023 13:58:41 GMT Subject: RFR: JDK-8307520: set minimum supported CPU architecture to Power8 on AIX In-Reply-To: References: Message-ID: <3EyyWAr5ybkqwPTeNpljYL2PB_2ppdODl7Y8EHaFhvk=.58382686-5771-4f82-8905-9a5e6d9ef6a8@github.com> On Thu, 11 May 2023 13:27:44 GMT, JoKern65 wrote: > In the compile flags, set the minimum supported CPU architecture to Power8 on AIX, because we do not want to support pwr7 architecture any more. Now Pwr8 should be the minimum hardware on AIX to run jdk ------------- PR Comment: https://git.openjdk.org/jdk/pull/13933#issuecomment-1544024177 From stefank at openjdk.org Thu May 11 14:03:29 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 11 May 2023 14:03:29 GMT Subject: RFR: 8307058: Implementation of Generational ZGC [v13] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 12:12:56 GMT, Stefan Karlsson wrote: >> Hi all, >> >> Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. >> >> The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention is to give the users time to validate and deploy their workloads with the new GC implementation. >> >> Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was qu... > > Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 932 commits: > > - Merge remote-tracking branch 'upstream/master' into zgc_generational_review > - Make barrier_Relocation inherit from Relocation instead of DataRelocation > - ZGC: Generational > > Co-authored-by: Stefan Karlsson > Co-authored-by: Per Liden > Co-authored-by: Albert Mingkun Yang > Co-authored-by: Erik ?sterlund > Co-authored-by: Axel Boldt-Christmas > Co-authored-by: Stefan Johansson > - UPSTREAM: RISCV tmp reg cleanup resolve_jobject > - CLEANUP: barrierSetNMethod_aarch64.cpp > - UPSTREAM: assembler_ppc CMPLI > > Co-authored-by: TheRealMDoerr > - UPSTREAM: assembler_ppc ANDI > > Co-authored-by: TheRealMDoerr > - Merge branch 'zgc_generational' into zgc_generational_rebase_target > - Workaround failed reservation in ZForwardingTest > - ZGC: Generational > > Co-authored-by: Stefan Karlsson > Co-authored-by: Per Liden > Co-authored-by: Albert Mingkun Yang > Co-authored-by: Erik ?sterlund > Co-authored-by: Axel Boldt-Christmas > Co-authored-by: Stefan Johansson > - ... and 922 more: https://git.openjdk.org/jdk/compare/0cbfbc40...9dd9681b Thanks all who have helped building Generational ZGC! I think it is time to integrate. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13771#issuecomment-1544037094 From stefank at openjdk.org Thu May 11 14:03:32 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 11 May 2023 14:03:32 GMT Subject: Integrated: 8307058: Implementation of Generational ZGC In-Reply-To: References: Message-ID: On Wed, 3 May 2023 09:04:50 GMT, Stefan Karlsson wrote: > Hi all, > > Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two generations; the young generation where newly allocated objects are born, and the old generation where long-lived objects get promoted to. The motivation for introducing generations is to allow ZGC to reclaim memory faster by not having to walk the entire object graph every time a garbage collection is run. This should make Generational ZGC suitable for more workloads. In particular workloads that previously hit allocation stalls because of high allocation rates, large live sets, or limited spare machine resources, have the potential to work better with Generational ZGC. For an in-depth description of Generational ZGC, see https://openjdk.org/jeps/439. > > The development of Generational ZGC started around the same time as the development of JDK 17. At that point we forked off the Generational ZGC development into its own branch and let non-generational live unaffected in openjdk/jdk. This safe-guarded non-generational ZGC and allowed Generational ZGC to move unhindered, without the shackles of having to fit into another GC implementation's design and quirks. Since then, almost all of the ZGC files have been changed. Moving forward to today, when it's ready for us to upstream Generational ZGC, we now need to deliver Generational ZGC without disrupting our current user-base. We have therefore opted to initially include both versions of ZGC in the code base, but with the intention to deprecate non-generational ZGC in a future release. Existing users running with only -XX:+UseZGC will get the non-generational ZGC, and users that want the new Generational ZGC need to run with -XX:+ZGenerational in addition to -XX:+UseZGC. The intention i s to give the users time to validate and deploy their workloads with the new GC implementation. > > Including both the new evolution of a GC and its legacy predecessor poses a few challenges for us GC developers. The first reaction could be to try to mash the two implementations together and sprinkle the GC code with conditional statements or dynamic dispatches. We have done similar experiments before. When ZGC was first born, we started an experiment where we converted G1 into getting the same features as the evolving ZGC. It was quite clea... This pull request has now been integrated. Changeset: d20034b0 Author: Stefan Karlsson URL: https://git.openjdk.org/jdk/commit/d20034b09c99026e7dc2213f7d88ebdc85e5b1e7 Stats: 67359 lines in 684 files changed: 58192 ins; 4252 del; 4915 mod 8307058: Implementation of Generational ZGC Co-authored-by: Stefan Karlsson Co-authored-by: Erik ?sterlund Co-authored-by: Axel Boldt-Christmas Co-authored-by: Per Liden Co-authored-by: Stefan Johansson Co-authored-by: Albert Mingkun Yang Co-authored-by: Erik Helin Co-authored-by: Roberto Casta?eda Lozano Co-authored-by: Nils Eliasson Co-authored-by: Martin Doerr Co-authored-by: Leslie Zhai Co-authored-by: Fei Yang Co-authored-by: Yadong Wang Reviewed-by: eosterlund, aboldtch, rcastanedalo ------------- PR: https://git.openjdk.org/jdk/pull/13771 From tsteele at openjdk.org Thu May 11 14:14:53 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Thu, 11 May 2023 14:14:53 GMT Subject: RFR: JDK-8307349: Support xlc17 clang toolchain on AIX In-Reply-To: References: Message-ID: On Wed, 10 May 2023 13:52:50 GMT, JoKern65 wrote: >> The new xlc17 compiler should be supported to build OpenJDK on AIX. This compiler, compared to the currently supported xlc16, has a significantly more recent clang (xlc 17.1.1 uses clang 15) included. >> 1. Because the frontend interface of the new compiler (c-flags, Ld-Flags) has changed from an xlc to a clang interface we decided to use the clang toolchain for the new xlc17 compiler. >> 2. Unfortunately, the system headers are mainly unchanged, so they do not harmonize with the src/hotspot/share/utilities/globalDefinitions_gcc.hpp which would be used if we totally switch to clang toolchain. So we keep the HOTSPOT_TOOLCHAIN_TYPE=xlc >> 3. In src/hotspot/share/utilities/globalDefinitions_xlc.hpp we introduce a new define AIX_XLC_GE_17 which is set if we build with the new xlc17 on AIX. This define will be used in following PRs. > > I followed your suggested corrections. Thanks a lot. Thanks for taking on these changes @JoKern65! Happy to have them in place :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/13898#issuecomment-1544059954 From azvegint at openjdk.org Thu May 11 14:16:46 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 11 May 2023 14:16:46 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v2] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 21:59:37 GMT, Phil Race wrote: > > It is not for the "we have all permissions" case, it is for the case when we only have a permission to some screens. So it won't hurt. > > But how does the app know when to call it ? Right now it doesn't know. If the user is not satisfied with the result, he can "reset" it. But it seems to be a weak position. > OK, so to make sure I understand, you use the token to see if you can obtain a stream for all connected displays. If any "fail" you know the user didn't approve that. > > So we can do this every time right ? And in conjunction with knowing which screen[s] were connected when we captured the token we know the situation changed and so we know it is appropriate to ignore the stored token - causing the user to be re-prompted. > > And even if the screens have changed if we already have the token we need for THIS screen capture we know whether we already have the permission we need. And if we do then we just use it and don't cause a user re-prompt. > > At this point I think we've done everything that "revoke" was needed for. The problem is how to relate the tokens to the screens. We don't have some universal id that says that the display we saved earlier is this current display. There is an opaque id of stream: https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.Start Stream properties include: id s Opaque identifier. **Will be unique for this stream and local to this session**. Will persist with future sessions, if they are restored using a restore token. This property was added in version 4 of this interface. Optional. But it didn't help much, as it local to the session(each token - different session), token looks like `0`, `1`, etc We can match the stream layout to the screen layout in the system, but it has its flaws: Let's say we have following layout of screens in system, displays have the same resolution(e.g. 1920*1080): ![image](https://github.com/openjdk/jdk/assets/77687766/92047fe4-ee31-4ae2-9327-c6d6516a34e9) Screen capture permission is granted for `A` and denied for `B`. 1. On a first run we are capturing screen area at `(100, 100, 100, 100)`. 2. We match an acquired `restore_token` to the screen at `(0,0,1920,1080)` 3. User decided to change screens to following layout: ![image](https://github.com/openjdk/jdk/assets/77687766/b68febd1-01f9-4528-a65c-aefa53d3b61a) 4. we are capturing screen area at `(100, 100, 100, 100)` again 5. Oh, we have a `restore_token` for the `(0,0,1920,1080)` screen, let's reuse it. 6. Ouch, we got black pixels because the token was issued for display `A` and it is now `(1920,0,1920,1080)` > Then [if I have everything right] the only open question is whether when permissions to the required screen or screens was previously denied, do we re-prompt ? My take is that we do not "store" a token that denies access. So next time the app is run they will be re-prompted. But we _probably_ don't want to keep re-prompting within this running instance of the JDK. > > BTW "the app" means "any app that can find this token, doesn't it" ? Yes, it is currently shared between Java applications for the same user. > Also if we follow the suggested policy of not storing tokens which don't grant permission then we'd also not over-write it in that case. Currently we only overwrite tokens when we get a new one from the system. In the full DENY case, we do not receive any token. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1544062418 From jlahoda at openjdk.org Thu May 11 14:17:56 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 11 May 2023 14:17:56 GMT Subject: RFR: JDK-8306983: Do not invoke external programs when switch terminal to raw mode on selected platforms [v3] In-Reply-To: References: Message-ID: > To support JShell and other usecases, the JDK uses JLine, which provides line-editing functionality inside a terminal. > > JLine has several ways to work with the terminal, based on various additional libraries and tools. Most of them are not directly usable inside the JDK, so currently, on non-Windows platforms, the JLine inside the JDK will use external programs, like `stty`, to inspect the terminal's properties and to switch the terminal to raw mode. > > This is slightly problematic, as the external programs might be missing, and while this is not that big problem for JShell, it might be a problem for other potential uses of JLine, like using it inside `System.console()`. > > So, the proposal here is to call the corresponding native methods directly, on selected platforms for now (Linux and Mac OS/X), instead of invoking the external programs. On Windows, this has always been the case, we are using a custom implementation of the interface that maps native and Java function for JNA there, and the proposal is to do the same here. We take the appropriate mapping interface for JNA, and provide hand-written implementation for it, using JNI. > > The Windows implementation is mostly unchanged, the changes are mostly non-Windows only. The overview of the changes is: > - `LastErrorException` is moved from the Windows-specific code to the platform-neutral code, as it is used by all the native implementations. This is the only change that directly affects the Windows-specific code > - `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java` and `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java` are created based on the corresponding files from JLine. In JLine, these files directly call platform-specific implementations, but in this patch, the platform specific code is commented out, and replaced with calls to `JDKNativePty`, which is a new platform-specific class, that delegates to the actual platform-specific implementations. Note the `JnaNativePty.java` and `JnaTerminalProvider.java` already exist in the Windows part, but have different pieces of code commented out, which makes them substantially different. > - for Linux and Mac OS/X, there are platform-specific implementations based on the corresponding code from JLine, with the hand-written JNI-based implementation of the JNA-based existing interfaces. They also have an implementation of `JDKNativePty`, which just delegates to the given platform's `"NativePty"` imple... Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Reflecting review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13687/files - new: https://git.openjdk.org/jdk/pull/13687/files/4cf8f67e..edeba637 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13687&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13687&range=01-02 Stats: 63 lines in 2 files changed: 24 ins; 24 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/13687.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13687/head:pull/13687 PR: https://git.openjdk.org/jdk/pull/13687 From erikj at openjdk.org Thu May 11 15:38:42 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 11 May 2023 15:38:42 GMT Subject: RFR: JDK-8307520: set minimum supported CPU architecture to Power8 on AIX In-Reply-To: References: Message-ID: On Thu, 11 May 2023 13:27:44 GMT, JoKern65 wrote: > In the compile flags, set the minimum supported CPU architecture to Power8 on AIX, because we do not want to support pwr7 architecture any more. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13933#pullrequestreview-1422899470 From jlu at openjdk.org Thu May 11 15:48:40 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 11 May 2023 15:48:40 GMT Subject: RFR: 8306597: Improve string formatting in EquivMapsGenerator.java Message-ID: Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK). The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, `EquivMapsGenerator.java` builds the same. ------------- Commit messages: - Replace ws with escaped newline - get rid of ws - Reduce duplication - Merge master and resolve conflicts - Reorder methods / text variables - Use Java text blocks and String format Changes: https://git.openjdk.org/jdk/pull/13935/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13935&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306597 Stats: 164 lines in 1 file changed: 73 ins; 63 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/13935.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13935/head:pull/13935 PR: https://git.openjdk.org/jdk/pull/13935 From vromero at openjdk.org Thu May 11 16:15:39 2023 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 11 May 2023 16:15:39 GMT Subject: RFR: JDK-8306983: Do not invoke external programs when switch terminal to raw mode on selected platforms [v3] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 14:17:56 GMT, Jan Lahoda wrote: >> To support JShell and other usecases, the JDK uses JLine, which provides line-editing functionality inside a terminal. >> >> JLine has several ways to work with the terminal, based on various additional libraries and tools. Most of them are not directly usable inside the JDK, so currently, on non-Windows platforms, the JLine inside the JDK will use external programs, like `stty`, to inspect the terminal's properties and to switch the terminal to raw mode. >> >> This is slightly problematic, as the external programs might be missing, and while this is not that big problem for JShell, it might be a problem for other potential uses of JLine, like using it inside `System.console()`. >> >> So, the proposal here is to call the corresponding native methods directly, on selected platforms for now (Linux and Mac OS/X), instead of invoking the external programs. On Windows, this has always been the case, we are using a custom implementation of the interface that maps native and Java function for JNA there, and the proposal is to do the same here. We take the appropriate mapping interface for JNA, and provide hand-written implementation for it, using JNI. >> >> The Windows implementation is mostly unchanged, the changes are mostly non-Windows only. The overview of the changes is: >> - `LastErrorException` is moved from the Windows-specific code to the platform-neutral code, as it is used by all the native implementations. This is the only change that directly affects the Windows-specific code >> - `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java` and `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java` are created based on the corresponding files from JLine. In JLine, these files directly call platform-specific implementations, but in this patch, the platform specific code is commented out, and replaced with calls to `JDKNativePty`, which is a new platform-specific class, that delegates to the actual platform-specific implementations. Note the `JnaNativePty.java` and `JnaTerminalProvider.java` already exist in the Windows part, but have different pieces of code commented out, which makes them substantially different. >> - for Linux and Mac OS/X, there are platform-specific implementations based on the corresponding code from JLine, with the hand-written JNI-based implementation of the JNA-based existing interfaces. They also have an implementation of `JDKNativePty`, which just delegates to the given platform's `"Nati... > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review feedback. src/jdk.internal.le/linux/classes/jdk/internal/org/jline/terminal/impl/jna/linux/CLibrary.java line 2: > 1: /* > 2: * Copyright (c) 2002-2020, the original author or authors. 2023 only? src/jdk.internal.le/linux/classes/jdk/internal/org/jline/terminal/impl/jna/linux/CLibrary.java line 16: > 14: import java.util.List; > 15: > 16: //import com.sun.jna.LastErrorException; there is a lot of commented code in this file, not sure if it has a purpose or just left overs? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1191336939 PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1191336400 From jlahoda at openjdk.org Thu May 11 16:29:05 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 11 May 2023 16:29:05 GMT Subject: RFR: JDK-8306983: Do not invoke external programs when switch terminal to raw mode on selected platforms [v3] In-Reply-To: References: Message-ID: <0FgB-dcc7qb7_2KzkJd3vSwgx-xHwGAUOVYxqF2EXS4=.92ac158b-1389-41a5-890c-a23a083a0563@github.com> On Thu, 11 May 2023 15:15:02 GMT, Vicente Romero wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Reflecting review feedback. > > src/jdk.internal.le/linux/classes/jdk/internal/org/jline/terminal/impl/jna/linux/CLibrary.java line 2: > >> 1: /* >> 2: * Copyright (c) 2002-2020, the original author or authors. > > 2023 only? This is the original header from JLine, which we generally keep. > src/jdk.internal.le/linux/classes/jdk/internal/org/jline/terminal/impl/jna/linux/CLibrary.java line 16: > >> 14: import java.util.List; >> 15: >> 16: //import com.sun.jna.LastErrorException; > > there is a lot of commented code in this file, not sure if it has a purpose or just left overs? I've intentionally left the original JLine code commented here and on other places, to see what the code was doing originally, and to possibly aid future merges of new versions of JLine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1191427112 PR Review Comment: https://git.openjdk.org/jdk/pull/13687#discussion_r1191428160 From vromero at openjdk.org Thu May 11 16:39:07 2023 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 11 May 2023 16:39:07 GMT Subject: RFR: JDK-8306983: Do not invoke external programs when switch terminal to raw mode on selected platforms [v3] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 14:17:56 GMT, Jan Lahoda wrote: >> To support JShell and other usecases, the JDK uses JLine, which provides line-editing functionality inside a terminal. >> >> JLine has several ways to work with the terminal, based on various additional libraries and tools. Most of them are not directly usable inside the JDK, so currently, on non-Windows platforms, the JLine inside the JDK will use external programs, like `stty`, to inspect the terminal's properties and to switch the terminal to raw mode. >> >> This is slightly problematic, as the external programs might be missing, and while this is not that big problem for JShell, it might be a problem for other potential uses of JLine, like using it inside `System.console()`. >> >> So, the proposal here is to call the corresponding native methods directly, on selected platforms for now (Linux and Mac OS/X), instead of invoking the external programs. On Windows, this has always been the case, we are using a custom implementation of the interface that maps native and Java function for JNA there, and the proposal is to do the same here. We take the appropriate mapping interface for JNA, and provide hand-written implementation for it, using JNI. >> >> The Windows implementation is mostly unchanged, the changes are mostly non-Windows only. The overview of the changes is: >> - `LastErrorException` is moved from the Windows-specific code to the platform-neutral code, as it is used by all the native implementations. This is the only change that directly affects the Windows-specific code >> - `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java` and `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java` are created based on the corresponding files from JLine. In JLine, these files directly call platform-specific implementations, but in this patch, the platform specific code is commented out, and replaced with calls to `JDKNativePty`, which is a new platform-specific class, that delegates to the actual platform-specific implementations. Note the `JnaNativePty.java` and `JnaTerminalProvider.java` already exist in the Windows part, but have different pieces of code commented out, which makes them substantially different. >> - for Linux and Mac OS/X, there are platform-specific implementations based on the corresponding code from JLine, with the hand-written JNI-based implementation of the JNA-based existing interfaces. They also have an implementation of `JDKNativePty`, which just delegates to the given platform's `"Nati... > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review feedback. Marked as reviewed by vromero (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13687#pullrequestreview-1423023134 From jlu at openjdk.org Thu May 11 20:21:57 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 11 May 2023 20:21:57 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v6] In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> Message-ID: > This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. > > In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Convert the merged master changes to UTF-8 - Merge master and fix conflicts - Close streams when finished loading into props - Adjust CF test to read in with UTF-8 to fix failing test - Reconvert CS.properties to UTF-8 - Revert all changes to CurrencySymbols.properties - Bug6204853 should not be converted - Copyright year for CompileProperties - Redo translation for CS.properties - Spot convert CurrencySymbols.properties - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a ------------- Changes: https://git.openjdk.org/jdk/pull/12726/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=05 Stats: 28877 lines in 493 files changed: 14 ins; 1 del; 28862 mod Patch: https://git.openjdk.org/jdk/pull/12726.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12726/head:pull/12726 PR: https://git.openjdk.org/jdk/pull/12726 From naoto at openjdk.org Thu May 11 20:37:40 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 11 May 2023 20:37:40 GMT Subject: RFR: 8306597: Improve string formatting in EquivMapsGenerator.java In-Reply-To: References: Message-ID: On Thu, 11 May 2023 15:40:50 GMT, Justin Lu wrote: > Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK). > > The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, `EquivMapsGenerator.java` builds the same. Looks good, with some cosmetic suggestions make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 269: > 267: * or visit www.oracle.com if you need additional information or have any > 268: * questions. > 269: */\n Can be a simple new line instead of `\n`. Also holds for other text blocks. make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 272: > 270: """; > 271: > 272: private static final String headerText = Not your change, but I'd capitalize those static final Strings make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 295: > 293: } > 294: > 295: private static final String getlsrText(){ getLSRText? ------------- PR Review: https://git.openjdk.org/jdk/pull/13935#pullrequestreview-1423387718 PR Review Comment: https://git.openjdk.org/jdk/pull/13935#discussion_r1191658464 PR Review Comment: https://git.openjdk.org/jdk/pull/13935#discussion_r1191661027 PR Review Comment: https://git.openjdk.org/jdk/pull/13935#discussion_r1191663140 From jlu at openjdk.org Thu May 11 21:39:50 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 11 May 2023 21:39:50 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v6] In-Reply-To: References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> Message-ID: On Thu, 11 May 2023 20:21:57 GMT, Justin Lu wrote: >> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. >> >> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. > > Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Convert the merged master changes to UTF-8 > - Merge master and fix conflicts > - Close streams when finished loading into props > - Adjust CF test to read in with UTF-8 to fix failing test > - Reconvert CS.properties to UTF-8 > - Revert all changes to CurrencySymbols.properties > - Bug6204853 should not be converted > - Copyright year for CompileProperties > - Redo translation for CS.properties > - Spot convert CurrencySymbols.properties > - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a Wondering if anyone has any thoughts on the consequences of this PR, in relation to Intellj's (and other IDEs) default encoding for .properties files. Intellj sets the default encoding for .properties files to ISO-8859-1, which would be the wrong encoding if the .properties files are converted to UTF-8 native. This would cause certain key,values to be skewed when represented in the file. Although the default file-encoding for .properties can be switched to UTF-8, it is not the default. Wondering what some solutions/thoughts to this are. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1544708830 From naoto at openjdk.org Thu May 11 21:51:13 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 11 May 2023 21:51:13 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v6] In-Reply-To: References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> Message-ID: <2apKDcin5cwY53zz5jOIPhqm7cCWhyYMdsXGU4TauEk=.781d695e-39fe-46f7-bd03-be514ca0b85c@github.com> On Thu, 11 May 2023 20:21:57 GMT, Justin Lu wrote: >> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. >> >> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. > > Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Convert the merged master changes to UTF-8 > - Merge master and fix conflicts > - Close streams when finished loading into props > - Adjust CF test to read in with UTF-8 to fix failing test > - Reconvert CS.properties to UTF-8 > - Revert all changes to CurrencySymbols.properties > - Bug6204853 should not be converted > - Copyright year for CompileProperties > - Redo translation for CS.properties > - Spot convert CurrencySymbols.properties > - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a I think this is fine, as those properties files are JDK's own. I believe the benefit of moving to UTF-8 outweighs the issue you wrote, which can be remedied by changing the encoding in the IDEs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1544722480 From jlu at openjdk.org Thu May 11 21:53:19 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 11 May 2023 21:53:19 GMT Subject: RFR: 8306597: Improve string formatting in EquivMapsGenerator.java [v2] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 20:34:48 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with three additional commits since the last revision: >> >> - Adjust new lines to appease jcheck? >> - Review: remove new line literals for new lines >> - Review: fix method / var names > > Looks good, with some cosmetic suggestions Thanks for the review @naotoj , implemented the suggestions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13935#issuecomment-1544713696 From jlu at openjdk.org Thu May 11 21:53:17 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 11 May 2023 21:53:17 GMT Subject: RFR: 8306597: Improve string formatting in EquivMapsGenerator.java [v2] In-Reply-To: References: Message-ID: > Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK). > > The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, the Locale equivalencies builds the same. Justin Lu has updated the pull request incrementally with three additional commits since the last revision: - Adjust new lines to appease jcheck? - Review: remove new line literals for new lines - Review: fix method / var names ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13935/files - new: https://git.openjdk.org/jdk/pull/13935/files/7a43ab93..9574a984 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13935&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13935&range=00-01 Stats: 16 lines in 1 file changed: 6 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/13935.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13935/head:pull/13935 PR: https://git.openjdk.org/jdk/pull/13935 From jlu at openjdk.org Thu May 11 22:23:47 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 11 May 2023 22:23:47 GMT Subject: RFR: 8306597: Improve string formatting in EquivMapsGenerator.java [v3] In-Reply-To: References: Message-ID: > Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK). > > The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, the Locale equivalencies builds the same. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Remove more ws in text block ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13935/files - new: https://git.openjdk.org/jdk/pull/13935/files/9574a984..33fd7993 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13935&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13935&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13935.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13935/head:pull/13935 PR: https://git.openjdk.org/jdk/pull/13935 From duke at openjdk.org Fri May 12 07:05:55 2023 From: duke at openjdk.org (JoKern65) Date: Fri, 12 May 2023 07:05:55 GMT Subject: Integrated: JDK-8307520: set minimum supported CPU architecture to Power8 on AIX In-Reply-To: References: Message-ID: On Thu, 11 May 2023 13:27:44 GMT, JoKern65 wrote: > In the compile flags, set the minimum supported CPU architecture to Power8 on AIX, because we do not want to support pwr7 architecture any more. This pull request has now been integrated. Changeset: 5f1f9460 Author: JoKern65 Committer: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/5f1f9460d75731513048a3bf205bc1ee6e5c483b Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 mod 8307520: set minimum supported CPU architecture to Power8 on AIX Reviewed-by: mbaesken, erikj ------------- PR: https://git.openjdk.org/jdk/pull/13933 From duke at openjdk.org Fri May 12 12:08:45 2023 From: duke at openjdk.org (JoKern65) Date: Fri, 12 May 2023 12:08:45 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code Message-ID: When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. With this PR we address only the platform dependent code changes. ------------- Commit messages: - JDK-8306304 Changes: https://git.openjdk.org/jdk/pull/13953/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13953&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306304 Stats: 36 lines in 9 files changed: 7 ins; 0 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/13953.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13953/head:pull/13953 PR: https://git.openjdk.org/jdk/pull/13953 From erikj at openjdk.org Fri May 12 12:50:43 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 12 May 2023 12:50:43 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code In-Reply-To: References: Message-ID: On Fri, 12 May 2023 12:01:43 GMT, JoKern65 wrote: > When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". > Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. > A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > With this PR we address only the platform dependent code changes. Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13953#pullrequestreview-1424445347 From duke at openjdk.org Fri May 12 14:09:43 2023 From: duke at openjdk.org (JoKern65) Date: Fri, 12 May 2023 14:09:43 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code In-Reply-To: References: Message-ID: On Fri, 12 May 2023 12:01:43 GMT, JoKern65 wrote: > When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". > Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. > A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > With this PR we address only the platform dependent code changes. Thank you for reviewing ------------- PR Comment: https://git.openjdk.org/jdk/pull/13953#issuecomment-1545806719 From thartmann at openjdk.org Fri May 12 14:18:45 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 12 May 2023 14:18:45 GMT Subject: RFR: 8307855: update for deprecated sprintf for src/utils In-Reply-To: <_y76ehEcXfM8bS00DzlNsVoOL3MUIp83ReGFdxsFlDA=.f0fc3530-3e27-49b5-a4f7-4082f2d7d06c@github.com> References: <_y76ehEcXfM8bS00DzlNsVoOL3MUIp83ReGFdxsFlDA=.f0fc3530-3e27-49b5-a4f7-4082f2d7d06c@github.com> Message-ID: On Wed, 10 May 2023 18:26:40 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have this update reviewed? > > The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the src/utils directory. > > Thanks, > Xuelei Looks good to me otherwise. src/utils/hsdis/binutils/hsdis-binutils.c line 2: > 1: /* > 2: 3* Copyright (c) 2008, 2023, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2008, 2023, Oracle and/or its affiliates. All rights reserved. ------------- Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13915#pullrequestreview-1424602363 PR Review Comment: https://git.openjdk.org/jdk/pull/13915#discussion_r1192434582 From xuelei at openjdk.org Fri May 12 14:52:59 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 12 May 2023 14:52:59 GMT Subject: RFR: 8307855: update for deprecated sprintf for src/utils [v2] In-Reply-To: <_y76ehEcXfM8bS00DzlNsVoOL3MUIp83ReGFdxsFlDA=.f0fc3530-3e27-49b5-a4f7-4082f2d7d06c@github.com> References: <_y76ehEcXfM8bS00DzlNsVoOL3MUIp83ReGFdxsFlDA=.f0fc3530-3e27-49b5-a4f7-4082f2d7d06c@github.com> Message-ID: > Hi, > > May I have this update reviewed? > > The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the src/utils directory. > > Thanks, > Xuelei Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: update typo in copyright statement ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13915/files - new: https://git.openjdk.org/jdk/pull/13915/files/6a7d4e69..e585bbf0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13915&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13915&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13915.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13915/head:pull/13915 PR: https://git.openjdk.org/jdk/pull/13915 From xuelei at openjdk.org Fri May 12 14:53:02 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 12 May 2023 14:53:02 GMT Subject: RFR: 8307855: update for deprecated sprintf for src/utils [v2] In-Reply-To: References: <_y76ehEcXfM8bS00DzlNsVoOL3MUIp83ReGFdxsFlDA=.f0fc3530-3e27-49b5-a4f7-4082f2d7d06c@github.com> Message-ID: On Fri, 12 May 2023 14:13:22 GMT, Tobias Hartmann wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> update typo in copyright statement > > src/utils/hsdis/binutils/hsdis-binutils.c line 2: > >> 1: /* >> 2: 3* Copyright (c) 2008, 2023, Oracle and/or its affiliates. All rights reserved. > > Suggestion: > > * Copyright (c) 2008, 2023, Oracle and/or its affiliates. All rights reserved. Oops. Thank you for the catch! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13915#discussion_r1192472311 From xuelei at openjdk.org Fri May 12 14:55:53 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 12 May 2023 14:55:53 GMT Subject: Integrated: 8307855: update for deprecated sprintf for src/utils In-Reply-To: <_y76ehEcXfM8bS00DzlNsVoOL3MUIp83ReGFdxsFlDA=.f0fc3530-3e27-49b5-a4f7-4082f2d7d06c@github.com> References: <_y76ehEcXfM8bS00DzlNsVoOL3MUIp83ReGFdxsFlDA=.f0fc3530-3e27-49b5-a4f7-4082f2d7d06c@github.com> Message-ID: On Wed, 10 May 2023 18:26:40 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have this update reviewed? > > The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the src/utils directory. > > Thanks, > Xuelei This pull request has now been integrated. Changeset: 4b0f4213 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.org/jdk/commit/4b0f4213a566c3c6d49c034ab6e022c93c4289b1 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod 8307855: update for deprecated sprintf for src/utils Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/jdk/pull/13915 From tsteele at openjdk.org Fri May 12 15:27:46 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Fri, 12 May 2023 15:27:46 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code In-Reply-To: References: Message-ID: On Fri, 12 May 2023 12:01:43 GMT, JoKern65 wrote: > When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". > Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. > A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > With this PR we address only the platform dependent code changes. Marked as reviewed by tsteele (Committer). src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp line 426: > 424: // Missing test if instr is commutative and if we should swap. > 425: if (right.value()->type()->as_LongConstant() && > 426: (x->op() == Bytecodes::_lsub && right.value()->type()->as_LongConstant()->value() == -32768 ) ) { I would prefer a shifted value here as it's usually more readable. If the compiler is being stubborn in its warnings, a comment explaining the magic value would be fine too. src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp line 480: > 478: // Missing test if instr is commutative and if we should swap. > 479: if (right.value()->type()->as_IntConstant() && > 480: (x->op() == Bytecodes::_isub && right.value()->type()->as_IntConstant()->value() == -32768) ) { As above. ------------- PR Review: https://git.openjdk.org/jdk/pull/13953#pullrequestreview-1424714446 PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1192505757 PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1192505876 From tsteele at openjdk.org Fri May 12 15:32:52 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Fri, 12 May 2023 15:32:52 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code In-Reply-To: References: Message-ID: <9lfGtX1kleo6vBh3j6_llYExI2XK4rAorE05To8P6Rk=.aa7f177b-40ac-4105-8fd9-7f72a34de2e6@github.com> On Fri, 12 May 2023 14:07:26 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. >> With this PR we address only the platform dependent code changes. > > Thank you for reviewing Thanks for your PR @JoKern65. I've been wanting to go over the new ibm-clang compiler warnings as well. It would be nice to 'enable warnings as errors' by default after we make the transition. I'm not sure if it's been mentioned to you already. As I understand it, we usually wait for 2 reviews before proceeding with changes unless they are deemed trivial. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13953#issuecomment-1545926700 From duke at openjdk.org Fri May 12 16:16:01 2023 From: duke at openjdk.org (JoKern65) Date: Fri, 12 May 2023 16:16:01 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: Message-ID: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> > When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". > Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. > A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > With this PR we address only the platform dependent code changes. JoKern65 has updated the pull request incrementally with one additional commit since the last revision: cosmetic changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13953/files - new: https://git.openjdk.org/jdk/pull/13953/files/ad3be1bd..d7e2d4f9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13953&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13953&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13953.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13953/head:pull/13953 PR: https://git.openjdk.org/jdk/pull/13953 From duke at openjdk.org Fri May 12 16:16:03 2023 From: duke at openjdk.org (JoKern65) Date: Fri, 12 May 2023 16:16:03 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code In-Reply-To: References: Message-ID: On Fri, 12 May 2023 12:01:43 GMT, JoKern65 wrote: > When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". > Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. > A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > With this PR we address only the platform dependent code changes. Explained change in a new comment -32768 means same as ((-1)<<15)) , but the compiler doesn't like this anymore. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13953#issuecomment-1545976254 From naoto at openjdk.org Fri May 12 16:43:55 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 12 May 2023 16:43:55 GMT Subject: RFR: 8306597: Improve string formatting in EquivMapsGenerator.java [v3] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 22:23:47 GMT, Justin Lu wrote: >> Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK). >> >> The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, the Locale equivalencies builds the same. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Remove more ws in text block make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 344: > 342: } > 343: > 344: private static final String footerText = " }\n\n}"; I'd prefer this one also be uppercased (and moved to a more suitable location). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13935#discussion_r1192593829 From tsteele at openjdk.org Fri May 12 16:55:47 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Fri, 12 May 2023 16:55:47 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> Message-ID: On Fri, 12 May 2023 16:16:01 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. >> With this PR we address only the platform dependent code changes. > > JoKern65 has updated the pull request incrementally with one additional commit since the last revision: > > cosmetic changes Thanks for adding that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13953#issuecomment-1546024401 From jlu at openjdk.org Fri May 12 17:25:45 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 12 May 2023 17:25:45 GMT Subject: RFR: 8306597: Improve string formatting in EquivMapsGenerator.java [v4] In-Reply-To: References: Message-ID: > Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK). > > The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, the Locale equivalencies builds the same. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Review: capitalize and move footer text. Add comments to main ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13935/files - new: https://git.openjdk.org/jdk/pull/13935/files/33fd7993..b4e6e683 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13935&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13935&range=02-03 Stats: 13 lines in 1 file changed: 10 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13935.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13935/head:pull/13935 PR: https://git.openjdk.org/jdk/pull/13935 From jlu at openjdk.org Fri May 12 17:25:49 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 12 May 2023 17:25:49 GMT Subject: RFR: 8306597: Improve string formatting in EquivMapsGenerator.java [v3] In-Reply-To: References: Message-ID: On Fri, 12 May 2023 16:41:18 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove more ws in text block > > make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 344: > >> 342: } >> 343: >> 344: private static final String footerText = " }\n\n}"; > > I'd prefer this one also be uppercased (and moved to a more suitable location). ah, missed that one, probably because of it's location too. Made uppercased and moved closer to the rest of the static text variables. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13935#discussion_r1192626527 From naoto at openjdk.org Fri May 12 17:32:49 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 12 May 2023 17:32:49 GMT Subject: RFR: 8306597: Improve string formatting in EquivMapsGenerator.java [v4] In-Reply-To: References: Message-ID: <2WPO1cEA46g85vIgS3teOTHpeiLRbG0ee7iWQSfazfM=.a7646928-a374-49e9-b488-656483af9ff1@github.com> On Fri, 12 May 2023 17:25:45 GMT, Justin Lu wrote: >> Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK). >> >> The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, the Locale equivalencies builds the same. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Review: capitalize and move footer text. Add comments to main Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13935#pullrequestreview-1424907858 From jvernee at openjdk.org Fri May 12 20:41:45 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 12 May 2023 20:41:45 GMT Subject: RFR: 8307527: MacOS Zero builds fail with undefined FFI_GO_CLOSURES after JDK-8304265 In-Reply-To: References: Message-ID: On Mon, 8 May 2023 10:31:20 GMT, Aleksey Shipilev wrote: >> After thinking a bit, I think I'd prefer this to be addressed in the build system instead. e.g. something like: >> >> >> diff --git a/make/autoconf/lib-ffi.m4 b/make/autoconf/lib-ffi.m4 >> index 0905c3cd225..83de5a4abf7 100644 >> --- a/make/autoconf/lib-ffi.m4 >> +++ b/make/autoconf/lib-ffi.m4 >> @@ -106,6 +106,13 @@ AC_DEFUN_ONCE([LIB_SETUP_LIBFFI], >> AC_MSG_ERROR([Could not find libffi! $HELP_MSG]) >> fi >> >> + if test "x${OPENJDK_TARGET_CPU}" = "xaarch64" && test "x${OPENJDK_TARGET_OS}" = xmacosx; then >> + # ffi.h checks '#if FFI_GO_CLOSURES' which throws a warning in xcode on aarch64 because the aarch64 >> + # ffitarget.h (included from ffi.h) doesn't explicitly define FFI_GO_CLOSURES (like it does on e.g. x64). >> + # define it explicitly here to avoid compilation errors >> + LIBFFI_CFLAGS="$LIBFFI_CFLAGS -DFFI_GO_CLOSURES=0" >> + fi >> + >> AC_MSG_CHECKING([if libffi works]) >> AC_LANG_PUSH(C) >> OLD_CFLAGS="$CFLAGS" >> >> >> And then remove the workaround from the source code. (`LIBFFI_CFLAGS` is used to build both relevant libraries, and should also be used when a new library is added that needs libffi. So this would avoid a repeat of this issue) >> >> Either way, let's thoroughly document the issue this time around, so future editors won't have to guess why this is needed. > >> And then remove the workaround from the source code. (`LIBFFI_CFLAGS` is used to build both relevant libraries, and should also be used when a new library is added that needs libffi. So this would avoid a repeat of this issue) > > Yes, I added a variant of that fix that explicitly checks for `FFI_GO_CLOSURES` definition during configure. (Now I have to find a system which actually supports recent FFI to test it... @shipilev While looking at something else, I noticed that the fallback linker was not handling variadic arguments correctly (and some of our tests were linking against the wrong descriptors). On macos/aarch64 with zero/fallback linker this could cause crashes in some of the java/foreign tests that use varidadic arguments (since the ABI is different for variadic args). I have a patch here to fix this: https://github.com/openjdk/jdk/compare/master...JornVernee:jdk:VAFixes That helps, but there are still some failing tests when using the fallback linker on macos/aarch64: java/foreign/TestUpcallStack.java Failed. Unexpected exit from test [exit code: 134] java/foreign/arraystructs/TestArrayStructs.java#interpreted Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 14 java/foreign/arraystructs/TestArrayStructs.java#specialized Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 14 I think this might be an issue with libffi, but I'm not sure (I'm using version 3.4.2). Note that all of these failures are cases where arguments are being passed on the stack. Also, FYI, I'll be on vacation the next to weeks, so I will likely not be available to reply here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13827#issuecomment-1546265480 From jjg at openjdk.org Fri May 12 21:03:56 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Fri, 12 May 2023 21:03:56 GMT Subject: RFR: 8300204: Sealed-class hierarchy graph missing nodes In-Reply-To: References: Message-ID: On Tue, 9 May 2023 06:35:03 GMT, Per Minborg wrote: >> Please review this simple patch that fixes the package determination for nested classes in the `@sealedGraph` taglet. >> >> Current JDK 21: >> https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/foreign/MemoryLayout.html >> https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/foreign/ValueLayout.html >> ![image](https://user-images.githubusercontent.com/7806504/236984282-f4361510-6208-4469-92d6-b9ce143204c3.png) >> >> This patch: >> https://cr.openjdk.org/~liach/8300204/java.base/java/lang/foreign/MemoryLayout.html >> https://cr.openjdk.org/~liach/8300204/java.base/java/lang/foreign/ValueLayout.html >> ![image](https://user-images.githubusercontent.com/7806504/236984331-a877a493-487a-444a-984c-9175393cbb92.png) > > Looks good to me! Thanks for providing this patch. Unfortunately, I am not a reviewer so we have to get someone else to review it. I'll sponsor this, given the comment by @minborg https://github.com/openjdk/jdk/pull/13875#issuecomment-1539537777 > Looks good to me! Thanks for providing this patch. Unfortunately, I am not a reviewer so we have to get someone else to review it. @minborg You may not be an OpenJDK "R"eviewer yet, but you can still "review" changes and report whether you approve the changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13875#issuecomment-1546291445 PR Comment: https://git.openjdk.org/jdk/pull/13875#issuecomment-1546296142 From liach at openjdk.org Fri May 12 21:03:58 2023 From: liach at openjdk.org (Chen Liang) Date: Fri, 12 May 2023 21:03:58 GMT Subject: Integrated: 8300204: Sealed-class hierarchy graph missing nodes In-Reply-To: References: Message-ID: On Tue, 9 May 2023 03:11:10 GMT, Chen Liang wrote: > Please review this simple patch that fixes the package determination for nested classes in the `@sealedGraph` taglet. > > Current JDK 21: > https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/foreign/MemoryLayout.html > https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/foreign/ValueLayout.html > ![image](https://user-images.githubusercontent.com/7806504/236984282-f4361510-6208-4469-92d6-b9ce143204c3.png) > > This patch: > https://cr.openjdk.org/~liach/8300204/java.base/java/lang/foreign/MemoryLayout.html > https://cr.openjdk.org/~liach/8300204/java.base/java/lang/foreign/ValueLayout.html > ![image](https://user-images.githubusercontent.com/7806504/236984331-a877a493-487a-444a-984c-9175393cbb92.png) This pull request has now been integrated. Changeset: d8afc7be Author: Chen Liang Committer: Jonathan Gibbons URL: https://git.openjdk.org/jdk/commit/d8afc7beeb4c41c2dae4ec1dd6671464eaec4720 Stats: 9 lines in 1 file changed: 1 ins; 0 del; 8 mod 8300204: Sealed-class hierarchy graph missing nodes Reviewed-by: jjg ------------- PR: https://git.openjdk.org/jdk/pull/13875 From kbarrett at openjdk.org Fri May 12 22:07:54 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 12 May 2023 22:07:54 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> Message-ID: On Fri, 12 May 2023 16:16:01 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. >> With this PR we address only the platform dependent code changes. > > JoKern65 has updated the pull request incrementally with one additional commit since the last revision: > > cosmetic changes Changes requested by kbarrett (Reviewer). src/hotspot/cpu/ppc/ppc.ad line 11444: > 11442: effect(KILL cr0); > 11443: ins_cost(DEFAULT_COST * 5); > 11444: size((VM_Version::has_brw() ? 16 : 20)); What is it complaining about here? src/hotspot/os/aix/os_aix.cpp line 464: > 462: guarantee0(shmid != -1); // Should always work. > 463: // Try to set pagesize. > 464: struct shmid_ds shm_buf = { {0,0,0,0,0,0,0,0},0,0,0,0,0,0,0,0,0,0,0,0,0,0 }; Would just `= {};` work? (I think it should, but with warnings who knows...) src/java.desktop/aix/native/libawt/porting_aix.c line 49: > 47: for (;;) { > 48: if (addr >= p->ldinfo_textorg && > 49: (char*)addr < (char*)(p->ldinfo_textorg) + p->ldinfo_textsize) { What is being warned about here? At worst, could you just cast the RHS to `void*`? ------------- PR Review: https://git.openjdk.org/jdk/pull/13953#pullrequestreview-1425195126 PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1192823550 PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1192824441 PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1192825686 From kbarrett at openjdk.org Fri May 12 22:07:55 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 12 May 2023 22:07:55 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: Message-ID: <4YjPGApkbH1tUGsRDIx4zr0wNyWh_KlhmCTWcVlrzog=.8618971d-58be-46da-ba52-0041ab476d95@github.com> On Fri, 12 May 2023 15:16:36 GMT, Tyler Steele wrote: >> JoKern65 has updated the pull request incrementally with one additional commit since the last revision: >> >> cosmetic changes > > src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp line 426: > >> 424: // Missing test if instr is commutative and if we should swap. >> 425: if (right.value()->type()->as_LongConstant() && >> 426: (x->op() == Bytecodes::_lsub && right.value()->type()->as_LongConstant()->value() == -32768 ) ) { > > I would prefer a shifted value here as it's usually more readable. If the compiler is being stubborn in its warnings, a comment explaining the magic value would be fine too. What is the warning here? Note that we've already turned off `-Wshift-negative-value` for gcc and xlc (but not for clang, for some reason). See `# Disabled warnings` in CompileJvm.gmk. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1192821299 From jjg at openjdk.org Fri May 12 22:09:47 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Fri, 12 May 2023 22:09:47 GMT Subject: RFR: 8307652: sealed class hierarchy graph doesn't distinguish non-sealed classes In-Reply-To: References: Message-ID: <7tWiHfGzhyY86-itKV0poJnO80RrNdIvU8bxgoNnbwI=.e52d5164-9f17-4e37-a75c-75bb21a2d565@github.com> On Tue, 9 May 2023 04:11:03 GMT, Chen Liang wrote: > `@sealedGraph` had a mechanism to render non-sealed classes differently, but it's useless because the graph nodes are not bordered. This patch converts the non-sealed classes to be rendered in italics instead. > > An example of `ConstantDesc`, which has a sealed hierarchy except `DynamicConstantDesc`: > JDK 20: > ![image](https://user-images.githubusercontent.com/7806504/236991678-e30c181a-cb1f-407a-b3e0-f648fe2df788.png) > > This patch: > ![image](https://user-images.githubusercontent.com/7806504/236991592-affcb128-9721-45cf-860c-6292ee6a8bb6.png) @minborg You should comment on this one. I'm not sure that italics by itself is a good idea. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13877#issuecomment-1546361261 From kbarrett at openjdk.org Fri May 12 23:44:43 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 12 May 2023 23:44:43 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code In-Reply-To: <9lfGtX1kleo6vBh3j6_llYExI2XK4rAorE05To8P6Rk=.aa7f177b-40ac-4105-8fd9-7f72a34de2e6@github.com> References: <9lfGtX1kleo6vBh3j6_llYExI2XK4rAorE05To8P6Rk=.aa7f177b-40ac-4105-8fd9-7f72a34de2e6@github.com> Message-ID: <8qe3ls9E7_X2nbWJdGWtUQC-AGFswGkKNu9M5HEEBBg=.0e5e36c7-8339-45d1-a61f-93bc478cd8cc@github.com> On Fri, 12 May 2023 15:29:32 GMT, Tyler Steele wrote: > I'm not sure if it's been mentioned to you already. As I understand it, we usually wait for 2 reviews before proceeding with changes unless they are deemed trivial. Also wait for 24 hours. See https://openjdk.org/guide/#life-of-a-pr bullet 6. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13953#issuecomment-1546438398 From kbarrett at openjdk.org Sun May 14 00:49:55 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 14 May 2023 00:49:55 GMT Subject: RFR: 8307855: update for deprecated sprintf for src/utils [v2] In-Reply-To: References: <_y76ehEcXfM8bS00DzlNsVoOL3MUIp83ReGFdxsFlDA=.f0fc3530-3e27-49b5-a4f7-4082f2d7d06c@github.com> Message-ID: On Fri, 12 May 2023 14:52:59 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> May I have this update reviewed? >> >> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the src/utils directory. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > update typo in copyright statement A couple of issues noticed after this PR has been integrated. src/utils/hsdis/binutils/hsdis-binutils.c line 222: > 220: const decode_func_stype decode_func_address = &decode_instructions; > 221: > 222: #define remaining_buflen(buf, bufsize, p) ((bufsize) - ((p) - (buf))) This shouldn't be a macro. Among other reasons, see the style guide. src/utils/hsdis/binutils/hsdis-binutils.c line 251: > 249: if (type) snprintf(p += strlen(p), remaining_buflen(buf, bufsize, p), " type='%s'", type); > 250: if (dsize) snprintf(p += strlen(p), remaining_buflen(buf, bufsize, p), " dsize='%d'", dsize); > 251: if (delays) snprintf(p += strlen(p), remaining_buflen(buf, bufsize, p), " delay='%d'", delays); What is the value for p that is used in the call to remaining_buflen? It is being assumed to be the value after the assignment by the first argument. However, according to the standard, it is unspecified, and the whole snprintf call invokes UB. This is because there aren't any sequence points between the update of p in the first argument and that reference. (C++17 changes this, but we aren't using C++17 yet.) ------------- PR Review: https://git.openjdk.org/jdk/pull/13915#pullrequestreview-1425474314 PR Review Comment: https://git.openjdk.org/jdk/pull/13915#discussion_r1193056435 PR Review Comment: https://git.openjdk.org/jdk/pull/13915#discussion_r1193056453 From duke at openjdk.org Mon May 15 04:26:05 2023 From: duke at openjdk.org (duke) Date: Mon, 15 May 2023 04:26:05 GMT Subject: Withdrawn: JDK-8300531: Update MSVC optimization flags to match GCC/Clang In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 14:32:20 GMT, Justin King wrote: > Update MSVC CFlags to be more consistent with other compilers. Also disables RTTI in a simliar manner to GCC/Clang for the JVM. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/12073 From thartmann at openjdk.org Mon May 15 05:17:55 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 15 May 2023 05:17:55 GMT Subject: RFR: 8307855: update for deprecated sprintf for src/utils [v2] In-Reply-To: References: <_y76ehEcXfM8bS00DzlNsVoOL3MUIp83ReGFdxsFlDA=.f0fc3530-3e27-49b5-a4f7-4082f2d7d06c@github.com> Message-ID: <81TE6e3xzQ8gpHtab6tmrvRM8SYaE16lStVB14LKMMo=.0cc1991d-a723-4263-b51a-39422249e62e@github.com> On Fri, 12 May 2023 14:52:59 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> May I have this update reviewed? >> >> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the src/utils directory. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > update typo in copyright statement The change is also missing a second review. I'm backing it out for now with https://github.com/openjdk/jdk/pull/13975. Let's redo with [JDK-8308071](https://bugs.openjdk.org/browse/JDK-8308071). Thanks, Tobias ------------- PR Comment: https://git.openjdk.org/jdk/pull/13915#issuecomment-1547205741 From thartmann at openjdk.org Mon May 15 05:19:51 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 15 May 2023 05:19:51 GMT Subject: RFR: 8308072: [BACKOUT] update for deprecated sprintf for src/utils Message-ID: <__uRbegoIjzZg2m9xpCS17L4InOWaCw5aN0T1JTqojc=.5f485b78-f46c-40be-b930-38ec836b3181@github.com> Clean backout of https://github.com/openjdk/jdk/pull/13915 / [JDK-8307855](https://bugs.openjdk.org/browse/JDK-8307855) because @kimbarrett noticed some issues after integration. Also the change is non-trivial and therefore missing a second review. Thanks, Tobias ------------- Commit messages: - 8308072: [BACKOUT] update for deprecated sprintf for src/utils Changes: https://git.openjdk.org/jdk/pull/13975/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13975&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308072 Stats: 6 lines in 1 file changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13975.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13975/head:pull/13975 PR: https://git.openjdk.org/jdk/pull/13975 From iris at openjdk.org Mon May 15 05:45:52 2023 From: iris at openjdk.org (Iris Clark) Date: Mon, 15 May 2023 05:45:52 GMT Subject: RFR: 8308072: [BACKOUT] update for deprecated sprintf for src/utils In-Reply-To: <__uRbegoIjzZg2m9xpCS17L4InOWaCw5aN0T1JTqojc=.5f485b78-f46c-40be-b930-38ec836b3181@github.com> References: <__uRbegoIjzZg2m9xpCS17L4InOWaCw5aN0T1JTqojc=.5f485b78-f46c-40be-b930-38ec836b3181@github.com> Message-ID: On Mon, 15 May 2023 05:13:00 GMT, Tobias Hartmann wrote: > Clean backout of https://github.com/openjdk/jdk/pull/13915 / [JDK-8307855](https://bugs.openjdk.org/browse/JDK-8307855) because @kimbarrett noticed some issues after integration. Also the change is non-trivial and therefore missing a second review. > > Thanks, > Tobias Verified this PR is a backout of the earlier change. ------------- Marked as reviewed by iris (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13975#pullrequestreview-1425795219 From thartmann at openjdk.org Mon May 15 05:45:53 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 15 May 2023 05:45:53 GMT Subject: RFR: 8308072: [BACKOUT] update for deprecated sprintf for src/utils In-Reply-To: <__uRbegoIjzZg2m9xpCS17L4InOWaCw5aN0T1JTqojc=.5f485b78-f46c-40be-b930-38ec836b3181@github.com> References: <__uRbegoIjzZg2m9xpCS17L4InOWaCw5aN0T1JTqojc=.5f485b78-f46c-40be-b930-38ec836b3181@github.com> Message-ID: On Mon, 15 May 2023 05:13:00 GMT, Tobias Hartmann wrote: > Clean backout of https://github.com/openjdk/jdk/pull/13915 / [JDK-8307855](https://bugs.openjdk.org/browse/JDK-8307855) because @kimbarrett noticed some issues after integration. Also the change is non-trivial and therefore missing a second review. > > Thanks, > Tobias Thanks for the quick review, Iris! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13975#issuecomment-1547222559 From thartmann at openjdk.org Mon May 15 05:45:54 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 15 May 2023 05:45:54 GMT Subject: Integrated: 8308072: [BACKOUT] update for deprecated sprintf for src/utils In-Reply-To: <__uRbegoIjzZg2m9xpCS17L4InOWaCw5aN0T1JTqojc=.5f485b78-f46c-40be-b930-38ec836b3181@github.com> References: <__uRbegoIjzZg2m9xpCS17L4InOWaCw5aN0T1JTqojc=.5f485b78-f46c-40be-b930-38ec836b3181@github.com> Message-ID: <75WW5eQV2JZyNjQKcuMLvmbHIbp_NkotYWYCd8F4Sn8=.b76aed95-e051-436f-bdd5-d31163a65a6f@github.com> On Mon, 15 May 2023 05:13:00 GMT, Tobias Hartmann wrote: > Clean backout of https://github.com/openjdk/jdk/pull/13915 / [JDK-8307855](https://bugs.openjdk.org/browse/JDK-8307855) because @kimbarrett noticed some issues after integration. Also the change is non-trivial and therefore missing a second review. > > Thanks, > Tobias This pull request has now been integrated. Changeset: 8d49ba9e Author: Tobias Hartmann URL: https://git.openjdk.org/jdk/commit/8d49ba9e8d3095f850b3007b56488a0c0cf8ddff Stats: 6 lines in 1 file changed: 0 ins; 2 del; 4 mod 8308072: [BACKOUT] update for deprecated sprintf for src/utils Reviewed-by: iris ------------- PR: https://git.openjdk.org/jdk/pull/13975 From xuelei at openjdk.org Mon May 15 06:15:54 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 15 May 2023 06:15:54 GMT Subject: RFR: 8307855: update for deprecated sprintf for src/utils [v2] In-Reply-To: References: <_y76ehEcXfM8bS00DzlNsVoOL3MUIp83ReGFdxsFlDA=.f0fc3530-3e27-49b5-a4f7-4082f2d7d06c@github.com> Message-ID: <5kuqiwFH_hV37tEZsdZxYziXhlM1kv2XLngoBrbY-mI=.3fb2435a-1362-48e6-93d6-64422e20f244@github.com> On Fri, 12 May 2023 14:52:59 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> May I have this update reviewed? >> >> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the src/utils directory. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > update typo in copyright statement > The change is also missing a second review. I'm backing it out for now with #13975. Let's redo with [JDK-8308071](https://bugs.openjdk.org/browse/JDK-8308071). > > Thanks, Tobias Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13915#issuecomment-1547248097 From xuelei at openjdk.org Mon May 15 06:15:56 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 15 May 2023 06:15:56 GMT Subject: RFR: 8307855: update for deprecated sprintf for src/utils [v2] In-Reply-To: References: <_y76ehEcXfM8bS00DzlNsVoOL3MUIp83ReGFdxsFlDA=.f0fc3530-3e27-49b5-a4f7-4082f2d7d06c@github.com> Message-ID: On Sun, 14 May 2023 00:43:51 GMT, Kim Barrett wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> update typo in copyright statement > > src/utils/hsdis/binutils/hsdis-binutils.c line 222: > >> 220: const decode_func_stype decode_func_address = &decode_instructions; >> 221: >> 222: #define remaining_buflen(buf, bufsize, p) ((bufsize) - ((p) - (buf))) > > This shouldn't be a macro. Among other reasons, see the style guide. May I have an reference to the style guide? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13915#discussion_r1193366077 From xuelei at openjdk.org Mon May 15 06:31:59 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 15 May 2023 06:31:59 GMT Subject: RFR: 8307855: update for deprecated sprintf for src/utils [v2] In-Reply-To: References: <_y76ehEcXfM8bS00DzlNsVoOL3MUIp83ReGFdxsFlDA=.f0fc3530-3e27-49b5-a4f7-4082f2d7d06c@github.com> Message-ID: On Sun, 14 May 2023 00:44:45 GMT, Kim Barrett wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> update typo in copyright statement > > src/utils/hsdis/binutils/hsdis-binutils.c line 251: > >> 249: if (type) snprintf(p += strlen(p), remaining_buflen(buf, bufsize, p), " type='%s'", type); >> 250: if (dsize) snprintf(p += strlen(p), remaining_buflen(buf, bufsize, p), " dsize='%d'", dsize); >> 251: if (delays) snprintf(p += strlen(p), remaining_buflen(buf, bufsize, p), " delay='%d'", delays); > > What is the value for p that is used in the call to remaining_buflen? > It is being assumed to be the value after the assignment by the first > argument. However, according to the standard, it is unspecified, and > the whole snprintf call invokes UB. This is because there aren't any > sequence points between the update of p in the first argument and that > reference. (C++17 changes this, but we aren't using C++17 yet.) For the 1st line (line 249), it is fine to use bufsize directly. The p in remaining_buflen is used to calculate the remaining length of the target buffer. To know the remaining buffer length, I need to know the pointer to the beginning buffer (the 'buf' parameter), the pointer to the beginning of the unused buffer (the 'p' parameter), and the total size of the buffer (the 'bufsize' parameter). The initial value of p is assigned to buf(p = buf), and then move forward by the used size ( p += strlen(p)). It's a good point to me about the update sequence of p, and I will make an update in a new PR. Thank you very much! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13915#discussion_r1193376513 From pminborg at openjdk.org Mon May 15 06:49:44 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 15 May 2023 06:49:44 GMT Subject: RFR: 8307652: sealed class hierarchy graph doesn't distinguish non-sealed classes In-Reply-To: References: Message-ID: On Tue, 9 May 2023 04:11:03 GMT, Chen Liang wrote: > `@sealedGraph` had a mechanism to render non-sealed classes differently, but it's useless because the graph nodes are not bordered. This patch converts the non-sealed classes to be rendered in italics instead. > > An example of `ConstantDesc`, which has a sealed hierarchy except `DynamicConstantDesc`: > JDK 20: > ![image](https://user-images.githubusercontent.com/7806504/236991678-e30c181a-cb1f-407a-b3e0-f648fe2df788.png) > > This patch: > ![image](https://user-images.githubusercontent.com/7806504/236991592-affcb128-9721-45cf-860c-6292ee6a8bb6.png) Thanks for this improvement suggestion. Indicating "openness" is certainly important. I was playing around with various ways of expressing it and came up with this: ![image](https://github.com/openjdk/jdk/assets/7457876/3f5204b5-7dd7-47ee-9df4-397c5b69f0d4) What is your opinion on it? It might be slightly more intuitive? We could even do this: ![image](https://github.com/openjdk/jdk/assets/7457876/32e2542f-ef81-4523-a658-d0a39da13ea8) Here is the code: digraph G { shape="none" rankdir = "BT" ClassDesc -> ConstantDesc MethodHandleDesc -> ConstantDesc DirectMethodHandleDesc -> MethodHandleDesc DynamicConstantDesc -> ConstantDesc Float -> ConstantDesc Hidden1 -> DynamicConstantDesc [style="dashed"] Hidden1 [label=""] ClassDesc [shape=none]; ConstantDesc [shape=none]; MethodHandleDesc [shape=none]; DynamicConstantDesc [shape=none]; DirectMethodHandleDesc [shape=none]; Float [shape=none]; Hidden1 [shape=none]; } ------------- PR Comment: https://git.openjdk.org/jdk/pull/13877#issuecomment-1547278887 From alanb at openjdk.org Mon May 15 07:52:05 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 15 May 2023 07:52:05 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v13] In-Reply-To: <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com> References: <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com> Message-ID: On Thu, 11 May 2023 11:25:51 GMT, Jim Laskey wrote: >> Add flexible main methods and anonymous main classes to the Java language. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Update VirtualParser.java src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 35: > 33: public class MainMethodFinder { > 34: private static boolean isPrivate(Method method) { > 35: return method != null && Modifier.isPrivate(method.getModifiers()); Are you sure you want to allow null here? It seems like it's a bug in the caller if that happens. src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 38: > 36: } > 37: > 38: private static boolean isPublic(Method method) { Is this left over from a previous iteration, it doesn't seem to be used. src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 53: > 51: > 52: /** > 53: * Gather all the "main" methods in the class heirarchy. heirarchy -> hierarchy src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 134: > 132: > 133: /** > 134: * {@return priority main method or null if none found} "or null if none found", is that out of date? src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 146: > 144: > 145: if (Modifier.isStatic(mods) && mainMethod.getDeclaringClass() != mainClass) { > 146: System.err.println("WARNING: static main in super class will be deprecated."); I thought that JEP 445 was deprecating this, in which case the text should be "is deprecated" rather than "will be". src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 156: > 154: > 155: List mains = new ArrayList<>(); > 156: gatherMains(mainClass, mainClass, mains); Instead of gatherMains, did you consider first looking for static main(String[], then static main()? Asking because I expected to only see the walk up the hierarchy when looking for an instance main. src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 162: > 160: } > 161: > 162: if (1 < mains.size()) { Checking if mains.size() > 1 might be easier on the eyes. src/java.base/share/classes/sun/launcher/LauncherHelper.java line 872: > 870: > 871: // Check the existence and signature of main and abort if incorrect > 872: public static void validateMainClass(Class mainClass) { Is there a reason that this is changed to public, maybe left over from a previous iteration? src/java.base/share/classes/sun/launcher/LauncherHelper.java line 896: > 894: * findMainMethod (above) will choose the correct method, based > 895: * on its name and parameter type, however, we still have to > 896: * ensure that the method is static (non-preview) and returns a void. Have you looked into findMainMethod checking the return type? Right now, we have findMainMethod returning a Method that needs further checking. src/java.base/share/classes/sun/launcher/LauncherHelper.java line 904: > 902: > 903: if (!PreviewFeatures.isEnabled()) { > 904: if (!isStatic || !isPublic || noArgs) { You can use && here and avoid the nested if. test/jdk/tools/launcher/InstanceMainTest.java line 31: > 29: * @run main InstanceMainTest > 30: */ > 31: public class InstanceMainTest extends TestHelper { Are you planning to add tests for the selection/precedence order? Also wondering if we need a test to check that there is a warning when the main method in found in the super class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193379090 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193378248 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193379468 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193415367 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193385008 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193440438 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193419331 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193444639 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193455653 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193443762 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193390566 From duke at openjdk.org Mon May 15 08:32:48 2023 From: duke at openjdk.org (JoKern65) Date: Mon, 15 May 2023 08:32:48 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> Message-ID: <2nOXHGp99zMM5YyMuMgN0blrNJjpXJjeLiJIc1dR4r0=.01e91354-789e-484f-a05c-01261354c0e8@github.com> On Fri, 12 May 2023 21:56:50 GMT, Kim Barrett wrote: >> JoKern65 has updated the pull request incrementally with one additional commit since the last revision: >> >> cosmetic changes > > src/hotspot/cpu/ppc/ppc.ad line 11444: > >> 11442: effect(KILL cr0); >> 11443: ins_cost(DEFAULT_COST * 5); >> 11444: size((VM_Version::has_brw() ? 16 : 20)); > > What is it complaining about here? /data/d042520/xlc17/jdk/src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp:426:97: error: shifting a negative signed value is undefined [-Werror,-Wshift-negative-value] I reverted my change in c1_LIRGenerator_ppc.cpp and added shift-negative-value to the DISABLED_WARNINGS_clang in CompileJvm.gmk. ad_ppc.cpp:18388:10: error: converting the result of '?:' with integer constants to a boolean always evaluates to 'true' [-Werror,-Wtautological-constant-compare] assert(VerifyOops || MachNode::size(ra_) <= VM_Version::has_brw() ? 16 : 20, "bad fixed size"); ^ Should I also add tautological-constant-compare to DISABLED_WARNINGS_clang in CompileJvm.gmk or where else? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1193506933 From asotona at openjdk.org Mon May 15 08:47:02 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 15 May 2023 08:47:02 GMT Subject: RFR: 8307326: Package jdk.internal.classfile.java.lang.constant become obsolete Message-ID: Package `jdk.internal.classfile.java.lang.constant` containing `ModuleDesc` and `PackageDesc` become obsolete after [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729). All references to `jdk.internal.classfile.java.lang.constant.ModuleDesc` and `jdk.internal.classfile.java.lang.constant.PackageDesc` across all JDK sources, tests and JMH benchmarks are replaced with `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc`. `jdk.internal.classfile.java.lang.constant` package export hooks are removed from java.base module-info, make files and test headers. Content of `jdk.internal.classfile.java.lang.constant` package and related tests under `jdk.classfile` are deleted. Method references renamed in [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729) are fixed: - `PackageDesc::packageName` to `PackageDesc::name` - `PackageDesc::packageInternalName` to `PackageDesc::internalName` - `ModuleDesc::moduleName` to `ModuleDesc::name`. Please review this pull request. Thanks, Adam ------------- Commit messages: - 8307326: Package jdk.internal.classfile.java.lang.constant become obsolete Changes: https://git.openjdk.org/jdk/pull/13979/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13979&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307326 Stats: 503 lines in 46 files changed: 0 ins; 446 del; 57 mod Patch: https://git.openjdk.org/jdk/pull/13979.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13979/head:pull/13979 PR: https://git.openjdk.org/jdk/pull/13979 From kbarrett at openjdk.org Mon May 15 09:37:46 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 15 May 2023 09:37:46 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: <2nOXHGp99zMM5YyMuMgN0blrNJjpXJjeLiJIc1dR4r0=.01e91354-789e-484f-a05c-01261354c0e8@github.com> References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> <2nOXHGp99zMM5YyMuMgN0blrNJjpXJjeLiJIc1dR4r0=.01e91354-789e-484f-a05c-01261354c0e8@github.com> Message-ID: On Mon, 15 May 2023 08:29:31 GMT, JoKern65 wrote: >> src/hotspot/cpu/ppc/ppc.ad line 11444: >> >>> 11442: effect(KILL cr0); >>> 11443: ins_cost(DEFAULT_COST * 5); >>> 11444: size((VM_Version::has_brw() ? 16 : 20)); >> >> What is it complaining about here? > > /data/d042520/xlc17/jdk/src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp:426:97: error: shifting a negative signed value is undefined [-Werror,-Wshift-negative-value] > I reverted my change in c1_LIRGenerator_ppc.cpp and added shift-negative-value to the DISABLED_WARNINGS_clang in CompileJvm.gmk. > > ad_ppc.cpp:18388:10: error: converting the result of '?:' with integer constants to a boolean always evaluates to 'true' [-Werror,-Wtautological-constant-compare] > assert(VerifyOops || MachNode::size(ra_) <= VM_Version::has_brw() ? 16 : 20, "bad fixed size"); > ^ > Should I also add tautological-constant-compare to DISABLED_WARNINGS_clang in CompileJvm.gmk or where else? I see, so `size` is kind of macro-like, and is just textually splicing its argument expression into another expression. And without the added parens the resulting full expression for the assert isn't checking what's intended, due to operator precedence. This is in generated source; it might be better to find the code generator (somewhere in adlc) and change it to add appropriate parens, as there may be other similar places (both here and for other platforms) that aren't doing what's intended but are not triggering warnings. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1193579404 From kbarrett at openjdk.org Mon May 15 09:37:47 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 15 May 2023 09:37:47 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> <2nOXHGp99zMM5YyMuMgN0blrNJjpXJjeLiJIc1dR4r0=.01e91354-789e-484f-a05c-01261354c0e8@github.com> Message-ID: On Mon, 15 May 2023 09:30:52 GMT, Kim Barrett wrote: >> /data/d042520/xlc17/jdk/src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp:426:97: error: shifting a negative signed value is undefined [-Werror,-Wshift-negative-value] >> I reverted my change in c1_LIRGenerator_ppc.cpp and added shift-negative-value to the DISABLED_WARNINGS_clang in CompileJvm.gmk. >> >> ad_ppc.cpp:18388:10: error: converting the result of '?:' with integer constants to a boolean always evaluates to 'true' [-Werror,-Wtautological-constant-compare] >> assert(VerifyOops || MachNode::size(ra_) <= VM_Version::has_brw() ? 16 : 20, "bad fixed size"); >> ^ >> Should I also add tautological-constant-compare to DISABLED_WARNINGS_clang in CompileJvm.gmk or where else? > > I see, so `size` is kind of macro-like, and is just textually splicing its argument expression into another expression. > And without the added parens the resulting full expression for the assert isn't checking what's intended, due > to operator precedence. > > This is in generated source; it might be better to find the code generator (somewhere in adlc) and change it > to add appropriate parens, as there may be other similar places (both here and for other platforms) that > aren't doing what's intended but are not triggering warnings. Such a fix of adlc is probably out of scope for this change though. We should probably have a separate bug for that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1193581173 From duke at openjdk.org Mon May 15 09:37:50 2023 From: duke at openjdk.org (JoKern65) Date: Mon, 15 May 2023 09:37:50 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> Message-ID: On Fri, 12 May 2023 21:59:11 GMT, Kim Barrett wrote: >> JoKern65 has updated the pull request incrementally with one additional commit since the last revision: >> >> cosmetic changes > > src/hotspot/os/aix/os_aix.cpp line 464: > >> 462: guarantee0(shmid != -1); // Should always work. >> 463: // Try to set pagesize. >> 464: struct shmid_ds shm_buf = { {0,0,0,0,0,0,0,0},0,0,0,0,0,0,0,0,0,0,0,0,0,0 }; > > Would just `= {};` work? (I think it should, but with warnings who knows...) os_aix.cpp:460:37: error: missing field 'gid' initializer [-Werror,-Wmissing-field-initializers] struct shmid_ds shm_buf = { 0 }; ={} seems to work, but I do not know if it works on every compiler because standard says: the initializer must be a **non-empty, (until C23)** brace-enclosed, comma-separated list of initializers for the members. Should I then disable Warning missing-field-initializers? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1193583982 From duke at openjdk.org Mon May 15 09:46:53 2023 From: duke at openjdk.org (JoKern65) Date: Mon, 15 May 2023 09:46:53 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> Message-ID: On Fri, 12 May 2023 22:01:46 GMT, Kim Barrett wrote: >> JoKern65 has updated the pull request incrementally with one additional commit since the last revision: >> >> cosmetic changes > > src/java.desktop/aix/native/libawt/porting_aix.c line 49: > >> 47: for (;;) { >> 48: if (addr >= p->ldinfo_textorg && >> 49: (char*)addr < (char*)(p->ldinfo_textorg) + p->ldinfo_textsize) { > > What is being warned about here? At worst, could you just cast the RHS to `void*`? /porting_aix.c:49:34: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith] addr < p->ldinfo_textorg + p->ldinfo_textsize) { and with` void*` cast on RHS porting_aix.c:49:43: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith] addr < (void*)(p->ldinfo_textorg) + p->ldinfo_textsize) { So either my code change or disabling warning gnu-pointer-arith. What would you prefer? and if you prefer disabling the Warning, where should I do it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1193594350 From duke at openjdk.org Mon May 15 09:55:45 2023 From: duke at openjdk.org (JoKern65) Date: Mon, 15 May 2023 09:55:45 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> <2nOXHGp99zMM5YyMuMgN0blrNJjpXJjeLiJIc1dR4r0=.01e91354-789e-484f-a05c-01261354c0e8@github.com> Message-ID: On Mon, 15 May 2023 09:32:26 GMT, Kim Barrett wrote: >> I see, so `size` is kind of macro-like, and is just textually splicing its argument expression into another expression. >> And without the added parens the resulting full expression for the assert isn't checking what's intended, due >> to operator precedence. >> >> This is in generated source; it might be better to find the code generator (somewhere in adlc) and change it >> to add appropriate parens, as there may be other similar places (both here and for other platforms) that >> aren't doing what's intended but are not triggering warnings. > > Such a fix of adlc is probably out of scope for this change though. We should probably have a separate bug for that. And what should I use as a workaround meanwhile to get our new compiler through? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1193605092 From shade at openjdk.org Mon May 15 10:07:50 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 15 May 2023 10:07:50 GMT Subject: RFR: 8308086: GHA: x86_32 host configuration failing with unmet dependencies Message-ID: Currently failing at host configuration step with: The following packages have unmet dependencies: libc6:i386 : Depends: libgcc-s1:i386 but it is not going to be installed libtiffxx5:i386 : Depends: libstdc++6:i386 (>= 5) but it is not going to be installed ``` The fix is to add the dependencies explicitly. Additional testing: - [ ] GHA ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/13981/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13981&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308086 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13981.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13981/head:pull/13981 PR: https://git.openjdk.org/jdk/pull/13981 From stuefe at openjdk.org Mon May 15 10:23:44 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 15 May 2023 10:23:44 GMT Subject: RFR: 8308086: GHA: x86_32 host configuration failing with unmet dependencies In-Reply-To: References: Message-ID: On Mon, 15 May 2023 10:00:42 GMT, Aleksey Shipilev wrote: > Currently failing at host configuration step with: > > > The following packages have unmet dependencies: > libc6:i386 : Depends: libgcc-s1:i386 but it is not going to be installed > libtiffxx5:i386 : Depends: libstdc++6:i386 (>= 5) but it is not going to be installed > ``` > > The fix is to add the dependencies explicitly. > > Additional testing: > - [ ] GHA Thank you for fixing this ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13981#pullrequestreview-1426238232 From mdoerr at openjdk.org Mon May 15 12:38:48 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 15 May 2023 12:38:48 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> Message-ID: On Fri, 12 May 2023 16:16:01 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. >> With this PR we address only the platform dependent code changes. > > JoKern65 has updated the pull request incrementally with one additional commit since the last revision: > > cosmetic changes Thanks for addressing all the warnings! Looks basically good to me. Some details need to get checked. src/hotspot/os/aix/os_aix.cpp line 677: > 675: #ifdef AIX_XLC_GE_17 > 676: #include "alloca.h" > 677: #endif Includes should better be at the beginning of the file. ------------- PR Review: https://git.openjdk.org/jdk/pull/13953#pullrequestreview-1426444262 PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1193770194 From mdoerr at openjdk.org Mon May 15 12:38:51 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 15 May 2023 12:38:51 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: <4YjPGApkbH1tUGsRDIx4zr0wNyWh_KlhmCTWcVlrzog=.8618971d-58be-46da-ba52-0041ab476d95@github.com> References: <4YjPGApkbH1tUGsRDIx4zr0wNyWh_KlhmCTWcVlrzog=.8618971d-58be-46da-ba52-0041ab476d95@github.com> Message-ID: On Fri, 12 May 2023 21:51:59 GMT, Kim Barrett wrote: >> src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp line 426: >> >>> 424: // Missing test if instr is commutative and if we should swap. >>> 425: if (right.value()->type()->as_LongConstant() && >>> 426: (x->op() == Bytecodes::_lsub && right.value()->type()->as_LongConstant()->value() == -32768 ) ) { >> >> I would prefer a shifted value here as it's usually more readable. If the compiler is being stubborn in its warnings, a comment explaining the magic value would be fine too. > > What is the warning here? Note that we've already turned off `-Wshift-negative-value` for gcc and xlc > (but not for clang, for some reason). See `# Disabled warnings` in CompileJvm.gmk. I think disabling the warning is fine. Alternatively, we could `#define MIN_INT16 -32768` somewhere or introduce `const int16_t min_int16 = (int16_t)1 << (sizeof(int16_t)*BitsPerByte-1);`. What do you prefer, Kim? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1193762594 From erikj at openjdk.org Mon May 15 13:20:47 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 15 May 2023 13:20:47 GMT Subject: RFR: 8307326: Package jdk.internal.classfile.java.lang.constant become obsolete In-Reply-To: References: Message-ID: On Mon, 15 May 2023 08:38:54 GMT, Adam Sotona wrote: > Package `jdk.internal.classfile.java.lang.constant` containing `ModuleDesc` and `PackageDesc` become obsolete after [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729). > All references to `jdk.internal.classfile.java.lang.constant.ModuleDesc` and `jdk.internal.classfile.java.lang.constant.PackageDesc` across all JDK sources, tests and JMH benchmarks are replaced with `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc`. > `jdk.internal.classfile.java.lang.constant` package export hooks are removed from java.base module-info, make files and test headers. > Content of `jdk.internal.classfile.java.lang.constant` package and related tests under `jdk.classfile` are deleted. > Method references renamed in [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729) are fixed: > - `PackageDesc::packageName` to `PackageDesc::name` > - `PackageDesc::packageInternalName` to `PackageDesc::internalName` > - `ModuleDesc::moduleName` to `ModuleDesc::name`. > > Please review this pull request. > > Thanks, > Adam Build changes look ok. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13979#pullrequestreview-1426543240 From shade at openjdk.org Mon May 15 13:24:47 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 15 May 2023 13:24:47 GMT Subject: RFR: 8308086: GHA: x86_32 host configuration failing with unmet dependencies In-Reply-To: References: Message-ID: On Mon, 15 May 2023 10:20:51 GMT, Thomas Stuefe wrote: > Thank you for fixing this Thanks for looking at it. Trivial, right? GHAs do not complain anymore. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13981#issuecomment-1547852643 From stuefe at openjdk.org Mon May 15 13:49:47 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 15 May 2023 13:49:47 GMT Subject: RFR: 8308086: GHA: x86_32 host configuration failing with unmet dependencies In-Reply-To: References: Message-ID: On Mon, 15 May 2023 13:22:12 GMT, Aleksey Shipilev wrote: > > Thank you for fixing this > > Thanks for looking at it. Trivial, right? Trivial. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13981#issuecomment-1547890912 From shade at openjdk.org Mon May 15 13:53:57 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 15 May 2023 13:53:57 GMT Subject: RFR: 8308086: GHA: x86_32 host configuration failing with unmet dependencies In-Reply-To: References: Message-ID: On Mon, 15 May 2023 10:00:42 GMT, Aleksey Shipilev wrote: > Currently failing at host configuration step with: > > > The following packages have unmet dependencies: > libc6:i386 : Depends: libgcc-s1:i386 but it is not going to be installed > libtiffxx5:i386 : Depends: libstdc++6:i386 (>= 5) but it is not going to be installed > ``` > > The fix is to add the dependencies explicitly. > > Additional testing: > - [x] GHA Thank you! I am integrating to have cleaner GHA testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13981#issuecomment-1547894703 From shade at openjdk.org Mon May 15 13:53:59 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 15 May 2023 13:53:59 GMT Subject: Integrated: 8308086: GHA: x86_32 host configuration failing with unmet dependencies In-Reply-To: References: Message-ID: On Mon, 15 May 2023 10:00:42 GMT, Aleksey Shipilev wrote: > Currently failing at host configuration step with: > > > The following packages have unmet dependencies: > libc6:i386 : Depends: libgcc-s1:i386 but it is not going to be installed > libtiffxx5:i386 : Depends: libstdc++6:i386 (>= 5) but it is not going to be installed > ``` > > The fix is to add the dependencies explicitly. > > Additional testing: > - [x] GHA This pull request has now been integrated. Changeset: ffab1ea9 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/ffab1ea9e730204df5ab823eaa3ab7fdb3bef876 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8308086: GHA: x86_32 host configuration failing with unmet dependencies Reviewed-by: stuefe ------------- PR: https://git.openjdk.org/jdk/pull/13981 From jlaskey at openjdk.org Mon May 15 17:01:59 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 15 May 2023 17:01:59 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v13] In-Reply-To: References: <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com> Message-ID: On Mon, 15 May 2023 06:31:40 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update VirtualParser.java > > src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 35: > >> 33: public class MainMethodFinder { >> 34: private static boolean isPrivate(Method method) { >> 35: return method != null && Modifier.isPrivate(method.getModifiers()); > > Are you sure you want to allow null here? It seems like it's a bug in the caller if that happens. Remnant of previous usage. Changed. > src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 38: > >> 36: } >> 37: >> 38: private static boolean isPublic(Method method) { > > Is this left over from a previous iteration, it doesn't seem to be used. Changed > src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 53: > >> 51: >> 52: /** >> 53: * Gather all the "main" methods in the class heirarchy. > > heirarchy -> hierarchy Changed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194107274 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194105447 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194108052 From jlaskey at openjdk.org Mon May 15 17:09:02 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 15 May 2023 17:09:02 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v13] In-Reply-To: References: <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com> Message-ID: <9ftk4o0DvBHN-oDAlW6nW7_oM_KU8k3ZBzezvgfKWwM=.ec49936e-68a8-4b6c-a8bd-ed8c70ef3faf@github.com> On Mon, 15 May 2023 06:45:45 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update VirtualParser.java > > test/jdk/tools/launcher/InstanceMainTest.java line 31: > >> 29: * @run main InstanceMainTest >> 30: */ >> 31: public class InstanceMainTest extends TestHelper { > > Are you planning to add tests for the selection/precedence order? > > Also wondering if we need a test to check that there is a warning when the main method in found in the super class. InstanceMainTest does check precedence. Are you expecting a test for all combinations? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194117636 From jlaskey at openjdk.org Mon May 15 17:21:59 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 15 May 2023 17:21:59 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v13] In-Reply-To: References: <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com> Message-ID: On Mon, 15 May 2023 06:38:48 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update VirtualParser.java > > src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 146: > >> 144: >> 145: if (Modifier.isStatic(mods) && mainMethod.getDeclaringClass() != mainClass) { >> 146: System.err.println("WARNING: static main in super class will be deprecated."); > > I thought that JEP 445 was deprecating this, in which case the text should be "is deprecated" rather than "will be". JEP 445 is not deprecating this. No advanced notice has been given. > src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 162: > >> 160: } >> 161: >> 162: if (1 < mains.size()) { > > Checking if mains.size() > 1 might be easier on the eyes. I never ever use > symbol. least to greatest left to right (maths). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194132127 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194133518 From jlaskey at openjdk.org Mon May 15 17:29:57 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 15 May 2023 17:29:57 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v13] In-Reply-To: References: <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com> Message-ID: On Mon, 15 May 2023 07:13:49 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update VirtualParser.java > > src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 134: > >> 132: >> 133: /** >> 134: * {@return priority main method or null if none found} > > "or null if none found", is that out of date? Changed > src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 156: > >> 154: >> 155: List mains = new ArrayList<>(); >> 156: gatherMains(mainClass, mainClass, mains); > > Instead of gatherMains, did you consider first looking for static main(String[], then static main()? Asking because I expected to only see the walk up the hierarchy when looking for an instance main. 99.99% of the time it will be a single method in a shallow hierarchy, so cost its low. Only reason I broke out public static main was to ensure performance for existing code was the same. > src/java.base/share/classes/sun/launcher/LauncherHelper.java line 872: > >> 870: >> 871: // Check the existence and signature of main and abort if incorrect >> 872: public static void validateMainClass(Class mainClass) { > > Is there a reason that this is changed to public, maybe left over from a previous iteration? Remnant. Changed. > src/java.base/share/classes/sun/launcher/LauncherHelper.java line 904: > >> 902: >> 903: if (!PreviewFeatures.isEnabled()) { >> 904: if (!isStatic || !isPublic || noArgs) { > > You can use && here and avoid the nested if. Easier to see when removing preview code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194138214 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194137852 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194141538 PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194141140 From jlaskey at openjdk.org Mon May 15 17:37:58 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 15 May 2023 17:37:58 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v13] In-Reply-To: References: <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com> Message-ID: On Mon, 15 May 2023 07:48:26 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update VirtualParser.java > > src/java.base/share/classes/sun/launcher/LauncherHelper.java line 896: > >> 894: * findMainMethod (above) will choose the correct method, based >> 895: * on its name and parameter type, however, we still have to >> 896: * ensure that the method is static (non-preview) and returns a void. > > Have you looked into findMainMethod checking the return type? Right now, we have findMainMethod returning a Method that needs further checking. At some point I would like to fold both launchers into a single launcher. To do so would require having the source code launcher use the same error reporting and adapting downstream accordingly (tests et al). There is also a separate project to support multi-file source code launcher and I didn't want to disrupt the flow of that project at this point in time. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194149300 From jlaskey at openjdk.org Mon May 15 18:08:16 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 15 May 2023 18:08:16 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v14] In-Reply-To: References: Message-ID: > Add flexible main methods and anonymous main classes to the Java language. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Requested Changes #2 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13689/files - new: https://git.openjdk.org/jdk/pull/13689/files/90b1e981..2b625a39 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=12-13 Stats: 9 lines in 2 files changed: 0 ins; 4 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/13689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689 PR: https://git.openjdk.org/jdk/pull/13689 From alanb at openjdk.org Mon May 15 18:39:57 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 15 May 2023 18:39:57 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v13] In-Reply-To: References: <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com> Message-ID: On Mon, 15 May 2023 17:18:01 GMT, Jim Laskey wrote: >> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 146: >> >>> 144: >>> 145: if (Modifier.isStatic(mods) && mainMethod.getDeclaringClass() != mainClass) { >>> 146: System.err.println("WARNING: static main in super class will be deprecated."); >> >> I thought that JEP 445 was deprecating this, in which case the text should be "is deprecated" rather than "will be". > > JEP 445 is not deprecating this. No advanced notice has been given. Ah, I thought it was being deprecated. The JEP currently has "We deprecate the existing behavior that the launcher searches for a public static void main(String[] args) method in a superclass if one is not found in the launched class, issuing a runtime warning if such a method is found". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194220442 From jlu at openjdk.org Mon May 15 19:49:55 2023 From: jlu at openjdk.org (Justin Lu) Date: Mon, 15 May 2023 19:49:55 GMT Subject: RFR: 8306597: Improve string formatting in EquivMapsGenerator.java [v5] In-Reply-To: References: Message-ID: > Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK). > > The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, the Locale equivalencies builds the same. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Align spacing of the maps to original ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13935/files - new: https://git.openjdk.org/jdk/pull/13935/files/b4e6e683..bc04b3d9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13935&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13935&range=03-04 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13935.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13935/head:pull/13935 PR: https://git.openjdk.org/jdk/pull/13935 From xuelei at openjdk.org Mon May 15 20:11:46 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 15 May 2023 20:11:46 GMT Subject: RFR: 8308071: [REDO] update for deprecated sprintf for src/utils Message-ID: Hi, This is a redo of JDK-8307855, where issues were found after integration. The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the src/utils directory. Thanks, Xuelei ------------- Commit messages: - 8308071: [REDO] update for deprecated sprintf for src/utils Changes: https://git.openjdk.org/jdk/pull/13995/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13995&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308071 Stats: 22 lines in 1 file changed: 17 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/13995.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13995/head:pull/13995 PR: https://git.openjdk.org/jdk/pull/13995 From mikael at openjdk.org Mon May 15 21:50:46 2023 From: mikael at openjdk.org (Mikael Vidstedt) Date: Mon, 15 May 2023 21:50:46 GMT Subject: RFR: 8308071: [REDO] update for deprecated sprintf for src/utils In-Reply-To: References: Message-ID: On Mon, 15 May 2023 18:46:00 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > This is a redo of JDK-8307855, where issues were found after integration. > > The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the src/utils directory. > > Thanks, > Xuelei src/utils/hsdis/binutils/hsdis-binutils.c line 248: > 246: size_t used_size = strlen(close); > 247: char* p = buf + used_size; > 248: bufsize -= used_size; May not happen in practice, but if `used_size` is larger than `bufsize` this will wrap to a very large value. Perhaps the `strcpy` above should also be an `snprintf`, and the return value handled the same way as for the subsequent `snprintf` calls? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13995#discussion_r1194394358 From jlu at openjdk.org Mon May 15 23:21:57 2023 From: jlu at openjdk.org (Justin Lu) Date: Mon, 15 May 2023 23:21:57 GMT Subject: Integrated: 8306597: Improve string formatting in EquivMapsGenerator.java In-Reply-To: References: Message-ID: On Thu, 11 May 2023 15:40:50 GMT, Justin Lu wrote: > Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK). > > The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, the Locale equivalencies builds the same. This pull request has now been integrated. Changeset: 31683722 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/316837226ecceb4daa14e2bc1be8ce120edbfdc9 Stats: 185 lines in 1 file changed: 94 ins; 70 del; 21 mod 8306597: Improve string formatting in EquivMapsGenerator.java Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/13935 From mbaesken at openjdk.org Tue May 16 07:25:59 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 16 May 2023 07:25:59 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <4YjPGApkbH1tUGsRDIx4zr0wNyWh_KlhmCTWcVlrzog=.8618971d-58be-46da-ba52-0041ab476d95@github.com> Message-ID: On Mon, 15 May 2023 12:25:29 GMT, Martin Doerr wrote: >> What is the warning here? Note that we've already turned off `-Wshift-negative-value` for gcc and xlc >> (but not for clang, for some reason). See `# Disabled warnings` in CompileJvm.gmk. > > I think disabling the warning is fine. Alternatively, we could `#define MIN_INT16 -32768` somewhere or introduce `const int16_t min_int16 = (int16_t)1 << (sizeof(int16_t)*BitsPerByte-1);`. What do you prefer, Kim? Hi Martin/Joachim , I like the MIN_INT16 define idea Martin proposed, makes the code more readable and makes the warning go away . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1194725996 From xuelei at openjdk.org Tue May 16 16:54:47 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 16 May 2023 16:54:47 GMT Subject: RFR: 8308071: [REDO] update for deprecated sprintf for src/utils [v2] In-Reply-To: References: Message-ID: > Hi, > > This is a redo of JDK-8307855, where issues were found after integration. > > The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the src/utils directory. > > Thanks, > Xuelei Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: replace strcpy with snprintf ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13995/files - new: https://git.openjdk.org/jdk/pull/13995/files/9ac95707..1f833d5e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13995&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13995&range=00-01 Stats: 5 lines in 1 file changed: 1 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13995.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13995/head:pull/13995 PR: https://git.openjdk.org/jdk/pull/13995 From xuelei at openjdk.org Tue May 16 16:54:50 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 16 May 2023 16:54:50 GMT Subject: RFR: 8308071: [REDO] update for deprecated sprintf for src/utils [v2] In-Reply-To: References: Message-ID: On Mon, 15 May 2023 21:47:19 GMT, Mikael Vidstedt wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> replace strcpy with snprintf > > src/utils/hsdis/binutils/hsdis-binutils.c line 248: > >> 246: size_t used_size = strlen(close); >> 247: char* p = buf + used_size; >> 248: bufsize -= used_size; > > May not happen in practice, but if `used_size` is larger than `bufsize` this will wrap to a very large value. Perhaps the `strcpy` above should also be an `snprintf`, and the return value handled the same way as for the subsequent `snprintf` calls? I think it is safe as the `buf` size has been checked at around line 230. However, it may make the code easier to read if replacing `strcpy` with `snprintf`. The patch was updated accordingly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13995#discussion_r1195441861 From liach at openjdk.org Tue May 16 17:16:57 2023 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 May 2023 17:16:57 GMT Subject: RFR: 8307652: sealed class hierarchy graph doesn't distinguish non-sealed classes [v2] In-Reply-To: References: Message-ID: > `@sealedGraph` had a mechanism to render non-sealed classes differently, but it's useless because the graph nodes are not bordered. This patch converts the non-sealed classes to be rendered in italics instead. > > An example of `ConstantDesc`, which has a sealed hierarchy except `DynamicConstantDesc`: > JDK 20: > ![image](https://user-images.githubusercontent.com/7806504/236991678-e30c181a-cb1f-407a-b3e0-f648fe2df788.png) > > This patch: > ![image](https://user-images.githubusercontent.com/7806504/236991592-affcb128-9721-45cf-860c-6292ee6a8bb6.png) Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Use an edge and node to indicate non-sealed hierarchy - Merge branch 'master' into fix/sealedgraph-nonsealed - 8307652: sealed class hierarchy graph doesn't distinguish non-sealed classes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13877/files - new: https://git.openjdk.org/jdk/pull/13877/files/cab36e65..bb2d215c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13877&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13877&range=00-01 Stats: 99505 lines in 1624 files changed: 79242 ins; 8145 del; 12118 mod Patch: https://git.openjdk.org/jdk/pull/13877.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13877/head:pull/13877 PR: https://git.openjdk.org/jdk/pull/13877 From liach at openjdk.org Tue May 16 17:23:45 2023 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 May 2023 17:23:45 GMT Subject: RFR: 8307652: sealed class hierarchy graph doesn't distinguish non-sealed classes In-Reply-To: References: Message-ID: On Mon, 15 May 2023 06:46:28 GMT, Per Minborg wrote: >> `@sealedGraph` had a mechanism to render non-sealed classes differently, but it's useless because the graph nodes are not bordered. This patch converts the non-sealed classes to be rendered in italics instead. >> >> An example of `ConstantDesc`, which has a sealed hierarchy except `DynamicConstantDesc`: >> JDK 20: >> ![image](https://user-images.githubusercontent.com/7806504/236991678-e30c181a-cb1f-407a-b3e0-f648fe2df788.png) >> >> This patch: >> ![image](https://github.com/openjdk/jdk/assets/7806504/4fb8ec10-4f10-4902-8b9d-107b3644b2cf) > > Thanks for this improvement suggestion. Indicating "openness" is certainly important. I was playing around with various ways of expressing it and came up with this: > > ![image](https://github.com/openjdk/jdk/assets/7457876/3f5204b5-7dd7-47ee-9df4-397c5b69f0d4) > > What is your opinion on it? It might be slightly more intuitive? We could even do this: > > ![image](https://github.com/openjdk/jdk/assets/7457876/32e2542f-ef81-4523-a658-d0a39da13ea8) > > > > Here is the code: > > > > digraph G { > > shape="none" > rankdir = "BT" > > ClassDesc -> ConstantDesc > MethodHandleDesc -> ConstantDesc > DirectMethodHandleDesc -> MethodHandleDesc > DynamicConstantDesc -> ConstantDesc > Float -> ConstantDesc > Hidden1 -> DynamicConstantDesc [style="dashed"] > > Hidden1 [label=""] > > ClassDesc [shape=none]; > ConstantDesc [shape=none]; > MethodHandleDesc [shape=none]; > DynamicConstantDesc [shape=none]; > DirectMethodHandleDesc [shape=none]; > Float [shape=none]; > Hidden1 [shape=none]; > } @minborg Done. I've made the `` in italics and its hover label is "Non-sealed Hierarchy". Example images of ConstantDesc and CallSite: ![image](https://github.com/openjdk/jdk/assets/7806504/f8e83eee-68b4-4a1e-9353-9c5ba5f453ee) ![image](https://github.com/openjdk/jdk/assets/7806504/f98dca5d-0fa9-4fa6-a680-df6c7b690524) In addition, the copyright year is updated to reflect the correct creation date of this taglet (2022 instead of 2017) ------------- PR Comment: https://git.openjdk.org/jdk/pull/13877#issuecomment-1550071543 From liach at openjdk.org Tue May 16 18:20:45 2023 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 May 2023 18:20:45 GMT Subject: RFR: 8307326: Package jdk.internal.classfile.java.lang.constant become obsolete In-Reply-To: References: Message-ID: <5CjNjAQme8BTCA-TJzjjV8Zb7e-xYvuHvQENi7nUkrs=.5c407434-4d8f-42a7-aec6-37961ea9afe3@github.com> On Mon, 15 May 2023 08:38:54 GMT, Adam Sotona wrote: > Package `jdk.internal.classfile.java.lang.constant` containing `ModuleDesc` and `PackageDesc` become obsolete after [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729). > All references to `jdk.internal.classfile.java.lang.constant.ModuleDesc` and `jdk.internal.classfile.java.lang.constant.PackageDesc` across all JDK sources, tests and JMH benchmarks are replaced with `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc`. > `jdk.internal.classfile.java.lang.constant` package export hooks are removed from java.base module-info, make files and test headers. > Content of `jdk.internal.classfile.java.lang.constant` package and related tests under `jdk.classfile` are deleted. > Method references renamed in [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729) are fixed: > - `PackageDesc::packageName` to `PackageDesc::name` > - `PackageDesc::packageInternalName` to `PackageDesc::internalName` > - `ModuleDesc::moduleName` to `ModuleDesc::name`. > > Please review this pull request. > > Thanks, > Adam I think these are all the occurrences of jdk.internal.classfile.java.lang.constant package. ------------- Marked as reviewed by liach (Author). PR Review: https://git.openjdk.org/jdk/pull/13979#pullrequestreview-1429153817 From jlaskey at openjdk.org Tue May 16 18:34:49 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 16 May 2023 18:34:49 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v15] In-Reply-To: References: Message-ID: > Add flexible main methods and anonymous main classes to the Java language. Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: - Merge branch 'master' into 8306112 - Requested Changes #2 - Update VirtualParser.java - Merge branch 'master' into 8306112 - Refactor source code launcher - Typo - Recommended changes #2 - Anonymous main classes renamed to unnamed classes - Add test - Move AnonymousMainClass to parser - ... and 19 more: https://git.openjdk.org/jdk/compare/316bc79e...185532a8 ------------- Changes: https://git.openjdk.org/jdk/pull/13689/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=14 Stats: 1234 lines in 28 files changed: 1069 ins; 77 del; 88 mod Patch: https://git.openjdk.org/jdk/pull/13689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689 PR: https://git.openjdk.org/jdk/pull/13689 From alanb at openjdk.org Tue May 16 18:34:50 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 16 May 2023 18:34:50 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v13] In-Reply-To: <9ftk4o0DvBHN-oDAlW6nW7_oM_KU8k3ZBzezvgfKWwM=.ec49936e-68a8-4b6c-a8bd-ed8c70ef3faf@github.com> References: <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com> <9ftk4o0DvBHN-oDAlW6nW7_oM_KU8k3ZBzezvgfKWwM=.ec49936e-68a8-4b6c-a8bd-ed8c70ef3faf@github.com> Message-ID: <90pfraspjRWfTepdB2XMf4siiN6ZFqCTh2Byn8UoI_M=.5d15d232-1589-4455-8c9e-61d86ec013f6@github.com> On Mon, 15 May 2023 17:05:48 GMT, Jim Laskey wrote: > InstanceMainTest does check precedence. Are you expecting a test for all combinations? Sorry, we discussed this in previous comments, ignore my latest comment on this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194221553 From kbarrett at openjdk.org Wed May 17 03:29:44 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 17 May 2023 03:29:44 GMT Subject: RFR: 8308071: [REDO] update for deprecated sprintf for src/utils [v2] In-Reply-To: References: Message-ID: On Tue, 16 May 2023 16:54:47 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> This is a redo of JDK-8307855, where issues were found after integration. >> >> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the src/utils directory. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > replace strcpy with snprintf Changes requested by kbarrett (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13995#pullrequestreview-1429733422 From kbarrett at openjdk.org Wed May 17 03:29:46 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 17 May 2023 03:29:46 GMT Subject: RFR: 8308071: [REDO] update for deprecated sprintf for src/utils [v2] In-Reply-To: References: Message-ID: On Tue, 16 May 2023 16:49:27 GMT, Xue-Lei Andrew Fan wrote: >> src/utils/hsdis/binutils/hsdis-binutils.c line 248: >> >>> 246: size_t used_size = strlen(close); >>> 247: char* p = buf + used_size; >>> 248: bufsize -= used_size; >> >> May not happen in practice, but if `used_size` is larger than `bufsize` this will wrap to a very large value. Perhaps the `strcpy` above should also be an `snprintf`, and the return value handled the same way as for the subsequent `snprintf` calls? > > I think it is safe as the `buf` size has been checked at around line 230. However, it may make the code easier to read if replacing `strcpy` with `snprintf`. The patch was updated accordingly. This and all uses of snprintf in this change are incorrect. If the output is truncated, snprintf returns the number of characters that would have been written if there had been enough space. That is, the result may be larger than bufsize. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13995#discussion_r1195887441 From xuelei at openjdk.org Wed May 17 04:17:43 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 17 May 2023 04:17:43 GMT Subject: RFR: 8308071: [REDO] update for deprecated sprintf for src/utils [v2] In-Reply-To: References: Message-ID: On Wed, 17 May 2023 03:26:45 GMT, Kim Barrett wrote: > This and all uses of snprintf in this change are incorrect. If the output is truncated, snprintf returns the number of characters that would have been written if there had been enough space. That is, the result may be larger than bufsize. The correctness of this change depends on the fact that the buffer has sufficient capacity, which has been checked at line 230. I agreed that this is not a typical use of `snprintf` that the returned value is not checked. I will make an update to check the returned value of `snprintf`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13995#discussion_r1195909903 From xuelei at openjdk.org Wed May 17 05:49:00 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 17 May 2023 05:49:00 GMT Subject: RFR: 8308071: [REDO] update for deprecated sprintf for src/utils [v3] In-Reply-To: References: Message-ID: <0Yayi6b8NFU7LzVm-3KP8PgtsI-xkcOOzIMTEt6_vMI=.5fcad730-2f76-40eb-b6e4-2668729e1ba8@github.com> > Hi, > > This is a redo of JDK-8307855, where issues were found after integration. > > The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the src/utils directory. > > Thanks, > Xuelei Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: check returned value of snprintf ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13995/files - new: https://git.openjdk.org/jdk/pull/13995/files/1f833d5e..dd6ddbc4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13995&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13995&range=01-02 Stats: 14 lines in 1 file changed: 12 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13995.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13995/head:pull/13995 PR: https://git.openjdk.org/jdk/pull/13995 From pminborg at openjdk.org Wed May 17 06:37:46 2023 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 17 May 2023 06:37:46 GMT Subject: RFR: 8307652: sealed class hierarchy graph doesn't distinguish non-sealed classes [v2] In-Reply-To: References: Message-ID: On Tue, 16 May 2023 17:16:57 GMT, Chen Liang wrote: >> `@sealedGraph` had a mechanism to render non-sealed classes differently, but it's useless because the graph nodes are not bordered. This patch converts the non-sealed classes to be rendered in italics instead. >> >> An example of `ConstantDesc`, which has a sealed hierarchy except `DynamicConstantDesc`: >> JDK 20: >> ![image](https://user-images.githubusercontent.com/7806504/236991678-e30c181a-cb1f-407a-b3e0-f648fe2df788.png) >> >> This patch: >> ![image](https://github.com/openjdk/jdk/assets/7806504/4fb8ec10-4f10-4902-8b9d-107b3644b2cf) > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Use an edge and node to indicate non-sealed hierarchy > - Merge branch 'master' into fix/sealedgraph-nonsealed > - 8307652: sealed class hierarchy graph doesn't distinguish non-sealed classes These changes look very good. A significant improvement to the graph rendering. ------------- Marked as reviewed by pminborg (Committer). PR Review: https://git.openjdk.org/jdk/pull/13877#pullrequestreview-1429913989 From kbarrett at openjdk.org Wed May 17 08:58:49 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 17 May 2023 08:58:49 GMT Subject: RFR: 8308071: [REDO] update for deprecated sprintf for src/utils [v3] In-Reply-To: <0Yayi6b8NFU7LzVm-3KP8PgtsI-xkcOOzIMTEt6_vMI=.5fcad730-2f76-40eb-b6e4-2668729e1ba8@github.com> References: <0Yayi6b8NFU7LzVm-3KP8PgtsI-xkcOOzIMTEt6_vMI=.5fcad730-2f76-40eb-b6e4-2668729e1ba8@github.com> Message-ID: On Wed, 17 May 2023 05:49:00 GMT, Xue-Lei Andrew Fan wrote: >> Hi, >> >> This is a redo of JDK-8307855, where issues were found after integration. >> >> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the src/utils directory. >> >> Thanks, >> Xuelei > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > check returned value of snprintf Changes requested by kbarrett (Reviewer). src/utils/hsdis/binutils/hsdis-binutils.c line 246: > 244: > 245: size_t used_size = snprintf(buf, bufsize, "%s", close); > 246: if ((used_size < 0) || (used_size >= bufsize)) { (used_size < 0) is tautologically false, since used_size is a size_t, so unsigned. I'm somewhat surprised this doesn't trigger a warning from some compiler. ------------- PR Review: https://git.openjdk.org/jdk/pull/13995#pullrequestreview-1430144188 PR Review Comment: https://git.openjdk.org/jdk/pull/13995#discussion_r1196161411 From kbarrett at openjdk.org Wed May 17 08:58:51 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 17 May 2023 08:58:51 GMT Subject: RFR: 8308071: [REDO] update for deprecated sprintf for src/utils [v3] In-Reply-To: References: Message-ID: <6oTmCMbuV_t23TrGFTMv1BuKTBt3GzpY4W7iXfuuKFA=.22e67e0a-c0d8-4d5d-8e20-039ce3243e6c@github.com> On Wed, 17 May 2023 04:15:01 GMT, Xue-Lei Andrew Fan wrote: >> This and all uses of snprintf in this change are incorrect. If the output is truncated, snprintf returns the >> number of characters that would have been written if there had been enough space. That is, the result >> may be larger than bufsize. > >> This and all uses of snprintf in this change are incorrect. If the output is truncated, snprintf returns the number of characters that would have been written if there had been enough space. That is, the result may be larger than bufsize. > > The correctness of this change depends on the fact that the buffer has sufficient capacity, which has been checked at line 230. I agreed that this is not a typical use of `snprintf` that the returned value is not checked. I will make an update to check the returned value of `snprintf`. OK, I missed that. (The relevant code doesn't show up in the default github diff. I really ought to know better than to use that view for reviewing.) Even having been pointed to the code, I had to do some counting and such to convince myself that it was safe. A bit of commentary might save some time for the next reader. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13995#discussion_r1196170575 From kbarrett at openjdk.org Wed May 17 09:47:46 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 17 May 2023 09:47:46 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> Message-ID: <_iLBokObnsgDeHfGIDZ2BmAg7xx6LkpGnLH6GhN_xPo=.a836570a-0fae-4af3-a09a-a8466694de06@github.com> On Mon, 15 May 2023 09:34:28 GMT, JoKern65 wrote: >> src/hotspot/os/aix/os_aix.cpp line 464: >> >>> 462: guarantee0(shmid != -1); // Should always work. >>> 463: // Try to set pagesize. >>> 464: struct shmid_ds shm_buf = { {0,0,0,0,0,0,0,0},0,0,0,0,0,0,0,0,0,0,0,0,0,0 }; >> >> Would just `= {};` work? (I think it should, but with warnings who knows...) > > os_aix.cpp:460:37: error: missing field 'gid' initializer [-Werror,-Wmissing-field-initializers] > struct shmid_ds shm_buf = { 0 }; > > ={} seems to work, but I do not know if it works on every compiler because standard says: the initializer must be a **non-empty, (until C23)** brace-enclosed, comma-separated list of initializers for the members. > Should I then disable Warning missing-field-initializers? Use struct shmid_ds shm_buf{}; to _value-initialize_. Calls the default constructor if there is one. Otherwise, performs _zero-initialization_, which is what we want here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1196232015 From kbarrett at openjdk.org Wed May 17 09:58:45 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 17 May 2023 09:58:45 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <4YjPGApkbH1tUGsRDIx4zr0wNyWh_KlhmCTWcVlrzog=.8618971d-58be-46da-ba52-0041ab476d95@github.com> Message-ID: On Tue, 16 May 2023 07:22:44 GMT, Matthias Baesken wrote: >> I think disabling the warning is fine. Alternatively, we could `#define MIN_INT16 -32768` somewhere or introduce `const int16_t min_int16 = (int16_t)1 << (sizeof(int16_t)*BitsPerByte-1);`. What do you prefer, Kim? > > Hi Martin/Joachim , I like the MIN_INT16 define idea Martin proposed, makes the code more readable and makes the warning go away . Use `INT16_MIN`, which is in , which we already use. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1196239520 From kbarrett at openjdk.org Wed May 17 09:58:46 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 17 May 2023 09:58:46 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> <2nOXHGp99zMM5YyMuMgN0blrNJjpXJjeLiJIc1dR4r0=.01e91354-789e-484f-a05c-01261354c0e8@github.com> Message-ID: On Mon, 15 May 2023 09:52:59 GMT, JoKern65 wrote: >> Such a fix of adlc is probably out of scope for this change though. We should probably have a separate bug for that. > > And what should I use as a workaround meanwhile to get our new compiler through? Now that I understand what the proposed change (adding an extra level of parens) is for, I'm okay with that for this PR. But there should be some followup to look at the code generated by adlc in this area. There could be other places where the wrong thing is being done but not generating a warning. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1196243839 From duke at openjdk.org Wed May 17 11:54:37 2023 From: duke at openjdk.org (JoKern65) Date: Wed, 17 May 2023 11:54:37 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v3] In-Reply-To: References: Message-ID: <-9STqzY6P_smSUlD7O-3n0IXoPi5t1TYYmtIeFpbDR0=.dee45abf-c001-4498-908f-ca272b224ca6@github.com> > When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". > Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. > A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > With this PR we address only the platform dependent code changes. JoKern65 has updated the pull request incrementally with one additional commit since the last revision: followed the suggested changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13953/files - new: https://git.openjdk.org/jdk/pull/13953/files/d7e2d4f9..c3bd97b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13953&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13953&range=01-02 Stats: 12 lines in 2 files changed: 4 ins; 3 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/13953.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13953/head:pull/13953 PR: https://git.openjdk.org/jdk/pull/13953 From mbaesken at openjdk.org Wed May 17 11:54:38 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 17 May 2023 11:54:38 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v3] In-Reply-To: <-9STqzY6P_smSUlD7O-3n0IXoPi5t1TYYmtIeFpbDR0=.dee45abf-c001-4498-908f-ca272b224ca6@github.com> References: <-9STqzY6P_smSUlD7O-3n0IXoPi5t1TYYmtIeFpbDR0=.dee45abf-c001-4498-908f-ca272b224ca6@github.com> Message-ID: <4FAR4XpMioQo1f-1Ynu7JJmAx96PuApjhtZXS7_3KYQ=.9364b390-032e-479a-8558-0167f3077c43@github.com> On Wed, 17 May 2023 11:49:24 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. >> With this PR we address only the platform dependent code changes. > > JoKern65 has updated the pull request incrementally with one additional commit since the last revision: > > followed the suggested changes Looks okay to me, thanks for addressing the issues. ------------- Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13953#pullrequestreview-1430464795 From duke at openjdk.org Wed May 17 11:54:41 2023 From: duke at openjdk.org (JoKern65) Date: Wed, 17 May 2023 11:54:41 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> Message-ID: On Fri, 12 May 2023 16:16:01 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. >> With this PR we address only the platform dependent code changes. > > JoKern65 has updated the pull request incrementally with one additional commit since the last revision: > > cosmetic changes I implemented all suggested changes. Thank you all for participating. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13953#issuecomment-1551237290 From mbaesken at openjdk.org Wed May 17 11:54:41 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 17 May 2023 11:54:41 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> Message-ID: On Fri, 12 May 2023 16:16:01 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. >> With this PR we address only the platform dependent code changes. > > JoKern65 has updated the pull request incrementally with one additional commit since the last revision: > > cosmetic changes error in GHA is unrelated The following packages have unmet dependencies: libc6:i386 : Depends: libgcc-s1:i386 but it is not going to be installed libtiffxx5:i386 : Depends: libstdc++6:i386 (>= 5) but it is not going to be installed E: Unable to correct problems, you have held broken packages. Error: Process completed with exit code 100. probably some mess in the infra. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13953#issuecomment-1551246979 From duke at openjdk.org Wed May 17 11:54:44 2023 From: duke at openjdk.org (JoKern65) Date: Wed, 17 May 2023 11:54:44 GMT Subject: Integrated: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code In-Reply-To: References: Message-ID: <0BTPHRbjRqlHSDzJJLkbJPC4Cqhgt1qN1a6RR8vTzGQ=.e73e0537-84c7-4764-a474-123dae1f46d5@github.com> On Fri, 12 May 2023 12:01:43 GMT, JoKern65 wrote: > When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". > Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. > A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > With this PR we address only the platform dependent code changes. This pull request has now been integrated. Changeset: c7951cf6 Author: JoKern65 Committer: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/c7951cf674581ccd021e7403f5c3bd898e0542f4 Stats: 37 lines in 9 files changed: 8 ins; 0 del; 29 mod 8306304: Fix xlc17 clang warnings in ppc and aix code Reviewed-by: erikj, tsteele, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/13953 From duke at openjdk.org Wed May 17 12:33:56 2023 From: duke at openjdk.org (xpbob) Date: Wed, 17 May 2023 12:33:56 GMT Subject: RFR: 8308283: Build failure with gcc 13.1.0 Message-ID: configure --enable-debug error: infinite recursion detected [-Werror=infinite-recursion] ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) configure java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] ?1161 | const LangSys& l = this+_.second.offset; ------------- Commit messages: - 8308283: Build failure with gcc 13.1.0 Changes: https://git.openjdk.org/jdk/pull/14032/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14032&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308283 Stats: 13 lines in 4 files changed: 12 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14032.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14032/head:pull/14032 PR: https://git.openjdk.org/jdk/pull/14032 From asotona at openjdk.org Wed May 17 12:48:53 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 17 May 2023 12:48:53 GMT Subject: Integrated: 8307326: Package jdk.internal.classfile.java.lang.constant become obsolete In-Reply-To: References: Message-ID: On Mon, 15 May 2023 08:38:54 GMT, Adam Sotona wrote: > Package `jdk.internal.classfile.java.lang.constant` containing `ModuleDesc` and `PackageDesc` become obsolete after [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729). > All references to `jdk.internal.classfile.java.lang.constant.ModuleDesc` and `jdk.internal.classfile.java.lang.constant.PackageDesc` across all JDK sources, tests and JMH benchmarks are replaced with `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc`. > `jdk.internal.classfile.java.lang.constant` package export hooks are removed from java.base module-info, make files and test headers. > Content of `jdk.internal.classfile.java.lang.constant` package and related tests under `jdk.classfile` are deleted. > Method references renamed in [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729) are fixed: > - `PackageDesc::packageName` to `PackageDesc::name` > - `PackageDesc::packageInternalName` to `PackageDesc::internalName` > - `ModuleDesc::moduleName` to `ModuleDesc::name`. > > Please review this pull request. > > Thanks, > Adam This pull request has now been integrated. Changeset: 5763be72 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/5763be726700be322de3bbaf345d80e11936b472 Stats: 503 lines in 46 files changed: 0 ins; 446 del; 57 mod 8307326: Package jdk.internal.classfile.java.lang.constant become obsolete Reviewed-by: erikj, liach ------------- PR: https://git.openjdk.org/jdk/pull/13979 From erikj at openjdk.org Wed May 17 13:08:46 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 17 May 2023 13:08:46 GMT Subject: RFR: 8308283: Build failure with gcc 13.1.0 In-Reply-To: References: Message-ID: On Wed, 17 May 2023 12:26:22 GMT, xpbob wrote: > configure --enable-debug > > error: infinite recursion detected [-Werror=infinite-recursion] > ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) > > configure > > java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] > ?1161 | const LangSys& l = this+_.second.offset; Build changes look good. Someone from hotspot should also weigh in. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14032#pullrequestreview-1430645081 From xuelei at openjdk.org Wed May 17 15:04:50 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 17 May 2023 15:04:50 GMT Subject: RFR: 8308071: [REDO] update for deprecated sprintf for src/utils [v4] In-Reply-To: References: Message-ID: > Hi, > > This is a redo of JDK-8307855, where issues were found after integration. > > The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the src/utils directory. > > Thanks, > Xuelei Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: size_t to int ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13995/files - new: https://git.openjdk.org/jdk/pull/13995/files/dd6ddbc4..244278a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13995&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13995&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13995.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13995/head:pull/13995 PR: https://git.openjdk.org/jdk/pull/13995 From xuelei at openjdk.org Wed May 17 15:04:57 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 17 May 2023 15:04:57 GMT Subject: RFR: 8308071: [REDO] update for deprecated sprintf for src/utils [v3] In-Reply-To: References: <0Yayi6b8NFU7LzVm-3KP8PgtsI-xkcOOzIMTEt6_vMI=.5fcad730-2f76-40eb-b6e4-2668729e1ba8@github.com> Message-ID: <-qvQkvH8SylX3unheSpOdsjz-mhrnyvqgxtNLKiOmGg=.41f065ea-f856-4436-88d3-8c7b8b01726d@github.com> On Wed, 17 May 2023 08:48:37 GMT, Kim Barrett wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> check returned value of snprintf > > src/utils/hsdis/binutils/hsdis-binutils.c line 246: > >> 244: >> 245: size_t used_size = snprintf(buf, bufsize, "%s", close); >> 246: if ((used_size < 0) || (used_size >= bufsize)) { > > (used_size < 0) is tautologically false, since used_size is a size_t, so unsigned. I'm somewhat surprised > this doesn't trigger a warning from some compiler. Updated to use `int` to replace `size_t.`. Thank you for the catching. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13995#discussion_r1196646900 From duke at openjdk.org Wed May 17 15:27:24 2023 From: duke at openjdk.org (Jan Kratochvil) Date: Wed, 17 May 2023 15:27:24 GMT Subject: RFR: 8308290: Add fontconfig requirement to building.md Message-ID: After following all the commands in `building.md` I still get on Fedora 38 x86_64: checking for fontconfig/fontconfig.h... no configure: error: Could not find fontconfig! Another issue is that it is all written with `yum` instead of `dnf` but people can handle it I guess. ------------- Commit messages: - 8308290: Add fontconfig requirement to building.md Changes: https://git.openjdk.org/jdk/pull/14034/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14034&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308290 Stats: 23 lines in 2 files changed: 23 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14034.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14034/head:pull/14034 PR: https://git.openjdk.org/jdk/pull/14034 From erikj at openjdk.org Wed May 17 15:58:02 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 17 May 2023 15:58:02 GMT Subject: RFR: 8308290: Add fontconfig requirement to building.md In-Reply-To: References: Message-ID: On Wed, 17 May 2023 14:41:01 GMT, Jan Kratochvil wrote: > After following all the commands in `building.md` I still get on Fedora 38 x86_64: > > > checking for fontconfig/fontconfig.h... no > configure: error: Could not find fontconfig! > > > Another issue is that it is all written with `yum` instead of `dnf` but people can handle it I guess. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14034#pullrequestreview-1431053997 From prr at openjdk.org Wed May 17 18:52:53 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 17 May 2023 18:52:53 GMT Subject: RFR: 8308283: Build failure with gcc 13.1.0 In-Reply-To: References: Message-ID: <2DGmslRRkkyYHGuhLnCslvb9-rC1ojbRkwzeEt_lT6E=.daa21a27-1410-4e84-af70-636b6bf35089@github.com> On Wed, 17 May 2023 12:26:22 GMT, xpbob wrote: > configure --enable-debug > > error: infinite recursion detected [-Werror=infinite-recursion] > ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) > > configure > > java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] > ?1161 | const LangSys& l = this+_.second.offset; This is a duplicate of https://bugs.openjdk.org/browse/JDK-8307210 Please check for existing reports before creating a new bug. We already plan to fix this before we officially upgrade to 13.1, until then you just disable the warning. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14032#issuecomment-1551894669 From jiefu at openjdk.org Wed May 17 23:08:48 2023 From: jiefu at openjdk.org (Jie Fu) Date: Wed, 17 May 2023 23:08:48 GMT Subject: RFR: 8308283: Build failure with gcc 13.1.0 In-Reply-To: <2DGmslRRkkyYHGuhLnCslvb9-rC1ojbRkwzeEt_lT6E=.daa21a27-1410-4e84-af70-636b6bf35089@github.com> References: <2DGmslRRkkyYHGuhLnCslvb9-rC1ojbRkwzeEt_lT6E=.daa21a27-1410-4e84-af70-636b6bf35089@github.com> Message-ID: On Wed, 17 May 2023 18:49:44 GMT, Phil Race wrote: > This is a duplicate of https://bugs.openjdk.org/browse/JDK-8307210 I don't think so since it also fixes the build broken due to `-Werror=infinite-recursion`. Actually, `-Werror=infinite-recursion` was first introduced in GCC12. So the build will also fail with GCC12. > Please check for existing reports before creating a new bug. We already plan to fix this before we officially upgrade to 13.1, until then you just disable the warning. I think it's fine to just disable the warning before you have cycles to fix it since it's a third-party code. Now part of our testing machines had been upgrade to GCC13 so it would be good to fix it as soon as possible. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14032#issuecomment-1552195846 From jiefu at openjdk.org Wed May 17 23:24:48 2023 From: jiefu at openjdk.org (Jie Fu) Date: Wed, 17 May 2023 23:24:48 GMT Subject: RFR: 8308283: Build failure with gcc 13.1.0 In-Reply-To: References: Message-ID: On Wed, 17 May 2023 12:26:22 GMT, xpbob wrote: > configure --enable-debug > > error: infinite recursion detected [-Werror=infinite-recursion] > ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) > > configure > > java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] > ?1161 | const LangSys& l = this+_.second.offset; @xpbob , maybe, it would be better to change the JBS title with something like `Build failure with GCC12 & GCC13`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14032#issuecomment-1552206443 From duke at openjdk.org Thu May 18 01:55:46 2023 From: duke at openjdk.org (xpbob) Date: Thu, 18 May 2023 01:55:46 GMT Subject: RFR: 8308283: Build failure with gcc 13.1.0 In-Reply-To: References: Message-ID: On Wed, 17 May 2023 12:26:22 GMT, xpbob wrote: > configure --enable-debug > > error: infinite recursion detected [-Werror=infinite-recursion] > ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) > > configure > > java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] > ?1161 | const LangSys& l = this+_.second.offset; The patch here involves two different parts. I tried to change the JBS title ------------- PR Comment: https://git.openjdk.org/jdk/pull/14032#issuecomment-1552298341 From duke at openjdk.org Thu May 18 02:09:00 2023 From: duke at openjdk.org (xpbob) Date: Thu, 18 May 2023 02:09:00 GMT Subject: RFR: 8308283: Build failure with gcc 13.1.0 In-Reply-To: <2DGmslRRkkyYHGuhLnCslvb9-rC1ojbRkwzeEt_lT6E=.daa21a27-1410-4e84-af70-636b6bf35089@github.com> References: <2DGmslRRkkyYHGuhLnCslvb9-rC1ojbRkwzeEt_lT6E=.daa21a27-1410-4e84-af70-636b6bf35089@github.com> Message-ID: On Wed, 17 May 2023 18:49:44 GMT, Phil Race wrote: >> configure --enable-debug >> >> error: infinite recursion detected [-Werror=infinite-recursion] >> ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) >> >> configure >> >> java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] >> ?1161 | const LangSys& l = this+_.second.offset; > > This is a duplicate of https://bugs.openjdk.org/browse/JDK-8307210 > Please check for existing reports before creating a new bug. > We already plan to fix this before we officially upgrade to 13.1, until then you just disable the warning. @prrace hi I found the error: infinite recursion detected [-Werror=infinite-recursion] message and check the information in existing reports,There are no similar bugs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14032#issuecomment-1552307691 From duke at openjdk.org Thu May 18 02:18:48 2023 From: duke at openjdk.org (xpbob) Date: Thu, 18 May 2023 02:18:48 GMT Subject: RFR: 8308283: Build failure with GCC12 & GCC13 In-Reply-To: References: Message-ID: On Wed, 17 May 2023 23:21:59 GMT, Jie Fu wrote: >> configure --enable-debug >> >> error: infinite recursion detected [-Werror=infinite-recursion] >> ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) >> >> configure >> >> java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] >> ?1161 | const LangSys& l = this+_.second.offset; > > @xpbob , maybe, it would be better to change the JBS title with something like `Build failure with GCC12 & GCC13`? @DamonFool @prrace I have changed the JBS title ------------- PR Comment: https://git.openjdk.org/jdk/pull/14032#issuecomment-1552313421 From jiefu at openjdk.org Thu May 18 02:38:51 2023 From: jiefu at openjdk.org (Jie Fu) Date: Thu, 18 May 2023 02:38:51 GMT Subject: RFR: 8308283: Build failure with GCC12 & GCC13 In-Reply-To: References: Message-ID: On Wed, 17 May 2023 12:26:22 GMT, xpbob wrote: > configure --enable-debug > > error: infinite recursion detected [-Werror=infinite-recursion] > ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) > > configure > > java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] > ?1161 | const LangSys& l = this+_.second.offset; src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 49: > 47: // Disable -Winfinite-recursion which is introduced in GCC 12. > 48: #if !defined(__clang_major__) && (__GNUC__ >= 12) > 49: #define PRAGMA_INFINITE_RECURSION_IGNORED PRAGMA_DISABLE_GCC_WARNING("-Winfinite-recursion") How about moving this line after Line 44? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14032#discussion_r1197283986 From duke at openjdk.org Thu May 18 03:11:23 2023 From: duke at openjdk.org (xpbob) Date: Thu, 18 May 2023 03:11:23 GMT Subject: RFR: 8308283: Build failure with GCC12 & GCC13 [v2] In-Reply-To: References: Message-ID: > configure --enable-debug > > error: infinite recursion detected [-Werror=infinite-recursion] > ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) > > configure > > java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] > ?1161 | const LangSys& l = this+_.second.offset; xpbob has updated the pull request incrementally with one additional commit since the last revision: merge line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14032/files - new: https://git.openjdk.org/jdk/pull/14032/files/1c80f579..3da47371 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14032&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14032&range=00-01 Stats: 5 lines in 1 file changed: 2 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14032.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14032/head:pull/14032 PR: https://git.openjdk.org/jdk/pull/14032 From duke at openjdk.org Thu May 18 03:15:53 2023 From: duke at openjdk.org (xpbob) Date: Thu, 18 May 2023 03:15:53 GMT Subject: RFR: 8308283: Build failure with GCC12 & GCC13 [v3] In-Reply-To: References: Message-ID: <8wy1eahoLl-9S83Eddo3jw3o3cKSE8HyqquqRfqsiw4=.ff75b795-38d3-4f00-99a0-135fe7c49277@github.com> > configure --enable-debug > > error: infinite recursion detected [-Werror=infinite-recursion] > ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) > > configure > > java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] > ?1161 | const LangSys& l = this+_.second.offset; xpbob has updated the pull request incrementally with one additional commit since the last revision: remove blank ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14032/files - new: https://git.openjdk.org/jdk/pull/14032/files/3da47371..34906c92 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14032&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14032&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14032.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14032/head:pull/14032 PR: https://git.openjdk.org/jdk/pull/14032 From jiefu at openjdk.org Thu May 18 03:21:49 2023 From: jiefu at openjdk.org (Jie Fu) Date: Thu, 18 May 2023 03:21:49 GMT Subject: RFR: 8308283: Build failure with GCC12 & GCC13 [v3] In-Reply-To: <8wy1eahoLl-9S83Eddo3jw3o3cKSE8HyqquqRfqsiw4=.ff75b795-38d3-4f00-99a0-135fe7c49277@github.com> References: <8wy1eahoLl-9S83Eddo3jw3o3cKSE8HyqquqRfqsiw4=.ff75b795-38d3-4f00-99a0-135fe7c49277@github.com> Message-ID: On Thu, 18 May 2023 03:15:53 GMT, xpbob wrote: >> configure --enable-debug >> >> error: infinite recursion detected [-Werror=infinite-recursion] >> ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) >> >> configure >> >> java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] >> ?1161 | const LangSys& l = this+_.second.offset; > > xpbob has updated the pull request incrementally with one additional commit since the last revision: > > remove blank LGTM Thanks for the update. ------------- Marked as reviewed by jiefu (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14032#pullrequestreview-1431943484 From duke at openjdk.org Thu May 18 03:21:51 2023 From: duke at openjdk.org (xpbob) Date: Thu, 18 May 2023 03:21:51 GMT Subject: RFR: 8308283: Build failure with GCC12 & GCC13 In-Reply-To: References: Message-ID: <8mQnUCyvdXhXrw0kwMFw7SPhwgSN5S5jZCcnYLmpBMc=.b8a6b84d-d65c-4b82-9e0c-fb54bb03f217@github.com> On Wed, 17 May 2023 23:21:59 GMT, Jie Fu wrote: >> configure --enable-debug >> >> error: infinite recursion detected [-Werror=infinite-recursion] >> ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) >> >> configure >> >> java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] >> ?1161 | const LangSys& l = this+_.second.offset; > > @xpbob , maybe, it would be better to change the JBS title with something like `Build failure with GCC12 & GCC13`? @DamonFool Thanks for the review,The code has been updated ------------- PR Comment: https://git.openjdk.org/jdk/pull/14032#issuecomment-1552348251 From duke at openjdk.org Thu May 18 08:50:57 2023 From: duke at openjdk.org (Jan Kratochvil) Date: Thu, 18 May 2023 08:50:57 GMT Subject: Integrated: 8308290: Add fontconfig requirement to building.md In-Reply-To: References: Message-ID: On Wed, 17 May 2023 14:41:01 GMT, Jan Kratochvil wrote: > After following all the commands in `building.md` I still get on Fedora 38 x86_64: > > > checking for fontconfig/fontconfig.h... no > configure: error: Could not find fontconfig! > > > Another issue is that it is all written with `yum` instead of `dnf` but people can handle it I guess. This pull request has now been integrated. Changeset: 57b8ed13 Author: Jan Kratochvil Committer: Yuri Nesterenko URL: https://git.openjdk.org/jdk/commit/57b8ed13984eab1ab0eaf70c1904dc0f50fe6129 Stats: 23 lines in 2 files changed: 23 ins; 0 del; 0 mod 8308290: Add fontconfig requirement to building.md Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/14034 From duke at openjdk.org Thu May 18 12:29:57 2023 From: duke at openjdk.org (xpbob) Date: Thu, 18 May 2023 12:29:57 GMT Subject: Integrated: 8308283: Build failure with GCC12 & GCC13 In-Reply-To: References: Message-ID: On Wed, 17 May 2023 12:26:22 GMT, xpbob wrote: > configure --enable-debug > > error: infinite recursion detected [-Werror=infinite-recursion] > ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) > > configure > > java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] > ?1161 | const LangSys& l = this+_.second.offset; This pull request has now been integrated. Changeset: bfc3ccd9 Author: bobpengxie Committer: Jie Fu URL: https://git.openjdk.org/jdk/commit/bfc3ccd90d579f6cba3a704766b7a1ea56beebe1 Stats: 13 lines in 4 files changed: 11 ins; 1 del; 1 mod 8308283: Build failure with GCC12 & GCC13 Reviewed-by: erikj, jiefu ------------- PR: https://git.openjdk.org/jdk/pull/14032 From kbarrett at openjdk.org Thu May 18 15:23:00 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 18 May 2023 15:23:00 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: <_iLBokObnsgDeHfGIDZ2BmAg7xx6LkpGnLH6GhN_xPo=.a836570a-0fae-4af3-a09a-a8466694de06@github.com> References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> <_iLBokObnsgDeHfGIDZ2BmAg7xx6LkpGnLH6GhN_xPo=.a836570a-0fae-4af3-a09a-a8466694de06@github.com> Message-ID: On Wed, 17 May 2023 09:44:47 GMT, Kim Barrett wrote: >> os_aix.cpp:460:37: error: missing field 'gid' initializer [-Werror,-Wmissing-field-initializers] >> struct shmid_ds shm_buf = { 0 }; >> >> ={} seems to work, but I do not know if it works on every compiler because standard says: the initializer must be a **non-empty, (until C23)** brace-enclosed, comma-separated list of initializers for the members. >> Should I then disable Warning missing-field-initializers? > > Use > > struct shmid_ds shm_buf{}; > > to _value-initialize_. Calls the default constructor if there is one. Otherwise, performs _zero-initialization_, > which is what we want here. The final suggested change (to value-initialize the object) seems to have *not* been made. However, I think it doesn't matter. The mentioned restriction against being non-empty until C23 is not relevant. This is C++, not C. Empty initializers are, and have always been, permitted by C++. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1197956866 From kbarrett at openjdk.org Thu May 18 15:49:51 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 18 May 2023 15:49:51 GMT Subject: RFR: 8308071: [REDO] update for deprecated sprintf for src/utils [v3] In-Reply-To: <-qvQkvH8SylX3unheSpOdsjz-mhrnyvqgxtNLKiOmGg=.41f065ea-f856-4436-88d3-8c7b8b01726d@github.com> References: <0Yayi6b8NFU7LzVm-3KP8PgtsI-xkcOOzIMTEt6_vMI=.5fcad730-2f76-40eb-b6e4-2668729e1ba8@github.com> <-qvQkvH8SylX3unheSpOdsjz-mhrnyvqgxtNLKiOmGg=.41f065ea-f856-4436-88d3-8c7b8b01726d@github.com> Message-ID: <24zfRJ2Ir1egB-U5XJd37qJZUliAqAXkKIaHqE8gG-8=.3e0fc1f7-5eae-4fc9-8135-42a40f917a1e@github.com> On Wed, 17 May 2023 14:51:49 GMT, Xue-Lei Andrew Fan wrote: >> src/utils/hsdis/binutils/hsdis-binutils.c line 246: >> >>> 244: >>> 245: size_t used_size = snprintf(buf, bufsize, "%s", close); >>> 246: if ((used_size < 0) || (used_size >= bufsize)) { >> >> (used_size < 0) is tautologically false, since used_size is a size_t, so unsigned. I'm somewhat surprised >> this doesn't trigger a warning from some compiler. > > Updated to use `int` to replace `size_t.`. Thank you for the catching. bufsize is size_t, so that's a comparison between signed and unsigned values, which I think some compilers will warn about. Maybe the preceding check for negative is getting rid of that? But will that still occur in a slowdebug build, or will the lack of optimization lead to a warning? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13995#discussion_r1197985875 From azvegint at openjdk.org Thu May 18 17:17:42 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 18 May 2023 17:17:42 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v3] In-Reply-To: References: Message-ID: > Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. > This comes with some difficulties, and one of them is the inability to get screenshots from the system. > This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) > > But this functionality is a very important part of automated testing. > > > At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): > > 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) > It has several drawbacks though: > + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). > + There is no way to disable the visual "screen flash" after screenshot > + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. > Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. > But we still can consider this option as a fallback. > > > > 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) > It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. > This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. > > + implementation is more complicated comparing to Screenshot API > + no intermediate file, screenshot data can be obtained from memory > + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) > > > So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. > > This change also introduces some new behavior for the robot: > A system window now appears asking for confirmation from the user to capture the screen. > + The user can refuse the screen capture completely. In this case a security exception will be thrown. > + The user can allow a screen capture for all screens o... Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: refactoring to remove resetScreenCapturePermission ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13803/files - new: https://git.openjdk.org/jdk/pull/13803/files/482471df..3f01bb26 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=01-02 Stats: 619 lines in 10 files changed: 504 ins; 48 del; 67 mod Patch: https://git.openjdk.org/jdk/pull/13803.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13803/head:pull/13803 PR: https://git.openjdk.org/jdk/pull/13803 From azvegint at openjdk.org Thu May 18 17:17:44 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 18 May 2023 17:17:44 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots In-Reply-To: References: Message-ID: On Fri, 5 May 2023 14:58:15 GMT, Alexander Zvegintsev wrote: > Do we really need to add this new API? probably we can implement the feature w/o this new method? Please review the changes to remove resetScreenCapturePermission The token is now stored together with the bounds of the screens for which the screen capture was allowed. Now when we want to take a screenshot, we create a list of the bounds of the system screens that have the data we're interested in. Based on this list, we pick up the tokens from the previously saved ones: a. exact match of the bounds of the screens b. the same size(screens can be moved, while the old token for them works) We try to get an image with these tokens, checking that the previously associated bounds have not changed and we get the image from the capture area available to us. If, for some reason, the old token is withdrawn, a new permission will be requested to capture screens. If none of the tokens worked, we try to get a new permission. If none of above worked, we throw a SecurityException. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1553360491 From xuelei at openjdk.org Thu May 18 17:50:22 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 18 May 2023 17:50:22 GMT Subject: RFR: 8308071: [REDO] update for deprecated sprintf for src/utils [v5] In-Reply-To: References: Message-ID: > Hi, > > This is a redo of JDK-8307855, where issues were found after integration. > > The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the src/utils directory. > > Thanks, > Xuelei Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: compare between int and size_t ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13995/files - new: https://git.openjdk.org/jdk/pull/13995/files/244278a0..ccef71e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13995&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13995&range=03-04 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13995.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13995/head:pull/13995 PR: https://git.openjdk.org/jdk/pull/13995 From xuelei at openjdk.org Thu May 18 17:50:41 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 18 May 2023 17:50:41 GMT Subject: RFR: 8308071: [REDO] update for deprecated sprintf for src/utils [v3] In-Reply-To: <24zfRJ2Ir1egB-U5XJd37qJZUliAqAXkKIaHqE8gG-8=.3e0fc1f7-5eae-4fc9-8135-42a40f917a1e@github.com> References: <0Yayi6b8NFU7LzVm-3KP8PgtsI-xkcOOzIMTEt6_vMI=.5fcad730-2f76-40eb-b6e4-2668729e1ba8@github.com> <-qvQkvH8SylX3unheSpOdsjz-mhrnyvqgxtNLKiOmGg=.41f065ea-f856-4436-88d3-8c7b8b01726d@github.com> <24zfRJ2Ir1egB-U5XJd37qJZUliAqAXkKIaHqE8gG-8=.3e0fc1f7-5eae-4fc9-8135-42a40f917a1e@github.com> Message-ID: <1tYQTu-AGF4FDHDYVVh75wXiRwR8qt2YnojKtTLFNXk=.c2d20be8-8616-4c8d-85bf-dc331bd1e812@github.com> On Thu, 18 May 2023 15:46:46 GMT, Kim Barrett wrote: >> Updated to use `int` to replace `size_t.`. Thank you for the catching. > > bufsize is size_t, so that's a comparison between signed and unsigned values, which I think some compilers > will warn about. Maybe the preceding check for negative is getting rid of that? But will that still occur in > a slowdebug build, or will the lack of optimization lead to a warning? As always, this comment helps a lot. Thank you! Updated to cast `int` to `size_t` explicitly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13995#discussion_r1198111051 From jlaskey at openjdk.org Thu May 18 19:06:28 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 18 May 2023 19:06:28 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v16] In-Reply-To: References: Message-ID: > Add flexible main methods and anonymous main classes to the Java language. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Give subclass priority ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13689/files - new: https://git.openjdk.org/jdk/pull/13689/files/185532a8..83f31522 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=14-15 Stats: 96 lines in 2 files changed: 43 ins; 30 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/13689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689 PR: https://git.openjdk.org/jdk/pull/13689 From gdams at openjdk.org Fri May 19 14:52:51 2023 From: gdams at openjdk.org (George Adams) Date: Fri, 19 May 2023 14:52:51 GMT Subject: RFR: 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal [v3] In-Reply-To: <1E6ZU_haLOvT9Br8S8ytnhw6CH3BZj2IaglTd17YYqA=.5bfa0dd8-88df-49be-a2e4-69e318dd3d84@github.com> References: <1E6ZU_haLOvT9Br8S8ytnhw6CH3BZj2IaglTd17YYqA=.5bfa0dd8-88df-49be-a2e4-69e318dd3d84@github.com> Message-ID: On Sat, 6 May 2023 12:42:23 GMT, George Adams wrote: >> Deprecate the Windows x86-32 port, with the intent to remove it in a future release. > > George Adams has updated the pull request incrementally with one additional commit since the last revision: > > typo fix This JEP has now been moved from "Proposed to target" to "Targeted" which means I think we can merge this now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13852#issuecomment-1554707136 From jiangli at openjdk.org Fri May 19 20:25:52 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 19 May 2023 20:25:52 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries Message-ID: Original description for JDK-8307194 change: ----- This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target - For libjvm.a specifically, exclude operator_new.o - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a - Handle long arguments case for static build in make/common/NativeCompilation.gmk - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS ----- Updates to address build failures reported on macosx- platforms: - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`. The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly. ------------- Commit messages: - Merge branch 'master' into JDK-8307858 - Clean up. - In clude $MACHINE_FLAG in partial linking flag. - Use '-m32' instead of '-m elf_i386'. - Use '-m elf_i386' for partial linking with gcc for linux 32-bit platform. - Only do partial linking step with gcc/clang on 64-bit platform. - Need to set $1_AR_OBJ_ARG to $$($1_LD_OBJ_ARG) instead of $1_LD_OBJ_ARG. - Merge branch 'master' into JDK-8307858 - Revert src/java.desktop/linux/native/libjsound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c change. - When building a static library, partially link the input object files first. Then create the static library using the output object file produced by partial linking. - ... and 1 more: https://git.openjdk.org/jdk/compare/265f40b4...8af1ec2f Changes: https://git.openjdk.org/jdk/pull/14064/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307858 Stats: 201 lines in 10 files changed: 150 ins; 34 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/14064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14064/head:pull/14064 PR: https://git.openjdk.org/jdk/pull/14064 From erikj at openjdk.org Fri May 19 21:23:02 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 19 May 2023 21:23:02 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries In-Reply-To: References: Message-ID: On Fri, 19 May 2023 20:18:53 GMT, Jiangli Zhou wrote: > Original description for JDK-8307194 change: > ----- > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: > > - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target > > - For libjvm.a specifically, exclude operator_new.o > > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols > - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled > - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a > > - Handle long arguments case for static build in make/common/NativeCompilation.gmk > > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > ----- > > Updates to address build failures reported on macosx- platforms: > > - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. > > The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`. > > The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly. I ran this patch in our internal build and test system and got failures on macos and windows. I think I know the cause for the mac failure, but the Windows failure I don't know. It looks like the same error I saw before after the original patch went in. [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): error C2220: the following warning is treated as an error [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data [2023-05-19T20:51:31,466Z] lib/CompileJvm.gmk:152: recipe for target '/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj' failed [2023-05-19T20:51:31,466Z] make[3]: *** [/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj] Error 1 make/common/NativeCompilation.gmk line 1208: > 1206: $$(call ExecuteWithLog, $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_partial_link, \ > 1207: $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE) \ > 1208: $$($1_LD_OBJ_ARG)) This command line is missing `$$($1_SYSROOT_LDFLAGS)` which is causing it to fail in our builds with: ld: library not found for -lSystem ------------- PR Review: https://git.openjdk.org/jdk/pull/14064#pullrequestreview-1435143793 PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1199405809 From liach at openjdk.org Fri May 19 21:27:48 2023 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 May 2023 21:27:48 GMT Subject: RFR: 8307652: sealed class hierarchy graph doesn't distinguish non-sealed classes In-Reply-To: <7tWiHfGzhyY86-itKV0poJnO80RrNdIvU8bxgoNnbwI=.e52d5164-9f17-4e37-a75c-75bb21a2d565@github.com> References: <7tWiHfGzhyY86-itKV0poJnO80RrNdIvU8bxgoNnbwI=.e52d5164-9f17-4e37-a75c-75bb21a2d565@github.com> Message-ID: On Fri, 12 May 2023 22:07:12 GMT, Jonathan Gibbons wrote: >> `@sealedGraph` had a mechanism to render non-sealed classes differently, but it's useless because the graph nodes are not bordered. This patch converts the non-sealed classes to be rendered in italics instead. >> >> An example of `ConstantDesc`, which has a sealed hierarchy except `DynamicConstantDesc`: >> JDK 20: >> ![image](https://user-images.githubusercontent.com/7806504/236991678-e30c181a-cb1f-407a-b3e0-f648fe2df788.png) >> >> This patch: >> ![image](https://github.com/openjdk/jdk/assets/7806504/4fb8ec10-4f10-4902-8b9d-107b3644b2cf) > > @minborg You should comment on this one. > > I'm not sure that italics by itself is a good idea. @jonathan-gibbons Can you take a look again at the revised version? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13877#issuecomment-1555269626 From jiangli at openjdk.org Fri May 19 21:50:49 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 19 May 2023 21:50:49 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries In-Reply-To: References: Message-ID: On Fri, 19 May 2023 21:20:19 GMT, Erik Joelsson wrote: > I ran this patch in our internal build and test system and got failures on macos and windows. Thanks a lot, @erikj79! I was going to ask your help for testing the patch. > I think I know the cause for the mac failure, but the Windows failure I don't know. It looks like the same error I saw before after the original patch went in. > > ``` > [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): error C2220: the following warning is treated as an error > [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data > [2023-05-19T20:51:31,466Z] lib/CompileJvm.gmk:152: recipe for target '/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj' failed > [2023-05-19T20:51:31,466Z] make[3]: *** [/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj] Error 1 > ``` The warning error looks the same as https://bugs.openjdk.org/browse/JDK-8307858?focusedCommentId=14581027&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14581027. Sorry I didn't look closely earlier. I just took a look of https://github.com/openjdk/jdk/blob/939344b8433b32166f42ad73ae3d96e84b033478/src/hotspot/share/compiler/disassembler.cpp#L792: #ifdef STATIC_BUILD char* p = strrchr(buf, '/'); *p = '\0'; strcat(p, "/lib/"); lib_offset = jvm_offset = strlen(buf); #else The code is only enabled for the static build, which is why the issue doesn't show up in regular JDK build. `strlen` return value is `size_t`. I'll work on a fix. Could you please help fix the mac failure as you have already looked into it. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1555290450 From erikj at openjdk.org Fri May 19 22:47:52 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 19 May 2023 22:47:52 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries In-Reply-To: References: Message-ID: On Fri, 19 May 2023 21:13:24 GMT, Erik Joelsson wrote: >> Original description for JDK-8307194 change: >> ----- >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: >> >> - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a >> >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk >> >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS >> ----- >> >> Updates to address build failures reported on macosx- platforms: >> >> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. >> >> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`. >> >> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly. > > make/common/NativeCompilation.gmk line 1208: > >> 1206: $$(call ExecuteWithLog, $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_partial_link, \ >> 1207: $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE) \ >> 1208: $$($1_LD_OBJ_ARG)) > > This command line is missing `$$($1_SYSROOT_LDFLAGS)` which is causing it to fail in our builds with: > > ld: library not found for -lSystem This is the mac failure, sorry if that wasn't clear. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1199482710 From bpb at openjdk.org Fri May 19 23:50:53 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 19 May 2023 23:50:53 GMT Subject: RFR: JDK-8306983: Do not invoke external programs when switch terminal to raw mode on selected platforms [v3] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 14:17:56 GMT, Jan Lahoda wrote: >> To support JShell and other usecases, the JDK uses JLine, which provides line-editing functionality inside a terminal. >> >> JLine has several ways to work with the terminal, based on various additional libraries and tools. Most of them are not directly usable inside the JDK, so currently, on non-Windows platforms, the JLine inside the JDK will use external programs, like `stty`, to inspect the terminal's properties and to switch the terminal to raw mode. >> >> This is slightly problematic, as the external programs might be missing, and while this is not that big problem for JShell, it might be a problem for other potential uses of JLine, like using it inside `System.console()`. >> >> So, the proposal here is to call the corresponding native methods directly, on selected platforms for now (Linux and Mac OS/X), instead of invoking the external programs. On Windows, this has always been the case, we are using a custom implementation of the interface that maps native and Java function for JNA there, and the proposal is to do the same here. We take the appropriate mapping interface for JNA, and provide hand-written implementation for it, using JNI. >> >> The Windows implementation is mostly unchanged, the changes are mostly non-Windows only. The overview of the changes is: >> - `LastErrorException` is moved from the Windows-specific code to the platform-neutral code, as it is used by all the native implementations. This is the only change that directly affects the Windows-specific code >> - `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java` and `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java` are created based on the corresponding files from JLine. In JLine, these files directly call platform-specific implementations, but in this patch, the platform specific code is commented out, and replaced with calls to `JDKNativePty`, which is a new platform-specific class, that delegates to the actual platform-specific implementations. Note the `JnaNativePty.java` and `JnaTerminalProvider.java` already exist in the Windows part, but have different pieces of code commented out, which makes them substantially different. >> - for Linux and Mac OS/X, there are platform-specific implementations based on the corresponding code from JLine, with the hand-written JNI-based implementation of the JNA-based existing interfaces. They also have an implementation of `JDKNativePty`, which just delegates to the given platform's `"Nati... > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review feedback. C++ looks fine. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13687#pullrequestreview-1435272595 From duke at openjdk.org Mon May 22 07:12:03 2023 From: duke at openjdk.org (JoKern65) Date: Mon, 22 May 2023 07:12:03 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> <_iLBokObnsgDeHfGIDZ2BmAg7xx6LkpGnLH6GhN_xPo=.a836570a-0fae-4af3-a09a-a8466694de06@github.com> Message-ID: On Thu, 18 May 2023 15:20:22 GMT, Kim Barrett wrote: >> Use >> >> struct shmid_ds shm_buf{}; >> >> to _value-initialize_. Calls the default constructor if there is one. Otherwise, performs _zero-initialization_, >> which is what we want here. > > The final suggested change (to direct-value-initialize the object) seems to have *not* been made. > > However, I think it doesn't matter. The mentioned restriction against being non-empty until C23 is not relevant. > This is C++, not C. Empty initializers are, and have always been, permitted by C++. Strange the last resulting change I see is `struct shmid_ds shm_buf{};` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1200056697 From pminborg at openjdk.org Mon May 22 07:24:54 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 22 May 2023 07:24:54 GMT Subject: RFR: 8307652: sealed class hierarchy graph doesn't distinguish non-sealed classes [v2] In-Reply-To: References: Message-ID: On Tue, 16 May 2023 17:16:57 GMT, Chen Liang wrote: >> `@sealedGraph` had a mechanism to render non-sealed classes differently, but it's useless because the graph nodes are not bordered. This patch converts the non-sealed classes to be rendered in italics instead. >> >> An example of `ConstantDesc`, which has a sealed hierarchy except `DynamicConstantDesc`: >> JDK 20: >> ![image](https://user-images.githubusercontent.com/7806504/236991678-e30c181a-cb1f-407a-b3e0-f648fe2df788.png) >> >> This patch: >> ![image](https://github.com/openjdk/jdk/assets/7806504/4fb8ec10-4f10-4902-8b9d-107b3644b2cf) > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Use an edge and node to indicate non-sealed hierarchy > - Merge branch 'master' into fix/sealedgraph-nonsealed > - 8307652: sealed class hierarchy graph doesn't distinguish non-sealed classes Marked as reviewed by pminborg (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13877#pullrequestreview-1435944754 From dholmes at openjdk.org Mon May 22 07:50:50 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 22 May 2023 07:50:50 GMT Subject: RFR: 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal [v3] In-Reply-To: References: <1E6ZU_haLOvT9Br8S8ytnhw6CH3BZj2IaglTd17YYqA=.5bfa0dd8-88df-49be-a2e4-69e318dd3d84@github.com> Message-ID: On Fri, 19 May 2023 14:49:54 GMT, George Adams wrote: >> George Adams has updated the pull request incrementally with one additional commit since the last revision: >> >> typo fix > > This JEP has now been moved from "Proposed to target" to "Targeted" which means I think we can merge this now. @gdams please see my comment above re the wording. Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/13852#issuecomment-1556710566 From gdams at openjdk.org Mon May 22 08:28:47 2023 From: gdams at openjdk.org (George Adams) Date: Mon, 22 May 2023 08:28:47 GMT Subject: RFR: 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal [v4] In-Reply-To: References: Message-ID: > Deprecate the Windows x86-32 port, with the intent to remove it in a future release. George Adams has updated the pull request incrementally with two additional commits since the last revision: - fixup - update wording from review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13852/files - new: https://git.openjdk.org/jdk/pull/13852/files/8c090a71..a79fa92e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13852&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13852&range=02-03 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13852.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13852/head:pull/13852 PR: https://git.openjdk.org/jdk/pull/13852 From gdams at openjdk.org Mon May 22 08:28:49 2023 From: gdams at openjdk.org (George Adams) Date: Mon, 22 May 2023 08:28:49 GMT Subject: RFR: 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal [v3] In-Reply-To: References: <1E6ZU_haLOvT9Br8S8ytnhw6CH3BZj2IaglTd17YYqA=.5bfa0dd8-88df-49be-a2e4-69e318dd3d84@github.com> Message-ID: On Fri, 19 May 2023 14:49:54 GMT, George Adams wrote: >> George Adams has updated the pull request incrementally with one additional commit since the last revision: >> >> typo fix > > This JEP has now been moved from "Proposed to target" to "Targeted" which means I think we can merge this now. > @gdams please see my comment above re the wording. Thanks @dholmes-ora updated PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/13852#issuecomment-1556763799 From gdams at openjdk.org Mon May 22 08:51:13 2023 From: gdams at openjdk.org (George Adams) Date: Mon, 22 May 2023 08:51:13 GMT Subject: RFR: 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal [v5] In-Reply-To: References: Message-ID: > Deprecate the Windows x86-32 port, with the intent to remove it in a future release. George Adams 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 six additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into jep449 - fixup - update wording from review - typo fix - fix wording - 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13852/files - new: https://git.openjdk.org/jdk/pull/13852/files/a79fa92e..29c960a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13852&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13852&range=03-04 Stats: 126189 lines in 2220 files changed: 95119 ins; 15372 del; 15698 mod Patch: https://git.openjdk.org/jdk/pull/13852.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13852/head:pull/13852 PR: https://git.openjdk.org/jdk/pull/13852 From asotona at openjdk.org Mon May 22 10:09:52 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 22 May 2023 10:09:52 GMT Subject: RFR: 8308093: Disable language preview features use in JDK Message-ID: This patch disables temporary use of language preview features in JDK. Temporary enabled language preview features (to allow Pattern Matching for switch use in the Classfile API library) are no more necessary. All redundant use of --enable-preview in the Classfile API tests are also removed. Please review. Thanks, Adam ------------- Commit messages: - 8308093: Disable language preview features use in JDK Changes: https://git.openjdk.org/jdk/pull/14076/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14076&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308093 Stats: 24 lines in 12 files changed: 0 ins; 22 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14076.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14076/head:pull/14076 PR: https://git.openjdk.org/jdk/pull/14076 From jlahoda at openjdk.org Mon May 22 10:42:59 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 22 May 2023 10:42:59 GMT Subject: Integrated: JDK-8306983: Do not invoke external programs when switch terminal to raw mode on selected platforms In-Reply-To: References: Message-ID: <4Le44LFGRnDuEc3h-oLJ8VXi2ET31F080YKx96zYeD4=.8e0c4545-616a-4074-8688-335c62313456@github.com> On Thu, 27 Apr 2023 11:21:04 GMT, Jan Lahoda wrote: > To support JShell and other usecases, the JDK uses JLine, which provides line-editing functionality inside a terminal. > > JLine has several ways to work with the terminal, based on various additional libraries and tools. Most of them are not directly usable inside the JDK, so currently, on non-Windows platforms, the JLine inside the JDK will use external programs, like `stty`, to inspect the terminal's properties and to switch the terminal to raw mode. > > This is slightly problematic, as the external programs might be missing, and while this is not that big problem for JShell, it might be a problem for other potential uses of JLine, like using it inside `System.console()`. > > So, the proposal here is to call the corresponding native methods directly, on selected platforms for now (Linux and Mac OS/X), instead of invoking the external programs. On Windows, this has always been the case, we are using a custom implementation of the interface that maps native and Java function for JNA there, and the proposal is to do the same here. We take the appropriate mapping interface for JNA, and provide hand-written implementation for it, using JNI. > > The Windows implementation is mostly unchanged, the changes are mostly non-Windows only. The overview of the changes is: > - `LastErrorException` is moved from the Windows-specific code to the platform-neutral code, as it is used by all the native implementations. This is the only change that directly affects the Windows-specific code > - `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java` and `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java` are created based on the corresponding files from JLine. In JLine, these files directly call platform-specific implementations, but in this patch, the platform specific code is commented out, and replaced with calls to `JDKNativePty`, which is a new platform-specific class, that delegates to the actual platform-specific implementations. Note the `JnaNativePty.java` and `JnaTerminalProvider.java` already exist in the Windows part, but have different pieces of code commented out, which makes them substantially different. > - for Linux and Mac OS/X, there are platform-specific implementations based on the corresponding code from JLine, with the hand-written JNI-based implementation of the JNA-based existing interfaces. They also have an implementation of `JDKNativePty`, which just delegates to the given platform's `"NativePty"` imple... This pull request has now been integrated. Changeset: a9705196 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/a9705196cea7d6f468b76b1cfff561352ee0b6b2 Stats: 2145 lines in 23 files changed: 2097 ins; 40 del; 8 mod 8306983: Do not invoke external programs when switch terminal to raw mode on selected platforms Co-authored-by: Adam Sotona Reviewed-by: erikj, vromero, bpb ------------- PR: https://git.openjdk.org/jdk/pull/13687 From liach at openjdk.org Mon May 22 11:52:50 2023 From: liach at openjdk.org (Chen Liang) Date: Mon, 22 May 2023 11:52:50 GMT Subject: RFR: 8308093: Disable language preview features use in JDK In-Reply-To: References: Message-ID: On Mon, 22 May 2023 10:01:55 GMT, Adam Sotona wrote: > This patch disables temporary use of language preview features in JDK. > Temporary enabled language preview features (to allow Pattern Matching for switch use in the Classfile API library) are no more necessary. > All redundant use of --enable-preview in the Classfile API tests are also removed. > > Please review. > > Thanks, > Adam The enable-preview for jmh benchmark compilation exists before Classfile API integration, so this should be it. ------------- Marked as reviewed by liach (Author). PR Review: https://git.openjdk.org/jdk/pull/14076#pullrequestreview-1436460682 From erikj at openjdk.org Mon May 22 12:52:52 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 22 May 2023 12:52:52 GMT Subject: RFR: 8308093: Disable language preview features use in JDK In-Reply-To: References: Message-ID: On Mon, 22 May 2023 10:01:55 GMT, Adam Sotona wrote: > This patch disables temporary use of language preview features in JDK. > Temporary enabled language preview features (to allow Pattern Matching for switch use in the Classfile API library) are no more necessary. > All redundant use of --enable-preview in the Classfile API tests are also removed. > > Please review. > > Thanks, > Adam Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14076#pullrequestreview-1436562362 From alanb at openjdk.org Mon May 22 13:01:49 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 22 May 2023 13:01:49 GMT Subject: RFR: 8308093: Disable language preview features use in JDK In-Reply-To: References: Message-ID: On Mon, 22 May 2023 10:01:55 GMT, Adam Sotona wrote: > This patch disables temporary use of language preview features in JDK. > Temporary enabled language preview features (to allow Pattern Matching for switch use in the Classfile API library) are no more necessary. > All redundant use of --enable-preview in the Classfile API tests are also removed. > > Please review. > > Thanks, > Adam Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14076#pullrequestreview-1436580302 From gdams at openjdk.org Mon May 22 15:48:03 2023 From: gdams at openjdk.org (George Adams) Date: Mon, 22 May 2023 15:48:03 GMT Subject: Integrated: 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal In-Reply-To: References: Message-ID: On Sat, 6 May 2023 09:39:17 GMT, George Adams wrote: > Deprecate the Windows x86-32 port, with the intent to remove it in a future release. This pull request has now been integrated. Changeset: 29b8d3d9 Author: George Adams Committer: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/29b8d3d9e73c3771f18b8d4d69e32475f17346fa Stats: 22 lines in 3 files changed: 22 ins; 0 del; 0 mod 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/13852 From darcy at openjdk.org Mon May 22 16:28:52 2023 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 22 May 2023 16:28:52 GMT Subject: RFR: 8308093: Disable language preview features use in JDK In-Reply-To: References: Message-ID: <6W0aexRp4fpOKLKKklkPohKXNP6yGQEVHOAKaHotvPQ=.64d8fc08-4c59-4186-b031-b66b215710d6@github.com> On Mon, 22 May 2023 10:01:55 GMT, Adam Sotona wrote: > This patch disables temporary use of language preview features in JDK. > Temporary enabled language preview features (to allow Pattern Matching for switch use in the Classfile API library) are no more necessary. > All redundant use of --enable-preview in the Classfile API tests are also removed. > > Please review. > > Thanks, > Adam Marked as reviewed by darcy (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14076#pullrequestreview-1437004246 From azvegint at openjdk.org Mon May 22 18:17:27 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 22 May 2023 18:17:27 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v4] In-Reply-To: References: Message-ID: > Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. > This comes with some difficulties, and one of them is the inability to get screenshots from the system. > This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) > > But this functionality is a very important part of automated testing. > > > At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): > > 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) > It has several drawbacks though: > + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). > + There is no way to disable the visual "screen flash" after screenshot > + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. > Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. > But we still can consider this option as a fallback. > > > > 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) > It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. > This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. > > + implementation is more complicated comparing to Screenshot API > + no intermediate file, screenshot data can be obtained from memory > + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) > > > So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. > > This change also introduces some new behavior for the robot: > A system window now appears asking for confirmation from the user to capture the screen. > + The user can refuse the screen capture completely. In this case a security exception will be thrown. > + The user can allow a screen capture for all screens o... Alexander Zvegintsev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - enable by default for Wayland - Merge branch 'master' into X11_compatibility_screencast - refactoring to remove resetScreenCapturePermission - update, based on review comments - remove wayland detection - BUILD_LIBPIPEWIRE_HEADER_DIRS -> LIBPIPEWIRE_HEADER_DIRS - replace tabs with spaces - main changes - add pipewire header files ------------- Changes: https://git.openjdk.org/jdk/pull/13803/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=03 Stats: 14701 lines in 106 files changed: 14663 ins; 18 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/13803.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13803/head:pull/13803 PR: https://git.openjdk.org/jdk/pull/13803 From jiangli at openjdk.org Mon May 22 19:14:00 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 22 May 2023 19:14:00 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries In-Reply-To: References: Message-ID: On Fri, 19 May 2023 22:45:16 GMT, Erik Joelsson wrote: >> make/common/NativeCompilation.gmk line 1208: >> >>> 1206: $$(call ExecuteWithLog, $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_partial_link, \ >>> 1207: $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE) \ >>> 1208: $$($1_LD_OBJ_ARG)) >> >> This command line is missing `$$($1_SYSROOT_LDFLAGS)` which is causing it to fail in our builds with: >> >> ld: library not found for -lSystem > > This is the mac failure, sorry if that wasn't clear. Thanks @erikj79. Could you please help provide some more info on the build failure: Which macOs version ran into the build issue? My mac is on Ventura 13.3.1 (a). It builds successfully for the `static-libs-image` target. Does it fail when partially linking `libjvm_relocatable.o` only, or it fails when partially linking other native libraries as well on macosx? Could you please share the partial linking command, e.g. hotspot/variant-server/libjvm/gtest/objs/static/BUILD_GTEST_LIBJVM_partial_link.cmdline? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1200929473 From jiangli at openjdk.org Mon May 22 19:24:52 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 22 May 2023 19:24:52 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries In-Reply-To: References: Message-ID: On Mon, 22 May 2023 19:10:57 GMT, Jiangli Zhou wrote: > Thanks @erikj79. Could you please help provide some more info on the build failure: > > Which macOs version ran into the build issue? My mac is on Ventura 13.3.1 (a). It builds successfully for the `static-libs-image` target. > > Does it fail when partially linking `libjvm_relocatable.o` only, or it fails when partially linking other native libraries as well on macosx? Could you please share the partial linking command, e.g. hotspot/variant-server/libjvm/gtest/objs/static/BUILD_GTEST_LIBJVM_partial_link.cmdline? Additional info, following is the partial linking command from my `macosx-x86_64` build: /usr/bin/g++ -m64 -r -o /.../github/JDK-8307858/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/gtest/objs/static/libjvm_relocatable.o @/.../github/JDK-8307858/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/gtest/objs/static/_BUILD_GTEST_LIBJVM_objectfilenames.txt ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1200946838 From jiangli at openjdk.org Mon May 22 19:40:00 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 22 May 2023 19:40:00 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v2] In-Reply-To: References: Message-ID: <0i3aaM1W1-QFR0Ezx6aNWgMlJpO6ODoK2sdt-nbjcW4=.c47621ea-521c-44ee-a469-8b7a87bcb097@github.com> > Original description for JDK-8307194 change: > ----- > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: > > - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target > > - For libjvm.a specifically, exclude operator_new.o > > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols > - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled > - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a > > - Handle long arguments case for static build in make/common/NativeCompilation.gmk > > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > ----- > > Updates to address build failures reported on macosx- platforms: > > - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. > > The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`. > > The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly. Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge branch 'master' into JDK-8307858 - Merge branch 'master' into JDK-8307858 - Clean up. - In clude $MACHINE_FLAG in partial linking flag. - Use '-m32' instead of '-m elf_i386'. - Use '-m elf_i386' for partial linking with gcc for linux 32-bit platform. It's based on the post on https://www.linuxquestions.org/questions/linux-software-2/relocatable-linking-on-x86-64-for-i386-872812/. - Only do partial linking step with gcc/clang on 64-bit platform. There is a linking failure with linux-x86 build: /usr/bin/ld: relocatable linking with relocations from format elf32-i386 (/home/runner/work/jdk/jdk/build/linux-x86/hotspot/variant-server/libjvm/libgtest/objs/gmock-all.o) to format elf64-x86-64 (/home/runner/work/jdk/jdk/build/linux-x86/hotspot/variant-server/libjvm/libgtest/objs/libgtest_relocatable.o) is not supported - Need to set $1_AR_OBJ_ARG to $$($1_LD_OBJ_ARG) instead of $1_LD_OBJ_ARG. - Merge branch 'master' into JDK-8307858 - Revert src/java.desktop/linux/native/libjsound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c change. - ... and 2 more: https://git.openjdk.org/jdk/compare/8474e693...fb945210 ------------- Changes: https://git.openjdk.org/jdk/pull/14064/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=01 Stats: 201 lines in 10 files changed: 150 ins; 34 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/14064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14064/head:pull/14064 PR: https://git.openjdk.org/jdk/pull/14064 From erikj at openjdk.org Mon May 22 19:47:51 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 22 May 2023 19:47:51 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v2] In-Reply-To: References: Message-ID: On Mon, 22 May 2023 19:21:52 GMT, Jiangli Zhou wrote: >> Thanks @erikj79. Could you please help provide some more info on the build failure: >> >> Which macOs version ran into the build issue? My mac is on Ventura 13.3.1 (a). It builds successfully for the `static-libs-image` target. >> >> Does it fail when partially linking `libjvm_relocatable.o` only, or it fails when partially linking other native libraries as well on macosx? Could you please share the partial linking command, e.g. hotspot/variant-server/libjvm/gtest/objs/static/BUILD_GTEST_LIBJVM_partial_link.cmdline? > >> Thanks @erikj79. Could you please help provide some more info on the build failure: >> >> Which macOs version ran into the build issue? My mac is on Ventura 13.3.1 (a). It builds successfully for the `static-libs-image` target. >> >> Does it fail when partially linking `libjvm_relocatable.o` only, or it fails when partially linking other native libraries as well on macosx? Could you please share the partial linking command, e.g. hotspot/variant-server/libjvm/gtest/objs/static/BUILD_GTEST_LIBJVM_partial_link.cmdline? > > Additional info, following is the partial linking command from my `macosx-x86_64` build: > > > /usr/bin/g++ -m64 -r -o /.../github/JDK-8307858/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/gtest/objs/static/libjvm_relocatable.o @/.../github/JDK-8307858/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/gtest/objs/static/_BUILD_GTEST_LIBJVM_objectfilenames.txt It fails because we are using a "devkit" and not an installed Xcode. The SYSROOT flags must always be added to any compiler or link command lines. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1200973154 From erikj at openjdk.org Mon May 22 19:57:59 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 22 May 2023 19:57:59 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v2] In-Reply-To: <0i3aaM1W1-QFR0Ezx6aNWgMlJpO6ODoK2sdt-nbjcW4=.c47621ea-521c-44ee-a469-8b7a87bcb097@github.com> References: <0i3aaM1W1-QFR0Ezx6aNWgMlJpO6ODoK2sdt-nbjcW4=.c47621ea-521c-44ee-a469-8b7a87bcb097@github.com> Message-ID: On Mon, 22 May 2023 19:40:00 GMT, Jiangli Zhou wrote: >> Original description for JDK-8307194 change: >> ----- >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: >> >> - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a >> >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk >> >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS >> ----- >> >> Updates to address build failures reported on macosx- platforms: >> >> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. >> >> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`. >> >> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly. > > Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Merge branch 'master' into JDK-8307858 > - Merge branch 'master' into JDK-8307858 > - Clean up. > - In clude $MACHINE_FLAG in partial linking flag. > - Use '-m32' instead of '-m elf_i386'. > - Use '-m elf_i386' for partial linking with gcc for linux 32-bit platform. > > It's based on the post on https://www.linuxquestions.org/questions/linux-software-2/relocatable-linking-on-x86-64-for-i386-872812/. > - Only do partial linking step with gcc/clang on 64-bit platform. > > There is a linking failure with linux-x86 build: > > /usr/bin/ld: relocatable linking with relocations from format elf32-i386 (/home/runner/work/jdk/jdk/build/linux-x86/hotspot/variant-server/libjvm/libgtest/objs/gmock-all.o) to format elf64-x86-64 (/home/runner/work/jdk/jdk/build/linux-x86/hotspot/variant-server/libjvm/libgtest/objs/libgtest_relocatable.o) is not supported > - Need to set $1_AR_OBJ_ARG to $$($1_LD_OBJ_ARG) instead of $1_LD_OBJ_ARG. > - Merge branch 'master' into JDK-8307858 > - Revert src/java.desktop/linux/native/libjsound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c change. > - ... and 2 more: https://git.openjdk.org/jdk/compare/8474e693...fb945210 make/common/NativeCompilation.gmk line 1175: > 1173: > 1174: ifeq ($$($1_TYPE), STATIC_LIBRARY) > 1175: $1_VARDEPS := $$($1_AR) $$(ARFLAGS) $$($1_ARFLAGS) $$($1_LIBS) \ We also need to add some things to VARDEPS. Looks like at least `$$($1_LD)` and `$$($1_SYSROOT_LDFLAGS)` are needed. Maybe conditionally. make/common/NativeCompilation.gmk line 1208: > 1206: $$(call ExecuteWithLog, $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_partial_link, \ > 1207: $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE) \ > 1208: $$($1_LD_OBJ_ARG)) This makes my build pass. Suggestion: $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $$($1_SYSROOT_LDFLAGS) \ $(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE) \ $$($1_LD_OBJ_ARG)) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1200980626 PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1200982365 From jiangli at openjdk.org Mon May 22 20:57:43 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 22 May 2023 20:57:43 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v3] In-Reply-To: References: Message-ID: > Original description for JDK-8307194 change: > ----- > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: > > - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target > > - For libjvm.a specifically, exclude operator_new.o > > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols > - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled > - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a > > - Handle long arguments case for static build in make/common/NativeCompilation.gmk > > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > ----- > > Updates to address build failures reported on macosx- platforms: > > - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. > > The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`. > > The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly. Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Update make/common/NativeCompilation.gmk Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14064/files - new: https://git.openjdk.org/jdk/pull/14064/files/fb945210..6a321bd1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14064/head:pull/14064 PR: https://git.openjdk.org/jdk/pull/14064 From jiangli at openjdk.org Mon May 22 20:57:47 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 22 May 2023 20:57:47 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v2] In-Reply-To: References: <0i3aaM1W1-QFR0Ezx6aNWgMlJpO6ODoK2sdt-nbjcW4=.c47621ea-521c-44ee-a469-8b7a87bcb097@github.com> Message-ID: On Mon, 22 May 2023 19:54:59 GMT, Erik Joelsson wrote: >> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Merge branch 'master' into JDK-8307858 >> - Merge branch 'master' into JDK-8307858 >> - Clean up. >> - In clude $MACHINE_FLAG in partial linking flag. >> - Use '-m32' instead of '-m elf_i386'. >> - Use '-m elf_i386' for partial linking with gcc for linux 32-bit platform. >> >> It's based on the post on https://www.linuxquestions.org/questions/linux-software-2/relocatable-linking-on-x86-64-for-i386-872812/. >> - Only do partial linking step with gcc/clang on 64-bit platform. >> >> There is a linking failure with linux-x86 build: >> >> /usr/bin/ld: relocatable linking with relocations from format elf32-i386 (/home/runner/work/jdk/jdk/build/linux-x86/hotspot/variant-server/libjvm/libgtest/objs/gmock-all.o) to format elf64-x86-64 (/home/runner/work/jdk/jdk/build/linux-x86/hotspot/variant-server/libjvm/libgtest/objs/libgtest_relocatable.o) is not supported >> - Need to set $1_AR_OBJ_ARG to $$($1_LD_OBJ_ARG) instead of $1_LD_OBJ_ARG. >> - Merge branch 'master' into JDK-8307858 >> - Revert src/java.desktop/linux/native/libjsound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c change. >> - ... and 2 more: https://git.openjdk.org/jdk/compare/8474e693...fb945210 > > make/common/NativeCompilation.gmk line 1208: > >> 1206: $$(call ExecuteWithLog, $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_partial_link, \ >> 1207: $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE) \ >> 1208: $$($1_LD_OBJ_ARG)) > > This makes my build pass. > Suggestion: > > $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $$($1_SYSROOT_LDFLAGS) \ > $(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE) \ > $$($1_LD_OBJ_ARG)) Thanks! Tested with a macosx-x86_64 build and also with our prototype on JDK 11 for linux-x64. They still build okay with the change. Looks like it affects/needed for cross build. Committing your fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1201077691 From jiangli at openjdk.org Mon May 22 21:27:58 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 22 May 2023 21:27:58 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v4] In-Reply-To: References: Message-ID: > Original description for JDK-8307194 change: > ----- > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: > > - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target > > - For libjvm.a specifically, exclude operator_new.o > > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols > - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled > - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a > > - Handle long arguments case for static build in make/common/NativeCompilation.gmk > > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > ----- > > Updates to address build failures reported on macosx- platforms: > > - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. > > The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`. > > The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly. Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) is gcc or clang, as suggested by @erikj79. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14064/files - new: https://git.openjdk.org/jdk/pull/14064/files/6a321bd1..695bda5e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=02-03 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14064/head:pull/14064 PR: https://git.openjdk.org/jdk/pull/14064 From jiangli at openjdk.org Mon May 22 21:28:04 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 22 May 2023 21:28:04 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v2] In-Reply-To: References: <0i3aaM1W1-QFR0Ezx6aNWgMlJpO6ODoK2sdt-nbjcW4=.c47621ea-521c-44ee-a469-8b7a87bcb097@github.com> Message-ID: On Mon, 22 May 2023 19:52:42 GMT, Erik Joelsson wrote: >> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Merge branch 'master' into JDK-8307858 >> - Merge branch 'master' into JDK-8307858 >> - Clean up. >> - In clude $MACHINE_FLAG in partial linking flag. >> - Use '-m32' instead of '-m elf_i386'. >> - Use '-m elf_i386' for partial linking with gcc for linux 32-bit platform. >> >> It's based on the post on https://www.linuxquestions.org/questions/linux-software-2/relocatable-linking-on-x86-64-for-i386-872812/. >> - Only do partial linking step with gcc/clang on 64-bit platform. >> >> There is a linking failure with linux-x86 build: >> >> /usr/bin/ld: relocatable linking with relocations from format elf32-i386 (/home/runner/work/jdk/jdk/build/linux-x86/hotspot/variant-server/libjvm/libgtest/objs/gmock-all.o) to format elf64-x86-64 (/home/runner/work/jdk/jdk/build/linux-x86/hotspot/variant-server/libjvm/libgtest/objs/libgtest_relocatable.o) is not supported >> - Need to set $1_AR_OBJ_ARG to $$($1_LD_OBJ_ARG) instead of $1_LD_OBJ_ARG. >> - Merge branch 'master' into JDK-8307858 >> - Revert src/java.desktop/linux/native/libjsound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c change. >> - ... and 2 more: https://git.openjdk.org/jdk/compare/8474e693...fb945210 > > make/common/NativeCompilation.gmk line 1175: > >> 1173: >> 1174: ifeq ($$($1_TYPE), STATIC_LIBRARY) >> 1175: $1_VARDEPS := $$($1_AR) $$(ARFLAGS) $$($1_ARFLAGS) $$($1_LIBS) \ > > We also need to add some things to VARDEPS. Looks like at least `$$($1_LD)` and `$$($1_SYSROOT_LDFLAGS)` are needed. Maybe conditionally. Fix, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1201128665 From azvegint at openjdk.org Mon May 22 22:34:17 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 22 May 2023 22:34:17 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v5] In-Reply-To: References: Message-ID: > Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. > This comes with some difficulties, and one of them is the inability to get screenshots from the system. > This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) > > But this functionality is a very important part of automated testing. > > > At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): > > 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) > It has several drawbacks though: > + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). > + There is no way to disable the visual "screen flash" after screenshot > + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. > Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. > But we still can consider this option as a fallback. > > > > 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) > It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. > This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. > > + implementation is more complicated comparing to Screenshot API > + no intermediate file, screenshot data can be obtained from memory > + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) > > > So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. > > This change also introduces some new behavior for the robot: > A system window now appears asking for confirmation from the user to capture the screen. > + The user can refuse the screen capture completely. In this case a security exception will be thrown. > + The user can allow a screen capture for all screens o... Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: Call loadGtk when awt.robot.gtk set to false ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13803/files - new: https://git.openjdk.org/jdk/pull/13803/files/716e3201..53de29bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=03-04 Stats: 30 lines in 1 file changed: 29 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13803.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13803/head:pull/13803 PR: https://git.openjdk.org/jdk/pull/13803 From dholmes at openjdk.org Tue May 23 02:48:10 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 23 May 2023 02:48:10 GMT Subject: RFR: 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal [v5] In-Reply-To: References: Message-ID: <18I9GAp8pelfTEPVqtaW2Ijimt1wHeROC2veSJf4IS4=.34c3a498-e267-47f2-9cf3-303de1695e43@github.com> On Mon, 22 May 2023 08:51:13 GMT, George Adams wrote: >> Deprecate the Windows x86-32 port, with the intent to remove it in a future release. > > George Adams 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 six additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into jep449 > - fixup > - update wording from review > - typo fix > - fix wording > - 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal Thanks for the update ------------- PR Review: https://git.openjdk.org/jdk/pull/13852#pullrequestreview-1438204051 From asotona at openjdk.org Tue May 23 07:27:05 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 23 May 2023 07:27:05 GMT Subject: Integrated: 8308093: Disable language preview features use in JDK In-Reply-To: References: Message-ID: <_GLlDTboTGCGkynUb5U62e-q8NksFwl0fSGfsBAQzl0=.5f1ef796-ec46-440a-9228-073fc3c2c471@github.com> On Mon, 22 May 2023 10:01:55 GMT, Adam Sotona wrote: > This patch disables temporary use of language preview features in JDK. > Temporary enabled language preview features (to allow Pattern Matching for switch use in the Classfile API library) are no more necessary. > All redundant use of --enable-preview in the Classfile API tests are also removed. > > Please review. > > Thanks, > Adam This pull request has now been integrated. Changeset: c4408278 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/c4408278d1012746c91ba4c31068538850c68d30 Stats: 24 lines in 12 files changed: 0 ins; 22 del; 2 mod 8308093: Disable language preview features use in JDK Reviewed-by: liach, erikj, alanb, darcy ------------- PR: https://git.openjdk.org/jdk/pull/14076 From azvegint at openjdk.org Tue May 23 15:15:29 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 23 May 2023 15:15:29 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v6] In-Reply-To: References: Message-ID: <3QEJBac8UZLkHTYjJKcCSyMleMK8iV1Dvlzwo9NXvwM=.e132b4cb-fb07-4503-bc9b-59129c9e360b@github.com> > Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. > This comes with some difficulties, and one of them is the inability to get screenshots from the system. > This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) > > But this functionality is a very important part of automated testing. > > > At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): > > 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) > It has several drawbacks though: > + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). > + There is no way to disable the visual "screen flash" after screenshot > + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. > Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. > But we still can consider this option as a fallback. > > > > 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) > It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. > This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. > > + implementation is more complicated comparing to Screenshot API > + no intermediate file, screenshot data can be obtained from memory > + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) > > > So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. > > This change also introduces some new behavior for the robot: > A system window now appears asking for confirmation from the user to capture the screen. > + The user can refuse the screen capture completely. In this case a security exception will be thrown. > + The user can allow a screen capture for all screens o... Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: awt.robot.screenshotMethod -> awt.robot.screenshotMethod, awt.robot.screencastDebug -> awt.robot.screenshotDebug ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13803/files - new: https://git.openjdk.org/jdk/pull/13803/files/53de29bf..c077dc7a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=04-05 Stats: 16 lines in 2 files changed: 5 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/13803.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13803/head:pull/13803 PR: https://git.openjdk.org/jdk/pull/13803 From azvegint at openjdk.org Tue May 23 15:16:08 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 23 May 2023 15:16:08 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v5] In-Reply-To: References: Message-ID: On Mon, 22 May 2023 22:34:17 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > Call loadGtk when awt.robot.gtk set to false The system properties have been renamed: `awt.robot.screenshotMethod` -> `awt.robot.screenshotMethod` `awt.robot.screencastDebug` -> `awt.robot.screenshotDebug` `awt.robot.screenshotMethod` - `dbusScreencast` defaults to Wayland session, `x11` defaults to X11 session, and to all other values except `dbusScreencast`. Note
  1. setting this to `x11` in a Wayland session means screen capture will always fail, as it does in earlier JDKs
  2. setting this to `dbusScreencast` in an X.org session should work but is only recommended for JDK debugging purposes
  3. The already existing `awt.robot.gtk` option is only valid for `x11` and has no effect for `dbusScreencast`.
`awt.robot.screenshotDebug` - `false` by default, if `true` prints debug information related if any available. This may be needed for a smoother experience when we later want to get a screenshot via [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-Screenshot.Screenshot). (it requires Gnome 43+, Ubuntu 22.04 LTS has 42.5). So we can add `dbusScreenshot` option for the `awt.robot.screenshotMethod` later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1559507625 From egahlin at openjdk.org Tue May 23 17:00:36 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 23 May 2023 17:00:36 GMT Subject: RFR: 8306703: JFR: Summary views Message-ID: Could I have a review of an enhancement that adds a view command to jfr. Testing: tier1, tier2 + jdk/jdk/jfr For the change to work properly when streaming, fix of JDK-8306703 needs to be applied. To simplify the review, changes not relevant to the feature, but that can use classes in jdk.jfr.internal.util package, will be refactored after this change has been integrated. Possibly in JDK 22. Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/14104/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14104&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306703 Stats: 7516 lines in 65 files changed: 7441 ins; 5 del; 70 mod Patch: https://git.openjdk.org/jdk/pull/14104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14104/head:pull/14104 PR: https://git.openjdk.org/jdk/pull/14104 From alanb at openjdk.org Tue May 23 18:05:21 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 23 May 2023 18:05:21 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v16] In-Reply-To: References: Message-ID: On Thu, 18 May 2023 19:06:28 GMT, Jim Laskey wrote: >> Add flexible main methods and anonymous main classes to the Java language. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Give subclass priority src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 129: > 127: * @throws NoSuchMethodException when not preview and no method found > 128: */ > 129: public static Method findMainMethod(Class mainClass) throws NoSuchMethodException { The latest iteration of changes removes the warning but the latest iteration of the JEP proposes a warning when an instance main or static no-args main is preferred over an inherited static main. Is it that the JEP is just running ahead a bit and the changes in the PR will catch up soon? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1202796707 From jlaskey at openjdk.org Tue May 23 18:12:09 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 23 May 2023 18:12:09 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v16] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 18:02:16 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Give subclass priority > > src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 129: > >> 127: * @throws NoSuchMethodException when not preview and no method found >> 128: */ >> 129: public static Method findMainMethod(Class mainClass) throws NoSuchMethodException { > > The latest iteration of changes removes the warning but the latest iteration of the JEP proposes a warning when an instance main or static no-args main is preferred over an inherited static main. Is it that the JEP is just running ahead a bit and the changes in the PR will catch up soon? Yes. There is some juggling going on to get the code to align with the requirement and the interpretation thereof. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1202804732 From jlaskey at openjdk.org Tue May 23 20:04:45 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 23 May 2023 20:04:45 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v17] In-Reply-To: References: Message-ID: > Add flexible main methods and anonymous main classes to the Java language. Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: - Fix missing constructor error messages and handle inner class launching - Merge branch 'master' into 8306112 - Issue warning if traditional main not used. - Give subclass priority - Merge branch 'master' into 8306112 - Requested Changes #2 - Update VirtualParser.java - Merge branch 'master' into 8306112 - Refactor source code launcher - Typo - ... and 23 more: https://git.openjdk.org/jdk/compare/bddf4838...b55f82f8 ------------- Changes: https://git.openjdk.org/jdk/pull/13689/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=16 Stats: 1235 lines in 28 files changed: 1071 ins; 32 del; 132 mod Patch: https://git.openjdk.org/jdk/pull/13689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689 PR: https://git.openjdk.org/jdk/pull/13689 From darcy at openjdk.org Tue May 23 20:36:11 2023 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 23 May 2023 20:36:11 GMT Subject: RFR: JDK-8306584: Start of release updates for JDK 22 Message-ID: Time to get JDK 22 underway... ------------- Commit messages: - Merge branch 'master' into JDK-8306584 - Merge branch 'master' into JDK-8306584 - Minor test fixes. - Merge branch 'master' into JDK-8306584 - Update symbol files to JDK 21 b23. - Merge branch 'JDK-8306584' of https://github.com/jddarcy/jdk into JDK-8306584 - Add symbol files. - Merge branch 'master' into JDK-8306584 - Problem list failing langtools test. - Merge branch 'master' into JDK-8306584 - ... and 9 more: https://git.openjdk.org/jdk/compare/8474e693...6047c2cb Changes: https://git.openjdk.org/jdk/pull/13567/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13567&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306584 Stats: 5650 lines in 69 files changed: 5596 ins; 0 del; 54 mod Patch: https://git.openjdk.org/jdk/pull/13567.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13567/head:pull/13567 PR: https://git.openjdk.org/jdk/pull/13567 From darcy at openjdk.org Tue May 23 20:36:12 2023 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 23 May 2023 20:36:12 GMT Subject: RFR: JDK-8306584: Start of release updates for JDK 22 In-Reply-To: References: Message-ID: On Thu, 20 Apr 2023 20:28:18 GMT, Joe Darcy wrote: > Time to get JDK 22 underway... Typical start-of-JDK-next changes. As usual, the bulk of the PR is the symbol file information to support "javac --release 21". ------------- PR Comment: https://git.openjdk.org/jdk/pull/13567#issuecomment-1560085911 From erikj at openjdk.org Tue May 23 20:41:58 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 23 May 2023 20:41:58 GMT Subject: RFR: JDK-8306584: Start of release updates for JDK 22 In-Reply-To: References: Message-ID: On Thu, 20 Apr 2023 20:28:18 GMT, Joe Darcy wrote: > Time to get JDK 22 underway... Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13567#pullrequestreview-1440532444 From jjg at openjdk.org Tue May 23 20:42:00 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 23 May 2023 20:42:00 GMT Subject: RFR: JDK-8306584: Start of release updates for JDK 22 In-Reply-To: References: Message-ID: On Thu, 20 Apr 2023 20:28:18 GMT, Joe Darcy wrote: > Time to get JDK 22 underway... test/langtools/tools/javac/versions/Versions.java line 26: > 24: /* > 25: * @test > 26: * @bug 4981566 5028634 5094412 6304984 7025786 7025789 8001112 8028545 8000961 8030610 8028546 8188870 8173382 8173382 8193290 8205619 8028563 8245147 8245586 8257453 8286035 8306586 At some point, this line should be wrapped test/langtools/tools/javac/versions/Versions.java line 93: > 91: TWENTY(false, "64.0", "20", Versions::checksrc20), > 92: TWENTY_ONE(false,"65.0", "21", Versions::checksrc20), > 93: TWENTY_TWO(false,"66.0", "22", Versions::checksrc20); when do these get updated? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1202974585 PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1202976605 From darcy at openjdk.org Tue May 23 20:52:57 2023 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 23 May 2023 20:52:57 GMT Subject: RFR: JDK-8306584: Start of release updates for JDK 22 In-Reply-To: References: Message-ID: On Tue, 23 May 2023 20:38:34 GMT, Jonathan Gibbons wrote: >> Time to get JDK 22 underway... > > test/langtools/tools/javac/versions/Versions.java line 93: > >> 91: TWENTY(false, "64.0", "20", Versions::checksrc20), >> 92: TWENTY_ONE(false,"65.0", "21", Versions::checksrc20), >> 93: TWENTY_TWO(false,"66.0", "22", Versions::checksrc20); > > when do these get updated? Ah, when new non-preview language structures are added. With two new language features in JDK 21, looks like it is time for me to add another one; thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1202991806 From iris at openjdk.org Tue May 23 21:20:57 2023 From: iris at openjdk.org (Iris Clark) Date: Tue, 23 May 2023 21:20:57 GMT Subject: RFR: JDK-8306584: Start of release updates for JDK 22 In-Reply-To: References: Message-ID: On Thu, 20 Apr 2023 20:28:18 GMT, Joe Darcy wrote: > Time to get JDK 22 underway... Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13567#pullrequestreview-1440582657 From liangchenblue at gmail.com Wed May 24 00:21:48 2023 From: liangchenblue at gmail.com (-) Date: Tue, 23 May 2023 19:21:48 -0500 Subject: RFR: 8307652: sealed class hierarchy graph doesn't distinguish non-sealed classes [v2] In-Reply-To: References: Message-ID: Hi, Jonathan Gibbons, would you mind taking a look at this and approve if this looks good? I wish to get this into JDK 21 before RDP 1 starts. On Mon, May 22, 2023 at 2:25?AM Per Minborg wrote: > > On Tue, 16 May 2023 17:16:57 GMT, Chen Liang wrote: > > >> `@sealedGraph` had a mechanism to render non-sealed classes differently, but it's useless because the graph nodes are not bordered. This patch converts the non-sealed classes to be rendered in italics instead. > >> > >> An example of `ConstantDesc`, which has a sealed hierarchy except `DynamicConstantDesc`: > >> JDK 20: > >> ![image](https://user-images.githubusercontent.com/7806504/236991678-e30c181a-cb1f-407a-b3e0-f648fe2df788.png) > >> > >> This patch: > >> ![image](https://github.com/openjdk/jdk/assets/7806504/4fb8ec10-4f10-4902-8b9d-107b3644b2cf) > > > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > > > - Use an edge and node to indicate non-sealed hierarchy > > - Merge branch 'master' into fix/sealedgraph-nonsealed > > - 8307652: sealed class hierarchy graph doesn't distinguish non-sealed classes > > Marked as reviewed by pminborg (Committer). > > ------------- > > PR Review: https://git.openjdk.org/jdk/pull/13877#pullrequestreview-1435944754 From kbarrett at openjdk.org Wed May 24 03:16:04 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 24 May 2023 03:16:04 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> <_iLBokObnsgDeHfGIDZ2BmAg7xx6LkpGnLH6GhN_xPo=.a836570a-0fae-4af3-a09a-a8466694de06@github.com> Message-ID: On Mon, 22 May 2023 07:09:30 GMT, JoKern65 wrote: >> The final suggested change (to direct-value-initialize the object) seems to have *not* been made. >> >> However, I think it doesn't matter. The mentioned restriction against being non-empty until C23 is not relevant. >> This is C++, not C. Empty initializers are, and have always been, permitted by C++. > > Strange the last resulting change I see is > `struct shmid_ds shm_buf{};` That's not what I see in this PR, and not what I see in the repository after the integration. Where are you seeing that? (If in your local repository, maybe you forgot a push to the PR?) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1203353066 From duke at openjdk.org Wed May 24 08:04:12 2023 From: duke at openjdk.org (Naoki Kishida) Date: Wed, 24 May 2023 08:04:12 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v17] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 20:04:45 GMT, Jim Laskey wrote: >> Add flexible main methods and anonymous main classes to the Java language. > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: > > - Fix missing constructor error messages and handle inner class launching > - Merge branch 'master' into 8306112 > - Issue warning if traditional main not used. > - Give subclass priority > - Merge branch 'master' into 8306112 > - Requested Changes #2 > - Update VirtualParser.java > - Merge branch 'master' into 8306112 > - Refactor source code launcher > - Typo > - ... and 23 more: https://git.openjdk.org/jdk/compare/bddf4838...b55f82f8 Can we use enum? public class Main{ enum Foo {A, B} void main() { System.out.println(Foo.A); } } ? OK enum Foo {A, B} void main() { System.out.println(Foo.A); } ?error(enumtest.java is the filename) enumtest.java:1: Error : package enumtest does not exist enum Foo {A, B} ^ ------------- PR Comment: https://git.openjdk.org/jdk/pull/13689#issuecomment-1560631740 From jlaskey at openjdk.org Wed May 24 12:00:11 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 24 May 2023 12:00:11 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v17] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 20:04:45 GMT, Jim Laskey wrote: >> Add flexible main methods and anonymous main classes to the Java language. > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: > > - Fix missing constructor error messages and handle inner class launching > - Merge branch 'master' into 8306112 > - Issue warning if traditional main not used. > - Give subclass priority > - Merge branch 'master' into 8306112 > - Requested Changes #2 > - Update VirtualParser.java > - Merge branch 'master' into 8306112 > - Refactor source code launcher > - Typo > - ... and 23 more: https://git.openjdk.org/jdk/compare/bddf4838...b55f82f8 Good catch - will look into it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13689#issuecomment-1560984490 From egahlin at openjdk.org Wed May 24 13:46:59 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 24 May 2023 13:46:59 GMT Subject: RFR: 8306703: JFR: Summary views [v2] In-Reply-To: References: Message-ID: > Could I have a review of an enhancement that adds a view command to jfr. > > Testing: tier1, tier2 + jdk/jdk/jfr > > For the change to work properly when streaming, fix of 8307738 needs to be applied. > > To simplify the review, changes not relevant to the feature, but that can use classes in jdk.jfr.internal.util package, will be refactored after this change has been integrated. Possibly in JDK 22. > > Thanks > Erik Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision: - Update comments and remove resetCache() duplicate - Update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14104/files - new: https://git.openjdk.org/jdk/pull/14104/files/94b2b839..c9796619 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14104&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14104&range=00-01 Stats: 234 lines in 16 files changed: 168 ins; 19 del; 47 mod Patch: https://git.openjdk.org/jdk/pull/14104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14104/head:pull/14104 PR: https://git.openjdk.org/jdk/pull/14104 From jlaskey at openjdk.org Wed May 24 14:12:24 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 24 May 2023 14:12:24 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v18] In-Reply-To: References: Message-ID: <7v5CJ2-10s6fliOBRJw5y_QyZL-TNkBsi56E5vokdG8=.c0ffcd0c-6b8d-41f5-8b20-44e3270cdb9a@github.com> > Add flexible main methods and anonymous main classes to the Java language. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Allow unqualified access to unnamed class (internally visible) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13689/files - new: https://git.openjdk.org/jdk/pull/13689/files/b55f82f8..e590c736 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=16-17 Stats: 35 lines in 2 files changed: 34 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689 PR: https://git.openjdk.org/jdk/pull/13689 From jiangli at openjdk.org Wed May 24 15:01:01 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 24 May 2023 15:01:01 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v4] In-Reply-To: References: Message-ID: On Fri, 19 May 2023 21:20:19 GMT, Erik Joelsson wrote: >> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: >> >> - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) is gcc or clang, as suggested by @erikj79. > > I ran this patch in our internal build and test system and got failures on macos and windows. I think I know the cause for the mac failure, but the Windows failure I don't know. It looks like the same error I saw before after the original patch went in. > > > [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): error C2220: the following warning is treated as an error > [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data > [2023-05-19T20:51:31,466Z] lib/CompileJvm.gmk:152: recipe for target '/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj' failed > [2023-05-19T20:51:31,466Z] make[3]: *** [/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj] Error 1 Hi @erikj79 Please let me know if you have any additional comments for the PR. Could you please also help run through testing for the latest version? Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1561320098 From jlaskey at openjdk.org Wed May 24 15:42:28 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 24 May 2023 15:42:28 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v19] In-Reply-To: References: Message-ID: > Add flexible main methods and anonymous main classes to the Java language. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Ignore SKIPs (semicolon class declarations) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13689/files - new: https://git.openjdk.org/jdk/pull/13689/files/e590c736..8ccb9502 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=17-18 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689 PR: https://git.openjdk.org/jdk/pull/13689 From aturbanov at openjdk.org Wed May 24 17:37:12 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 24 May 2023 17:37:12 GMT Subject: RFR: 8306703: JFR: Summary views [v2] In-Reply-To: References: Message-ID: On Wed, 24 May 2023 13:46:59 GMT, Erik Gahlin wrote: >> Could I have a review of an enhancement that adds a view command to jfr. >> >> Testing: tier1, tier2 + jdk/jdk/jfr >> >> For the change to work properly when streaming, fix of 8307738 needs to be applied. >> >> To simplify the review, changes not relevant to the feature, but that can use classes in jdk.jfr.internal.util package, will be refactored after this change has been integrated. Possibly in JDK 22. >> >> Thanks >> Erik > > Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision: > > - Update comments and remove resetCache() duplicate > - Update src/jdk.jfr/share/classes/jdk/jfr/internal/query/FieldFormatter.java line 94: > 92: } > 93: if (object instanceof RecordedClass clazz) { > 94: String text = ValueFormatter.formatClass(clazz); Suggestion: String text = ValueFormatter.formatClass(clazz); src/jdk.jfr/share/classes/jdk/jfr/internal/query/Function.java line 38: > 36: abstract class Function { > 37: > 38: abstract public void add(Object value); let's use blessed modifiers order Suggestion: public abstract void add(Object value); src/jdk.jfr/share/classes/jdk/jfr/internal/query/QueryParser.java line 230: > 228: private String text() throws ParseException { > 229: if (tokenizer.peekChar() != '\'') { > 230: throw new ParseException("Expected text to start with a single quote character", position()); Suggestion: throw new ParseException("Expected text to start with a single quote character", position()); src/jdk.jfr/share/classes/jdk/jfr/internal/query/QueryParser.java line 270: > 268: private Property property() throws ParseException { > 269: String text = tokenizer.next(); > 270: Consumer style = switch (text.toLowerCase()) { Suggestion: Consumer style = switch (text.toLowerCase()) { src/jdk.jfr/share/classes/jdk/jfr/internal/query/QueryParser.java line 333: > 331: > 332: @Override > 333: public void close() throws ParseException { Suggestion: public void close() throws ParseException { src/jdk.jfr/share/classes/jdk/jfr/internal/query/QueryPrinter.java line 167: > 165: out.println(); > 166: for (ValueDescriptor f : type.getFields()) { > 167: String typeName = Utils.makeSimpleName(f.getTypeName()); Suggestion: String typeName = Utils.makeSimpleName(f.getTypeName()); src/jdk.jfr/share/classes/jdk/jfr/internal/util/ValueFormatter.java line 62: > 60: if (roundedDuration.equals(Duration.ZERO)) { > 61: return "0 s"; > 62: } else if(roundedDuration.isNegative()){ Suggestion: } else if (roundedDuration.isNegative()){ src/jdk.jfr/share/classes/jdk/jfr/internal/util/ValueFormatter.java line 73: > 71: // 0.000001 ms - 0.000999 ms > 72: double outputMs = (double) d.toNanosPart() / 1_000_000; > 73: return String.format("%.6f ms", outputMs); Suggestion: return String.format("%.6f ms", outputMs); src/jdk.jfr/share/classes/jdk/jfr/internal/util/ValueFormatter.java line 79: > 77: int outputDigit = NANO_SIGNIFICANT_FIGURES - valueLength; > 78: double outputMs = (double) d.toNanosPart() / 1_000_000; > 79: return String.format("%." + outputDigit + "f ms", outputMs); Suggestion: return String.format("%." + outputDigit + "f ms", outputMs); src/jdk.jfr/share/classes/jdk/jfr/internal/util/ValueFormatter.java line 85: > 83: int outputDigit = MILL_SIGNIFICANT_FIGURES - valueLength; > 84: double outputSecond = d.toSecondsPart() + (double) d.toMillisPart() / 1_000; > 85: return String.format("%." + outputDigit + "f s", outputSecond); Suggestion: return String.format("%." + outputDigit + "f s", outputSecond); src/jdk.jfr/share/classes/jdk/jfr/internal/util/ValueFormatter.java line 88: > 86: } else if (d.compareTo(HOUR) < 0) { > 87: // 1 m 0 s - 59 m 59 s > 88: return String.format("%d m %d s", d.toMinutesPart(), d.toSecondsPart()); Suggestion: return String.format("%d m %d s", d.toMinutesPart(), d.toSecondsPart()); src/jdk.jfr/share/classes/jdk/jfr/internal/util/ValueFormatter.java line 91: > 89: } else if (d.compareTo(DAY) < 0) { > 90: // 1 h 0 m - 23 h 59 m > 91: return String.format("%d h %d m", d.toHoursPart(), d.toMinutesPart()); Suggestion: return String.format("%d h %d m", d.toHoursPart(), d.toMinutesPart()); src/jdk.jfr/share/classes/jdk/jfr/internal/util/ValueFormatter.java line 94: > 92: } else { > 93: // 1 d 0 h - > 94: return String.format("%d d %d h", d.toDaysPart(), d.toHoursPart()); Suggestion: return String.format("%d d %d h", d.toDaysPart(), d.toHoursPart()); src/jdk.jfr/share/classes/jdk/jfr/internal/util/ValueFormatter.java line 105: > 103: if (d.equals(Duration.ZERO)) { > 104: return d; > 105: } else if(d.isNegative()){ Suggestion: } else if (d.isNegative()){ test/jdk/jdk/jfr/tool/TestView.java line 59: > 57: output.shouldContain("could not open file "); > 58: > 59: Path file = Utils.createTempFile("faked-file", ".jfr"); Suggestion: Path file = Utils.createTempFile("faked-file", ".jfr"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14104#discussion_r1204551894 PR Review Comment: https://git.openjdk.org/jdk/pull/14104#discussion_r1204552796 PR Review Comment: https://git.openjdk.org/jdk/pull/14104#discussion_r1204548720 PR Review Comment: https://git.openjdk.org/jdk/pull/14104#discussion_r1204548978 PR Review Comment: https://git.openjdk.org/jdk/pull/14104#discussion_r1204549215 PR Review Comment: https://git.openjdk.org/jdk/pull/14104#discussion_r1204552179 PR Review Comment: https://git.openjdk.org/jdk/pull/14104#discussion_r1204549570 PR Review Comment: https://git.openjdk.org/jdk/pull/14104#discussion_r1204549775 PR Review Comment: https://git.openjdk.org/jdk/pull/14104#discussion_r1204550437 PR Review Comment: https://git.openjdk.org/jdk/pull/14104#discussion_r1204550910 PR Review Comment: https://git.openjdk.org/jdk/pull/14104#discussion_r1204551139 PR Review Comment: https://git.openjdk.org/jdk/pull/14104#discussion_r1204551400 PR Review Comment: https://git.openjdk.org/jdk/pull/14104#discussion_r1204551505 PR Review Comment: https://git.openjdk.org/jdk/pull/14104#discussion_r1204551639 PR Review Comment: https://git.openjdk.org/jdk/pull/14104#discussion_r1204546888 From erikj at openjdk.org Wed May 24 19:16:58 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 24 May 2023 19:16:58 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v4] In-Reply-To: References: Message-ID: <4DLj_HAFFpv2ZhVaat71afM_xf3BPQ9sRW0FQOcRfr4=.8aac858e-55a9-4ed1-b397-ef84e73af2cc@github.com> On Fri, 19 May 2023 21:20:19 GMT, Erik Joelsson wrote: >> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: >> >> - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) is gcc or clang, as suggested by @erikj79. > > I ran this patch in our internal build and test system and got failures on macos and windows. I think I know the cause for the mac failure, but the Windows failure I don't know. It looks like the same error I saw before after the original patch went in. > > > [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): error C2220: the following warning is treated as an error > [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data > [2023-05-19T20:51:31,466Z] lib/CompileJvm.gmk:152: recipe for target '/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj' failed > [2023-05-19T20:51:31,466Z] make[3]: *** [/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj] Error 1 > Hi @erikj79 Please let me know if you have any additional comments for the PR. Could you please also help run through testing for the latest version? Thanks I'm running a full set of builds now, but in my initial local build on mac, I see a lot of warnings like this: .../Xcode/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/lib/libc++.tbd, ignoring unexpected dylib text stub file Any idea what that could be caused by or if it's possible to eliminate? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1561798109 From erikj at openjdk.org Wed May 24 20:31:57 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 24 May 2023 20:31:57 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v4] In-Reply-To: References: Message-ID: On Mon, 22 May 2023 21:27:58 GMT, Jiangli Zhou wrote: >> Original description for JDK-8307194 change: >> ----- >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: >> >> - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a >> >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk >> >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS >> ----- >> >> Updates to address build failures reported on macosx- platforms: >> >> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. >> >> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`. >> >> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) is gcc or clang, as suggested by @erikj79. My build job is still running, but it has failed in two distinct ways already. See below for mac fix. Our cross build of arm32 fails with this message: [2023-05-24T19:25:15,310Z] /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: fatal error: cannot mix -r with dynamic object /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libstdc++.so make/common/NativeCompilation.gmk line 1210: > 1208: ifneq ($(findstring $(TOOLCHAIN_TYPE), gcc clang), ) > 1209: $$(call ExecuteWithLog, $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_partial_link, \ > 1210: $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $$($1_SYSROOT_LDFLAGS) \ Mac builds failed in our distributed system. I believe this will fix it: Suggestion: $(if $$($1_LINK_OBJS_RELATIVE), $$(CD) $$(OUTPUTDIR) ; ) \ $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $$($1_SYSROOT_LDFLAGS) \ It also looks like the indentation in this block is off, 3 spaces instead of 4. ------------- PR Review: https://git.openjdk.org/jdk/pull/14064#pullrequestreview-1442698087 PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1204726154 From jjg at openjdk.org Wed May 24 20:45:58 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 24 May 2023 20:45:58 GMT Subject: RFR: 8307652: sealed class hierarchy graph doesn't distinguish non-sealed classes [v2] In-Reply-To: References: Message-ID: On Tue, 16 May 2023 17:16:57 GMT, Chen Liang wrote: >> `@sealedGraph` had a mechanism to render non-sealed classes differently, but it's useless because the graph nodes are not bordered. This patch converts the non-sealed classes to be rendered in italics instead. >> >> An example of `ConstantDesc`, which has a sealed hierarchy except `DynamicConstantDesc`: >> JDK 20: >> ![image](https://user-images.githubusercontent.com/7806504/236991678-e30c181a-cb1f-407a-b3e0-f648fe2df788.png) >> >> This patch: >> ![image](https://github.com/openjdk/jdk/assets/7806504/4fb8ec10-4f10-4902-8b9d-107b3644b2cf) > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Use an edge and node to indicate non-sealed hierarchy > - Merge branch 'master' into fix/sealedgraph-nonsealed > - 8307652: sealed class hierarchy graph doesn't distinguish non-sealed classes Generally, a good feature and a nice solution. I endorse @minborg's approval. Given this is in a build-time taglet for JDK documentation, the use of `` is acceptable and a reasonably good solution. If this were to ever become a standard javadoc feature, we would maybe have to figure out how to localize the string, but that is not necessary here. ------------- Marked as reviewed by jjg (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13877#pullrequestreview-1442720465 PR Comment: https://git.openjdk.org/jdk/pull/13877#issuecomment-1561898654 From jiangli at openjdk.org Wed May 24 21:02:00 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 24 May 2023 21:02:00 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v5] In-Reply-To: References: Message-ID: > Original description for JDK-8307194 change: > ----- > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: > > - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target > > - For libjvm.a specifically, exclude operator_new.o > > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols > - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled > - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a > > - Handle long arguments case for static build in make/common/NativeCompilation.gmk > > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > ----- > > Updates to address build failures reported on macosx- platforms: > > - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. > > The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`. > > The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly. Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Update make/common/NativeCompilation.gmk Thanks you! Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14064/files - new: https://git.openjdk.org/jdk/pull/14064/files/695bda5e..93366e38 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=03-04 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14064/head:pull/14064 PR: https://git.openjdk.org/jdk/pull/14064 From erikj at openjdk.org Wed May 24 21:02:01 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 24 May 2023 21:02:01 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v4] In-Reply-To: References: Message-ID: On Wed, 24 May 2023 20:29:09 GMT, Erik Joelsson wrote: > My build job is still running, but it has failed in two distinct ways already. See below for mac fix. Our cross build of arm32 fails with this message: > > ``` > [2023-05-24T19:25:15,310Z] /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: fatal error: cannot mix -r with dynamic object /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libstdc++.so > ``` If this is a problem with your partial link solution, then perhaps just employing the relative path trick for the `ar` command line on mac could be enough to handle long paths and lots of object files? That appears to be how we handle it with clang for linking already due to @-file problems. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1561910764 From jiangli at openjdk.org Wed May 24 21:02:01 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 24 May 2023 21:02:01 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v4] In-Reply-To: References: Message-ID: On Wed, 24 May 2023 20:52:38 GMT, Erik Joelsson wrote: >> My build job is still running, but it has failed in two distinct ways already. See below for mac fix. Our cross build of arm32 fails with this message: >> >> >> [2023-05-24T19:25:15,310Z] /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: fatal error: cannot mix -r with dynamic object /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libstdc++.so > >> My build job is still running, but it has failed in two distinct ways already. See below for mac fix. Our cross build of arm32 fails with this message: >> >> ``` >> [2023-05-24T19:25:15,310Z] /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: fatal error: cannot mix -r with dynamic object /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libstdc++.so >> ``` > > If this is a problem with your partial link solution, then perhaps just employing the relative path trick for the `ar` command line on mac could be enough to handle long paths and lots of object files? That appears to be how we handle it with clang for linking already due to @-file problems. > > Hi @erikj79 Please let me know if you have any additional comments for the PR. Could you please also help run through testing for the latest version? Thanks > > I'm running a full set of builds now, but in my initial local build on mac, I see a lot of warnings like this: > > ``` > .../Xcode/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/lib/libc++.tbd, ignoring unexpected dylib text stub file > ``` > > Any idea what that could be caused by or if it's possible to eliminate? I observed the same warnings on my macosx-x86_64 local build. It's from the partial linking step. Not much information yielded when I searched for `ignoring unexpected dylib text stub file`. Search found https://opensource.apple.com/source/ld64/ld64-609/src/ld/InputFiles.cpp with the linker code throwing the warning (`dylibsNotAllowed` is true if `_options.outputKind` is `Options::kObjectFile`, which is related to what we are observing). I tried linking a `javastatic` executable using the static libraries created with partial linking on macosx-x86_64 last week. I was able to execute `javastatic` in my quick test but didn't go further for more verification, as the runtime didn't work with the static build yet. Haven't found any information on how to suppress the warning either. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1561913004 From liach at openjdk.org Wed May 24 21:07:06 2023 From: liach at openjdk.org (Chen Liang) Date: Wed, 24 May 2023 21:07:06 GMT Subject: Integrated: 8307652: sealed class hierarchy graph doesn't distinguish non-sealed classes In-Reply-To: References: Message-ID: On Tue, 9 May 2023 04:11:03 GMT, Chen Liang wrote: > `@sealedGraph` had a mechanism to render non-sealed classes differently, but it's useless because the graph nodes are not bordered. This patch converts the non-sealed classes to be rendered in italics instead. > > An example of `ConstantDesc`, which has a sealed hierarchy except `DynamicConstantDesc`: > JDK 20: > ![image](https://user-images.githubusercontent.com/7806504/236991678-e30c181a-cb1f-407a-b3e0-f648fe2df788.png) > > This patch: > ![image](https://github.com/openjdk/jdk/assets/7806504/4fb8ec10-4f10-4902-8b9d-107b3644b2cf) This pull request has now been integrated. Changeset: 1451ac17 Author: Chen Liang Committer: Jonathan Gibbons URL: https://git.openjdk.org/jdk/commit/1451ac1770aa1fde0a96e475dfe9a92bc76b4eb9 Stats: 59 lines in 1 file changed: 44 ins; 6 del; 9 mod 8307652: sealed class hierarchy graph doesn't distinguish non-sealed classes Reviewed-by: pminborg, jjg ------------- PR: https://git.openjdk.org/jdk/pull/13877 From jiangli at openjdk.org Wed May 24 21:50:55 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 24 May 2023 21:50:55 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v4] In-Reply-To: References: Message-ID: On Wed, 24 May 2023 20:52:38 GMT, Erik Joelsson wrote: > > My build job is still running, but it has failed in two distinct ways already. See below for mac fix. Our cross build of arm32 fails with this message: > > ``` > > [2023-05-24T19:25:15,310Z] /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: fatal error: cannot mix -r with dynamic object /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libstdc++.so > > ``` > > If this is a problem with your partial link solution, then perhaps just employing the relative path trick for the `ar` command line on mac could be enough to handle long paths and lots of object files? That appears to be how we handle it with clang for linking already due to @-file problems. The partial linking was originally suggested by C++/Clang toolchain folks to mitigate linker overhead that was observed during final executable link time. For a static library containing any object file (`.o`) that was compiled with ThinLTO (https://clang.llvm.org/docs/ThinLTO.html) enabled, linking an executable using the static library without distributed ThinLTO could experience more overhead and slow down linking. Solving the macosx `ar` limitation is a side-effect/benefit of using partial linking. We probably would want to include the partial linking even without the `ar` limitation. Is it possible `$$($1_SYSROOT_LDFLAGS)` pulled in `libstdc++.so` as part of the input for partial linking with the linux-aarch64 cross build? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1561969001 From jiangli at openjdk.org Thu May 25 01:22:02 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 25 May 2023 01:22:02 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v4] In-Reply-To: References: Message-ID: On Wed, 24 May 2023 21:47:49 GMT, Jiangli Zhou wrote: > > > My build job is still running, but it has failed in two distinct ways already. See below for mac fix. Our cross build of arm32 fails with this message: > > > ``` > > > [2023-05-24T19:25:15,310Z] /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: fatal error: cannot mix -r with dynamic object /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libstdc++.so > > > ``` > > > > > > If this is a problem with your partial link solution, then perhaps just employing the relative path trick for the `ar` command line on mac could be enough to handle long paths and lots of object files? That appears to be how we handle it with clang for linking already due to @-file problems. > > The partial linking was originally suggested by C++/Clang toolchain folks to mitigate linker overhead that was observed during final executable link time. For a static library containing any object file (`.o`) that was compiled with ThinLTO (https://clang.llvm.org/docs/ThinLTO.html) enabled, linking an executable using the static library without distributed ThinLTO could experience more overhead and slow down linking. Solving the macosx `ar` limitation is a side-effect/benefit of using partial linking. We probably would want to include the partial linking even without the `ar` limitation. > > Is it possible `$$($1_SYSROOT_LDFLAGS)` pulled in `libstdc++.so` as part of the input for partial linking with the linux-aarch64 cross build? Another possibility might be the user provided `BUILD_LDCXX` includes extra options in the testing build (?). If that's the case, we probably could define a separate `BUILD_LD_PARTIAL` with no added options. In our prototype on JDK 11, we define a separate one for partial linking. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1562128417 From dholmes at openjdk.org Thu May 25 05:10:21 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 25 May 2023 05:10:21 GMT Subject: RFR: 8308341: JNI_GetCreatedJavaVMs returns a partially initialized JVM Message-ID: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> We now track the in-progress and completed states of VM creation and only return a VM from JNI_GetCreatedJavaVMs when there is a fully initialized VM. Testing: - new regression test - tiers 1-3 (sanity) Thanks ------------- Commit messages: - Added regression test - 8308341: JNI_GetCreatedJavaVMs returns a partially initialized JVM Changes: https://git.openjdk.org/jdk/pull/14139/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14139&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308341 Stats: 179 lines in 4 files changed: 164 ins; 2 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/14139.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14139/head:pull/14139 PR: https://git.openjdk.org/jdk/pull/14139 From duke at openjdk.org Thu May 25 07:20:09 2023 From: duke at openjdk.org (JoKern65) Date: Thu, 25 May 2023 07:20:09 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> <_iLBokObnsgDeHfGIDZ2BmAg7xx6LkpGnLH6GhN_xPo=.a836570a-0fae-4af3-a09a-a8466694de06@github.com> Message-ID: On Wed, 24 May 2023 03:13:34 GMT, Kim Barrett wrote: >> Strange the last resulting change I see is >> `struct shmid_ds shm_buf{};` > > That's not what I see in this PR, and not what I see in the repository after the integration. Where are you seeing > that? (If in your local repository, maybe you forgot a push to the PR?) I checked it directly in repository [https://github.com/openjdk/jdk/blob/master/src/hotspot/os/aix/os_aix.cpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/os/aix/os_aix.cpp) And there I see the desired `struct shmid_ds shm_buf{};` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1205094231 From kbarrett at openjdk.org Thu May 25 09:13:13 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 25 May 2023 09:13:13 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> <_iLBokObnsgDeHfGIDZ2BmAg7xx6LkpGnLH6GhN_xPo=.a836570a-0fae-4af3-a09a-a8466694de06@github.com> Message-ID: On Thu, 25 May 2023 07:16:29 GMT, JoKern65 wrote: >> That's not what I see in this PR, and not what I see in the repository after the integration. Where are you seeing >> that? (If in your local repository, maybe you forgot a push to the PR?) > > I checked it directly in repository > [https://github.com/openjdk/jdk/blob/master/src/hotspot/os/aix/os_aix.cpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/os/aix/os_aix.cpp) > And there I see the desired > `struct shmid_ds shm_buf{};` Weird! I see: https://github.com/openjdk/jdk/blob/master/src/hotspot/os/aix/os_aix.cpp#L467 (permalink:) `https://github.com/openjdk/jdk/blob/d87713440a1ddb830e87171b009efe9507e644cb/src/hotspot/os/aix/os_aix.cpp#L467` https://github.com/openjdk/jdk/blob/d87713440a1ddb830e87171b009efe9507e644cb/src/hotspot/os/aix/os_aix.cpp#L467 struct shmid_ds shm_buf = { }; (above line was cut-and-pasted) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1205226537 From duke at openjdk.org Thu May 25 09:28:22 2023 From: duke at openjdk.org (JoKern65) Date: Thu, 25 May 2023 09:28:22 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code Message-ID: When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". Some of those are in shared codebase and could be addressed by small adjustments. A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. ------------- Commit messages: - white space - JDK-8308288 Changes: https://git.openjdk.org/jdk/pull/14146/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14146&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308288 Stats: 52 lines in 11 files changed: 46 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/14146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14146/head:pull/14146 PR: https://git.openjdk.org/jdk/pull/14146 From jsjolen at openjdk.org Thu May 25 10:21:00 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 25 May 2023 10:21:00 GMT Subject: RFR: 8308341: JNI_GetCreatedJavaVMs returns a partially initialized JVM In-Reply-To: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> References: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> Message-ID: <2EoMWGrWIv78bhu7AotLiJdR5LVy2Y-5V_62cW7aDeo=.6a4c4703-5ceb-49dd-8208-213f758cd152@github.com> On Thu, 25 May 2023 05:02:19 GMT, David Holmes wrote: > We now track the in-progress and completed states of VM creation and only return a VM from JNI_GetCreatedJavaVMs when there is a fully initialized VM. > > Testing: > - new regression test > - tiers 1-3 (sanity) > > Thanks Hi, over all looks good, but I have some questions regarding the tests and I wonder whether you missed a case. src/hotspot/share/prims/jni.cpp line 3475: > 3473: > 3474: // Global invocation API vars > 3475: enum VM_Creation_State { Nit: Would `enum class` be preferred here? src/hotspot/share/prims/jni.cpp line 3943: > 3941: // initialization, so only bail-out if something seems very wrong. > 3942: // Though how would we get here in that case? > 3943: if (vm_created == NOT_CREATED) { Shouldn't we also handle `IN_PROGRESS`? test/hotspot/jtreg/runtime/jni/getCreatedJavaVMs/exeGetCreatedJavaVMs.c line 1: > 1: /* Can we make this test behave even worse than it already does and have you caused a crash with this test before applying your changes? If it has caused a crash, then I think we're OK with the current form of the test. Two ideas to make it more likely to crash: 1. Have more threads racing 2. Let's say you spawn more threads, is it possible for `printf` to prevent data races as it's MT-Safe? More threads would increase likelihood of contention on the implicit lock, leading to some threads having been significantly slowed down by having to perform a more expensive locking procedure, is my thought process. ------------- PR Review: https://git.openjdk.org/jdk/pull/14139#pullrequestreview-1443519793 PR Review Comment: https://git.openjdk.org/jdk/pull/14139#discussion_r1205276576 PR Review Comment: https://git.openjdk.org/jdk/pull/14139#discussion_r1205284282 PR Review Comment: https://git.openjdk.org/jdk/pull/14139#discussion_r1205305164 From aturbanov at openjdk.org Thu May 25 10:23:01 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 25 May 2023 10:23:01 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v6] In-Reply-To: <3QEJBac8UZLkHTYjJKcCSyMleMK8iV1Dvlzwo9NXvwM=.e132b4cb-fb07-4503-bc9b-59129c9e360b@github.com> References: <3QEJBac8UZLkHTYjJKcCSyMleMK8iV1Dvlzwo9NXvwM=.e132b4cb-fb07-4503-bc9b-59129c9e360b@github.com> Message-ID: <1MlRHUmykupjleuDLBKEmSlIlH3Aeat1zjN5013U5dE=.48688040-62f5-4d63-9c92-18708eff78c3@github.com> On Tue, 23 May 2023 15:15:29 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > awt.robot.screenshotMethod -> awt.robot.screenshotMethod, awt.robot.screencastDebug -> awt.robot.screenshotDebug src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java line 108: > 106: Rectangle captureArea = new Rectangle(x, y, width, height); > 107: > 108: List affectedScreenBounds = getSystemScreensBounds() nit Suggestion: List affectedScreenBounds = getSystemScreensBounds() ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1205310080 From egahlin at openjdk.org Thu May 25 10:34:45 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 25 May 2023 10:34:45 GMT Subject: RFR: 8306703: JFR: Summary views [v3] In-Reply-To: References: Message-ID: > Could I have a review of an enhancement that adds a view command to jfr. > > Testing: tier1, tier2 + jdk/jdk/jfr > > For the change to work properly when streaming, fix of 8307738 needs to be applied. > > To simplify the review, changes not relevant to the feature, but that can use classes in jdk.jfr.internal.util package, will be refactored after this change has been integrated. Possibly in JDK 22. > > Thanks > Erik Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: Updates ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14104/files - new: https://git.openjdk.org/jdk/pull/14104/files/c9796619..e4e4bba1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14104&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14104&range=01-02 Stats: 24 lines in 8 files changed: 2 ins; 0 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/14104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14104/head:pull/14104 PR: https://git.openjdk.org/jdk/pull/14104 From mgronlun at openjdk.org Thu May 25 12:24:57 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 25 May 2023 12:24:57 GMT Subject: RFR: 8306703: JFR: Summary views [v3] In-Reply-To: References: Message-ID: On Thu, 25 May 2023 10:34:45 GMT, Erik Gahlin wrote: >> Could I have a review of an enhancement that adds a view command to jfr. >> >> Testing: tier1, tier2 + jdk/jdk/jfr >> >> For the change to work properly when streaming, fix of 8307738 needs to be applied. >> >> To simplify the review, changes not relevant to the feature, but that can use classes in jdk.jfr.internal.util package, will be refactored after this change has been integrated. Possibly in JDK 22. >> >> Thanks >> Erik > > Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: > > Updates This is great work Erik! It is going to help folks better understand what is important, and the extension capabilities are numerous. Thank you very much! ------------- Marked as reviewed by mgronlun (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14104#pullrequestreview-1443769068 From egahlin at openjdk.org Thu May 25 12:54:01 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 25 May 2023 12:54:01 GMT Subject: RFR: 8306703: JFR: Summary views [v4] In-Reply-To: References: Message-ID: > Could I have a review of an enhancement that adds a view command to jfr. > > Testing: tier1, tier2 + jdk/jdk/jfr > > For the change to work properly when streaming, fix of 8307738 needs to be applied. > > To simplify the review, changes not relevant to the feature, but that can use classes in jdk.jfr.internal.util package, will be refactored after this change has been integrated. Possibly in JDK 22. > > Thanks > Erik Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: Minor fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14104/files - new: https://git.openjdk.org/jdk/pull/14104/files/e4e4bba1..98c71d22 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14104&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14104&range=02-03 Stats: 12 lines in 3 files changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/14104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14104/head:pull/14104 PR: https://git.openjdk.org/jdk/pull/14104 From egahlin at openjdk.org Thu May 25 12:56:58 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 25 May 2023 12:56:58 GMT Subject: RFR: 8306703: JFR: Summary views [v3] In-Reply-To: References: Message-ID: On Thu, 25 May 2023 12:22:30 GMT, Markus Gr?nlund wrote: > This is great work, Erik! It is going to help folks better focus to understand what is important and the extension capabilities are numerous. Thank you very much! Thanks for the review! It was a lot to go through. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14104#issuecomment-1562857403 From mbaesken at openjdk.org Thu May 25 12:57:55 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 25 May 2023 12:57:55 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code In-Reply-To: References: Message-ID: On Thu, 25 May 2023 09:14:14 GMT, JoKern65 wrote: > When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". > Some of those are in shared codebase and could be addressed by small adjustments. > A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. In the macro define checks, you both check macros _AIX and AIX, sometimes this, sometimes that. Might be possible to just use one of the two for consistency, but I am fine with using both as well, leave this up to you. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1562859320 From jlaskey at openjdk.org Thu May 25 14:32:44 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 25 May 2023 14:32:44 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v20] In-Reply-To: References: Message-ID: > Add flexible main methods and anonymous main classes to the Java language. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Improving error recovery in presence of less important syntactic errors in top-level methods and fields. Author: Jan Lahoda ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13689/files - new: https://git.openjdk.org/jdk/pull/13689/files/8ccb9502..cfac821a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=18-19 Stats: 32 lines in 4 files changed: 24 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/13689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689 PR: https://git.openjdk.org/jdk/pull/13689 From kbarrett at openjdk.org Thu May 25 15:23:58 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 25 May 2023 15:23:58 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code In-Reply-To: References: Message-ID: On Thu, 25 May 2023 09:14:14 GMT, JoKern65 wrote: > When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". > Some of those are in shared codebase and could be addressed by small adjustments. > A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. Sorry, but I can't review the warning suppressions. Without more information about exactly what warnings are being suppressed and where, I have no way to evaluate whether suppression is an appropriate response. It could be that some of the warnings are correctly pointing out (possibly serious) flaws that really need to be fixed. Continuing to hide them doesn't seem like a winning strategy to me. I also suggest avoiding omnibus changes like this when possible (which it is here). Just because it's all about removing warnings from a new toolchain doesn't make it a cohesive change. That makes it harder to review and to manage the review, because it is larger and affects a wide range of areas, so may need many reviewers. And the whole thing might get stalled by discussion of one piece. make/modules/java.desktop/lib/Awt2dLibraries.gmk line 706: > 704: # temporarily disable PNG_POWERPC_VSX_OPT which would be set, because > 705: # if defined(__PPC64__) && defined(__ALTIVEC__) && defined(__VSX__) > 706: # is true, the then needed libpng function .png_init_filter_functions_vsx s/then// src/hotspot/share/utilities/globalDefinitions_xlc.hpp line 47: > 45: #undef malloc > 46: extern void *malloc(size_t) asm("vec_malloc"); > 47: #endif Wow! And I don't mean that in a good way. I'm not questioning whether this is correct, just commenting on how crazy it seems that such a thing might be needed. test/jdk/java/io/File/libGetXSpace.c line 128: > 126: #else > 127: struct statfs buf; > 128: int result = statfs((char*)chars, &buf); Is this working around a bug in IBM's declaration? Also, pre-existing, the cast seems really suspicious. The type of `chars` is `jchar*`, which is a sequence of 16bit characters. Does this actually work? If so, how? ------------- PR Review: https://git.openjdk.org/jdk/pull/14146#pullrequestreview-1444057072 PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1205622153 PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1205655676 PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1205673657 From egahlin at openjdk.org Thu May 25 15:43:09 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 25 May 2023 15:43:09 GMT Subject: Integrated: 8306703: JFR: Summary views In-Reply-To: References: Message-ID: On Tue, 23 May 2023 16:37:17 GMT, Erik Gahlin wrote: > Could I have a review of an enhancement that adds a view command to jfr. > > Testing: tier1, tier2 + jdk/jdk/jfr > > For the change to work properly when streaming, fix of 8307738 needs to be applied. > > To simplify the review, changes not relevant to the feature, but that can use classes in jdk.jfr.internal.util package, will be refactored after this change has been integrated. Possibly in JDK 22. > > Thanks > Erik This pull request has now been integrated. Changeset: 98acce13 Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/98acce13d5f79dba3c29c87f30a0364b44cd3951 Stats: 7656 lines in 64 files changed: 7585 ins; 5 del; 66 mod 8306703: JFR: Summary views Reviewed-by: mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/14104 From duke at openjdk.org Thu May 25 16:16:57 2023 From: duke at openjdk.org (JoKern65) Date: Thu, 25 May 2023 16:16:57 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code In-Reply-To: References: Message-ID: On Thu, 25 May 2023 15:18:41 GMT, Kim Barrett wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Some of those are in shared codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > > test/jdk/java/io/File/libGetXSpace.c line 128: > >> 126: #else >> 127: struct statfs buf; >> 128: int result = statfs((char*)chars, &buf); > > Is this working around a bug in IBM's declaration? > > Also, pre-existing, the cast seems really suspicious. The type of `chars` is `jchar*`, which is a > sequence of 16bit characters. Does this actually work? If so, how? This is IBMs declaration of statfs `extern int statfs(char *, struct statfs *);` So the compiler will not accept a `const char*` Indeed I do not know if this ever worked, but my change makes it not worse. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1205745144 From azvegint at openjdk.org Thu May 25 16:29:39 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 25 May 2023 16:29:39 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v7] In-Reply-To: References: Message-ID: > Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. > This comes with some difficulties, and one of them is the inability to get screenshots from the system. > This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) > > But this functionality is a very important part of automated testing. > > > At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): > > 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) > It has several drawbacks though: > + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). > + There is no way to disable the visual "screen flash" after screenshot > + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. > Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. > But we still can consider this option as a fallback. > > > > 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) > It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. > This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. > > + implementation is more complicated comparing to Screenshot API > + no intermediate file, screenshot data can be obtained from memory > + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) > > > So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. > > This change also introduces some new behavior for the robot: > A system window now appears asking for confirmation from the user to capture the screen. > + The user can refuse the screen capture completely. In this case a security exception will be thrown. > + The user can allow a screen capture for all screens o... Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: rework token storage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13803/files - new: https://git.openjdk.org/jdk/pull/13803/files/c077dc7a..1bd099cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=05-06 Stats: 459 lines in 3 files changed: 358 ins; 38 del; 63 mod Patch: https://git.openjdk.org/jdk/pull/13803.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13803/head:pull/13803 PR: https://git.openjdk.org/jdk/pull/13803 From azvegint at openjdk.org Thu May 25 16:49:02 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 25 May 2023 16:49:02 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v7] In-Reply-To: References: Message-ID: On Thu, 25 May 2023 16:29:39 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > rework token storage Token storage now does not use Preferences API and serialization. (there were some problems with missing token during automated testing). Properties API is now used: No more writing to file if token data was not updated. Detect external changes to the file, and update the token data if it was updated. If we can't save the data, we can still use the received token, but we won't keep it between runs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1563212589 From mdoerr at openjdk.org Thu May 25 18:21:58 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 25 May 2023 18:21:58 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code In-Reply-To: References: Message-ID: On Thu, 25 May 2023 15:04:32 GMT, Kim Barrett wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Some of those are in shared codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > > src/hotspot/share/utilities/globalDefinitions_xlc.hpp line 47: > >> 45: #undef malloc >> 46: extern void *malloc(size_t) asm("vec_malloc"); >> 47: #endif > > Wow! And I don't mean that in a good way. I'm not questioning whether this is correct, just commenting > on how crazy it seems that such a thing might be needed. The crazy thing is that `malloc` is defined! That means all places where we use the term malloc are getting replaced without such a workaround. (E.g. for log tags.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1205867287 From dholmes at openjdk.org Fri May 26 01:09:57 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 26 May 2023 01:09:57 GMT Subject: RFR: 8308341: JNI_GetCreatedJavaVMs returns a partially initialized JVM In-Reply-To: <2EoMWGrWIv78bhu7AotLiJdR5LVy2Y-5V_62cW7aDeo=.6a4c4703-5ceb-49dd-8208-213f758cd152@github.com> References: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> <2EoMWGrWIv78bhu7AotLiJdR5LVy2Y-5V_62cW7aDeo=.6a4c4703-5ceb-49dd-8208-213f758cd152@github.com> Message-ID: On Thu, 25 May 2023 09:49:58 GMT, Johan Sj?len wrote: >> We now track the in-progress and completed states of VM creation and only return a VM from JNI_GetCreatedJavaVMs when there is a fully initialized VM. >> >> Testing: >> - new regression test >> - tiers 1-3 (sanity) >> >> Thanks > > src/hotspot/share/prims/jni.cpp line 3475: > >> 3473: >> 3474: // Global invocation API vars >> 3475: enum VM_Creation_State { > > Nit: Would `enum class` be preferred here? I prefer a basic enum for this (just named integer constants). > src/hotspot/share/prims/jni.cpp line 3943: > >> 3941: // initialization, so only bail-out if something seems very wrong. >> 3942: // Though how would we get here in that case? >> 3943: if (vm_created == NOT_CREATED) { > > Shouldn't we also handle `IN_PROGRESS`? I guess my comment was not clear enough. :) It is normal to get here while IN_PROGRESS due to calls from the JDK native code during initialization. So we only consider it an error to call then when NOT_CREATED. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14139#discussion_r1206130207 PR Review Comment: https://git.openjdk.org/jdk/pull/14139#discussion_r1206129897 From dholmes at openjdk.org Fri May 26 01:19:54 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 26 May 2023 01:19:54 GMT Subject: RFR: 8308341: JNI_GetCreatedJavaVMs returns a partially initialized JVM In-Reply-To: <2EoMWGrWIv78bhu7AotLiJdR5LVy2Y-5V_62cW7aDeo=.6a4c4703-5ceb-49dd-8208-213f758cd152@github.com> References: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> <2EoMWGrWIv78bhu7AotLiJdR5LVy2Y-5V_62cW7aDeo=.6a4c4703-5ceb-49dd-8208-213f758cd152@github.com> Message-ID: On Thu, 25 May 2023 10:17:59 GMT, Johan Sj?len wrote: >> We now track the in-progress and completed states of VM creation and only return a VM from JNI_GetCreatedJavaVMs when there is a fully initialized VM. >> >> Testing: >> - new regression test >> - tiers 1-3 (sanity) >> >> Thanks > > Hi, over all looks good, but I have some questions regarding the tests and I wonder whether you missed a case. Thanks for looking at this @jdksjolen ! > test/hotspot/jtreg/runtime/jni/getCreatedJavaVMs/exeGetCreatedJavaVMs.c line 1: > >> 1: /* > > Can we make this test behave even worse than it already does and have you caused a crash with this test before applying your changes? If it has caused a crash, then I think we're OK with the current form of the test. > > Two ideas to make it more likely to crash: > > 1. Have more threads racing > 2. Let's say you spawn more threads, is it possible for `printf` to prevent data races as it's MT-Safe? More threads would increase likelihood of contention on the implicit lock, leading to some threads having been significantly slowed down by having to perform a more expensive locking procedure, is my thought process. The test crashes an unpatched VM. We only need the two threads. One will initiate the creation of the VM and the other then tries to attach to it. We want the second thread to call GetCreatedJavaVMs very quickly to make it more likely the VM is not initialized, but not so quickly that GetCreatedJavaVMs reports zero VMs (regardless of the patch). The time it takes the main thread to create the second thread seems to handle that nicely. Of course it depends on number of CPUs etc but on my local machine the test, and the original version from the JBS issue, reliably crashes every time before the fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14139#issuecomment-1563689278 PR Review Comment: https://git.openjdk.org/jdk/pull/14139#discussion_r1206133926 From darcy at openjdk.org Fri May 26 06:10:07 2023 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 26 May 2023 06:10:07 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v20] In-Reply-To: References: Message-ID: On Thu, 25 May 2023 14:32:44 GMT, Jim Laskey wrote: >> Add flexible main methods and anonymous main classes to the Java language. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Improving error recovery in presence of less important syntactic errors in top-level methods and fields. > > Author: Jan Lahoda test/jdk/tools/launcher/InstanceMainTest.java line 31: > 29: * @run main InstanceMainTest > 30: */ > 31: public class InstanceMainTest extends TestHelper { By my reading of the spec, "main" methods can be defined in record classes and enum classes as well as normal classes. Are there tests for record and enum main method operation? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1206277064 From forax at openjdk.org Fri May 26 06:23:05 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 26 May 2023 06:23:05 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v20] In-Reply-To: References: Message-ID: <7txzmoyjMl_VmeZW96En2DsyU50tTb4Vf9ls9cPTcUQ=.76a7f314-5ca8-4d27-b1a3-2541ca60bd73@github.com> On Fri, 26 May 2023 06:07:05 GMT, Joe Darcy wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Improving error recovery in presence of less important syntactic errors in top-level methods and fields. >> >> Author: Jan Lahoda > > test/jdk/tools/launcher/InstanceMainTest.java line 31: > >> 29: * @run main InstanceMainTest >> 30: */ >> 31: public class InstanceMainTest extends TestHelper { > > By my reading of the spec, "main" methods can be defined in record classes and enum classes as well as normal classes. > Are there tests for record and enum main method operation? You can also have a `main` method inside an interface. For enum classes and interfaces, the main has to be static. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1206285923 From mbaesken at openjdk.org Fri May 26 07:14:55 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 26 May 2023 07:14:55 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code In-Reply-To: References: Message-ID: On Thu, 25 May 2023 16:13:49 GMT, JoKern65 wrote: >> test/jdk/java/io/File/libGetXSpace.c line 128: >> >>> 126: #else >>> 127: struct statfs buf; >>> 128: int result = statfs((char*)chars, &buf); >> >> Is this working around a bug in IBM's declaration? >> >> Also, pre-existing, the cast seems really suspicious. The type of `chars` is `jchar*`, which is a >> sequence of 16bit characters. Does this actually work? If so, how? > > This is IBMs declaration of statfs > `extern int statfs(char *, struct statfs *);` > So the compiler will not accept a `const char*` > Indeed I do not know if this ever worked, but my change makes it not worse. Here is the documentation of statfs on AIX https://www.ibm.com/docs/en/aix/7.2?topic=s-statfs-fstatfs-statfs64-fstatfs64-ustat-subroutine (showing the IBM declaration Joachim told us) . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1206326207 From mbaesken at openjdk.org Fri May 26 07:55:56 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 26 May 2023 07:55:56 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code In-Reply-To: References: Message-ID: On Fri, 26 May 2023 07:12:07 GMT, Matthias Baesken wrote: >> This is IBMs declaration of statfs >> `extern int statfs(char *, struct statfs *);` >> So the compiler will not accept a `const char*` >> Indeed I do not know if this ever worked, but my change makes it not worse. > > Here is the documentation of statfs on AIX https://www.ibm.com/docs/en/aix/7.2?topic=s-statfs-fstatfs-statfs64-fstatfs64-ustat-subroutine (showing the IBM declaration Joachim told us) . > Also, pre-existing, the cast seems really suspicious. The type of `chars` is `jchar*`, which is a sequence of 16bit characters. Does this actually work? If so, how? Probably a jchar to char conversion would be needed for the array elements, maybe like this here (or is there a better utility function in the codebase) ? See jCharArrayToCKCharArray https://github.com/openjdk/jdk/blob/199b1bf5009120efd1fd37a1ddabc0c6fb84f62c/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c#L644 I am not aware of an AIX statfs for wchars but maybe I miss something. But it is a separate issue of Java_GetXSpace_getSpace0 anyway and should be handled in another bug. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1206370114 From duke at openjdk.org Fri May 26 08:31:46 2023 From: duke at openjdk.org (JoKern65) Date: Fri, 26 May 2023 08:31:46 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: Message-ID: > When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". > Some of those are in shared codebase and could be addressed by small adjustments. > A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. JoKern65 has updated the pull request incrementally with one additional commit since the last revision: forgotton _ ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14146/files - new: https://git.openjdk.org/jdk/pull/14146/files/2699fdce..da38fb2d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14146&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14146&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14146/head:pull/14146 PR: https://git.openjdk.org/jdk/pull/14146 From jsjolen at openjdk.org Fri May 26 08:44:55 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 26 May 2023 08:44:55 GMT Subject: RFR: 8308341: JNI_GetCreatedJavaVMs returns a partially initialized JVM In-Reply-To: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> References: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> Message-ID: On Thu, 25 May 2023 05:02:19 GMT, David Holmes wrote: > We now track the in-progress and completed states of VM creation and only return a VM from JNI_GetCreatedJavaVMs when there is a fully initialized VM. > > Testing: > - new regression test > - tiers 1-3 (sanity) > > Thanks Thank you for this patch, everything looks good to me )including the build changes). ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14139#pullrequestreview-1445617452 From jsjolen at openjdk.org Fri May 26 08:44:59 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 26 May 2023 08:44:59 GMT Subject: RFR: 8308341: JNI_GetCreatedJavaVMs returns a partially initialized JVM In-Reply-To: References: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> <2EoMWGrWIv78bhu7AotLiJdR5LVy2Y-5V_62cW7aDeo=.6a4c4703-5ceb-49dd-8208-213f758cd152@github.com> Message-ID: On Fri, 26 May 2023 01:06:21 GMT, David Holmes wrote: >> src/hotspot/share/prims/jni.cpp line 3943: >> >>> 3941: // initialization, so only bail-out if something seems very wrong. >>> 3942: // Though how would we get here in that case? >>> 3943: if (vm_created == NOT_CREATED) { >> >> Shouldn't we also handle `IN_PROGRESS`? > > I guess my comment was not clear enough. :) It is normal to get here while IN_PROGRESS due to calls from the JDK native code during initialization. So we only consider it an error to call then when NOT_CREATED. Sloppy reading from me! That makes sense, and the code doing the work (L3960-L3965) seems to take all precautions necessary to ensure that nothing goes wrong if we're `IN_PROGRESS`. Just a minor suggestion: "during VM initialization" could be "while VM initialization is in progress" to mirror the language in the enum, but that's up to you. >> test/hotspot/jtreg/runtime/jni/getCreatedJavaVMs/exeGetCreatedJavaVMs.c line 1: >> >>> 1: /* >> >> Can we make this test behave even worse than it already does and have you caused a crash with this test before applying your changes? If it has caused a crash, then I think we're OK with the current form of the test. >> >> Two ideas to make it more likely to crash: >> >> 1. Have more threads racing >> 2. Let's say you spawn more threads, is it possible for `printf` to prevent data races as it's MT-Safe? More threads would increase likelihood of contention on the implicit lock, leading to some threads having been significantly slowed down by having to perform a more expensive locking procedure, is my thought process. > > The test crashes an unpatched VM. We only need the two threads. One will initiate the creation of the VM and the other then tries to attach to it. We want the second thread to call GetCreatedJavaVMs very quickly to make it more likely the VM is not initialized, but not so quickly that GetCreatedJavaVMs reports zero VMs (regardless of the patch). The time it takes the main thread to create the second thread seems to handle that nicely. Of course it depends on number of CPUs etc but on my local machine the test, and the original version from the JBS issue, reliably crashes every time before the fix. Alright, then I'm very happy with this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14139#discussion_r1206430443 PR Review Comment: https://git.openjdk.org/jdk/pull/14139#discussion_r1206432196 From duke at openjdk.org Fri May 26 10:12:55 2023 From: duke at openjdk.org (JoKern65) Date: Fri, 26 May 2023 10:12:55 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: Message-ID: On Fri, 26 May 2023 08:31:46 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Some of those are in shared codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > > JoKern65 has updated the pull request incrementally with one additional commit since the last revision: > > forgotton _ Here are the reasons for the disabled warnings in make/modules/java.base/Lib.gmk DISABLED_WARNINGS_clang_aix_DefaultProxySelector.c := deprecated-non-prototype, \ DISABLED_WARNINGS_clang_aix_NetworkInterface.c := gnu-pointer-arith, \ DISABLED_WARNINGS_clang_aix_UnixNativeDispatcher.c := undef, \ src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype] proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error); ^ src/java.base/unix/native/libnet/NetworkInterface.c:1612:24: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith] end = (void *)nddp + size; ~~~~~~~~~~~~ ^ src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c:1251:7: error: '_ALLBSD_SOURCE' is not defined, evaluates to 0 [-Werror,-Wundef] #elif _ALLBSD_SOURCE ^ ------------- PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564143664 From duke at openjdk.org Fri May 26 10:20:58 2023 From: duke at openjdk.org (JoKern65) Date: Fri, 26 May 2023 10:20:58 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: Message-ID: <1HhxMPs2-ZAR3zcdR6EhFDCJAYnMfVKxh3pmDh2vQlQ=.a836c68b-6098-436c-b34e-3fb35f9c2d36@github.com> On Fri, 26 May 2023 08:31:46 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Some of those are in shared codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > > JoKern65 has updated the pull request incrementally with one additional commit since the last revision: > > forgotton _ Here are the reasons for the disabled warnings in make/modules/java.base/lib/CoreLibraries.gmk DISABLED_WARNINGS_clang_aix_ProcessHandleImpl_unix.c := sign-compare, \ DISABLED_WARNINGS_clang_aix := gnu-pointer-arith, \ DISABLED_WARNINGS_clang := gnu-pointer-arith format-nonliteral deprecated-non-prototype, \ src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:638 comparison of integers of different signs: 'int' and 'unsigned long' if (ret < sizeof(psinfo_t)) { ^ src/java.base/aix/native/libjli/java_md_aix.c:42:38: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith] addr < p->ldinfo_textorg + p->ldinfo_textsize) { ~~~~~~~~~~~~~~~~~ ^ src/java.base/share/native/libzip/zlib/inffast.c:74:20: error: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype] void ZLIB_INTERNAL inflate_fast(strm, start) ^ src/java.base/share/native/libjli/java.c:2311:22: error: format string is not a string literal [-Werror,-Wformat-nonliteral] vfprintf(stderr, fmt, vl); ^~~ ------------- PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564165195 From mbaesken at openjdk.org Fri May 26 10:24:55 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 26 May 2023 10:24:55 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: Message-ID: On Fri, 26 May 2023 10:05:56 GMT, JoKern65 wrote: > src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c:1251:7: error: '_ALLBSD_SOURCE' is not defined, evaluates to 0 [-Werror,-Wundef] > #elif _ALLBSD_SOURCE > Should probably better be `#elif defined(_ALLBSD_SOURCE)` ------------- PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564168769 From mbaesken at openjdk.org Fri May 26 10:47:55 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 26 May 2023 10:47:55 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: <1HhxMPs2-ZAR3zcdR6EhFDCJAYnMfVKxh3pmDh2vQlQ=.a836c68b-6098-436c-b34e-3fb35f9c2d36@github.com> References: <1HhxMPs2-ZAR3zcdR6EhFDCJAYnMfVKxh3pmDh2vQlQ=.a836c68b-6098-436c-b34e-3fb35f9c2d36@github.com> Message-ID: On Fri, 26 May 2023 10:18:37 GMT, JoKern65 wrote: > src/java.base/share/native/libjli/java.c:2311:22: error: format string is not a string literal [-Werror,-Wformat-nonliteral] vfprintf(stderr, fmt, vl); ^~~ We disable this warning too for clang on all platforms in BUILD_LIBJLI ( DISABLED_WARNINGS_clang := **format-nonlitera**l deprecated-non-prototype, \ ), so I think we should do it the same way for BUILD_LIBJLI_STATIC on AIX. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564193886 From mbaesken at openjdk.org Fri May 26 10:55:02 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 26 May 2023 10:55:02 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: <1HhxMPs2-ZAR3zcdR6EhFDCJAYnMfVKxh3pmDh2vQlQ=.a836c68b-6098-436c-b34e-3fb35f9c2d36@github.com> References: <1HhxMPs2-ZAR3zcdR6EhFDCJAYnMfVKxh3pmDh2vQlQ=.a836c68b-6098-436c-b34e-3fb35f9c2d36@github.com> Message-ID: On Fri, 26 May 2023 10:18:37 GMT, JoKern65 wrote: > Here are the reasons for the disabled warnings in make/modules/java.base/lib/CoreLibraries.gmk DISABLED_WARNINGS_clang_aix_ProcessHandleImpl_unix.c := sign-compare, DISABLED_WARNINGS_clang_aix := gnu-pointer-arith, DISABLED_WARNINGS_clang := gnu-pointer-arith format-nonliteral deprecated-non-prototype, \ > > src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:638 comparison of integers of different signs: 'int' and 'unsigned long' if (ret < sizeof(psinfo_t)) { ^ > `fread` returns a `size_t ` on Linux and AIX, could you please check Mac/BSD too ? https://github.com/openjdk/jdk/blob/d3b9b364da8c11c9b4dd14a6451a7b24f41202e7/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c#L636 We should probably change to size_t ret (from type int), then the warning would not occur, correct ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564207011 From duke at openjdk.org Fri May 26 12:19:55 2023 From: duke at openjdk.org (JoKern65) Date: Fri, 26 May 2023 12:19:55 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: Message-ID: On Fri, 26 May 2023 08:31:46 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Some of those are in shared codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > > JoKern65 has updated the pull request incrementally with one additional commit since the last revision: > > forgotton _ Here are the reasons for the disabled warnings in make/modules/java.desktop/lib/Awt2dLibraries.gmk /data/d042520/pr/jdk/src/java.desktop/unix/native/common/awt/awt_GraphicsEnv.h:53:12: error: a function declaration without a prototype is deprecated in all versions of C and is treated as a zero-parameter prototype in C2x, conflicting with a previous declaration [-Werror,-Wdeprecated-non-prototype] extern int XShmQueryExtension(); ^ /usr/include/X11/extensions/XShm.h:91:6: note: conflicting prototype is here Bool XShmQueryExtension( ^ solved by adding line (generic, because several source files are involved) DISABLED_WARNINGS_clang_aix := deprecated-non-prototype, \ src/java.desktop/unix/native/libawt_xawt/xawt/awt_Taskbar.c:158:11: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses] if (m = fp_unity_launcher_entry_get_quicklist(entry)) { ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ solved by adding line DISABLED_WARNINGS_clang_aix_awt_Taskbar.c := parentheses, \ src/java.desktop/share/native/common/java2d/opengl/OGLPaints.c:581:48: error: format string is not a string literal [-Werror,-Wformat-nonliteral] snprintf(cycleCode, sizeof(cycleCode), noCycleCode, texCoordCalcCode); ^~~~~~~~~~~ solved by adding line DISABLED_WARNINGS_clang_aix_OGLPaints.c := format-nonliteral, \ src/java.desktop/share/native/common/java2d/opengl/OGLBufImgOps.c:153:48: error: format string is not a string literal [-Werror,-Wformat-nonliteral] snprintf(finalSource, sizeof(finalSource), convolveShaderSource, ^~~~~~~~~~~~~~~~~~~~ solved by adding line DISABLED_WARNINGS_clang_aix_OGLBufImgOps.c := format-nonliteral, \ src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:1095:41: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses] if ((synth_state & MOUSE_OVER) != 0 && (synth_state & PRESSED) == 0 || ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~ src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:1180:29: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses] if (init_result = (NULL == gtk2_widgets[_GTK_CHECK_MENU_ITEM_TYPE])) ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ solved by adding line DISABLED_WARNINGS_clang_aix_gtk2_interface.c := parentheses logical-op-parentheses, \ src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c:903:29: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses] if (init_result = (NULL == gtk3_widgets[_GTK_BUTTON_TYPE])) ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ solved by adding line DISABLED_WARNINGS_clang_aix_gtk3_interface.c := parentheses, \ src/java.desktop/unix/native/libawt_xawt/awt/sun_awt_X11_GtkFileDialogPeer.c:87:26: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses] if (pendingException = (*env)->ExceptionOccurred(env)) { ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ solved by adding line DISABLED_WARNINGS_clang_aix_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \ src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c:1969:32: error: comparison of integers of different signs: 'Window' (aka 'unsigned long') and 'jlong' (aka 'long') [-Werror,-Wsign-compare] if (currentFocusWindow != w) { ~~~~~~~~~~~~~~~~~~ ^ ~ solved by adding line DISABLED_WARNINGS_clang_aix_awt_InputMethod.c := sign-compare, \ Here is the reason for the disabled warning in make/modules/java.security.jgss/Lib.gmk src/java.security.jgss/share/native/libj2gss/NativeUtil.h:30: /data/d042520/pr/jdk/src/java.security.jgss/share/native/libj2gss/gssapi.h:48:5: error: 'TARGET_OS_MAC' is not defined, evaluates to 0 [-Werror,-Wundef] #if TARGET_OS_MAC && (defined(__ppc__) || defined(__ppc64__) || defined(__i386__) || defined(__x86_64__)) ^ make/modules/java.security.jgss/Lib.gmk add line DISABLED_WARNINGS_clang_aix := undef, \ Here is the reason for the disabled warning in make/modules/jdk.jdwp.agent/Lib.gmk src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c:718:33: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces] struct in6_addr mappedAny = IN6ADDR_ANY_INIT; ^~~~~~~~~~~~~~~~ /usr/include/netinet/in.h:454:32: note: expanded from macro 'IN6ADDR_ANY_INIT' #define IN6ADDR_ANY_INIT {0, 0, 0, 0} solved by adding line DISABLED_WARNINGS_clang_aix := missing-braces, \ ------------- PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564303459 PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564304989 PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564306115 From jlaskey at openjdk.org Fri May 26 13:08:08 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 26 May 2023 13:08:08 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v20] In-Reply-To: <7txzmoyjMl_VmeZW96En2DsyU50tTb4Vf9ls9cPTcUQ=.76a7f314-5ca8-4d27-b1a3-2541ca60bd73@github.com> References: <7txzmoyjMl_VmeZW96En2DsyU50tTb4Vf9ls9cPTcUQ=.76a7f314-5ca8-4d27-b1a3-2541ca60bd73@github.com> Message-ID: On Fri, 26 May 2023 06:20:14 GMT, R?mi Forax wrote: >> test/jdk/tools/launcher/InstanceMainTest.java line 31: >> >>> 29: * @run main InstanceMainTest >>> 30: */ >>> 31: public class InstanceMainTest extends TestHelper { >> >> By my reading of the spec, "main" methods can be defined in record classes and enum classes as well as normal classes. >> Are there tests for record and enum main method operation? > > You can also have a `main` method inside an interface. For enum classes and interfaces, the main has to be static. updating tests ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1206753443 From jlaskey at openjdk.org Fri May 26 13:19:49 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 26 May 2023 13:19:49 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v21] In-Reply-To: References: Message-ID: > Add flexible main methods and anonymous main classes to the Java language. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Add main tests for inferface/enum/record ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13689/files - new: https://git.openjdk.org/jdk/pull/13689/files/cfac821a..4e54c17a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=19-20 Stats: 128 lines in 2 files changed: 27 ins; 22 del; 79 mod Patch: https://git.openjdk.org/jdk/pull/13689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689 PR: https://git.openjdk.org/jdk/pull/13689 From jlaskey at openjdk.org Fri May 26 13:22:59 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 26 May 2023 13:22:59 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v22] In-Reply-To: References: Message-ID: > Add flexible main methods and anonymous main classes to the Java language. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Remove trailing whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13689/files - new: https://git.openjdk.org/jdk/pull/13689/files/4e54c17a..06aa43ec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=20-21 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/13689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689 PR: https://git.openjdk.org/jdk/pull/13689 From mdoerr at openjdk.org Fri May 26 13:37:55 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 26 May 2023 13:37:55 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: Message-ID: On Fri, 26 May 2023 08:31:46 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Some of those are in shared codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > > JoKern65 has updated the pull request incrementally with one additional commit since the last revision: > > forgotton _ Just a side note: The warning elimination is new for AIX compilers. We had given it up at earlier times: https://bugs.openjdk.org/browse/JDK-8202325 I still appreciate if we can get warning free and it makes sense to review all of them. But, I wouldn't require it for JDK21. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564406986 From mkartashev at openjdk.org Fri May 26 15:36:00 2023 From: mkartashev at openjdk.org (Maxim Kartashev) Date: Fri, 26 May 2023 15:36:00 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v7] In-Reply-To: References: Message-ID: <1wgLMR5-P0FK3ZAoncmfyyyZrorua3lb9nyx8-zAO3Q=.bbc72712-af1e-41d8-896d-3391b8455e77@github.com> On Thu, 25 May 2023 16:29:39 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > rework token storage Tried running this version on my machine (Ubuntu 22.04, two displays with 100% and 200% scaling). A few observations: 1. I couldn't get any of the screenshot tests working through `jtreg` (screenshots are all black, no permission is ever asked). Does anybody know how to do that properly? Can this be made to work out of the box? 2. Running manually is OK for the most part except for some tests in certain configurations: * Test `test/jdk/java/awt/Robot/HiDPIScreenCapture/ScreenCaptureGtkTest.java` consistently fails with `sun.java2d.uiScale` other than `1`. For example, $ java -Dsun.java2d.uiScale=3 ScreenCaptureGtkTest.java Creating screen capture of java.awt.Rectangle[x=89,y=99,width=100,height=100] Exception in thread "main" java.lang.SecurityException: Screen Capture in the selected area was not allowed at java.desktop/sun.awt.screencast.ScreencastHelper.getRGBPixels(ScreencastHelper.java:161) at java.desktop/sun.awt.X11.XRobotPeer.getRGBPixels(XRobotPeer.java:139) at java.desktop/java.awt.Robot.createCompatibleImage(Robot.java:606) at java.desktop/java.awt.Robot.createScreenCapture(Robot.java:477) at ScreenCaptureGtkTest.captureImageOf(ScreenCaptureGtkTest.java:130) at ScreenCaptureGtkTest.main(ScreenCaptureGtkTest.java:96) and this is when I allow both screens to be captured in the system dialog that appears after the start of the test. The same failure can be observed with `java -Dsun.java2d.uiScale=2 HiDPIRobotScreenCaptureTest.java`. Both tests hang after throwing those exceptions, by the way. * The same test fails in a different fashion with `-Djdk.gtk.version=2`. For example: $ java -Djdk.gtk.version=2 -Dsun.java2d.uiScale=1 ScreenCaptureGtkTest.java WARNING: the GTK 2 library is deprecated and its support will be removed in a future release Gtk-Message: 19:17:15.122: Failed to load module "canberra-gtk-module" Creating screen capture of java.awt.Rectangle[x=89,y=99,width=100,height=100] Could not load native libraries for ScreencastHelper Checking color at 139, 149 to be equal to java.awt.Color[r=0,g=255,b=0]... Mismatch: found java.awt.Color[r=0,g=0,b=0] instead Check image.png Exception in thread "main" java.lang.RuntimeException: Wrong screen pixel color at ScreenCaptureGtkTest.checkPixelColors(ScreenCaptureGtkTest.java:115) at ScreenCaptureGtkTest.main(ScreenCaptureGtkTest.java:100) * Test `test/jdk/java/awt/Robot/HiDPIScreenCapture/ScreenCaptureResolutionTest.java` fails and hangs like so: $ java ScreenCaptureResolutionTest.java Exception in thread "AWT-EventQueue-0" java.lang.RuntimeException: Exception while validating ScreenCapture at ScreenCaptureResolutionTest$2.run(ScreenCaptureResolutionTest.java:75) at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714) at java.base/java.security.AccessController.doPrivileged(AccessController.java:400) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1564568586 From azvegint at openjdk.org Fri May 26 15:54:56 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 26 May 2023 15:54:56 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v7] In-Reply-To: <1wgLMR5-P0FK3ZAoncmfyyyZrorua3lb9nyx8-zAO3Q=.bbc72712-af1e-41d8-896d-3391b8455e77@github.com> References: <1wgLMR5-P0FK3ZAoncmfyyyZrorua3lb9nyx8-zAO3Q=.bbc72712-af1e-41d8-896d-3391b8455e77@github.com> Message-ID: On Fri, 26 May 2023 15:32:41 GMT, Maxim Kartashev wrote: > Tried running this version on my machine (Ubuntu 22.04, two displays with 100% and 200% scaling). A few observations: > > 1. I couldn't get any of the screenshot tests working through `jtreg` (screenshots are all black, no permission is ever asked). Does anybody know how to do that properly? Can this be made to work out of the box? jtreg strips env variables down to a very few. so providing following options should solve the issue: `jtreg -ea -e:DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS -e:WAYLAND_DISPLAY=$WAYLAND_DISPLAY ...` This is already addressed in jtreg 7.3 by [openjdk/jtreg/pull/152](https://github.com/openjdk/jtreg/pull/152) > 2. Running manually is OK for the most part except for some tests in certain configurations: > > > * Test `test/jdk/java/awt/Robot/HiDPIScreenCapture/ScreenCaptureGtkTest.java` consistently fails with `sun.java2d.uiScale` other than `1`. For example, > > > ``` > $ java -Dsun.java2d.uiScale=3 ScreenCaptureGtkTest.java > Creating screen capture of java.awt.Rectangle[x=89,y=99,width=100,height=100] > Exception in thread "main" java.lang.SecurityException: Screen Capture in the selected area was not allowed > at java.desktop/sun.awt.screencast.ScreencastHelper.getRGBPixels(ScreencastHelper.java:161) > at java.desktop/sun.awt.X11.XRobotPeer.getRGBPixels(XRobotPeer.java:139) > at java.desktop/java.awt.Robot.createCompatibleImage(Robot.java:606) > at java.desktop/java.awt.Robot.createScreenCapture(Robot.java:477) > at ScreenCaptureGtkTest.captureImageOf(ScreenCaptureGtkTest.java:130) > at ScreenCaptureGtkTest.main(ScreenCaptureGtkTest.java:96) > ``` > > and this is when I allow both screens to be captured in the system dialog that appears after the start of the test. The same failure can be observed with `java -Dsun.java2d.uiScale=2 HiDPIRobotScreenCaptureTest.java`. Both tests hang after throwing those exceptions, by the way. > I'll take a look. > * The same test fails in a different fashion with `-Djdk.gtk.version=2`. For example: This is intended, GTK2 is not supported and deprecated for removal. [JDK-8280031](https://bugs.openjdk.org/browse/JDK-8280031) ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1564594406 From tonyp at openjdk.org Fri May 26 16:15:16 2023 From: tonyp at openjdk.org (Antonios Printezis) Date: Fri, 26 May 2023 16:15:16 GMT Subject: RFR: 8308969: make test-prebuilt doesn't return the correct exit code Message-ID: For 'make' test and 'make test-only' the existence of exit-with-error is checked in the main target in Init.gmk. Is there a better way to fix this than to check for the existence of exit-with-error in RunTestsPrebuilt.gmk? ------------- Commit messages: - 8308969: make test-prebuilt doesn't return the correct exit code Changes: https://git.openjdk.org/jdk/pull/14183/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14183&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308969 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14183.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14183/head:pull/14183 PR: https://git.openjdk.org/jdk/pull/14183 From mkartashev at openjdk.org Fri May 26 16:16:00 2023 From: mkartashev at openjdk.org (Maxim Kartashev) Date: Fri, 26 May 2023 16:16:00 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v7] In-Reply-To: References: Message-ID: On Thu, 25 May 2023 16:29:39 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > rework token storage > This is already addressed in jtreg 7.3 by https://github.com/openjdk/jtreg/pull/152 Thanks for the info! > This is intended, GTK2 is not supported and deprecated for removal. [JDK-8280031](https://bugs.openjdk.org/browse/JDK-8280031) That's fine, but the test still fails: Exception in thread "main" java.lang.RuntimeException: Wrong screen pixel color Deprecated shouldn't mean dysfunctional, so perhaps remove the line * @run main/othervm -Djdk.gtk.version=2 -Dsun.java2d.uiScale=1 ScreenCaptureGtkTest from the test if there's no intention to make it work even (and especially) in the future. It will always fail on XWayland. Or, if removing is hard for some reason, make it conditional and execute this test only in the pure X environment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1564621611 From stuefe at openjdk.org Fri May 26 17:01:57 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 26 May 2023 17:01:57 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: Message-ID: On Thu, 25 May 2023 18:18:43 GMT, Martin Doerr wrote: >> src/hotspot/share/utilities/globalDefinitions_xlc.hpp line 47: >> >>> 45: #undef malloc >>> 46: extern void *malloc(size_t) asm("vec_malloc"); >>> 47: #endif >> >> Wow! And I don't mean that in a good way. I'm not questioning whether this is correct, just commenting >> on how crazy it seems that such a thing might be needed. > > The crazy thing is that `malloc` is defined! That means all places where we use the term malloc are getting replaced without such a workaround. (E.g. for log tags.) So, we do this only for malloc? Not for calloc, posix_memalign, realloc etc? What about free? As ugly as defining malloc is (and I remember QADRT), I hesitate about removing that define. Removing that define and hard-coding it here assumes 1) our replacement is equivalent (ok, easy to check) 2) it will always be equivalent in future AIX versions 3) pointers it returns work with the unchanged free() and realloc() the system provides, and will always do so. I don't know... I would not do this just to get rid of a warning. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1207078176 From gziemski at openjdk.org Fri May 26 17:53:58 2023 From: gziemski at openjdk.org (Gerard Ziemski) Date: Fri, 26 May 2023 17:53:58 GMT Subject: RFR: 8308341: JNI_GetCreatedJavaVMs returns a partially initialized JVM In-Reply-To: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> References: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> Message-ID: On Thu, 25 May 2023 05:02:19 GMT, David Holmes wrote: > We now track the in-progress and completed states of VM creation and only return a VM from JNI_GetCreatedJavaVMs when there is a fully initialized VM. > > Testing: > - new regression test > - tiers 1-3 (sanity) > > Thanks Looks fine to me. I have one question though: why wouldn't it be enough to move `vm_created = 1` from where we had it before, down to where we now have `vm_created = COMPLETE` ? I'm not 100% sure why we need the intermediate step `IN_PROGRESS` ------------- PR Review: https://git.openjdk.org/jdk/pull/14139#pullrequestreview-1446696175 From gziemski at openjdk.org Fri May 26 18:04:56 2023 From: gziemski at openjdk.org (Gerard Ziemski) Date: Fri, 26 May 2023 18:04:56 GMT Subject: RFR: 8308341: JNI_GetCreatedJavaVMs returns a partially initialized JVM In-Reply-To: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> References: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> Message-ID: On Thu, 25 May 2023 05:02:19 GMT, David Holmes wrote: > We now track the in-progress and completed states of VM creation and only return a VM from JNI_GetCreatedJavaVMs when there is a fully initialized VM. > > Testing: > - new regression test > - tiers 1-3 (sanity) > > Thanks test/hotspot/jtreg/runtime/jni/getCreatedJavaVMs/TestGetCreatedJavaVMs.java line 27: > 25: * @test > 26: * @library /test/lib > 27: * @requires os.family == "Linux" Why is it Linux only? Does `ProcessTools.createNativeTestProcessBuilder("GetCreatedJavaVMs");` only work on Linux? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14139#discussion_r1207155995 From jiangli at openjdk.org Fri May 26 20:28:55 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 26 May 2023 20:28:55 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v4] In-Reply-To: References: Message-ID: On Thu, 25 May 2023 01:19:11 GMT, Jiangli Zhou wrote: > > > > My build job is still running, but it has failed in two distinct ways already. See below for mac fix. Our cross build of arm32 fails with this message: > > > > ``` > > > > [2023-05-24T19:25:15,310Z] /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: fatal error: cannot mix -r with dynamic object /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libstdc++.so > > > > ``` > > > > > > > > > If this is a problem with your partial link solution, then perhaps just employing the relative path trick for the `ar` command line on mac could be enough to handle long paths and lots of object files? That appears to be how we handle it with clang for linking already due to @-file problems. > > > > > > The partial linking was originally suggested by C++/Clang toolchain folks to mitigate linker overhead that was observed during final executable link time. For a static library containing any object file (`.o`) that was compiled with ThinLTO (https://clang.llvm.org/docs/ThinLTO.html) enabled, linking an executable using the static library without distributed ThinLTO could experience more overhead and slow down linking. Solving the macosx `ar` limitation is a side-effect/benefit of using partial linking. We probably would want to include the partial linking even without the `ar` limitation. > > Is it possible `$$($1_SYSROOT_LDFLAGS)` pulled in `libstdc++.so` as part of the input for partial linking with the linux-aarch64 cross build? > > Another possibility might be the user provided `BUILD_LDCXX` includes extra options in the testing build (?). If that's the case, we probably could define a separate `BUILD_LD_PARTIAL` with no added options. In our prototype on JDK 11, we define a separate one for partial linking. I tried building `static-libs-image` for linux-aarch64 on Ubuntu machine using `devkit` to reproduce the failure. Also tried building for `linux-ppc64le-server-release` target using `devkit` on Ubuntu. Both built successfully with using `devkit`. I could not build a `devkit` for arm32 (with `make TARGETS="arm-linux-gnueabihf" BASE_OS=Fedora BASE_OS_VERSION=17`, also tried with BASE_OS_VERSION=17). @erikj79 Could you please help provide additional insight for the build failure you found for arm32? `BUILD_LIBJVM_partial_link.cmdline` might help shed some light. For the `aarch64-linux-gnu` build using `devkit`, I see following, which is ok. No unexpected options are included. /.../bin/aarch64-linux-gnu-g++ -r --sysroot=/.../aarch64-linux-gnu/sysroot -o /...linux-aarch64-server-release/hotspot/variant-server/libjvm/objs/static/libjvm_relocatable.o @/.../hotspot/variant-server/libjvm/objs/static/_BUILD_LIBJVM_objectfilenames.txt ------------- PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1564908324 From mdoerr at openjdk.org Fri May 26 20:29:54 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 26 May 2023 20:29:54 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: Message-ID: On Fri, 26 May 2023 16:58:41 GMT, Thomas Stuefe wrote: >> The crazy thing is that `malloc` is defined! That means all places where we use the term malloc are getting replaced without such a workaround. (E.g. for log tags.) > > So, we do this only for malloc? Not for calloc, posix_memalign, realloc etc? What about free? > > As ugly as defining malloc is (and I remember QADRT), I hesitate about removing that define. > > Removing that define and hard-coding it here assumes 1) our replacement is equivalent (ok, easy to check) 2) it will always be equivalent in future AIX versions 3) pointers it returns work with the unchanged free() and realloc() the system provides, and will always do so. > > I don't know... I would not do this just to get rid of a warning. This one is not just to get rid of a warning. We get real test errors because malloc gets replaced by vec_malloc in log tags. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1207308708 From jiangli at openjdk.org Fri May 26 20:39:57 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 26 May 2023 20:39:57 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v5] In-Reply-To: References: Message-ID: On Wed, 24 May 2023 21:02:00 GMT, Jiangli Zhou wrote: >> Original description for JDK-8307194 change: >> ----- >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: >> >> - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a >> >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk >> >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS >> ----- >> >> Updates to address build failures reported on macosx- platforms: >> >> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. >> >> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`. >> >> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Update make/common/NativeCompilation.gmk > > Thanks you! > > Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> `with `make TARGETS="arm-linux-gnueabihf" BASE_OS=Fedora BASE_OS_VERSION=17`, also tried with BASE_OS_VERSION=17` Fix typo: `also tried with BASE_OS_VERSION=18` ------------- PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1564919758 From darcy at openjdk.org Fri May 26 21:37:18 2023 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 26 May 2023 21:37:18 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v22] In-Reply-To: References: Message-ID: On Fri, 26 May 2023 13:22:59 GMT, Jim Laskey wrote: >> Add flexible main methods and anonymous main classes to the Java language. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove trailing whitespace In case I overlooked them, it would be good to have some core reflection tests of what a unnamed class looks like reflectively, basically a core reflection analogue to the draft javac/javax.lang.model test: https://github.com/openjdk/jdk/pull/14140/files#diff-106fc5b2c4d391546c7fa8a75e68fbd963733964f8f7ddf577606b5afda9b889 ------------- PR Comment: https://git.openjdk.org/jdk/pull/13689#issuecomment-1564983686 From prr at openjdk.org Fri May 26 21:52:56 2023 From: prr at openjdk.org (Phil Race) Date: Fri, 26 May 2023 21:52:56 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v7] In-Reply-To: References: Message-ID: On Thu, 25 May 2023 16:29:39 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > rework token storage macos builds are broken with this change. The problem is unix/classes/sun/awt/screencast, causing unix/classes/sun/awt/X11 to be built but it fails because we don't (and shouldn't) generate the XAWT source on macOS. You need to add screencast to the exclude list for macOS. git diff make/modules/java.desktop/Java.gmk diff --git a/make/modules/java.desktop/Java.gmk b/make/modules/java.desktop/Java.gmk index 19cd5b7da83..c9057c09c7f 100644 --- a/make/modules/java.desktop/Java.gmk +++ b/make/modules/java.desktop/Java.gmk @@ -68,6 +68,7 @@ EXCLUDE_FILES += \ ifeq ($(call isTargetOs, macosx), true) # exclude all X11 on Mac. EXCLUDES += \ + sun/awt/screencast \ sun/awt/X11 \ sun/java2d/x11 \ sun/java2d/jules \ ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1564995771 From azvegint at openjdk.org Sat May 27 01:25:40 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Sat, 27 May 2023 01:25:40 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v8] In-Reply-To: References: Message-ID: > Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. > This comes with some difficulties, and one of them is the inability to get screenshots from the system. > This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) > > But this functionality is a very important part of automated testing. > > > At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): > > 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) > It has several drawbacks though: > + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). > + There is no way to disable the visual "screen flash" after screenshot > + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. > Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. > But we still can consider this option as a fallback. > > > > 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) > It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. > This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. > > + implementation is more complicated comparing to Screenshot API > + no intermediate file, screenshot data can be obtained from memory > + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) > > > So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. > > This change also introduces some new behavior for the robot: > A system window now appears asking for confirmation from the user to capture the screen. > + The user can refuse the screen capture completely. In this case a security exception will be thrown. > + The user can allow a screen capture for all screens o... Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: fix macos build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13803/files - new: https://git.openjdk.org/jdk/pull/13803/files/1bd099cd..257445f4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=06-07 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13803.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13803/head:pull/13803 PR: https://git.openjdk.org/jdk/pull/13803 From azvegint at openjdk.org Sat May 27 01:25:42 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Sat, 27 May 2023 01:25:42 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v7] In-Reply-To: References: Message-ID: On Fri, 26 May 2023 21:50:15 GMT, Phil Race wrote: > macos builds are broken with this change. The problem is unix/classes/sun/awt/screencast, causing unix/classes/sun/awt/X11 to be built but it fails because we don't (and shouldn't) generate the XAWT source on macOS. > > You need to add screencast to the exclude list for macOS. Nice catch, fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1565133825 From stuefe at openjdk.org Sat May 27 11:28:54 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 27 May 2023 11:28:54 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: Message-ID: <_XilBe6ie0uDMER4oIjzTgKa2uMbjs-OjJGMH5exY-g=.78341a5f-d44a-49a4-ad82-0d3be2f2ffd3@github.com> On Fri, 26 May 2023 20:27:12 GMT, Martin Doerr wrote: > This one is not just to get rid of a warning. We get real test errors because malloc gets replaced by vec_malloc in log tags. That does not invalidate my argument, nor does it answer my question. Those test errors could be also fixed by renaming the log tag. Maybe that would be the better way. Also, I'm curious, why does it not complain about "free", which is a logtag as well? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1207892378 From stuefe at openjdk.org Sat May 27 11:52:55 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 27 May 2023 11:52:55 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: <_XilBe6ie0uDMER4oIjzTgKa2uMbjs-OjJGMH5exY-g=.78341a5f-d44a-49a4-ad82-0d3be2f2ffd3@github.com> References: <_XilBe6ie0uDMER4oIjzTgKa2uMbjs-OjJGMH5exY-g=.78341a5f-d44a-49a4-ad82-0d3be2f2ffd3@github.com> Message-ID: On Sat, 27 May 2023 11:25:41 GMT, Thomas Stuefe wrote: >> This one is not just to get rid of a warning. We get real test errors because malloc gets replaced by vec_malloc in log tags. > >> This one is not just to get rid of a warning. We get real test errors because malloc gets replaced by vec_malloc in log tags. > > That does not invalidate my argument, nor does it answer my question. Those test errors could be also fixed by renaming the log tag. Maybe that would be the better way. > > Also, I'm curious, why does it not complain about "free", which is a logtag as well? I am basically worried that undefining malloc, even if it seems harmless now, exposes us to difficult-to-investigate problems down the road, since it depends on how the libc devs will reform those macros in the future. I would prefer a simple solution that does not depend on how the libc includes evolve. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1207907447 From kbarrett at openjdk.org Sat May 27 15:36:55 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 27 May 2023 15:36:55 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: <_XilBe6ie0uDMER4oIjzTgKa2uMbjs-OjJGMH5exY-g=.78341a5f-d44a-49a4-ad82-0d3be2f2ffd3@github.com> Message-ID: On Sat, 27 May 2023 11:50:11 GMT, Thomas Stuefe wrote: >>> This one is not just to get rid of a warning. We get real test errors because malloc gets replaced by vec_malloc in log tags. >> >> That does not invalidate my argument, nor does it answer my question. Those test errors could be also fixed by renaming the log tag. Maybe that would be the better way. >> >> Also, I'm curious, why does it not complain about "free", which is a logtag as well? > > I am basically worried that undefining malloc, even if it seems harmless now, exposes us to difficult-to-investigate problems down the road, since it depends on how the libc devs will reform those macros in the future. I would prefer a simple solution that does not depend on how the libc includes evolve. Is it possible to see the stdlib.h source code that is being a problem? Maybe more eyes can come up with a better solution, or at least come to a better understanding of why we have to go this way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1208039639 From dholmes at openjdk.org Mon May 29 02:17:59 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 29 May 2023 02:17:59 GMT Subject: RFR: 8308341: JNI_GetCreatedJavaVMs returns a partially initialized JVM In-Reply-To: References: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> Message-ID: On Fri, 26 May 2023 17:50:58 GMT, Gerard Ziemski wrote: > I have one question though: why wouldn't it be enough to move `vm_created = 1` from where we had it before, down to where we now have `vm_created = COMPLETE` ? Because we need to prevent two threads from concurrently loading and initializing a VM in the same process. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14139#issuecomment-1566396959 From dholmes at openjdk.org Mon May 29 02:23:55 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 29 May 2023 02:23:55 GMT Subject: RFR: 8308341: JNI_GetCreatedJavaVMs returns a partially initialized JVM In-Reply-To: References: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> Message-ID: On Fri, 26 May 2023 08:41:40 GMT, Johan Sj?len wrote: >> We now track the in-progress and completed states of VM creation and only return a VM from JNI_GetCreatedJavaVMs when there is a fully initialized VM. >> >> Testing: >> - new regression test >> - tiers 1-3 (sanity) >> >> Thanks > > Thank you for this patch, everything looks good to me )including the build changes). Thanks for the review @jdksjolen ------------- PR Comment: https://git.openjdk.org/jdk/pull/14139#issuecomment-1566402651 From dholmes at openjdk.org Mon May 29 02:23:58 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 29 May 2023 02:23:58 GMT Subject: RFR: 8308341: JNI_GetCreatedJavaVMs returns a partially initialized JVM In-Reply-To: References: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> Message-ID: On Fri, 26 May 2023 18:01:51 GMT, Gerard Ziemski wrote: >> We now track the in-progress and completed states of VM creation and only return a VM from JNI_GetCreatedJavaVMs when there is a fully initialized VM. >> >> Testing: >> - new regression test >> - tiers 1-3 (sanity) >> >> Thanks > > test/hotspot/jtreg/runtime/jni/getCreatedJavaVMs/TestGetCreatedJavaVMs.java line 27: > >> 25: * @test >> 26: * @library /test/lib >> 27: * @requires os.family == "Linux" > > Why is it Linux only? > > Does `ProcessTools.createNativeTestProcessBuilder("GetCreatedJavaVMs");` only work on Linux? > > Filed https://bugs.openjdk.org/browse/CODETOOLS-7903477 to have it implemented on macOS. It was Linux only primarily because I copied another test. It should work on any platform that uses pthreads - so not Windows. I can expand the makefile logic to build the test code on all platforms. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14139#discussion_r1208772314 From dholmes at openjdk.org Mon May 29 03:13:30 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 29 May 2023 03:13:30 GMT Subject: RFR: 8308341: JNI_GetCreatedJavaVMs returns a partially initialized JVM [v2] In-Reply-To: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> References: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> Message-ID: > We now track the in-progress and completed states of VM creation and only return a VM from JNI_GetCreatedJavaVMs when there is a fully initialized VM. > > Testing: > - new regression test > - tiers 1-3 (sanity) > > Thanks David Holmes has updated the pull request incrementally with one additional commit since the last revision: Enable the test on all Posix platforms ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14139/files - new: https://git.openjdk.org/jdk/pull/14139/files/8f6aa1f7..2bf95d8c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14139&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14139&range=00-01 Stats: 6 lines in 2 files changed: 1 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14139.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14139/head:pull/14139 PR: https://git.openjdk.org/jdk/pull/14139 From dholmes at openjdk.org Mon May 29 03:13:30 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 29 May 2023 03:13:30 GMT Subject: RFR: 8308341: JNI_GetCreatedJavaVMs returns a partially initialized JVM [v2] In-Reply-To: References: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> Message-ID: On Fri, 26 May 2023 17:50:58 GMT, Gerard Ziemski wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Enable the test on all Posix platforms > > Looks fine to me. > > I have one question though: why wouldn't it be enough to move `vm_created = 1` from where we had it before, down to where we now have `vm_created = COMPLETE` ? > > I'm not 100% sure why we need the intermediate step `IN_PROGRESS` Thanks for looking at this @gerard-ziemski . The test now runs on all non-Windows platforms. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14139#issuecomment-1566437051 From lkorinth at openjdk.org Mon May 29 13:22:25 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 29 May 2023 13:22:25 GMT Subject: RFR: 8309048: Remove malloc locker test case Message-ID: There is a bunch of tests that are used to test critical section/gc locker. One of the test is named malloc. In that test, JNI code is doing a loop of `malloc()` followed `sleep()` followed by a `free()`. There is no JVM lock implementation to be tested on malloc/free. Let us save test time, code complexity and confusion by removing this test. (Oracle) hs-tier5 testing passed on x86-64. ------------- Commit messages: - 8309048: Remove malloc locker test case Changes: https://git.openjdk.org/jdk/pull/14201/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14201&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309048 Stats: 241 lines in 9 files changed: 0 ins; 240 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14201.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14201/head:pull/14201 PR: https://git.openjdk.org/jdk/pull/14201 From ehelin at openjdk.org Mon May 29 13:29:01 2023 From: ehelin at openjdk.org (Erik Helin) Date: Mon, 29 May 2023 13:29:01 GMT Subject: RFR: 8308961: Automatically find configuration matching name of checked of branch Message-ID: Hi all, please review this smaller patch to the build system. This patch changes what the build system will do when there are multiple configurations available and none has been selected (neither via `CONF` nor via `SPEC`). Instead of printing an error message (current behavior) the build system will instead check if the name of any configuration exactly matches the name of the checked out Git branch. If so, then that configuration will be built. The rationale for this change is that many developers (including me) use branches to work on multiple things concurrently. Having (at least) one configuration per branch, named after the branch, is a very natural model then for setting up one's build configurations. Having the build configuration corresponding to the checked out Git branch built automatically is then very convenient (instead of typing `make CONF=$(git branch --show-current)` every time). A couple of design considerations: - why use `$$(shell command -v git 2>/dev/null)` instead of `$$(GIT)` from autoconf? Because we don't have a `spec.gmk` available because we haven't chosen a configuration yet, so we don't have `$$(GIT)`. - why use `git rev-parse --abbrev-ref HEAD` instead of `git branch --show-current`? Because `git rev-parse --abbrev-ref` has been around since [2009](https://github.com/git/git/commit/a45d34691ea624e93863e95706eeb1b1909304f3) and `git branch --show-current` was introduced in Git 2.22 in 2019 (plus that `rev-parse --abbrev-ref` works with a detached `HEAD`). `git rev-parse --is-inside-work-tree` is from [2007](https://github.com/git/git/commit/892c41b98ae2e6baf3aa13901cb10db9ac67d2f3), but I think requiring a Git installation more recent than 2009 should be ok. - why match the branch name exactly instead of a looser matching? This could be beneficial if branches are named e.g. `$(git branch --show-current)-fastdebug`, but I wanted to start out with something strict and then the matching can be made looser if needed. - is this backwards compatible? Yes, at least I think so. Previously the build system would return an error but now it might build a configuration, that seems compatible. The patch does not interfere at all with the code paths where `CONF` or `SPEC` has been set. ### Testing - [x] Tested locally on macOS/aarch64 and Linux/x64 with and without configurations matching the named Git branch. - [x] Tested locally on macOS/aarch64 and Linux/x64 without a Git client. - [x] Tested locally on macOS/aarch64 and Linux/x64 with a source directory without a `.git` directory (i.e. not a repository). Thanks, Erik ------------- Commit messages: - Support builds without a repository - 8308961: Automatically find configuration matching name of checked of branch Changes: https://git.openjdk.org/jdk/pull/14202/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14202&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308961 Stats: 18 lines in 1 file changed: 14 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14202.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14202/head:pull/14202 PR: https://git.openjdk.org/jdk/pull/14202 From dholmes at openjdk.org Tue May 30 00:45:08 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 30 May 2023 00:45:08 GMT Subject: RFR: 8308961: Automatically find configuration matching name of checked of branch In-Reply-To: References: Message-ID: On Mon, 29 May 2023 13:21:27 GMT, Erik Helin wrote: > Hi all, > > please review this smaller patch to the build system. This patch changes what the build system will do when there are multiple configurations available and none has been selected (neither via `CONF` nor via `SPEC`). Instead of printing an error message (current behavior) the build system will instead check if the name of any configuration exactly matches the name of the checked out Git branch. If so, then that configuration will be built. > > The rationale for this change is that many developers (including me) use branches to work on multiple things concurrently. Having (at least) one configuration per branch, named after the branch, is a very natural model then for setting up one's build configurations. Having the build configuration corresponding to the checked out Git branch built automatically is then very convenient (instead of typing `make CONF=$(git branch --show-current)` every time). > > A couple of design considerations: > - why use `$$(shell command -v git 2>/dev/null)` instead of `$$(GIT)` from autoconf? Because we don't have a `spec.gmk` available because we haven't chosen a configuration yet, so we don't have `$$(GIT)`. > - why use `git rev-parse --abbrev-ref HEAD` instead of `git branch --show-current`? Because `git rev-parse --abbrev-ref` has been around since [2009](https://github.com/git/git/commit/a45d34691ea624e93863e95706eeb1b1909304f3) and `git branch --show-current` was introduced in Git 2.22 in 2019 (plus that `rev-parse --abbrev-ref` works with a detached `HEAD`). `git rev-parse --is-inside-work-tree` is from [2007](https://github.com/git/git/commit/892c41b98ae2e6baf3aa13901cb10db9ac67d2f3), but I think requiring a Git installation more recent than 2009 should be ok. > - why match the branch name exactly instead of a looser matching? This could be beneficial if branches are named e.g. `$(git branch --show-current)-fastdebug`, but I wanted to start out with something strict and then the matching can be made looser if needed. > - is this backwards compatible? Yes, at least I think so. Previously the build system would return an error but now it might build a configuration, that seems compatible. The patch does not interfere at all with the code paths where `CONF` or `SPEC` has been set. > > ### Testing > - [x] Tested locally on macOS/aarch64 and Linux/x64 with and without configurations matching the named Git branch. > - [x] Tested locally on macOS/aarch64 and Linux/x64 without a Git client. > - [x] Tested locally on macOS/aarch64 a... I'm not sure how useful this is in general as it very much depends on your own style of working. I use branch-based configurations as well but I use a wrapper script to manage that - in part because the wrapper will also run configure if no configuration currently exists. The main limitation I see with the proposal (and I may be misreading it) is that the exact name match seems to preclude working when your configurations have the form `mybranch` and `mybranch-debug` etc. make/InitSupport.gmk line 251: > 249: ifeq ($$(words $$(all_spec_files)), 1) > 250: # We found exactly one configuration, use it > 251: SPECS := $$(strip $$(all_spec_files)) It may be better to keep this as the first action and only do the git checks if necessary. That would minimise potential interference with single branch repos. ------------- PR Review: https://git.openjdk.org/jdk/pull/14202#pullrequestreview-1449929051 PR Review Comment: https://git.openjdk.org/jdk/pull/14202#discussion_r1209607563 From dholmes at openjdk.org Tue May 30 01:18:54 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 30 May 2023 01:18:54 GMT Subject: RFR: 8309048: Remove malloc locker test case In-Reply-To: References: Message-ID: On Mon, 29 May 2023 13:14:24 GMT, Leo Korinth wrote: > There is a bunch of tests that are used to test critical section/gc locker. One of the test is named malloc. In that test, JNI code is doing a loop of `malloc()` followed `sleep()` followed by a `free()`. There is no JVM lock implementation to be tested on malloc/free. Let us save test time, code complexity and confusion by removing this test. > > (Oracle) hs-tier5 testing passed on x86-64. Looks fine. I couldn't find anything explaining the history of this test. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14201#pullrequestreview-1449946999 From tschatzl at openjdk.org Tue May 30 09:20:56 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 30 May 2023 09:20:56 GMT Subject: RFR: 8309048: Remove malloc locker test case In-Reply-To: References: Message-ID: On Mon, 29 May 2023 13:14:24 GMT, Leo Korinth wrote: > There is a bunch of tests that are used to test critical section/gc locker. One of the test is named malloc. In that test, JNI code is doing a loop of `malloc()` followed `sleep()` followed by a `free()`. There is no JVM lock implementation to be tested on malloc/free. Let us save test time, code complexity and confusion by removing this test. > > (Oracle) hs-tier5 testing passed on x86-64. Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14201#pullrequestreview-1450495229 From ehelin at openjdk.org Tue May 30 13:38:39 2023 From: ehelin at openjdk.org (Erik Helin) Date: Tue, 30 May 2023 13:38:39 GMT Subject: RFR: 8308961: Automatically find configuration matching name of checked of branch [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this smaller patch to the build system. This patch changes what the build system will do when there are multiple configurations available and none has been selected (neither via `CONF` nor via `SPEC`). Instead of printing an error message (current behavior) the build system will instead check if the name of any configuration exactly matches the name of the checked out Git branch. If so, then that configuration will be built. > > The rationale for this change is that many developers (including me) use branches to work on multiple things concurrently. Having (at least) one configuration per branch, named after the branch, is a very natural model then for setting up one's build configurations. Having the build configuration corresponding to the checked out Git branch built automatically is then very convenient (instead of typing `make CONF=$(git branch --show-current)` every time). > > A couple of design considerations: > - why use `$$(shell command -v git 2>/dev/null)` instead of `$$(GIT)` from autoconf? Because we don't have a `spec.gmk` available because we haven't chosen a configuration yet, so we don't have `$$(GIT)`. > - why use `git rev-parse --abbrev-ref HEAD` instead of `git branch --show-current`? Because `git rev-parse --abbrev-ref` has been around since [2009](https://github.com/git/git/commit/a45d34691ea624e93863e95706eeb1b1909304f3) and `git branch --show-current` was introduced in Git 2.22 in 2019 (plus that `rev-parse --abbrev-ref` works with a detached `HEAD`). `git rev-parse --is-inside-work-tree` is from [2007](https://github.com/git/git/commit/892c41b98ae2e6baf3aa13901cb10db9ac67d2f3), but I think requiring a Git installation more recent than 2009 should be ok. > - why match the branch name exactly instead of a looser matching? This could be beneficial if branches are named e.g. `$(git branch --show-current)-fastdebug`, but I wanted to start out with something strict and then the matching can be made looser if needed. > - is this backwards compatible? Yes, at least I think so. Previously the build system would return an error but now it might build a configuration, that seems compatible. The patch does not interfere at all with the code paths where `CONF` or `SPEC` has been set. > > ### Testing > - [x] Tested locally on macOS/aarch64 and Linux/x64 with and without configurations matching the named Git branch. > - [x] Tested locally on macOS/aarch64 and Linux/x64 without a Git client. > - [x] Tested locally on macOS/aarch64 a... Erik Helin has updated the pull request incrementally with one additional commit since the last revision: Fuzzier matching ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14202/files - new: https://git.openjdk.org/jdk/pull/14202/files/b233d60f..db7c8b6a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14202&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14202&range=00-01 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/14202.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14202/head:pull/14202 PR: https://git.openjdk.org/jdk/pull/14202 From ehelin at openjdk.org Tue May 30 13:49:56 2023 From: ehelin at openjdk.org (Erik Helin) Date: Tue, 30 May 2023 13:49:56 GMT Subject: RFR: 8308961: Automatically find configuration matching name of checked of branch [v2] In-Reply-To: References: Message-ID: <-lthobZAAkDnx2dhGayVxodGRlFHi0Hi7pfTd0nNUVw=.e0a7f3eb-80c4-400b-8a69-768888efdeea@github.com> On Tue, 30 May 2023 00:38:50 GMT, David Holmes wrote: >> Erik Helin has updated the pull request incrementally with one additional commit since the last revision: >> >> Fuzzier matching > > make/InitSupport.gmk line 251: > >> 249: ifeq ($$(words $$(all_spec_files)), 1) >> 250: # We found exactly one configuration, use it >> 251: SPECS := $$(strip $$(all_spec_files)) > > It may be better to keep this as the first action and only do the git checks if necessary. That would minimise potential interference with single branch repos. That is a good idea, and I thought about it, but it is hard to structure the logic that way and not end up with duplicated code (early return doesn't seem to be a thing in GNU Make macros). What I means that the following is (at least to me) hard to express in a GNU Make macro: ifeq ($$(words $$(all_spec_files)), 1) # Somehow set SPECS and return, do not continue to execute endif GIT := ... ifneq ($$(GIT),) ... endif ... The two Git commands potentially being executed are `O(1)`, they do not scale with repository size and should have minimal overhead. Since both flags to `git rev-parse` being used have been around since 2009 I think the risk of encountering a Git installation where they do not exist or do not work is very low. The `rev-parse` command is a so called "plumbing" command in Git which means that the Git project considers the CLI interface an API and keep it backwards compatible (so we shouldn't run in to future Git releases renaming and/or removing these flags). I therefore think it is worth keeping the logic a bit nicer and instead run these two extra `git rev-parse` commands and one extra `command -v` invocation (sometimes a shell built-in) for the single branch repo case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14202#discussion_r1210301940 From gziemski at openjdk.org Tue May 30 14:41:59 2023 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 30 May 2023 14:41:59 GMT Subject: RFR: 8308341: JNI_GetCreatedJavaVMs returns a partially initialized JVM [v2] In-Reply-To: References: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> Message-ID: On Mon, 29 May 2023 02:15:05 GMT, David Holmes wrote: > > I have one question though: why wouldn't it be enough to move `vm_created = 1` from where we had it before, down to where we now have `vm_created = COMPLETE` ? > > Because we need to prevent two threads from concurrently loading and initializing a VM in the same process. Wouldn't it be less complex to use a lock or some "init once" mechanism (pthread_once) instead of a 3 stage atomic field? Do we really need to know whether the process is in the middle of initialization for any reason other than whether it's actually done? Just to clarify - I'm OK with the fix you have proposed, I was just curious if you considered any other alternatives. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14139#issuecomment-1568554708 From kbarrett at openjdk.org Tue May 30 14:42:59 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 30 May 2023 14:42:59 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: <_XilBe6ie0uDMER4oIjzTgKa2uMbjs-OjJGMH5exY-g=.78341a5f-d44a-49a4-ad82-0d3be2f2ffd3@github.com> Message-ID: On Sat, 27 May 2023 15:33:37 GMT, Kim Barrett wrote: >> I am basically worried that undefining malloc, even if it seems harmless now, exposes us to difficult-to-investigate problems down the road, since it depends on how the libc devs will reform those macros in the future. I would prefer a simple solution that does not depend on how the libc includes evolve. > > Is it possible to see the stdlib.h source code that is being a problem? Maybe more eyes can come up > with a better solution, or at least come to a better understanding of why we have to go this way. Technically it's our fault. The standard library is permitted to provide a macro replacements for (nearly?) any function. (C99 7.1.3/1 3rd bullet) But it's really annoying. Presumably AIX is only doing so for a subset of the allocation functions, e.g. not "free" for example. Having "malloc" defined as a macro seems like it should raise all kinds of havoc, not just around log tags. Consider our "os::malloc" function? The preprocessor knows nothing about C++ namespace qualifiers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1210388482 From ehelin at openjdk.org Tue May 30 15:00:55 2023 From: ehelin at openjdk.org (Erik Helin) Date: Tue, 30 May 2023 15:00:55 GMT Subject: RFR: 8308961: Automatically find configuration matching name of checked of branch [v2] In-Reply-To: References: Message-ID: On Tue, 30 May 2023 00:42:37 GMT, David Holmes wrote: > The main limitation I see with the proposal (and I may be misreading it) is that the exact name match seems to preclude working when your configurations have the form `mybranch` and `mybranch-debug` etc. Thanks @dholmes-ora for having a look! First, just to clarify, this change is fully backwards compatible. If you had more than one configuration before, you would have to select the one to build using either `CONF` or `SPEC`. With this change, if you have more than one configuration containing the name of the checked out Git branch, you still have to use `CONF` or `SPEC` (there is no way we can infer the one you want to build). I also name my configurations `$(git branch --show-current)-{release,fastdebug,slowdebug}`, although I only use a `-fastdebug` configuration to start out with. Your comment a make me reconsider what I wrote in the pull request description: > Why match the branch name exactly instead of a looser matching? This could be beneficial if branches are named e.g. $(git branch --show-current)-fastdebug, but I wanted to start out with something strict and then the matching can be made looser if needed. So I pushed a change (see [db7c8b6](https://gith.openjdk.org/jdk/pull/14202/commits/db7c8b6aa9e135783b38476a1f826c449a2153f8)) that uses a fuzzier matching. Now if there are multiple configurations and exactly one contains the current branch name, then it will be built. This allows you have to have a single `jdk-1234567-fastdebug` configuration and just build it by running `make`. I'm of course aware that I can use a script to achieve all of this - I've had one for years called `bake`, short for "branch make". However if many developers are structuring their concurrent work using branches, then I think we should add what support we can in upstream to make that workflow easier. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14202#issuecomment-1568589731 From gziemski at openjdk.org Tue May 30 15:02:02 2023 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 30 May 2023 15:02:02 GMT Subject: RFR: 8308341: JNI_GetCreatedJavaVMs returns a partially initialized JVM [v2] In-Reply-To: References: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> Message-ID: <-oKHOvbd-XTKm07mc9_gnwpqFWEwmeJQOBdovwEoyJU=.e1db80a4-a1e3-422f-aba2-1a6f313cd42b@github.com> On Mon, 29 May 2023 03:13:30 GMT, David Holmes wrote: >> We now track the in-progress and completed states of VM creation and only return a VM from JNI_GetCreatedJavaVMs when there is a fully initialized VM. >> >> Testing: >> - new regression test >> - tiers 1-3 (sanity) >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Enable the test on all Posix platforms Marked as reviewed by gziemski (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14139#pullrequestreview-1451174952 From xuelei at openjdk.org Tue May 30 17:30:58 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 30 May 2023 17:30:58 GMT Subject: RFR: 8308071: [REDO] update for deprecated sprintf for src/utils [v3] In-Reply-To: <24zfRJ2Ir1egB-U5XJd37qJZUliAqAXkKIaHqE8gG-8=.3e0fc1f7-5eae-4fc9-8135-42a40f917a1e@github.com> References: <0Yayi6b8NFU7LzVm-3KP8PgtsI-xkcOOzIMTEt6_vMI=.5fcad730-2f76-40eb-b6e4-2668729e1ba8@github.com> <-qvQkvH8SylX3unheSpOdsjz-mhrnyvqgxtNLKiOmGg=.41f065ea-f856-4436-88d3-8c7b8b01726d@github.com> <24zfRJ2Ir1egB-U5XJd37qJZUliAqAXkKIaHqE8gG-8=.3e0fc1f7-5eae-4fc9-8135-42a40f917a1e@github.com> Message-ID: On Thu, 18 May 2023 15:46:46 GMT, Kim Barrett wrote: >> Updated to use `int` to replace `size_t.`. Thank you for the catching. > > bufsize is size_t, so that's a comparison between signed and unsigned values, which I think some compilers > will warn about. Maybe the preceding check for negative is getting rid of that? But will that still occur in > a slowdebug build, or will the lack of optimization lead to a warning? @kimbarrett Did you have a chance to have another look? Please let me know if you prefer to the update that the returned value of snprintf() is not checked because the memory size has been checked previously. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13995#discussion_r1210598423 From kdnilsen at openjdk.org Tue May 30 17:54:18 2023 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 30 May 2023 17:54:18 GMT Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) Message-ID: OpenJDK Colleagues: Please review this proposed integration of Generational mode for Shenandoah GC under https://bugs.openjdk.org/browse/JDK-8307314. Generational mode of Shenandoah is enabled by adding `-XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a command line that already specifies ` -XX:+UseShenandoahGC`. The implementation automatically adjusts the sizes of old generation and young generation to efficiently utilize the entire heap capacity. Generational mode of Shenandoah resembles G1 in the following regards: 1. Old-generation marking runs concurrently during the time that multiple young generation collections run to completion. 2. After old-generation marking completes, we perform a sequence of mixed collections. Each mixed collection combines collection of young generation with evacuation of a portion of the old-generation regions identified for collection based on old-generation marking information. 3. Unlike G1, young-generation collections and evacuations are entirely concurrent, as with single-generation Shenandoah. 4. As with single-generation Shenandoah, there is no explicit notion of eden and survivor space within the young generation. In practice, regions that were most recently allocated tend to have large amounts of garbage and these regions tend to be collected with very little effort. Young-generation objects that survive garbage collection tend to accumulate in regions that hold survivor objects. These regions tend to have smaller amounts of garbage, and are less likely to be collected. If they survive a sufficient number of young-generation collections, the ?survivor? regions are promoted into the old generation. We expect to refine heuristics as we gain experience with more production workloads. In the future, we plan to remove the ?experimental? qualifier from generational mode, at which time we expect that generational mode will become the default mode for Shenandoah. **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, HyperAlloc, and multiple AWS production workload simulators. We test on Linux x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and Windows x64. ------------- Commit messages: - Revert changes to jcheck configuration - Remove early planning docs from PR - Merge remote-tracking branch 'shenandoah/master' into merge-generational-shenandoah - Expand old on demand - Merge openjdk/jdk:master - Make generational mode experimental - Merge openjdk/jdk:master - Improve mixed collection logging - Use soft max capacity only for trigger calculations - Use static assert to validate card offset encoding mask - ... and 281 more: https://git.openjdk.org/jdk/compare/ce5251af...aa85a907 Changes: https://git.openjdk.org/jdk/pull/14185/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307314 Stats: 20150 lines in 205 files changed: 18237 ins; 904 del; 1009 mod Patch: https://git.openjdk.org/jdk/pull/14185.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14185/head:pull/14185 PR: https://git.openjdk.org/jdk/pull/14185 From darcy at openjdk.org Tue May 30 18:35:44 2023 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 30 May 2023 18:35:44 GMT Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v2] In-Reply-To: References: Message-ID: > Time to get JDK 22 underway... Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: - Merge branch 'master' into JDK-8306584 - Merge branch 'master' into JDK-8306584 - Sync in symbol changes for JDK 21 build 24. - Merge branch 'master' into JDK-8306584 - Merge branch 'master' into JDK-8306584 - Merge branch 'master' into JDK-8306584 - Minor test fixes. - Merge branch 'master' into JDK-8306584 - Update symbol files to JDK 21 b23. - Merge branch 'JDK-8306584' of https://github.com/jddarcy/jdk into JDK-8306584 - ... and 13 more: https://git.openjdk.org/jdk/compare/1b8e6bf3...c7682791 ------------- Changes: https://git.openjdk.org/jdk/pull/13567/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13567&range=01 Stats: 5829 lines in 69 files changed: 5775 ins; 0 del; 54 mod Patch: https://git.openjdk.org/jdk/pull/13567.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13567/head:pull/13567 PR: https://git.openjdk.org/jdk/pull/13567 From coleenp at openjdk.org Tue May 30 18:45:57 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 30 May 2023 18:45:57 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: Message-ID: <-J0qbu5Ym0zr1WgUHHd2xw4qAwCsXrusMtlVCIH4snk=.d6571950-4708-430d-b119-150728407390@github.com> On Fri, 26 May 2023 08:31:46 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Some of those are in shared codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > > JoKern65 has updated the pull request incrementally with one additional commit since the last revision: > > forgotton _ src/hotspot/share/runtime/javaThread.cpp line 115: > 113: #include > 114: #endif > 115: Could these conditionals be included in globalDefinitions_xlc.hpp instead? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1210684136 From coleenp at openjdk.org Tue May 30 19:06:54 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 30 May 2023 19:06:54 GMT Subject: RFR: 8309048: Remove malloc locker test case In-Reply-To: References: Message-ID: <7Z_jlhWc1MUfTir_0px1NbOE2EqKghADMGMo9ML2DLo=.9dd204f2-8876-4057-bc0a-6e5c65d261f1@github.com> On Mon, 29 May 2023 13:14:24 GMT, Leo Korinth wrote: > There is a bunch of tests that are used to test critical section/gc locker. One of the test is named malloc. In that test, JNI code is doing a loop of `malloc()` followed `sleep()` followed by a `free()`. There is no JVM lock implementation to be tested on malloc/free. Let us save test time, code complexity and confusion by removing this test. > > (Oracle) hs-tier5 testing passed on x86-64. This looks like a nice cleanup. I think we should migrate these tests into the tests/hotspot/gc directory and reconcile duplicates with other tests that do the same thing. This could be a future RFE/improvement. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14201#pullrequestreview-1451637547 From tony at rivosinc.com Tue May 30 19:45:40 2023 From: tony at rivosinc.com (Tony Printezis) Date: Tue, 30 May 2023 15:45:40 -0400 Subject: RFR: 8308969: make test-prebuilt doesn't return the correct exit code In-Reply-To: References: Message-ID: Hi, Could someone with more makefile experience than me give me some feedback on this change? Thank you! Tony > On May 26, 2023, at 12:15 PM, Antonios Printezis wrote: > > For 'make' test and 'make test-only' the existence of exit-with-error is checked in the main target in Init.gmk. Is there a better way to fix this than to check for the existence of exit-with-error in RunTestsPrebuilt.gmk? > > ------------- > > Commit messages: > - 8308969: make test-prebuilt doesn't return the correct exit code > > Changes: https://git.openjdk.org/jdk/pull/14183/files > Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14183&range=00 > Issue: https://bugs.openjdk.org/browse/JDK-8308969 > Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod > Patch: https://git.openjdk.org/jdk/pull/14183.diff > Fetch: git fetch https://git.openjdk.org/jdk.git pull/14183/head:pull/14183 > > PR: https://git.openjdk.org/jdk/pull/14183 From darcy at openjdk.org Tue May 30 20:17:57 2023 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 30 May 2023 20:17:57 GMT Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v2] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 20:49:43 GMT, Joe Darcy wrote: >> test/langtools/tools/javac/versions/Versions.java line 93: >> >>> 91: TWENTY(false, "64.0", "20", Versions::checksrc20), >>> 92: TWENTY_ONE(false,"65.0", "21", Versions::checksrc20), >>> 93: TWENTY_TWO(false,"66.0", "22", Versions::checksrc20); >> >> when do these get updated? > > Ah, when new non-preview language structures are added. With two new language features in JDK 21, looks like it is time for me to add another one; thanks. Better to fix this omission in JDK 21; please see https://github.com/openjdk/jdk/pull/14229. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1210778891 From prr at openjdk.org Tue May 30 20:43:06 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 30 May 2023 20:43:06 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v8] In-Reply-To: References: Message-ID: On Sat, 27 May 2023 01:25:40 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > fix macos build src/java.desktop/share/classes/java/awt/peer/RobotPeer.java line 130: > 128: return false; > 129: } > 130: The only change to this file is adding a blank line. Please revert. src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java line 139: > 137: > 138: for (TokenItem tokenItem : tokensForRectangle) { > 139: retVal = getRGBPixelsImpl( This can't be right. You surely want to check all cases of retVal not just the last one. src/java.desktop/unix/classes/sun/awt/screencast/TokenItem.java line 88: > 86: > 87: public boolean hasValidBounds() { > 88: //This check is very formal, in order to filter out abnormal values very "rough" ? src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 62: > 60: private static final String REL_NAME = > 61: ".java/.robot/screencast-tokens.properties"; > 62: .java is already hidden. Why make .robot hidden ? src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 66: > 64: private static final Path PROPS_PATH; > 65: private static final Path PROP_FILENAME; > 66: private static final Object PROPS_LOCK = new Object(); Why do you need PROPS_LOCK to synchronize access to PROPS ? I don't see why you can't synchronize on PROPS directly ? src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 150: > 148: } > 149: > 150: private static class WatcherThread extends Thread { What is all this for ? Reading and writing a file doesn't need all this. src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 387: > 385: } > 386: > 387: try (OutputStream output = Files.newOutputStream(PROPS_PATH)) { Note that this stream is un-buffered (slow) https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Files.html#newOutputStream(java.nio.file.Path,java.nio.file.OpenOption...) Maybe doesn't matter given how small the file is. src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 43: > 41: > 42: #define EXCEPTION_CHECK_DESCRIBE_CLEAR() if ((*env)->ExceptionCheck(env)) { \ > 43: (*env)->ExceptionDescribe(env); \ Describe already clears the exception https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#exceptiondescribe src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 375: > 373: DEBUG_SCREENCAST("@@@ using screen %i\n", index); > 374: if (index >= screenSpace.screenCount) { > 375: DEBUG_SCREENCAST("? Wrong index for screen\n", NULL); I've seen this "! in a triangle" symbol in a quite a few places in the DEBUG messages. Looks like you got some non-ascii char in there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1210736642 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1210738114 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1210735716 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1210744585 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1210754519 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1210749175 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1210767223 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1210788290 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1210799141 From iris at openjdk.org Tue May 30 21:25:01 2023 From: iris at openjdk.org (Iris Clark) Date: Tue, 30 May 2023 21:25:01 GMT Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v2] In-Reply-To: References: Message-ID: On Tue, 30 May 2023 18:35:44 GMT, Joe Darcy wrote: >> Time to get JDK 22 underway... > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: > > - Merge branch 'master' into JDK-8306584 > - Merge branch 'master' into JDK-8306584 > - Sync in symbol changes for JDK 21 build 24. > - Merge branch 'master' into JDK-8306584 > - Merge branch 'master' into JDK-8306584 > - Merge branch 'master' into JDK-8306584 > - Minor test fixes. > - Merge branch 'master' into JDK-8306584 > - Update symbol files to JDK 21 b23. > - Merge branch 'JDK-8306584' of https://github.com/jddarcy/jdk into JDK-8306584 > - ... and 13 more: https://git.openjdk.org/jdk/compare/1b8e6bf3...c7682791 Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13567#pullrequestreview-1451837705 From duke at openjdk.org Tue May 30 21:46:59 2023 From: duke at openjdk.org (JoKern65) Date: Tue, 30 May 2023 21:46:59 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: <-J0qbu5Ym0zr1WgUHHd2xw4qAwCsXrusMtlVCIH4snk=.d6571950-4708-430d-b119-150728407390@github.com> References: <-J0qbu5Ym0zr1WgUHHd2xw4qAwCsXrusMtlVCIH4snk=.d6571950-4708-430d-b119-150728407390@github.com> Message-ID: On Tue, 30 May 2023 18:42:54 GMT, Coleen Phillimore wrote: >> JoKern65 has updated the pull request incrementally with one additional commit since the last revision: >> >> forgotton _ > > src/hotspot/share/runtime/javaThread.cpp line 115: > >> 113: #include >> 114: #endif >> 115: > > Could these conditionals be included in globalDefinitions_xlc.hpp instead? In principle the `#include ` could be included in globalDefinitions_xlc.hpp. But alloca.h implements it with a `#undef alloca` `#define alloca(size) __builtin_alloca (size)` If this new global define does not introduce new trouble (even in future coding) when it is seen in every source, we can go this way. Are there any obstacles from anyone else? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1210853233 From darcy at openjdk.org Tue May 30 22:16:08 2023 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 30 May 2023 22:16:08 GMT Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v3] In-Reply-To: References: Message-ID: > Time to get JDK 22 underway... Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: - Merge branch 'master' into JDK-8306584 - Merge branch 'master' into JDK-8306584 - Merge branch 'master' into JDK-8306584 - Sync in symbol changes for JDK 21 build 24. - Merge branch 'master' into JDK-8306584 - Merge branch 'master' into JDK-8306584 - Merge branch 'master' into JDK-8306584 - Minor test fixes. - Merge branch 'master' into JDK-8306584 - Update symbol files to JDK 21 b23. - ... and 14 more: https://git.openjdk.org/jdk/compare/cb40db05...376dbe26 ------------- Changes: https://git.openjdk.org/jdk/pull/13567/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13567&range=02 Stats: 5828 lines in 69 files changed: 5775 ins; 0 del; 53 mod Patch: https://git.openjdk.org/jdk/pull/13567.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13567/head:pull/13567 PR: https://git.openjdk.org/jdk/pull/13567 From darcy at openjdk.org Tue May 30 22:16:09 2023 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 30 May 2023 22:16:09 GMT Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v3] In-Reply-To: References: Message-ID: <3jywj8fLCqTlr-mps0rsYBXgb4jhxQaDFNCcgXLpSUQ=.e0a59fa0-5307-4d4c-8b5e-87c9e4d42d74@github.com> On Tue, 30 May 2023 20:14:59 GMT, Joe Darcy wrote: >> Ah, when new non-preview language structures are added. With two new language features in JDK 21, looks like it is time for me to add another one; thanks. > > Better to fix this omission in JDK 21; please see https://github.com/openjdk/jdk/pull/14229. > Better to fix this omission in JDK 21; please see #14229. Addressed by merge of JDK-8309134 into JDK 22; thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1210875483 From dholmes at openjdk.org Tue May 30 22:43:55 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 30 May 2023 22:43:55 GMT Subject: RFR: 8308341: JNI_GetCreatedJavaVMs returns a partially initialized JVM [v2] In-Reply-To: References: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> Message-ID: On Tue, 30 May 2023 14:39:21 GMT, Gerard Ziemski wrote: >>> I have one question though: why wouldn't it be enough to move `vm_created = 1` from where we had it before, down to where we now have `vm_created = COMPLETE` ? >> >> Because we need to prevent two threads from concurrently loading and initializing a VM in the same process. > >> > I have one question though: why wouldn't it be enough to move `vm_created = 1` from where we had it before, down to where we now have `vm_created = COMPLETE` ? >> >> Because we need to prevent two threads from concurrently loading and initializing a VM in the same process. > > Wouldn't it be less complex to use a lock or some "init once" mechanism (pthread_once) instead of a 3 stage atomic field? Do we really need to know whether the process is in the middle of initialization for any reason other than whether it's actually done? > > Just to clarify - I'm OK with the fix you have proposed, I was just curious if you considered any other alternatives. Thanks for the review @gerard-ziemski > Just to clarify - I'm OK with the fix you have proposed, I was just curious if you considered any other alternatives. Atomics are the simplest cross-platform solution available at this stage of VM init (which is "nothing is initialized yet") - even Atomic use is limited to Atomic::xchg as we can't require any stubs. We have no VM locks available and anything external to the VM (like pthread_once) would require as OS-specific solution in shared code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14139#issuecomment-1569223117 From dholmes at openjdk.org Tue May 30 22:50:14 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 30 May 2023 22:50:14 GMT Subject: RFR: 8308341: JNI_GetCreatedJavaVMs returns a partially initialized JVM [v2] In-Reply-To: References: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> Message-ID: On Mon, 29 May 2023 03:13:30 GMT, David Holmes wrote: >> We now track the in-progress and completed states of VM creation and only return a VM from JNI_GetCreatedJavaVMs when there is a fully initialized VM. >> >> Testing: >> - new regression test >> - tiers 1-3 (sanity) >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Enable the test on all Posix platforms I'm aware from https://github.com/openjdk/jdk/pull/14209 that this new test will fail on AIX but as it will need the same fix as being discussed there I'd rather patch it once we know we have a cross-platform solution. I will file a follow up bug for that (unless we can fix it in #14209.) Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14139#issuecomment-1569229733 From dholmes at openjdk.org Tue May 30 22:50:16 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 30 May 2023 22:50:16 GMT Subject: Integrated: 8308341: JNI_GetCreatedJavaVMs returns a partially initialized JVM In-Reply-To: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> References: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> Message-ID: On Thu, 25 May 2023 05:02:19 GMT, David Holmes wrote: > We now track the in-progress and completed states of VM creation and only return a VM from JNI_GetCreatedJavaVMs when there is a fully initialized VM. > > Testing: > - new regression test > - tiers 1-3 (sanity) > > Thanks This pull request has now been integrated. Changeset: 1e6770fb Author: David Holmes URL: https://git.openjdk.org/jdk/commit/1e6770fb978e630b38a70a05120c50f723bb66dc Stats: 178 lines in 4 files changed: 163 ins; 2 del; 13 mod 8308341: JNI_GetCreatedJavaVMs returns a partially initialized JVM Reviewed-by: jsjolen, gziemski ------------- PR: https://git.openjdk.org/jdk/pull/14139 From lmesnik at openjdk.org Wed May 31 05:33:55 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 31 May 2023 05:33:55 GMT Subject: RFR: 8309048: Remove malloc locker test case In-Reply-To: References: Message-ID: On Mon, 29 May 2023 13:14:24 GMT, Leo Korinth wrote: > There is a bunch of tests that are used to test critical section/gc locker. One of the test is named malloc. In that test, JNI code is doing a loop of `malloc()` followed `sleep()` followed by a `free()`. There is no JVM lock implementation to be tested on malloc/free. Let us save test time, code complexity and confusion by removing this test. > > (Oracle) hs-tier5 testing passed on x86-64. Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14201#pullrequestreview-1452234684 From dholmes at openjdk.org Wed May 31 08:06:00 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 31 May 2023 08:06:00 GMT Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v3] In-Reply-To: References: Message-ID: On Tue, 30 May 2023 22:16:08 GMT, Joe Darcy wrote: >> Time to get JDK 22 underway... > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: > > - Merge branch 'master' into JDK-8306584 > - Merge branch 'master' into JDK-8306584 > - Merge branch 'master' into JDK-8306584 > - Sync in symbol changes for JDK 21 build 24. > - Merge branch 'master' into JDK-8306584 > - Merge branch 'master' into JDK-8306584 > - Merge branch 'master' into JDK-8306584 > - Minor test fixes. > - Merge branch 'master' into JDK-8306584 > - Update symbol files to JDK 21 b23. > - ... and 14 more: https://git.openjdk.org/jdk/compare/cb40db05...376dbe26 Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13567#pullrequestreview-1452455740 From duke at openjdk.org Wed May 31 08:21:57 2023 From: duke at openjdk.org (JoKern65) Date: Wed, 31 May 2023 08:21:57 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: <-J0qbu5Ym0zr1WgUHHd2xw4qAwCsXrusMtlVCIH4snk=.d6571950-4708-430d-b119-150728407390@github.com> Message-ID: On Tue, 30 May 2023 21:44:17 GMT, JoKern65 wrote: >> src/hotspot/share/runtime/javaThread.cpp line 115: >> >>> 113: #include >>> 114: #endif >>> 115: >> >> Could these conditionals be included in globalDefinitions_xlc.hpp instead? > > In principle the `#include ` could be included in globalDefinitions_xlc.hpp. But alloca.h implements it with a > `#undef alloca` > `#define alloca(size) __builtin_alloca (size)` > If this new global define does not introduce new trouble (even in future coding) when it is seen in every source, we can go this way. > Are there any obstacles from anyone else? At least the whole jdk actually builds with `#include ` in globalDefinitions_xlc.hpp ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1211272616 From lkorinth at openjdk.org Wed May 31 08:59:11 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 31 May 2023 08:59:11 GMT Subject: RFR: 8309048: Remove malloc locker test case In-Reply-To: References: Message-ID: On Mon, 29 May 2023 13:14:24 GMT, Leo Korinth wrote: > There is a bunch of tests that are used to test critical section/gc locker. One of the test is named malloc. In that test, JNI code is doing a loop of `malloc()` followed `sleep()` followed by a `free()`. There is no JVM lock implementation to be tested on malloc/free. Let us save test time, code complexity and confusion by removing this test. > > (Oracle) hs-tier5 testing passed on x86-64. Thanks David, Thomas, Coleen and Leonid! I am looking into further cleanups... ------------- PR Comment: https://git.openjdk.org/jdk/pull/14201#issuecomment-1569773788 From lkorinth at openjdk.org Wed May 31 08:59:12 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 31 May 2023 08:59:12 GMT Subject: Integrated: 8309048: Remove malloc locker test case In-Reply-To: References: Message-ID: On Mon, 29 May 2023 13:14:24 GMT, Leo Korinth wrote: > There is a bunch of tests that are used to test critical section/gc locker. One of the test is named malloc. In that test, JNI code is doing a loop of `malloc()` followed `sleep()` followed by a `free()`. There is no JVM lock implementation to be tested on malloc/free. Let us save test time, code complexity and confusion by removing this test. > > (Oracle) hs-tier5 testing passed on x86-64. This pull request has now been integrated. Changeset: 88236263 Author: Leo Korinth URL: https://git.openjdk.org/jdk/commit/88236263dcea96dd0cb33c15367ce6e755a949e9 Stats: 241 lines in 9 files changed: 0 ins; 240 del; 1 mod 8309048: Remove malloc locker test case Reviewed-by: dholmes, tschatzl, coleenp, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/14201 From jlaskey at openjdk.org Wed May 31 12:57:28 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 31 May 2023 12:57:28 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v23] In-Reply-To: References: Message-ID: > Add flexible main methods and anonymous main classes to the Java language. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Remove mandated flag ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13689/files - new: https://git.openjdk.org/jdk/pull/13689/files/06aa43ec..a8b31010 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=21-22 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689 PR: https://git.openjdk.org/jdk/pull/13689 From jlaskey at openjdk.org Wed May 31 13:01:47 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 31 May 2023 13:01:47 GMT Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview) [v24] In-Reply-To: References: Message-ID: > Add flexible main methods and anonymous main classes to the Java language. Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: - Merge branch 'master' into 8306112 - Remove mandated flag - Remove trailing whitespace - Add main tests for inferface/enum/record - Improving error recovery in presence of less important syntactic errors in top-level methods and fields. Author: Jan Lahoda - Ignore SKIPs (semicolon class declarations) - Allow unqualified access to unnamed class (internally visible) - Fix missing constructor error messages and handle inner class launching - Merge branch 'master' into 8306112 - Issue warning if traditional main not used. - ... and 30 more: https://git.openjdk.org/jdk/compare/4aea7dab...d0189fc2 ------------- Changes: https://git.openjdk.org/jdk/pull/13689/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=23 Stats: 1299 lines in 31 files changed: 1134 ins; 32 del; 133 mod Patch: https://git.openjdk.org/jdk/pull/13689.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689 PR: https://git.openjdk.org/jdk/pull/13689 From azvegint at openjdk.org Wed May 31 15:03:04 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 31 May 2023 15:03:04 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v9] In-Reply-To: References: Message-ID: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> > Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. > This comes with some difficulties, and one of them is the inability to get screenshots from the system. > This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) > > But this functionality is a very important part of automated testing. > > > At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): > > 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) > It has several drawbacks though: > + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). > + There is no way to disable the visual "screen flash" after screenshot > + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. > Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. > But we still can consider this option as a fallback. > > > > 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) > It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. > This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. > > + implementation is more complicated comparing to Screenshot API > + no intermediate file, screenshot data can be obtained from memory > + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) > > > So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. > > This change also introduces some new behavior for the robot: > A system window now appears asking for confirmation from the user to capture the screen. > + The user can refuse the screen capture completely. In this case a security exception will be thrown. > + The user can allow a screen capture for all screens o... Alexander Zvegintsev has updated the pull request incrementally with four additional commits since the last revision: - improve retVal processing - address token storage comments - removing non-ascii - EXCEPTION_CHECK_DESCRIBE_CLEAR -> EXCEPTION_CHECK_DESCRIBE ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13803/files - new: https://git.openjdk.org/jdk/pull/13803/files/257445f4..389cfd73 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=07-08 Stats: 107 lines in 7 files changed: 23 ins; 13 del; 71 mod Patch: https://git.openjdk.org/jdk/pull/13803.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13803/head:pull/13803 PR: https://git.openjdk.org/jdk/pull/13803 From azvegint at openjdk.org Wed May 31 15:06:04 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 31 May 2023 15:06:04 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v8] In-Reply-To: References: Message-ID: On Tue, 30 May 2023 19:33:20 GMT, Phil Race wrote: >> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: >> >> fix macos build > > src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java line 139: > >> 137: >> 138: for (TokenItem tokenItem : tokensForRectangle) { >> 139: retVal = getRGBPixelsImpl( > > This can't be right. You surely want to check all cases of retVal not just the last one. Updated. > src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 62: > >> 60: private static final String REL_NAME = >> 61: ".java/.robot/screencast-tokens.properties"; >> 62: > > .java is already hidden. Why make .robot hidden ? Updated. > src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 150: > >> 148: } >> 149: >> 150: private static class WatcherThread extends Thread { > > What is all this for ? Reading and writing a file doesn't need all this. This is to work from multiple VM with the file. We only read the file the first time we use `createScreenCapture` and when another VM externally modifies the file. Alternatively we could read it before each use of `createScreenCapture`, but I wanted to avoid unnecessary reading and reduce the possible simultaneous writing and reading time. > src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 387: > >> 385: } >> 386: >> 387: try (OutputStream output = Files.newOutputStream(PROPS_PATH)) { > > Note that this stream is un-buffered (slow) > https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Files.html#newOutputStream(java.nio.file.Path,java.nio.file.OpenOption...) > Maybe doesn't matter given how small the file is. Moved to newBufferedWriter/Readed > src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 43: > >> 41: >> 42: #define EXCEPTION_CHECK_DESCRIBE_CLEAR() if ((*env)->ExceptionCheck(env)) { \ >> 43: (*env)->ExceptionDescribe(env); \ > > Describe already clears the exception > https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#exceptiondescribe Updated. > src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 375: > >> 373: DEBUG_SCREENCAST("@@@ using screen %i\n", index); >> 374: if (index >= screenSpace.screenCount) { >> 375: DEBUG_SCREENCAST("? Wrong index for screen\n", NULL); > > I've seen this "! in a triangle" symbol in a quite a few places in the DEBUG messages. > Looks like you got some non-ascii char in there. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1211860159 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1211860753 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1211727223 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1211865131 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1211864955 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1211866052 From gziemski at openjdk.org Wed May 31 15:31:12 2023 From: gziemski at openjdk.org (Gerard Ziemski) Date: Wed, 31 May 2023 15:31:12 GMT Subject: RFR: 8308341: JNI_GetCreatedJavaVMs returns a partially initialized JVM [v2] In-Reply-To: References: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> Message-ID: On Tue, 30 May 2023 14:39:21 GMT, Gerard Ziemski wrote: >>> I have one question though: why wouldn't it be enough to move `vm_created = 1` from where we had it before, down to where we now have `vm_created = COMPLETE` ? >> >> Because we need to prevent two threads from concurrently loading and initializing a VM in the same process. > >> > I have one question though: why wouldn't it be enough to move `vm_created = 1` from where we had it before, down to where we now have `vm_created = COMPLETE` ? >> >> Because we need to prevent two threads from concurrently loading and initializing a VM in the same process. > > Wouldn't it be less complex to use a lock or some "init once" mechanism (pthread_once) instead of a 3 stage atomic field? Do we really need to know whether the process is in the middle of initialization for any reason other than whether it's actually done? > > Just to clarify - I'm OK with the fix you have proposed, I was just curious if you considered any other alternatives. >> Thanks for the review @gerard-ziemski >> >> > Just to clarify - I'm OK with the fix you have proposed, I was just curious if you considered any other alternatives. >> >> Atomics are the simplest cross-platform solution available at this stage of VM init (which is "nothing is initialized yet") - even >Atomic use is limited to Atomic::xchg as we can't require any stubs. We have no VM locks available and anything external to the >VM (like pthread_once) would require as OS-specific solution in shared code. I guess it's a compromise either way. You have chosen to use an OS independent mechanism, at the cost of exposing the implementation to the outside world, by introducing a new stage (needs CSR). I think, I would have prefer (with what I know at this time) with keeping the implementation details hidden from outside (no need for CSR), at the cost of using platform dependent locks here, or some sort of initialize once mechanism. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14139#issuecomment-1570451028 From jlahoda at openjdk.org Wed May 31 18:16:00 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 31 May 2023 18:16:00 GMT Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v3] In-Reply-To: References: Message-ID: On Tue, 30 May 2023 22:16:08 GMT, Joe Darcy wrote: >> Time to get JDK 22 underway... > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: > > - Merge branch 'master' into JDK-8306584 > - Merge branch 'master' into JDK-8306584 > - Merge branch 'master' into JDK-8306584 > - Sync in symbol changes for JDK 21 build 24. > - Merge branch 'master' into JDK-8306584 > - Merge branch 'master' into JDK-8306584 > - Merge branch 'master' into JDK-8306584 > - Minor test fixes. > - Merge branch 'master' into JDK-8306584 > - Update symbol files to JDK 21 b23. > - ... and 14 more: https://git.openjdk.org/jdk/compare/cb40db05...376dbe26 javac and symbol related changes seem reasonable to me. Two minor comments added for consideration. src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java line 127: > 125: V64(64, 0), // JDK 20 > 126: V65(65, 0), // JDK 21 > 127: V66(66, 0); // JDK 22 A very small nit/suggestion - it should be possible to do: V66(66, 0), //JDK 22 ; (i.e. ending the enum constant with `,`, and putting the semicolon on a new line.) This way adding a new constant would mean just one line addition, no modification. (The same could be done for other enums.) test/langtools/tools/javac/versions/Versions.java line 93: > 91: TWENTY(false, "64.0", "20", Versions::checksrc20), > 92: TWENTY_ONE(false,"65.0", "21", Versions::checksrc21), > 93: TWENTY_TWO(false,"66.0", "22", Versions::checksrc21); Should there be `checksrc22` instead of `checksrc21`? Or is that done later? ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13567#pullrequestreview-1453854784 PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1212101629 PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1212114188 From prr at openjdk.org Wed May 31 20:22:14 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 31 May 2023 20:22:14 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v9] In-Reply-To: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> References: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> Message-ID: On Wed, 31 May 2023 15:03:04 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with four additional commits since the last revision: > > - improve retVal processing > - address token storage comments > - removing non-ascii > - EXCEPTION_CHECK_DESCRIBE_CLEAR -> EXCEPTION_CHECK_DESCRIBE I'm getting pretty consistent testing results now - meaning the ones that have known issues are the ones that fail, and I've looked at the code sufficiently. The restore token seems to be behaving properly now. I did have one case I've not understood where a test system got very confused about the display resolution of the monitor and needed a full power cycle. I don't know if a specific test caused that or it was something else, but it isn't repeatable (at least not yet) so shouldn't block integration. I am quite sure that SOME of the test failures are unstable tests that we've been lucky with all these years and xwayland is now showing up the instability. Things un-related to robot and more about timing for the most part. Although there's one test that seriously over-stresses robot with > 10,000 calls in a loop to getPixelColor() I'll see if I can push test update fixes to at least some of these to reduce noise. But I'm OK to approve now. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13803#pullrequestreview-1454093265 From prr at openjdk.org Wed May 31 20:28:18 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 31 May 2023 20:28:18 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: Message-ID: On Fri, 26 May 2023 08:31:46 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Some of those are in shared codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > > JoKern65 has updated the pull request incrementally with one additional commit since the last revision: > > forgotton _ I am Ok with the client-libs changes here. I did not look at anything else. So you'll need more approvals before its ready to push. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14146#pullrequestreview-1454101589 From darcy at openjdk.org Wed May 31 20:39:44 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 31 May 2023 20:39:44 GMT Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v4] In-Reply-To: References: Message-ID: <2vhEXa4W2A-VkPRaEyqaidm2tKuWdhqvJOA2mgvvC4g=.0a0a7ffa-1e26-45b0-838c-865bb02a2b82@github.com> > Time to get JDK 22 underway... Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: - Respond to review comments. - Merge branch 'master' into JDK-8306584 - Merge branch 'master' into JDK-8306584 - Merge branch 'master' into JDK-8306584 - Merge branch 'master' into JDK-8306584 - Sync in symbol changes for JDK 21 build 24. - Merge branch 'master' into JDK-8306584 - Merge branch 'master' into JDK-8306584 - Merge branch 'master' into JDK-8306584 - Minor test fixes. - ... and 16 more: https://git.openjdk.org/jdk/compare/12649025...7b446793 ------------- Changes: https://git.openjdk.org/jdk/pull/13567/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13567&range=03 Stats: 5843 lines in 69 files changed: 5789 ins; 0 del; 54 mod Patch: https://git.openjdk.org/jdk/pull/13567.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13567/head:pull/13567 PR: https://git.openjdk.org/jdk/pull/13567 From darcy at openjdk.org Wed May 31 20:41:13 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 31 May 2023 20:41:13 GMT Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v3] In-Reply-To: References: Message-ID: On Wed, 31 May 2023 18:02:09 GMT, Jan Lahoda wrote: >> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: >> >> - Merge branch 'master' into JDK-8306584 >> - Merge branch 'master' into JDK-8306584 >> - Merge branch 'master' into JDK-8306584 >> - Sync in symbol changes for JDK 21 build 24. >> - Merge branch 'master' into JDK-8306584 >> - Merge branch 'master' into JDK-8306584 >> - Merge branch 'master' into JDK-8306584 >> - Minor test fixes. >> - Merge branch 'master' into JDK-8306584 >> - Update symbol files to JDK 21 b23. >> - ... and 14 more: https://git.openjdk.org/jdk/compare/cb40db05...376dbe26 > > src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java line 127: > >> 125: V64(64, 0), // JDK 20 >> 126: V65(65, 0), // JDK 21 >> 127: V66(66, 0); // JDK 22 > > A very small nit/suggestion - it should be possible to do: > > V66(66, 0), //JDK 22 > ; > > > (i.e. ending the enum constant with `,`, and putting the semicolon on a new line.) This way adding a new constant would mean just one line addition, no modification. (The same could be done for other enums.) Updated. > test/langtools/tools/javac/versions/Versions.java line 93: > >> 91: TWENTY(false, "64.0", "20", Versions::checksrc20), >> 92: TWENTY_ONE(false,"65.0", "21", Versions::checksrc21), >> 93: TWENTY_TWO(false,"66.0", "22", Versions::checksrc21); > > Should there be `checksrc22` instead of `checksrc21`? Or is that done later? Good catch. I have a refactoring of the test planned which will eliminate the explicit "checksrc$N" methods. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1212284124 PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1212283880 From aturbanov at openjdk.org Wed May 31 20:56:21 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 31 May 2023 20:56:21 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v9] In-Reply-To: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> References: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> Message-ID: On Wed, 31 May 2023 15:03:04 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with four additional commits since the last revision: > > - improve retVal processing > - address token storage comments > - removing non-ascii > - EXCEPTION_CHECK_DESCRIBE_CLEAR -> EXCEPTION_CHECK_DESCRIBE make/modules/java.desktop/lib/Awt2dLibraries.gmk line 195: > 193: > 194: LIBPIPEWIRE_HEADER_DIRS := \ > 195: $(TOPDIR)/src/$(MODULE)/unix/native/libpipewire/include Are you sure Tab should be used here? in all other places of this file spaces are used for indentation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1212298738 From aturbanov at openjdk.org Wed May 31 21:09:15 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 31 May 2023 21:09:15 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v9] In-Reply-To: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> References: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> Message-ID: <49V03ZEKWKUCrE9mQixXApM_Kij9pdTKY-Uu2NLW3N8=.cfe72533-5cce-4470-9322-801a93ad99e0@github.com> On Wed, 31 May 2023 15:03:04 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with four additional commits since the last revision: > > - improve retVal processing > - address token storage comments > - removing non-ascii > - EXCEPTION_CHECK_DESCRIBE_CLEAR -> EXCEPTION_CHECK_DESCRIBE src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 303: > 301: > 302: Set> entries; > 303: synchronized (PROPS) { I'm not sure I understand purpose of this `synchronized` block. `entrySet()` returns _view_ of Properties entries, not a copy. It means concurrent thread could modify content of `PROPS` when we do `stream()` below. >From my opinion either we need to perform all work inside `synchronized` to be sure that no concurrent modification are possible. Or just remove `synchronized` (`Properties` is a thread safe class) and _be ready_ of possible concurrent updates ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1212313046 From aturbanov at openjdk.org Wed May 31 21:18:15 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 31 May 2023 21:18:15 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v9] In-Reply-To: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> References: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> Message-ID: On Wed, 31 May 2023 15:03:04 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with four additional commits since the last revision: > > - improve retVal processing > - address token storage comments > - removing non-ascii > - EXCEPTION_CHECK_DESCRIBE_CLEAR -> EXCEPTION_CHECK_DESCRIBE src/java.desktop/unix/classes/sun/awt/screencast/TokenItem.java line 111: > 109: > 110: public static TokenItem parse(String token, Object input) { > 111: if (token == null || input == null) return null; Do we need this `null` checks? Currently only non-null values are passed to this method ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1212323291 From aturbanov at openjdk.org Wed May 31 21:24:12 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 31 May 2023 21:24:12 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v9] In-Reply-To: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> References: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> Message-ID: On Wed, 31 May 2023 15:03:04 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with four additional commits since the last revision: > > - improve retVal processing > - address token storage comments > - removing non-ascii > - EXCEPTION_CHECK_DESCRIBE_CLEAR -> EXCEPTION_CHECK_DESCRIBE src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 307: > 305: } > 306: > 307: Set malformed = new LinkedHashSet<>(); Can we use plain HashSet here? Seems there is not much reason to save original order of tokens. src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 320: > 318: return tokenItem; > 319: }) > 320: .filter(obj -> !Objects.isNull(obj)) `Objects.isNull` wasn't supposed to be used like this. Let's either inline it and use `!= null` or use method reference `.filter(Objects::nonNull)` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1212328710 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1212326672 From aturbanov at openjdk.org Wed May 31 21:38:12 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 31 May 2023 21:38:12 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v9] In-Reply-To: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> References: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> Message-ID: On Wed, 31 May 2023 15:03:04 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with four additional commits since the last revision: > > - improve retVal processing > - address token storage comments > - removing non-ascii > - EXCEPTION_CHECK_DESCRIBE_CLEAR -> EXCEPTION_CHECK_DESCRIBE src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 346: > 344: rectangle.height > 345: )) > 346: .collect(Collectors.toCollection(ArrayList::new)); why not plain toList() collector? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1212340873 From prr at openjdk.org Wed May 31 22:35:15 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 31 May 2023 22:35:15 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v9] In-Reply-To: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> References: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> Message-ID: <-FJMSrpWiLdsZ902c4-dmdU6CxJecnoHtUhqJmtKlf4=.b60c9934-62d3-49ad-b96f-39190b6a89e3@github.com> On Wed, 31 May 2023 15:03:04 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with four additional commits since the last revision: > > - improve retVal processing > - address token storage comments > - removing non-ascii > - EXCEPTION_CHECK_DESCRIBE_CLEAR -> EXCEPTION_CHECK_DESCRIBE I spoke too soon :-( I remembered about an odd result from last week and it seems that whenever I have a full screen window capture fails - at least on my system and I think one lab system. See test and output below from a fully patched Ubuntu 22.04.02 system import java.awt.Frame; import java.awt.GraphicsDevice; import java.awt.Rectangle; import java.awt.Robot; public class FSW { public static void main(String args[]) throws Exception { Robot robot = new Robot(); Frame frame = new Frame("FSW"); GraphicsDevice gd = frame.getGraphicsConfiguration().getDevice(); try { gd.setFullScreenWindow(frame); robot.delay(5000); robot.createScreenCapture(new Rectangle(50, 50, 10, 10)); } finally { gd.setFullScreenWindow(null); frame.dispose(); } } } % java FSW cropTo:163 Unexpected stride / 4: 0 srcW: 1920 and the capture fails every time. And again with debugging turned on ScreencastWatcher: started // getRGBPixels affectedScreenBounds [java.awt.Rectangle[x=0,y=0,width=1920,height=1200]] // getTokens exact matches 1. [Token: 41dc61fb-279b-4069-b408-30873451fb03 java.awt.Rectangle[x=0,y=0,width=1920,height=1200] ] // getTokens same sizes 2. [Token: 41dc61fb-279b-4069-b408-30873451fb03 java.awt.Rectangle[x=0,y=0,width=1920,height=1200] ] // storeToken old: |41dc61fb-279b-4069-b408-30873451fb03| new |41dc61fb-279b-4069-b408-30873451fb03| allowed bounds [0, 0, 1920, 1200] // Storing TokenItem: Token: 41dc61fb-279b-4069-b408-30873451fb03 java.awt.Rectangle[x=0,y=0,width=1920,height=1200] initXdgDesktopPortal:236 connection/sender name :1.525 / 1_525 checkVersion:190 ScreenCast protocol version 4 Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl:833 taking screenshot at x: 50 y 50 w 10 h 10 with token |41dc61fb-279b-4069-b408-30873451fb03| initXdgDesktopPortal:236 connection/sender name :1.525 / 1_525 checkVersion:190 ScreenCast protocol version 4 callbackScreenCastStart:611 available screen count 1 rebuildScreenData:87 ==== screenId#35 rebuildScreenData:132 ----------------------- rebuildScreenData:133 screenId#35 || bounds x 0 y 0 w 1920 h 1200 || capture area x 0 y 0 w 0 h 0 shouldCapture 0 rebuildScreenData:134 #---------------------# callbackScreenCastStart:617 rebuildScreenData result |0| callbackScreenCastStart:630 restore_token |41dc61fb-279b-4069-b408-30873451fb03| storeRestoreToken:653 saving token, old: |41dc61fb-279b-4069-b408-30873451fb03| > new: |41dc61fb-279b-4069-b408-30873451fb03| portalScreenCastStart:709 ScreenCastStartResult |0| getPipewireFd:886 portalScreenCastStart result |0| checkCanCaptureAllRequiredScreens:847 Found allowed screen bounds in affected screen bounds 0 0 1920 1200 getPipewireFd:900 --- portalScreenCastStart getPipewireFd:907 pwFd 17 doLoop:557 screenId#35[loc(0,0) size(1920x1200)] @@@ adding screen 0 checkScreen:472 screenId#35 || bounds x 0 y 0 w 1920 h 1200 || capture area x 50 y 50 w 10 h 10 shouldCapture 1 connectStream:373 @@@ using screen 0 connectStream:411 screenId#35 || bounds x 0 y 0 w 1920 h 1200 || capture area x 50 y 50 w 10 h 10 shouldCapture 1 startStream:355 screenId#35: stream connecting 0x7f04548e3600 onStreamStateChanged:303 screenId#35[loc(0,0) size(1920x1200)] state 0 (unconnected) -> 1 (connecting) err (null) onStreamStateChanged:303 screenId#35[loc(0,0) size(1920x1200)] state 1 (connecting) -> 2 (paused) err (null) onStreamParamChanged:197 screenId#35[loc(0,0) size(1920x1200)] param event id 4 onStreamParamChanged:218 screenId#35[loc(0,0) size(1920x1200)] stream format: Spa:Enum:VideoFormat:BGRx (8) 1920x1200 connectStream:424 screenId#35[loc(0,0) size(1920x1200)] frame size: 1920x1200 doLoop:563 screenId#35[loc(0,0) size(1920x1200)] @@@ screen processed 0 onStreamStateChanged:303 screenId#35[loc(0,0) size(1920x1200)] state 2 (paused) -> 3 (streaming) err (null) onStreamProcess:236 screenId#35[loc(0,0) size(1920x1200)] hasFormat 1 captureDataReady 0 shouldCapture 1 onStreamProcess:271 screenId#35 || bounds x 0 y 0 w 1920 h 1200 || capture area x 50 y 50 w 10 h 10 shouldCapture 1 onStreamProcess:272 screenId#35[loc(0,0) size(1920x1200)] got a frame of size 0 offset 0 stride 0 flags 0 FD 31 captureDataReady 0 onStreamProcess:292 screenId#35[loc(0,0) size(1920x1200)] data ready Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl:856 all data ready Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl:864 screenId#35[loc(0,0) size(1920x1200)] @@@ copying screen data 0, captureData 0x7f03d40042a0 || x 50 y 50 w 10 h 10 requested area || x 0 y 0 w 1920 h 1200 screen bound || x 50 y 50 w 10 h 10 in-screen coords capture area onStreamParamChanged:197 screenId#35[loc(0,0) size(1920x1200)] param event id 4 onStreamStateChanged:303 screenId#35[loc(0,0) size(1920x1200)] state 3 (streaming) -> 2 (paused) err (null) onStreamStateChanged:303 screenId#35[loc(0,0) size(1920x1200)] state 2 (paused) -> 0 (unconnected) err (null) doCleanup:109 STOPPING loop ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1571048110 From dholmes at openjdk.org Wed May 31 23:05:19 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 31 May 2023 23:05:19 GMT Subject: RFR: 8308341: JNI_GetCreatedJavaVMs returns a partially initialized JVM [v2] In-Reply-To: References: <70EdOsdu-XZJwsuEg2Paw_AztjzAlaxJnJ1KX7QOh_s=.a55430d0-ce46-40e5-92e4-23f305006d01@github.com> Message-ID: On Wed, 31 May 2023 15:27:51 GMT, Gerard Ziemski wrote: > You have chosen to use an OS independent mechanism, at the cost of exposing the implementation to the outside world, by introducing a new stage (needs CSR). That is not an accurate characterisation of this change. The CSR request is needed because of the change in behaviour it introduces (by only returning a fully initialized VM), and has nothing at all to do with the implementation. We still need to be able to distinguish when VM creation has started (to prevent concurrent attempt) and when it has completed (so GetCreatedJavaVMs can return a valid VM) - the mechanism by which that is achieved is immaterial. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14139#issuecomment-1571075022